Utilisation de DsAddSidHistory

La fonction DsAddSidHistory obtient le SID (identificateur de sécurité) de compte principal d'un principal de sécurité dans un domaine (source) et l’ajoute à l’attribut sIDHistory d’un principal de sécurité dans un autre domaine (destination), dans une autre forêt. Lorsque le domaine source est en mode natif Windows 2000, cette fonction récupère également les valeurs sIDHistory du principal source et les ajoute au sIDHistory du principal de destination.

L’ajout de SID au sIDHistory d'un principal de sécurité est une opération affectant la sécurité qui accorde efficacement au principal de destination l'accès à toutes les ressources accessibles au principal source, à condition qu'il existe des approbations entre les domaines de ressources applicables et le domaine de destination.

Dans un domaine en mode natif Windows 2000, l'ouverture d'une session utilisateur se traduit par la création d'un jeton d’accès qui contient le SID du compte principal de l’utilisateur et les SID des groupes, ainsi que le sIDHistory de l'utilisateur et le sIDHistory des groupes dont il est membre. La présence de ces anciens SID (valeurs sIDHistory) dans le jeton de l’utilisateur accorde à celui-ci l’accès aux ressources protégées par des listes de contrôle d’accès (ACL) contenant les anciens SID.

Cette opération facilite certains scénarios de déploiement de Windows 2000. En particulier, elle prend en charge un scénario dans lequel des comptes appartenant à une nouvelle forêt Windows 2000 sont créés pour des utilisateurs et des groupes qui existent déjà dans un environnement de production Windows NT 4.0. En plaçant le SID du compte Windows NT 4.0 dans le sIDHistory du compte Windows 2000, l’utilisateur qui se connecte à son nouveau compte Windows 2000 conserve son accès aux ressources réseau.

DsAddSidHistory prend également en charge la migration de serveurs de ressources de contrôleurs de domaine secondaire (BDC) sous Windows NT 4.0 (ou de contrôleurs de domaine et de serveurs membres d'un domaine Windows 2000 en mode natif) vers un domaine Windows 2000 en tant que serveurs membres. Cette migration nécessite la création, dans le domaine Windows 2000 de destination, de groupes locaux de domaine qui contiennent, dans leur sIDHistory, les identificateurs de sécurité principaux des groupes locaux définis dans le BDC (ou les groupes locaux de domaine référencés dans des listes de contrôle d'accès (ACL) sur les serveurs Windows 2000) dans le domaine source. En créant un groupe local de destination contenant le sIDHistory et tous les membres du groupe local source, l’accès aux ressources du serveur migré, protégé par des ACL référençant le groupe local source, est conservé pour tous les membres.

Remarque

L’utilisation de DsAddSidHistory nécessite une compréhension de ses implications plus larges en matière d'administration et de sécurité, aussi bien dans ces scénarios que dans d'autres. Pour plus d’informations, consultez le livre blanc « Planification de la migration de Windows NT vers Microsoft Windows 2000 », dans le fichier Dommig.doc des outils de support de Windows 2000. Cette documentation se trouve également sur le CD du produit sous \support\tools.

Exigences relatives aux autorisations

DsAddSidHistory nécessite des privilèges d’administrateur dans les domaines source et de destination. Plus précisément, l’appelant de cette API doit être membre du groupe des Administrateurs de domaine du domaine de destination. Une vérification codée en dur est réalisée pour cette appartenance. De plus, le compte fourni dans le paramètre SrcDomainCreds doit être membre des Administrateurs ou du groupe des Administrateurs de domaine du domaine source. Si NULL est transmis dans SrcDomainCreds, l’appelant de l’API doit être membre des Administrateurs ou du groupe des Administrateurs de domaine du domaine source.

Exigences relatives au domaine et aux approbations

