Partager via

Bonnes pratiques de sécurité pour Dynamics 365 Customer Engagement (on-premises)

  • Article

Internet Information Services (IIS) est un service Web exigible inclus dans Windows Server. Dynamics 365 Customer Engagement (on-premises) dépend d’un service Web IIS efficace et sécurisé. Prenez en compte les éléments suivants :

  • Dans les fichiers de configuration machine.config et web.config, vous pouvez déterminer si le débogage est activé et si des messages d’erreur détaillés sont envoyés au client. Assurez-vous que le débogage est désactivé sur tous les serveurs de production et qu’un message d’erreur générique est envoyé au client en cas de problème. Vous évitez ainsi l’envoi inutile d’informations à propos de la configuration du serveur Web au client.

  • Vérifiez que les Service Packs et mises à jour les plus récents pour le système d’exploitation et IIS ont été appliqués. Pour obtenir les informations les plus récentes, consultez le site Web Microsoft Sécurité.

  • Le programme d’installation de Dynamics 365 Server crée des pools d’applications appelés CRMAppPool et CRMDeploymentServiceAppPool qui fonctionnent sous les informations d’identification spécifiées lors de l’installation. Pour faciliter un modèle à faibles privilèges, il est conseillé de spécifier des comptes d’utilisateur de domaine distincts pour ces pools d’applications plutôt que d’utiliser un compte Service réseau. Par ailleurs, il est recommandé de ne pas installer d’autres applications ASP.NET sous ces pools d’applications. Pour des informations sur les autorisations minimales requises pour ces composants, voir Autorisations minimales requises pour le programme d’installation, les services et composants Microsoft Dynamics 365.

Important

  • Assurez-vous que tous les sites Web qui s’exécutent sur le même ordinateur que le site Web Dynamics 365 Customer Engagement (on-premises) ont également accès à la base de données Customer Engagement.
  • Si vous utilisez un compte d’utilisateur de domaine, avant d’exécuter le programme d’installation de Microsoft Dynamics 365 Server, vous devrez peut-être vérifier que le nom de principal du service (SPN) est correctement défini pour ce compte, et si nécessaire, définir le SPN correct. Pour plus d’informations sur les noms de principal du service et leur définition, consultez la page Utilisation des SPN lors de la configuration des applications Web hébergées sur IIS (éventuellement en anglais).

Gestion des noms de principal du service dans Microsoft Dynamics 365

L’attribut de nom de principal du service (SPN) est un attribut à plusieurs valeurs non lié qui est créé à partir du nom d’hôte DNS. Le nom de principal du service est utilisé pendant l’authentification mutuelle entre le client et le serveur hébergeant un service spécifique. Le client recherche un compte d’ordinateur basé sur le SPN du service auquel il tente de se connecter.

Le programme d’installation de Dynamics 365 Server déploie des services propres au rôle et des pools d’applications Web qui fonctionnent avec les informations d’identification utilisateur spécifiées lors de l’installation. Pour examiner la liste complète de ces rôles et les autorisations requises, consultez Autorisations minimales requises pour le programme d’installation, les services et composants Microsoft Dynamics 365.

Lorsque déployez une infrastructure Dynamics 365 Customer Engagement (on-premises) hébergée, deux de ces rôles peuvent demander une attention particulière :

  • Service Web de déploiement

  • Service d’application

Dans des scénarios de batterie de serveurs Web, comme dans le cas d’une offre hébergée, il est recommandé de conserver l’authentification du mode noyau activée. En outre, vous devez envisager l’utilisation de comptes d’utilisateurs de domaine distincts pour exécuter ces services pour les raisons suivantes :

  • L’utilisation de comptes de service distincts pour ces rôles serveur facilite l’implémentation de l’équilibrage de charge matérielle.

  • Le rôle serveur Service Web de déploiement nécessite l’élévation des autorisations pour mettre en service les organisations de la base de données Customer Engagement. Si vous souhaitez choisir un modèle avec moins de privilèges, la solution la plus sûre pour implémenter les SPN dans une infrastructure Dynamics 365 Customer Engagement (on-premises) hébergée implique l’exécution du service Web de déploiement sous un compte d’utilisateur de domaine différent du service d’application.

Si vous décidez d’utiliser des comptes de domaine distincts pour ces rôles serveur, vous devez vérifier que le SPN est correct pour chaque compte avant de démarrer le programme d’installation de Dynamics 365 Server. Ainsi, la définition du SPN correct sera plus simple.

Si l’authentification du mode noyau est activée, les SPN seront définis pour le compte de l’ordinateur, indépendamment du compte de service spécifié. Lorsque vous implémentez une batterie de serveurs Web, activez l’authentification du mode noyau et modifiez le fichier ApplicationHost.config local.

Si les services Web de déploiement et d’applications sont exécutés sur le même système et si l’authentification du mode noyau est désactivée, vous pouvez configurer les deux services afin qu’ils s’exécutent sous le même compte d’utilisateur de domaine pour empêcher les problèmes de SPN en double. Si vous ne pouvez pas activer l’authentification du mode noyau, installez les services Web de déploiement et d’applications sur des systèmes distincts. Les SPN devront peut-être être créés manuellement dans la mesure où l’authentification du mode noyau est désactivée.

Voir aussi

Considérations relatives à la sécurité pour Microsoft Dynamics 365
Meilleures pratiques d’administration de Microsoft Dynamics 365