Emplacement de création d’un point de connexion de service

Lorsqu’un instance de services de domaine Active Directory est installé, le programme d’installation du service crée des objets de point de connexion de service (SCP) dans services de domaine Active Directory. L’objectif principal doit être de réduire le trafic de réplication et de permettre une administration et une maintenance efficaces des objets.

N’oubliez pas que les applications clientes recherchent des SSP en recherchant des mots clés dans le répertoire. L’attribut mots clés d’un SCP est inclus dans le catalogue global ; les clients peuvent effectuer une recherche dans le catalogue global pour trouver des SSP dans la forêt. Pour cette raison, le client n’influence pas l’emplacement de publication des SSP.

Réduire le trafic de réplication

Pour réduire le trafic de réplication, créez des SSP dans la partition de domaine du domaine de l’ordinateur hôte du service. Par exemple, vous pouvez créer des SSP en tant qu’objets enfants de l’objet ordinateur sur lequel le service est installé. Une partition de domaine de services de domaine Active Directory, parfois appelée contexte de nommage de domaine, contient des objets spécifiques au domaine, tels que les objets pour les utilisateurs et les ordinateurs du domaine. Une réplica complète de tous les objets de la partition de domaine est répliquée sur chaque contrôleur de domaine (DC) du domaine, mais elle n’est pas répliquée sur les contrôleurs de domaine d’autres domaines.

Ne créez pas de SSP dans la partition Configuration, également appelée contexte de nommage de configuration, car les modifications apportées à la partition Configuration sont répliquées sur chaque contrôleur de domaine de la forêt. Comme indiqué ci-dessus, les clients dans toute la forêt peuvent interroger le catalogue global pour trouver des SSP n’importe où dans la forêt, de sorte que la création de SSP dans la partition Configuration ne les rend pas plus visibles pour les clients ; elle génère uniquement plus de trafic de réplication.

Facilité d’administration

Tenez compte des instructions suivantes pour l’administration d’objets :

• Placez des objets spécifiques au service où les administrateurs peuvent contrôler l’accès à ceux-ci à l’aide d’autorisations d’accès héritées et de stratégie.
• Placez les objets là où un administrateur peut facilement les trouver.

Un bon emplacement par défaut qui répond aux deux objectifs consiste à créer scp et d’autres objets spécifiques au service sous l’objet ordinateur de l’ordinateur hôte de chaque instance de service. Pour plus d’informations, consultez Publication sous un objet ordinateur.

Une bonne alternative pour les services qui ne sont pas liés à un seul hôte consiste à créer un conteneur pour les objets de service sous le conteneur système dans une partition de domaine. Pour plus d’informations, consultez Publication dans un conteneur de système de domaine.

Le diagramme suivant montre une partie de la hiérarchie de conteneurs par défaut pour une partition de domaine.

Le diagramme montre la hiérarchie de domaine par défaut incluse avec services de domaine Active Directory. Toutefois, de nombreuses entreprises créent une hiérarchie de conteneurs d’unités d’organisation pour regrouper des classes d’objets, telles que des utilisateurs et des ordinateurs, à des fins d’administration. Les administrateurs peuvent ensuite appliquer des entrées de contrôle d’accès héritées et de stratégie à une unité d’organisation pour déléguer l’autorité d’administration pour les objets de l’unité d’organisation. Cela permet aux administrateurs de gérer efficacement une entreprise, mais cela a quelques conséquences pour les programmeurs de services :

• L’objet ordinateur d’un hôte de service peut ne pas se trouver sous le conteneur Ordinateurs, comme indiqué dans le diagramme. Pour plus d’informations sur la recherche de l’objet ordinateur pour l’ordinateur local, consultez Publication sous un objet ordinateur.
• Les administrateurs peuvent déplacer des objets à mesure que leurs besoins organisationnels changent. Cela signifie que vous ne pouvez pas dépendre de vos objets restant dans un emplacement fixe ; autrement dit, votre service ne peut pas dépendre d’un nom unique d’objet restant le même. Utilisez plutôt l’attribut objectGUID d’un objet, qui ne change pas si l’objet est déplacé ou renommé. Pour plus d’informations, ainsi qu’un exemple de code qui crée un SCP, stocke son objetGUID et récupère ultérieurement l’objetGUID pour le lier au SCP, consultez Création et maintenance d’un point de connexion de service.
• Toutes les classes d’objets standard liées au service, ainsi que toutes les sous-classes de ces classes, sont des enfants valides des classes ordinateur et organizationalUnit . Si vous étendez le schéma pour définir votre propre classe spécifique au service, assurez-vous que l’ordinateur et les classes organizationalUnit sont incluses dans les classes supérieures possibles.
• Le programme d’installation du service détermine l’emplacement par défaut pour la création de SSP. Vous pouvez autoriser l’administrateur qui installe le service à spécifier un autre chemin d’installation.

Les objets spécifiques au service ne doivent pas être créés dans les zones suivantes :

• Les services ne doivent pas publier d’objets directement dans les conteneurs Utilisateurs ou Ordinateurs d’une partition de domaine, ni créer de nouveaux conteneurs dans ces conteneurs. Toutefois, les services peuvent publier des objets en tant qu’objets enfants d’un objet ordinateur, que l’objet ordinateur soit stocké ou non dans le conteneur Ordinateurs.
• Les services, qui utilisent l’inscription et la résolution des sockets Windows (RnR) ou les API rpcn (RPC Name Service) pour se publier, créent les objets appropriés dans les conteneurs WinsockServices et RpcServices sous le conteneur système d’une partition de domaine. Ne créez pas explicitement d’objets dans ces conteneurs. Cela ne cause pas de préjudice direct, mais peut prêter à confusion pour les administrateurs.