Share via

Bewährte Methoden für die Sicherheit von Dynamics 365 Customer Engagement (on-premises)

  • Artikel

Internet Information Services (IIS) ist ein ausgereifter Webdienst, der in Windows Server enthalten ist. Dynamics 365 Customer Engagement (on-premises) hängt von einem effizienten und sicheren IIS-Webdienst ab. Beachten Sie Folgendes:

  • In den Konfigurationsdateien machine.config und web.config können Sie festlegen, ob das Debuggen aktiviert werden soll und ob ausführliche Fehlermeldungen an den Client gesendet werden sollen. Stellen Sie sicher, dass das Debuggen auf allen Produktionsservern deaktiviert ist und im Fall von Problemen eine allgemeine Fehlermeldung an den Client gesendet wird. Dadurch wird verhindert, dass unnötige Informationen zur Konfiguration des Webservers an den Client gesendet werden.

  • Stellen Sie sicher, dass die neuesten IIS-Service Packs und Updates für das Betriebssystem installiert sind. Aktuelle Informationen finden Sie auf der Microsoft Security-Website.

  • Dynamics 365 Server Setup erstellt Anwendungspools mit den Namen CRMAppPool und CRMDeploymentServiceAppPool, die mit Benutzeranmeldeinformationen arbeiten, die Sie bei der Einrichtung angeben. Um ein Modell mit geringsten Rechten zu ermöglichen, wird empfohlen, separate Domänenbenutzerkonten für diese Anwendungspools anzugeben und nicht das Netzwerkdienstkonto zu verwenden. Es wird außerdem empfohlen, keine andere ASP.NET-Anwendung unter diesen Anwendungspools zu installieren. Informationen zu den für diese Komponenten erforderlichen Mindestberechtigungen finden Sie unter Mindestberechtigungen für Microsoft Dynamics 365-Setup und -Dienste.

Wichtig

  • Achten Sie darauf, dass alle Websites, die auf dem gleichen Computer wie die Dynamics 365 Customer Engagement (on-premises)-Website ausgeführt werden, ebenfalls über Zugriff auf die Customer Engagement-Datenbank verfügen.
  • Bei Verwendung eines Domänenbenutzerkontos müssen Sie vor der Ausführung von Microsoft Dynamics 365 Server-Setup überprüfen, ob der Dienstprinzipalname (Service Principal Name, SPN) für das Konto richtig festgelegt ist, und gegebenenfalls den richtigen Dienstprinzipalnamen festlegen. Weitere Informationen zu Dienstprinzipalnamen und deren Festlegung finden Sie unter Verwenden von Dienstprinzipalnamen bei der Konfiguration von Webanwendungen, die in IIS gehostet werden (möglicherweise in englischer Sprache).

Verwaltung von Dienstprinzipalnamen in Microsoft Dynamics 365

Beim Attribut des Dienstprinzipalnamens (SPN) handelt es sich um ein nicht verknüpftes Attribut mit mehreren Werten, das aus dem DNS-Hostnamen erstellt wird. Der SPN wird bei der gegenseitigen Authentifizierung zwischen dem Client und dem Server, der einen bestimmten Dienst hostet, verwendet. Vom Client wird ein Computerkonto basierend auf dem SPN des Diensts gesucht, zu dem eine Verbindung hergestellt werden soll.

Vom Dynamics 365 Server-Installationsdienst werden rollenspezifische Dienste und Webanwendungspools bereitgestellt, die mit den bei der Einrichtung angegebenen Benutzeranmeldeinformationen ausgeführt werden. Die vollständige Liste dieser Rollen und ihrer Berechtigungsanforderungen können Sie unter Für Microsoft Dynamics 365-Setup und -Dienste erforderliche Mindestberechtigungen überprüfen.

Bei der Bereitstellung einer gehosteten Dynamics 365 Customer Engagement (on-premises)-Infrastruktur erfordern zwei dieser Rollen möglicherweise zusätzliche Überlegungen:

  • Bereitstellungswebdienst

  • Anwendungsdienst

In einem Webfarmszenario, beispielsweise bei einer gehosteten Bereitstellung, wird empfohlen, die Kernelmodusauthentifizierung aktiviert zu lassen. Darüber hinaus sollten Sie aus folgenden Gründen die Verwendung separater Domänenbenutzerkonten zur Ausführung dieser Dienste in Betracht ziehen:

  • Durch zwei separate Dienstkonten für diese Serverrollen wird die Implementierung des Hardwarelastenausgleichs erleichtert.

  • Für die Deployment Web Service-Serverrolle sind erhöhte Rechte zum Bereitstellen von Organisationen in der Customer Engagement-Datenbank erforderlich. Wenn Sie ein Modell mit geringsten Rechten bereitstellen möchten, besteht der sicherste Ansatz für die Implementierung von Serverprinzipalnamen in einer gehosteten Dynamics 365 Customer Engagement (on-premises)-Infrastruktur in der Ausführung des Bereitstellungswebdienstes unter einem anderen Domänenbenutzerkonto als der Anwendungsdienst.

Wenn Sie diesem Vorschlag folgen, separate Domänenkonten für diese Server-Rollen zu verwenden, sollten Sie überprüfen, ob die SPN für jedes Konto korrekt ist, bevor Sie Dynamics 365 Server Setup starten. Dadurch ist es einfacher, ggf. den richtigen SPN festzulegen.

Ist die Kernelmodusauthentifizierung aktiviert, werden die Serverprinzipalnamen für das Computerkonto unabhängig vom angegebenen Dienstkonto festgelegt. Beim Implementieren einer Webfarm aktivieren Sie Kernelmodusauthentifizierung und ändern Sie die lokale Datei ApplicationHost.config.

Werden der Anwendungs- und der Bereitstellungswebdienst bei deaktivierter Kernelmodusauthentifizierung im selben System ausgeführt, können Sie beide Dienste zur Ausführung unter demselben Domänenbenutzerkonto konfigurieren, um Probleme mit doppelten Serverprinzipalnamen zu vermeiden. Kann die Kernelmodusauthentifizierung nicht aktiviert werden, installieren Sie Anwendungs- und Bereitstellungswebdienst auf unterschiedlichen Systemen. Die Serverprinzipalnamen müssen möglicherweise trotzdem manuell erstellt werden, da die Kernelmodusauthentifizierung deaktiviert ist.

Siehe auch

Sicherheitsüberlegungen für Microsoft Dynamics 365
Bewährte Methoden für die Microsoft Dynamics 365-Administration