DsAddSidHistory exige que le domaine de destination soit en mode natif Windows 2000 (ou version ultérieure), car seul ce type de domaine prend en charge l’attribut sIDHistory. Le domaine source peut être sous Windows NT 4.0 ou Windows 2000, en mode mixte ou natif. Les domaines source et de destination ne doivent pas se trouver dans la même forêt. Par définition, les domaines Windows NT 4.0 ne sont pas dans une forêt. Cette contrainte inter-forêts garantit que les SID dupliqués, qu'il s'agisse de SID principaux ou de valeurs sIDHistory, ne sont pas créés dans une même forêt.

Dans les cas répertoriés au tableau suivant, DsAddSidHistory nécessite une approbation externe du domaine source vers le domaine de destination.

Cas	Description
Le domaine source est Windows 2000.	L'attribut sIDHistory source, disponible uniquement dans les domaines source Windows 2000, peut être lu uniquement à l'aide de LDAP, qui requiert cette approbation pour la protection de l’intégrité.
Le domaine source est Windows NT 4.0, et la valeur de SrcDomainCreds est NULL.	L’emprunt d’identité, qui est requis pour prendre en charge les opérations du domaine source à partir des informations d’identification de l’appelant, dépend de cette approbation. L’emprunt d’identité nécessite également que le contrôleur de domaine de destination ait l'option « Approuvé pour la délégation » activée par défaut sur les contrôleurs de domaine.

Toutefois, aucune approbation n'est requise entre les domaines source et de destination si le domaine source est Windows NT 4.0 et la valeur de SrcDomainCreds n’est pas NULL.

Exigences relatives au contrôleur de domaine source

DsAddSidHistory exige que le contrôleur de domaine, sélectionné comme cible pour les opérations dans le domaine source, soit le contrôleur de domaine principal dans les domaines Windows NT 4.0 ou l’émulateur de contrôleur de domaine principal dans les domaines Windows 2000. L’audit du domaine source est généré par le biais d’opérations d’écriture, c'est pourquoi le contrôleur de domaine principal est requis dans les domaines source Windows NT 4.0, et la restriction au seul contrôleur de domaine principal veille à ce que les audits DsAddSidHistory soient générés sur un seul ordinateur. Cela réduit le besoin d’examiner les journaux d’audit de tous les contrôleurs de domaine pour surveiller l’utilisation de cette opération.

Remarque

Dans les domaines source Windows NT 4.0, le contrôleur de domaine principal (cible des opérations dans le domaine source) doit exécuter le Service Pack 4 (SP4) ou une version ultérieure pour pouvoir assurer correctement la prise en charge de l’audit.

La valeur de registre suivante doit être créée en tant que valeur REG_DWORD et configurée sur 1 au niveau du contrôleur de domaine source, aussi bien sous Windows NT 4.0 que Windows 2000.

HKEY_LOCAL_MACHINE
   System
      CurrentControlSet
         Control
            Lsa
               TcpipClientSupport

La sélection de cette valeur active les appels RPC sur le transport TCP. Cela est nécessaire, car, par défaut, les interfaces SAMRPC ne sont accessibles à distance que sur des canaux nommés. L’utilisation de canaux nommés donne lieu à un système de gestion des informations d’identification adapté aux utilisateurs connectés de manière interactive et effectuant des appels réseau, mais n’est pas suffisamment souple pour un processus système qui effectue des appels réseau avec des informations d’identification fournies par l’utilisateur. À cet effet, l'emploi de RPC sur TCP est plus adapté. La configuration de cette valeur ne diminue pas la sécurité du système. Si cette valeur est créée ou modifiée, le contrôleur de domaine source doit être redémarré pour que ce paramètre soit pris en compte.

Un nouveau groupe local, « <SrcDomainName>$$$$ », doit être créé dans le domaine source à des fins d’audit.

Audit

