Récupération de forêt Active Directory : récupération d’un seul domaine dans une forêt multidomaine

  • Article

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 et 2012

Dans certains scénarios, il peut être nécessaire de récupérer un seul domaine au sein d’une forêt qui a plusieurs domaines, au lieu de récupérer la forêt complète. Cette rubrique décrit les considérations relatives à la récupération d’un seul domaine et les stratégies possibles.

Comme pour le processus de récupération de forêt, vous restaurez un ou plusieurs contrôleurs de domaine à partir de la sauvegarde dans le domaine et effectuez un nettoyage des métadonnées des contrôleurs de domaine restants. De nouveaux contrôleurs de domaine sont ensuite ajoutés en joignant de nouveaux membres, en installant des rôles AD DS et en les promouvant. Vous pouvez également utiliser le Clonage de contrôleur de domaine ou Installer à partir du support pour la tâche.

La récupération d’un seul domaine présente un défi unique pour la reconstruction des serveurs de catalogue global (GC). Par exemple, si le premier contrôleur de domaine (DC) du domaine est restauré à partir d’une sauvegarde créée une semaine plus tôt, tous les autres GC de la forêt ont des données plus à jour pour ce domaine que le contrôleur de domaine restauré. Pour rétablir la cohérence des données GC, il y a deux options :

  • Annulez l’hébergement de la partition des domaines récupérés dans tous les GC de la forêt, à l’exception de ceux du domaine récupéré, en une fois l’opération terminée, réhébergez tous les GC dans la forêt. Veillez également à ne pas surcharger les GC restants. Dans de grands environnements, la coordination de cette activité peut être très complexe.

  • Suivre le processus de récupération de forêt pour récupérer le domaine, puis supprimer les objets en attente dans les GC des autres domaines.

Les sections suivantes décrivent les considérations générales de chaque option. L’ensemble complet des étapes à effectuer pour la récupération varie selon les différents environnements Active Directory.

Recréer les comptes de service administrés de groupe (gMSA)

Avertissement

Si les objets de clé racine KDS de la forêt ont été compromis, vous devez recréer les comptes gMSA dans plusieurs domaines, même si le domaine lui-même n’a pas été compromis.

Le problème et sa résolution sont abordés dans Comment récupérer après une attaque gMSA Golden.

Vous devez empêcher un attaquant d’utiliser des données collectées à partir d’une sauvegarde de contrôleur de domaine volée pour s’authentifier à l’aide des informations d’identification calculées par le gMSA. Remplacez tous les gMSA dans les domaines de la forêt qui utilisent les objets de clé racine KDS exposés par des comptes gMSA utilisant un nouvel objet de clé racine KDS. La procédure est décrite dans Prise en main des comptes de service administrés de groupe avec quelques modifications importantes :

  • Désactivez tous les comptes gMSA existants, définissez l’attribut userAccountControl sur 4098 (type de station de travail + désactivé).

  • Créez un objet clé racine KDS comme décrit dans Créer la clé racine du service de distribution de clés (KDS, Key Distribution Service).

    Important

    Redémarrez le service de distribution de clés Microsoft (KDSSVC) sur le même contrôleur de domaine. Cela est nécessaire pour que le nouvel objet soit récupéré par KDSSVC. Créez des comptes gMSA pour remplacer les comptes existants sur le même contrôleur de domaine. À ce stade, modifiez le compte gMSA existant, car les noms de principaux de service uniques doivent être affectés au gMSA actif.

  • Une fois que les serveurs membres sont de nouveau joints au domaine, mettez à jour les composants qui utilisaient gMSA avec les nouveaux comptes.

Pour vous assurer que le nouveau gMSA utilise le nouvel objet de clé racine KDS, vérifiez que les données binaires de l’attribut msDS-ManagedPasswordId ont le GUID de l’objet de clé racine KDS correspondant. L’objet aurait le CN de CN=e3779ca1-bfa2-9f7b-b9a5-20cf44f2f8d6.

gmsa cn value

msDS-ManagedPasswordId du gMSA doit avoir le décalage de démarrage du GUID 24 avec les trois premières parties du GUID dans l’ordre d’échange d’octets (rouge, vert, bleu) et le reste dans l’ordre d’octet normal (orange) :

guid with color coding

Si le premier gMSA a été créé à l’aide de la nouvelle clé racine KDS, toutes les créations de gMSA suivantes sont correctes.

Nettoyage

  • Supprimez les anciens comptes gMSA qui utilisaient les anciens objets de clé racine KDS.
  • Supprimez les anciens objets de clé racine KDS.

Réhéberger tous les GC

Avertissement

Le nom de connexion et le mot de passe du compte d’utilisateur administrateur de domaine par défaut (« RID-500 ») pour tous les domaines doivent être disponibles, et le ou les comptes activés pour une utilisation en cas de problème empêchant l’accès à un GC pour l’ouverture de session.

Note

Pour autoriser l’ouverture de session sans vérification GC, il est également possible de configurer la valeur HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\IgnoreGCFailures sur 1.

Si ce paramètre est inconnu, obtenez l’ID de domaine à l’aide de whoami /all pour un autre compte dans chaque domaine ou exécutez la commande suivante pour identifier le RID 500.\$DomainSID = (Get-ADDomain).DomainSID.Value\$ObjSID = New-ObjectSystem.Security.Principal.SecurityIdentifier("\$DomainSID-500")\$RID500 = \$ObjSID.Translate([System.Security.Principal.NTAccount])\$RID500.Value

Le réhébergement de tous les GC peut être effectué à l’aide des commandes repadmin /unhost et repadmin /rehost (partie de repadmin /experthelp). Vous exécutez les commandes repadmin sur chaque GC de chaque domaine qui n’est pas récupéré. Vous devez vérifier que plus aucun GC ne contient de copie du domaine récupéré. Pour ce faire, commencez par annuler l’hébergement de la partition de domaine dans tous les contrôleurs de domaine des domaines non récupérés de la forêt. Étant donné que les GC ne contiennent plus la partition, vous pouvez la réhéberger. Lors du réhébergement, tenez compte de la structure du site et de la réplication de votre forêt. Par exemple, terminez le réhébergement d’un contrôleur de domaine par site avant de réhéberger les autres contrôleurs de domaine de ce site.

Cette option convient à une petite organisation qui a seulement quelques contrôleurs de domaine pour chaque domaine. Tous les GC peuvent être reconstruits un vendredi soir et, si nécessaire, vous pouvez terminer la réplication de toutes les partitions de domaine en lecture seule avant le lundi matin. Toutefois, si vous avez besoin de récupérer un grand domaine qui couvre des sites dans le monde entier, le réhébergement de la partition de domaine en lecture seule sur tous les GC d’autres domaines peut avoir un impact significatif sur les opérations et éventuellement nécessiter des temps d’arrêt.

Rechercher et supprimer des objets en attente

Sur les GC de tous les autres domaines de la forêt, vous recherchez et supprimez les objets en attente de la partition en lecture seule du domaine récupéré, le cas échéant.

La source du nettoyage des objets en attente doit être un contrôleur de domaine dans le domaine récupéré. Pour être certain que le contrôleur de domaine source n’a aucun objet en attente dans les partitions de domaine, vous pouvez supprimer le catalogue global.

La suppression des objets en attente convient aux grandes organisations qui ne peuvent pas risquer le temps d’arrêt associé au réhébergement du contexte d’attribution de noms de domaine.

Pour plus d’informations, consultez Utiliser repadmin pour supprimer des objets en attente.

Étapes suivantes