Les opérations DsAddSidHistory sont auditées pour veiller à ce que les administrateurs des domaines source et de destination soient en mesure de détecter le moment où cette fonction a été exécutée. L’audit est obligatoire à la fois dans le domaine source et dans celui de destination. DsAddSidHistory vérifie que le mode Audit est activé dans chaque domaine, et que l’audit de la Gestion des comptes des événements Réussite/Échec est activé. Dans le domaine de destination, un événement d’audit unique « Ajout de l'historique SID » est généré pour chaque opération DsAddSidHistory ayant réussi ou échoué.

Les événements d’audit uniques « Ajout de l'historique SID » ne sont pas disponibles sur les systèmes Windows NT 4.0. Pour générer des événements d’audit qui reflètent sans ambiguïté l’utilisation de DsAddSidHistory sur le domaine source, il effectue des opérations sur un groupe spécial dont le nom est l’identificateur unique du journal d’audit. Un groupe local, « <SrcDomainName>$$$$ », dont le nom est composé du nom NetBIOS du domaine source suivi de trois signes dollar ($) (code ASCII = 0x24 et Unicode = U+0024), doit être créé sur le contrôleur de domaine source avant d’appeler DsAddSidHistory. Chaque utilisateur source et groupe global ciblé par cette opération est ajouté, puis supprimé de l’appartenance à ce groupe. Des événements Ajouter un membre et Supprimer un membre sont ainsi générés dans le domaine source, et il est possible de les surveiller en recherchant des événements qui font référence au nom du groupe.

Remarque

Les opérations DsAddSidHistory sur des groupes locaux dans un domaine source sous Windows NT 4.0 ou en mode mixte Windows 2000 ne peuvent pas être auditées, car les groupes locaux ne peuvent pas être membres d’un autre groupe local, et ne peuvent donc pas être ajoutés au groupe local « <SrcDomainName>$$$ » spécial. Cette absence d’audit ne pose aucun problème de sécurité au domaine source, puisque l’accès à ses ressources n’est pas affecté par cette opération. L’ajout du SID d’un groupe local source à un groupe local de destination n'autorise pas d'autres utilisateurs à accéder aux ressources source, qui sont protégées par ce groupe local. L’ajout de membres au groupe local de destination ne leur donne pas accès aux ressources source. Les membres ajoutés sont autorisés à accéder uniquement aux serveurs du domaine de destination migrés à partir du domaine source, dont les ressources peuvent avoir été protégées par le SID du groupe local source.

Sécurité de la transmission des données

DsAddSidHistory applique les mesures de sécurité suivantes :

• Appelées à partir d’une station de travail sous Windows 2000, les informations d’identification de l’appelant sont utilisées pour authentifier et protéger l’appel RPC vers le contrôleur de domaine de destination. Si la valeur SrcDomainCreds est différente de NULL, la station de travail et le contrôleur de domaine de destination doivent prendre en charge le chiffrement 128 bits pour protéger les informations d’identification. Si le chiffrement 128 bits n’est pas disponible et que des SrcDomainCreds sont fournis, l’appel doit être effectué sur le contrôleur de domaine de destination.
• Le contrôleur de domaine de destination communique avec le contrôleur de domaine source soit via SrcDomainCreds, soit à travers les informations d’identification de l’appelant pour authentifier mutuellement et protéger l’intégrité de la lecture du SID du compte source (par recherche SAM) et sIDHistory (via lecture LDAP).

Modèles de menace

Le tableau suivant dresse une liste des menaces potentielles associées à l’appel DsAddSidHistory et propose des mesures de sécurité adaptées à chacune de ces menaces.

Menace potentielle	Mesure de sécurité
Attaque de l’intercepteur (man-in-the-middle) Un utilisateur non autorisé intercepte l’appel de retour du SID de recherche de l’objet source et remplace le SID de l’objet source par un SID arbitraire à insérer dans le SIDhistory d'un objet cible.	Le SID de recherche de l’objet source est un RPC authentifié à l'aide des informations d’identification de l’administrateur de l’appelant, avec protection des messages fondée sur l’intégrité du paquet. Il est ainsi impossible de modifier l’appel de retour sans que cela soit détecté. Le contrôleur de domaine de destination crée un événement d’audit « Ajout de l'historique SID » unique qui reflète le SID ajouté au sIDHistory du compte de destination.
Domaine source de type « cheval de Troie » Un utilisateur non autorisé crée un domaine source de type « cheval de Troie » sur un réseau privé qui a le même SID de domaine et une partie des mêmes SID de compte que le domaine source légitime. L’utilisateur non autorisé tente ensuite d’exécuter DsAddSidHistory dans un domaine de destination pour obtenir le SID d’un compte source. Pour ce faire, il n'est pas nécessaire d'utiliser les informations d'identification de l'Administrateur du domaine source réel, ni de conserver une piste d'audit dans le domaine source réel. Pour créer le domaine source de type « cheval de Troie », l'utilisateur peut recourir à l’une des méthodes suivantes : Obtenir une copie (BDC secondaire) du domaine source SAM. Créer un nouveau domaine, en modifiant le SID de domaine sur le disque pour qu’il corresponde au SID de domaine source légitime, puis créer suffisamment d’utilisateurs pour instancier un compte avec le SID souhaité. Créer un réplica du BDC. Pour cela, il est nécessaire de posséder les informations d’identification de l'Administrateur du domaine source. L'utilisateur non autorisé transfère ensuite le réplica sur un réseau privé pour mettre son attaque en œuvre.	Même si un utilisateur non autorisé peut avoir à sa disposition de nombreux moyens pour récupérer ou créer le SID d'un objet source souhaité, il ne peut pas l'utiliser pour mettre à jour le sIDHistory d'un compte sans être membre du groupe d'Administrateurs du domaine de destination. Étant donné que sur le contrôleur de domaine de destination, la vérification de l’appartenance aux Administrateurs du domaine est codée en dur, sur le contrôleur de domaine cible, il n’existe aucune méthode de modification du disque permettant de changer les données de contrôle d’accès qui protègent cette fonction. Toute tentative de cloner un compte source de type « cheval de Troie » est auditée dans le domaine de destination. Cette attaque est atténuée en restreignant l’appartenance au groupe d'Administrateurs du domaine à des personnes de confiance absolue.
Modification sur disque de l’historique SID Un utilisateur non autorisé chevronné, disposant des informations d'identification d'un Administrateur de domaine et d'un accès physique à un contrôleur de domaine dans le domaine de destination, pourrait modifier la valeur d'un compte sIDHistory sur le disque.	Une telle tentative est rendue impossible par l'utilisation de DsAddSidHistory. Cette attaque est atténuée en empêchant l'accès physique aux contrôleurs de domaine à tous les utilisateurs, exception faite des administrateurs de confiance absolue.
Code non autorisé utilisé pour supprimer des protections Un utilisateur non autorisé ou un administrateur malveillant disposant d’un accès physique au code du service d'annuaire peut créer un code non autorisé qui : Supprime dans le code la vérification de l'appartenance au groupe d'Administrateurs du domaine. Modifie les appels sur le contrôleur de domaine source qui dirige le SID vers un LookupSidFromName non audité. Supprime les appels du journal d’audit.	Une personne disposant d’un accès physique au code DS et ayant des connaissances suffisantes pour créer du code non autorisé est capable de modifier arbitrairement l’attribut sIDHistory d’un compte. L’API DsAddSidHistory n’accroît pas ce risque de sécurité.
Ressources vulnérables aux SID volés Si un utilisateur non autorisé réussit à utiliser l’une des méthodes ici décrites pour modifier un compte sIDHistory et que les domaines de ressources concernés approuvent le domaine du compte d’utilisateur non autorisé, ce dernier peut obtenir un accès non autorisé aux ressources du SID volé, et ce, potentiellement sans laisser de piste d’audit dans le domaine de compte à partir duquel le SID a été volé.	Les administrateurs de domaines de ressources protègent leurs ressources en configurant uniquement les relations d’approbation qui sont logiques du point de vue de la sécurité. L’utilisation de DsAddSidHistory est limitée, dans le domaine cible approuvé, aux seuls membres du groupe d'Administrateurs de domaine qui disposent déjà d’autorisations étendues dans le cadre de leurs responsabilités.
Domaine cible non autorisé Un utilisateur non autorisé crée un domaine Windows 2000 avec un compte dont le sIDHistory contient un SID volé à partir d’un domaine source. L’utilisateur non autorisé utilise ce compte pour un accès non autorisé aux ressources.	L’utilisateur non autorisé a besoin des informations d’identification de l'Administrateur du domaine source pour pouvoir utiliser DsAddSidHistory, ce qui laisse une piste d’audit sur le contrôleur de domaine source. Le domaine cible non autorisé obtient un accès non autorisé uniquement dans d’autres domaines qui approuvent le domaine non autorisé, ce qui nécessite des privilèges d’Administrateur dans ces domaines de ressources.

Contraintes opérationnelles

Cette section décrit les contraintes opérationnelles associées à l’utilisation de la fonction DsAddSidHistory.

Il ne faut pas que le SID de SrcPrincipal existe déjà dans la forêt de destination, que ce soit en tant que SID de compte principal, ou dans le sIDHistory d’un compte. L’exception est que DsAddSidHistory ne génère pas d’erreur s'il se produit une tentative d’ajout d'un SID à un sIDHistory contenant un SID identique. Ce comportement permet à DsAddSidHistory de s'exécuter plusieurs fois avec une entrée identique, ce qui se traduit par une réussite et un état final cohérent, afin de faciliter la tâche des développeurs d’outils.

Remarque

La latence de réplication du Catalogue global peut fournir une fenêtre pendant laquelle il est possible de créer des SID dupliqués. Toutefois, ces SID dupliqués peuvent être facilement supprimés par un administrateur.

SrcPrincipal et DstPrincipal doivent être de l’un des types suivants :

• Utilisateur

• Groupe sécurisé, comme :

  Groupe local Groupe global Groupe local au niveau du domaine (uniquement en mode natif Windows 2000) Groupe universel (uniquement en mode natif Windows 2000)

Les types d’objets de SrcPrincipal et DstPrincipal doivent concorder.

• Si SrcPrincipal est un utilisateur, DstPrincipal doit être un utilisateur.
• Si SrcPrincipal est un groupe local ou un groupe local au niveau du domaine, DstPrincipal doit être un groupe local au niveau du domaine.
• Si SrcPrincipal est un groupe global ou universel, DstPrincipal doit être un groupe global ou universel.

SrcPrincipal et DstPrincipal ne peuvent pas être de l’un des types suivants : (dans ces cas, DsAddSidHistory échoue avec un message d'erreur)

• Ordinateur (station de travail ou contrôleur de domaine)

• Approbation inter-domaines

• Compte temporairement dupliqué (fonctionnalité virtuellement inutilisée, héritée de LANman)

• Comptes avec des SID connus. Les SID connus sont identiques dans chaque domaine ; ainsi, leur ajout à un sIDHistory violerait l’exigence d’unicité des SID dans une forêt Windows 2000. Les comptes avec des SID connus incluent les groupes locaux suivants :

  Opérateurs de compte Administrateurs Opérateurs de sauvegarde Invités Opérateurs d’impression Réplicateurs Opérateurs de serveur Utilisateurs

Si SrcPrincipal a un identificateur relatif (RID) connu et un préfixe spécifique au domaine, à savoir correspondant à des Administrateurs du domaine, des Utilisateurs du domaine ou des Ordinateurs du domaine, alors DstPrincipal doit posséder le même RID connu pour assurer la réussite de DsAddSidHistory. Les comptes ayant des RID connus incluent les utilisateurs et les groupes globaux suivants :

• Administrateurs
• Invité
• Administrateurs du domaine
• Invités du domaine
• Utilisateurs du domaine

Définition de la valeur de registre

La procédure suivante montre comment définir la valeur de registre TcpipClientSupport.

Pour définir la valeur de registre TcpipClientSupport

1. Créez la valeur de registre suivante en tant que valeur REG_DWORD sur le contrôleur de domaine source et donnez-lui la valeur 1.

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\TcpipClientSupport

2. Redémarrez ensuite le contrôleur de domaine source. Cette valeur de registre permet à SAM d'écouter via TCP/IP. DsAddSidHistory échoue si cette valeur n’est pas définie sur le contrôleur de domaine source.

Activation de l’audit des événements de gestion des utilisateurs/groupes

La procédure suivante montre comment activer l’audit des événements de gestion des utilisateurs/groupes dans un domaine source ou de destination Windows Server 2000 ou Windows Server 2003.

Pour activer l’audit des événements de gestion des utilisateurs/groupes dans un domaine source ou de destination Windows Server 2000 ou Windows Server 2003

1. Dans le composant logiciel enfichable MMC Utilisateurs et ordinateurs Active Directory, sélectionnez le conteneur Contrôleurs de domaine du domaine de destination.
2. Cliquez avec le bouton droit sur Contrôleurs de domaine et sélectionnez Propriétés.
3. Cliquez sur l’onglet Stratégie de groupe.
4. Sélectionnez la Stratégie des contrôleurs de domaine par défaut et cliquez sur Modifier.
5. Sous Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Stratégie d’audit, double-cliquez sur Auditer la gestion des comptes.
6. Dans la fenêtre Auditer la gestion des comptes, choisissez d'auditer aussi bien lesRéussites que les Échecs. Les mises à jour des stratégies prennent effet après un redémarrage ou une actualisation.
7. Vérifiez que l’audit est activé en consultant la stratégie d’audit effective dans le composant logiciel enfichable MMC de la stratégie de groupe.

La procédure suivante montre comment activer l’audit des événements de gestion des utilisateurs/groupes dans un domaine Windows NT 4.0.

Pour activer l’audit des événements de gestion des utilisateurs/groupes dans un domaine Windows NT 4.0

1. Dans Gestionnaire des utilisateurs pour les domaines, cliquez sur le menu Stratégies et sélectionnez Audit.
2. Sélectionnez Auditer ces événements.
3. Dans Gestion des utilisateurs et des groupes, sélectionnez Réussite et échec.

La procédure suivante montre comment activer l’audit des événements de gestion des utilisateurs/groupes dans un domaine source Windows NT 4.0, Windows 2000 ou Windows Server 2003.

Pour activer l’audit des événements de gestion des utilisateurs/groupes dans un domaine source Windows NT 4.0, Windows 2000 ou Windows Server 2003

1. Dans Gestionnaire des utilisateurs pour les domaines, cliquez sur le menu Utilisateur et sélectionnez Nouveau groupe local.
2. Saisissez un nom de groupe composé du nom NetBIOS du domaine source suivi de trois signes dollar ($), par exemple, FABRIKAM$$$$. Le champ Description doit indiquer que ce groupe est employé pour auditer l’utilisation des opérations DsAddSidHistory ou de clonage. Assurez-vous qu'il n'y a aucun membre dans le groupe. Cliquez sur OK.

L’opération DsAddSidHistory échoue si l’audit source et de destination ne sont pas activés comme décrit ici.

Si nécessaire, configurez l’approbation

Si l’une des valeurs suivantes est vraie, il est nécessaire d'établir une approbation du domaine source au domaine de destination (dans une forêt différente) :

• Le domaine source est Windows Server 2003.
• Le domaine source est Windows NT 4.0, et la valeur de SrcDomainCreds est NULL.