Récupération de forêt Active Directory : effectuer la récupération initiale
Cette section comprend les étapes suivantes :
- Restaurer le premier contrôleur de domaine accessible en écriture dans chaque domaine
- Reconnecter chaque contrôleur de domaine accessible en écriture restauré au réseau
- Ajouter le catalogue global à un contrôleur de domaine dans le domaine racine de la forêt
Restaurer le premier contrôleur de domaine accessible en écriture dans chaque domaine
En commençant par un contrôleur de domaine accessible en écriture dans le domaine racine de forêt, suivez les étapes décrites dans cette section afin de restaurer le premier contrôleur de domaine. Le domaine racine de la forêt est important, car il stocke les groupes Administrateurs de schéma et Administrateurs d’entreprise. Il permet également de maintenir la hiérarchie d’approbation dans la forêt. En outre, le domaine racine de forêt contient généralement le serveur racine DNS pour l’espace de noms DNS de la forêt. Par conséquent, la zone DNS intégrée à Active Directory pour ce domaine contient les enregistrements de ressources d’alias (CNAME) pour tous les autres contrôleurs de domaine de la forêt (qui sont requis pour la réplication) et les enregistrements de ressources DNS du catalogue global.
Après avoir récupéré le domaine racine de la forêt, répétez les mêmes étapes pour récupérer les domaines restants dans la forêt. Vous pouvez récupérer plusieurs domaines simultanément ; toutefois, récupérez toujours un domaine parent avant de récupérer un enfant pour éviter toute rupture dans la hiérarchie d’approbation ou la résolution de noms DNS.
Pour chaque domaine que vous récupérez, restaurez un contrôleur de domaine accessible en écriture à partir de la sauvegarde. Il s’agit de la partie la plus importante de la récupération, car le contrôleur de domaine doit avoir une base de données qui n’a pas été influencée par tout ce qui a provoqué l’échec de la forêt. Il est important de disposer d’une sauvegarde approuvée qui est minutieusement testée avant son introduction dans l’environnement de production.
Ensuite, effectuez les étapes suivantes. Vous trouverez les procédures d’exécution de certaines étapes dans Récupération de forêt AD : procédures.
Si vous envisagez de restaurer un serveur physique, assurez-vous que le câble réseau du contrôleur de domaine cible n’est pas attaché et n’est donc pas connecté au réseau de production. Pour une machine virtuelle, vous pouvez supprimer la carte réseau ou utiliser une carte réseau attachée à un autre réseau dans lequel vous pouvez tester le processus de récupération tout en étant isolé du réseau de production.
Étant donné qu’il s’agit du premier contrôleur de domaine accessible en écriture dans le domaine, vous devez effectuer une restauration non authentifiée d’AD DS et une restauration faisant autorité de SYSVOL. L’opération de restauration doit être effectuée à l’aide d’une application de sauvegarde et de restauration prenant en compte Active Directory, telle que la sauvegarde Windows Server (recommandée). Si l’ID de génération Hyper-Vistor est pris en charge sur l’hôte, vous pouvez également effectuer la restauration non authentifiée à l’aide d’un instantané de machine virtuelle.
Une restauration faisant autorité de SYSVOL est requise sur le premier contrôleur de domaine récupéré, car la réplication du dossier SYSVOL doit être redémarrée avec les nouvelles instances après la récupération d’un sinistre. Tous les contrôleurs de domaine suivants ajoutés dans le domaine doivent resynchroniser leur dossier SYSVOL avec une copie du dossier qui a été sélectionné pour faire autorité.
Avertissement
Effectuez une opération de restauration faisant autorité (ou principale) de SYSVOL uniquement pour le premier contrôleur de domaine à restaurer dans le domaine racine de la forêt. L’exécution incorrecte des opérations de restauration principales de SYSVOL sur d’autres contrôleurs de domaine entraîne des conflits de réplication de données SYSVOL. Il existe deux façons d’effectuer une restauration non authentifiée d’AD DS et une restauration faisant autorité de SYSVOL :
Effectuez une récupération complète du serveur, puis forcez une synchronisation faisant autorité de SYSVOL. Pour obtenir des procédures détaillées, consultez Exécution d’une récupération complète du serveur et Exécution d’une synchronisation faisant autorité de SYSVOL répliqué par DFSR.
Effectuez une récupération complète du serveur suivie d’une restauration de l’état du système. Cette option nécessite que vous créiez les deux types de sauvegardes à l’avance : une sauvegarde complète du serveur et une sauvegarde de l’état du système. Pour obtenir des procédures détaillées, consultez Exécution d’une récupération complète du serveur et Exécution d’une restauration non autorisée d’Active Directory Domain Services.
Après avoir restauré et redémarré le contrôleur de domaine accessible en écriture, vérifiez que l’échec n’a pas affecté les données sur le contrôleur de domaine. Si les données du contrôleur de domaine sont endommagées, répétez l’étape 2 avec une autre sauvegarde.
Si le contrôleur de domaine restauré héberge un rôle de maître d’opérations, vous devrez peut-être ajouter l’entrée de registre suivante pour éviter qu’AD DS ne soit indisponible tant qu’il n’a pas terminé la réplication d’une partition de répertoire accessible en écriture :
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations
Créez l’entrée avec le type de données REG_DWORD et la valeur 0. Une fois la forêt complètement récupérée, vous pouvez réinitialiser la valeur de cette entrée à 1, ce qui nécessite qu’un contrôleur de domaine qui redémarre et détient des rôles de maître d’opérations ait réussi la réplication AD DS entrante et sortante avec ses partenaires de réplique connus avant qu’il ne s’annonce en tant que contrôleur de domaine et commence à fournir des services aux clients. Pour plus d'informations sur les conditions requises par la synchronisation initiale, consultez Rôles FSMO Active Directory.
Passez aux étapes suivantes uniquement après avoir restauré et vérifié les données et avant de connecter cet ordinateur au réseau de production.
Si vous pensez que l’échec à l’échelle de la forêt était lié à une intrusion réseau ou à une attaque malveillante, réinitialisez les mots de passe de compte pour tous les comptes d’administration, y compris les membres des groupes Administrateurs d’entreprise, Administrateurs de domaine, Administrateurs de schéma, Opérateurs de serveur, Opérateurs de compte, etc. La procédure complète de réinitialisation de mot de passe du compte krbtgt est également nécessaire. La réinitialisation des mots de passe de compte d’administration doit être effectuée avant l’installation de contrôleurs de domaine supplémentaires pendant la phase suivante de la récupération de la forêt.
Dans ce cas aussi, veillez à remplacer tous les mots de passe GMSA comme si un compte administratif avait été pris en charge, l’attaquant pourrait avoir récupéré des informations qui lui permet de s’authentifier en tant que GMSA. Pour plus d’informations, consultez l’article sur l'attaque GMSA golden.
Si vous pensez que des comptes d’utilisateur ont été compromis, vous devez également planifier une réinitialisation de mot de passe utilisateur pour tous les utilisateurs du domaine.
Sur le premier contrôleur de domaine restauré dans le domaine racine de forêt, saisissez tous les rôles de maître d’opérations à l’échelle du domaine et de la forêt. Les informations d’identification des administrateurs d’entreprise et de schéma sont nécessaires pour saisir les rôles nécessaires de maître des opérations à l’échelle de la forêt.
Dans chaque domaine enfant, saisissez les rôles nécessaires de maître d’opérations à l’échelle du domaine. Bien que vous ne conserviez les rôles de maître d’opérations sur le contrôleur de domaine restauré que temporairement, la saisie de ces rôles vous permet de savoir quel contrôleur de domaine les héberge à ce stade dans le processus de récupération de forêt. Dans le cadre de votre processus de post-récupération, vous pouvez redistribuer les rôles de maître d’opérations en fonction des besoins. Pour plus d’informations sur la saisie des rôles de maître d’opérations, consultez Saisie d’un rôle de maître d’opérations. Pour obtenir des recommandations sur l’emplacement des rôles de maître d’opérations, consultez Que sont les maîtres d’opérations ?. Consultez également Placement et optimisation d’opération monomaître flexible (FSMO) sur les contrôleurs de domaine AD.
Nettoyez les métadonnées de tous les autres contrôleurs de domaine accessibles en écriture dans le domaine racine de forêt que vous ne restaurez pas à partir de la sauvegarde (tous les contrôleurs de domaine accessibles en écriture dans le domaine, à l’exception de ce premier contrôleur de domaine). Si vous utilisez la version d’Utilisateurs et ordinateurs Active Directory ou de Sites et services Active Directory incluse dans Windows Server 2012, ou version ultérieure, ou encore RSAT pour Windows 10 ou version ultérieure, le nettoyage des métadonnées est effectué automatiquement lorsque vous supprimez un objet de contrôleur de domaine. En outre, l’objet serveur et l’objet ordinateur pour le contrôleur de domaine supprimé sont également supprimés automatiquement. Pour plus d’informations, consultez Nettoyage des métadonnées des contrôleurs de domaine accessibles en écriture supprimés et Nettoyer les métadonnées d’un serveur AD DS.
Le nettoyage des métadonnées empêche la duplication possible d’objets NTDS-settings si AD DS est installé sur un contrôleur de domaine dans un autre site. Potentiellement, cela peut également enregistrer le vérificateur de cohérence des connaissances, le processus de création de liens de réplication lorsque les contrôleurs de domaine eux-mêmes risquent de ne pas être présents. En outre, dans le cadre du nettoyage des métadonnées, les enregistrements de ressources DNS du localisateur de contrôleur de domaine pour tous les autres contrôleurs de domaine du domaine seront supprimés du DNS.
Tant que les métadonnées de tous les autres contrôleurs de domaine du domaine ne sont pas supprimées, ce contrôleur de domaine, s’il s’agissait d’un maître RID avant la récupération, n’assumera pas le rôle de maître RID et ne pourra donc pas émettre de nouveaux RID. Vous verrez peut-être l’ID d’événement 16650 dans le journal système dans Observateur d’événements indiquant cet échec, mais vous devriez voir l’ID d’événement 16648 indiquant la réussite un peu de temps après avoir nettoyé les métadonnées.
Si vous avez des zones DNS stockées dans AD DS, assurez-vous que le service serveur DNS local est installé et en cours d’exécution sur le contrôleur de domaine que vous avez restauré. Si ce contrôleur de domaine n’était pas un serveur DNS avant l’échec de la forêt, vous devez installer et configurer le rôle serveur DNS sur le contrôleur de domaine ou un serveur DNS doit être disponible sur l’environnement de restauration.
Dans le domaine racine de la forêt, configurez le contrôleur de domaine restauré avec sa propre adresse IP comme serveur DNS par défaut. Vous pouvez configurer ce paramètre dans les propriétés TCP/IP de l’adaptateur réseau local (LAN). Il s’agit du premier serveur DNS dans la forêt. Pour plus d’informations, consultez Recommandations pour les paramètres client DNS (Domain Name System).
Dans chaque domaine enfant, configurez le contrôleur de domaine restauré avec l’adresse IP du premier serveur DNS dans le domaine racine de forêt comme serveur DNS par défaut. Vous pouvez configurer ce paramètre dans les propriétés TCP/IP de l’adaptateur LAN. Pour plus d’informations, consultez Recommandations pour les paramètres client DNS (Domain Name System).
Dans les zones DNS _msdcs et de domaine, supprimez les enregistrements NS des contrôleurs de domaine qui n’existent plus après le nettoyage des métadonnées. Vérifiez si les enregistrements SRV des contrôleurs de domaine nettoyés ont été supprimés. Pour accélérer la suppression des enregistrements SRV DNS, exécutez :
nltest.exe /dsderegdns:server.domain.tld
Augmentez la valeur du pool RID disponible de 100 000. Pour plus d’informations, consultez Augmentation de la valeur des pools RID disponibles. Si vous avez des raisons de croire que l’augmentation du pool RID de 100 000 est insuffisante pour votre situation, vous devez déterminer, en tenant compte de la consommation moyenne de RID sur votre environnement, la plus faible augmentation dont l’utilisation reste sûre. Les RID sont une ressource finie qui ne doit pas être utilisée inutilement.
Si de nouveaux principaux de sécurité ont été créés dans le domaine après l’heure de la sauvegarde que vous utilisez pour la restauration, ces principaux de sécurité peuvent avoir des droits d’accès sur certains objets. Ces principaux de sécurité n’existent plus après la récupération, car la récupération est revenue à la sauvegarde ; toutefois, leurs droits d’accès peuvent toujours exister. Si le pool RID disponible n’est pas déclenché après une restauration, les nouveaux objets utilisateur créés après la récupération de forêt peuvent obtenir des ID de sécurité (SID) identiques et avoir accès à ces objets, ce qui n’était pas prévu à l’origine.
Par exemple, il peut y avoir eu un nouvel employé. L’objet utilisateur n’existe plus après l’opération de restauration, car il a été créé après la sauvegarde utilisée pour restaurer le domaine. Toutefois, tous les droits d’accès qui ont été attribués à cet objet utilisateur peuvent être conservés après l’opération de restauration. Si le SID de cet objet utilisateur est réaffecté à un nouvel objet après l’opération de restauration, le nouvel objet obtient ces droits d’accès.
Invalider le pool RID actuel. Le pool RID actuel est invalidé après une restauration de l’état du système. Toutefois, si aucune restauration de l’état du système n’a été effectuée, le pool RID actuel doit être invalidé pour empêcher le contrôleur de domaine restauré de réécrire des RID à partir du pool RID affecté au moment de la création de la sauvegarde. Pour plus d’informations, consultez Invalidation du pool RID actuel.
Remarque
La première fois que vous tentez de créer un objet avec un SID après avoir invalidé le pool RID, vous recevez une erreur. La tentative de création d’un objet déclenche une demande pour un nouveau pool RID. La nouvelle tentative de l’opération réussit, car le nouveau pool RID sera alloué.
Réinitialisez deux fois le mot de passe du compte d’ordinateur de ce contrôleur de domaine. Pour plus d’informations, consultez Réinitialisation du mot de passe du compte d’ordinateur du contrôleur de domaine.
Réinitialiser deux fois le mot de passe krbtgt. Pour plus d’informations, consultez Réinitialisation du mot de passe krbtgt. Étant donné que l’historique des mots de passe krbtgt est de deux mots de passe, réinitialisez deux fois les mots de passe pour supprimer le mot de passe d’origine (avant échec) de l’historique des mots de passe.
Remarque
Si la récupération de forêt se fait en réponse à une violation de la sécurité, vous pouvez également réinitialiser les mots de passe d’approbation. Pour plus d’informations, consultez Réinitialisation d’un mot de passe d’approbation d’un côté de l’approbation.
Si la forêt a plusieurs domaines et que le contrôleur de domaine restauré était un serveur de catalogue global avant l’échec, décochez la case Catalogue global dans les propriétés NTDS Settings pour supprimer le catalogue global du contrôleur de domaine. L’exception à cette règle est le cas courant d’une forêt avec un seul domaine. Dans ce cas, il n’est pas nécessaire de supprimer le catalogue global. Pour plus d’informations, consultez Suppression du catalogue global.
En restaurant un catalogue global à partir d’une sauvegarde plus récente que d’autres sauvegardes utilisées pour restaurer des contrôleurs de domaine dans d’autres domaines, vous pouvez introduire des objets en attente. Considérez l'exemple suivant. Dans le domaine A, DC1 est restauré à partir d’une sauvegarde effectuée à l’heure T1. Dans le domaine B, DC2 est restauré à partir d’une sauvegarde de catalogue global effectuée à l’heure T2. Supposons que l’heure T2 soit plus récente que T1 et que certains objets aient été créés entre T1 et T2. Une fois ces contrôleurs de domaine restaurés, DC2, qui est un catalogue global, contient des données plus récentes pour la réplique partielle du domaine A que le domaine A lui-même. DC2, dans ce cas, contient des objets en attente, car ces objets ne sont pas présents sur DC1.
La présence d’objets en attente peut entraîner des problèmes. Par exemple, les messages électroniques peuvent ne pas être remis à un utilisateur dont l’objet utilisateur a été déplacé d’un domaine à l’autre. Une fois que vous avez remis en ligne le contrôleur de domaine ou le serveur de catalogue global obsolète, les deux instances de l’objet utilisateur apparaissent dans le catalogue global. Les deux objets ont la même adresse de messagerie ; par conséquent, les messages électroniques ne peuvent pas être remis.
Autre problème : un compte d’utilisateur qui n’existe plus peut toujours apparaître dans la liste d’adresses globale.
De plus, un groupe universel qui n’existe plus peut toujours apparaître dans le jeton d’accès d’un utilisateur.
Si vous avez restauré un contrôleur de domaine qui était un catalogue global (par inadvertance ou parce qu’il s’agissait de la sauvegarde solitaire que vous avez approuvée), nous vous recommandons d’empêcher l’apparition d’objets en attente en désactivant le catalogue global peu après la fin de l’opération de restauration. La désactivation de l’indicateur de catalogue global entraîne la perte de toutes ses répliques partielles (partitions) et la relégation à l’état de contrôleur de domaine normal.
Si vous utilisez des comptes gMSA, vous devrez peut-être les recréer, car les détails de la génération de mot de passe peuvent être exposés à un attaquant, consultez :
Comment récupérer à partir d’une attaque gMSA goldenConsultez Récupération de forêt AD : récupération d’un domaine unique dans une forêt multidomaine pour connaître les étapes à suivre pour remplacer les gMSA et s’assurer qu’ils utilisent du matériel de clé sécurisé.
Configurer le service de temps Windows. Dans le domaine racine de la forêt, configurez l’émulateur de contrôleur de domaine principal pour synchroniser l’heure à partir d’une source de temps externe. Pour plus d’informations, consultez Configurer le service de temps Windows sur l’émulateur de contrôleur de domaine principal du domaine racine de forêt.
Reconnecter chaque contrôleur de domaine accessible en écriture restauré à un réseau commun
À ce stade, votre contrôleur de domaine devrait être restauré (et les étapes de récupération, effectuées) dans le domaine racine de la forêt et dans chacun des domaines restants. Connectez ces contrôleurs de domaine à un réseau commun isolé du reste de l’environnement et effectuez les étapes suivantes afin de valider l’intégrité et la réplication de la forêt.
Notes
Lorsque vous connectez les contrôleurs de domaine physiques à un réseau isolé, vous devrez peut-être modifier leurs adresses IP. Par conséquent, les adresses IP des enregistrements DNS sont incorrectes. Étant donné qu’un serveur de catalogue global n’est pas disponible, les mises à jour dynamiques sécurisées pour DNS échouent. Les contrôleurs de domaine virtuels sont plus avantageux dans ce cas, car ils peuvent être connectés à un nouveau réseau virtuel sans modifier leurs adresses IP. C’est l’une des raisons pour lesquelles les contrôleurs de domaine virtuels sont recommandés en tant que premiers contrôleurs de domaine à restaurer pendant la récupération de forêt.
Vérifier l’intégrité de la réplication de la forêt
Après validation, connectez les contrôleurs de domaine au réseau de production et effectuez les étapes de vérification de l’intégrité de la réplication de forêt.
- Pour corriger la résolution de noms, créez des enregistrements de délégation DNS et configurez le transfert DNS et les indicateurs racine en fonction des besoins.
- Exécutez
repadmin /replsum
pour vérifier la réplication entre contrôleurs de domaine. - Si les contrôleurs de domaine restaurés ne sont pas des partenaires de réplication directe, la récupération de réplication sera beaucoup plus rapide en créant des objets de connexion temporaires entre eux.
- Pour valider le nettoyage des métadonnées, exécutez
Repadmin /viewlist \*
afin d’obtenir la liste de tous les contrôleurs de domaine dans la forêt. ExécutezNltest /DCList:***\<domain\>*
pour obtenir la liste de tous les contrôleurs de domaine dans le domaine. - Afin de vérifier l’intégrité du contrôleur de domaine et du DNS, exécutez
DCDiag /v
pour signaler des erreurs de tous les contrôleurs de domaine de la forêt.
Ajouter le catalogue global à un contrôleur de domaine dans le domaine racine de la forêt
Un catalogue global est nécessaire pour les raisons suivantes (liste non exhaustive) :
- Pour activer les connexions pour les utilisateurs.
- Pour permettre au service Net Logon en cours d’exécution sur les contrôleurs de domaine de chaque domaine enfant d’inscrire et de supprimer des enregistrements sur le serveur DNS dans le domaine racine.
Bien qu’il soit préférable que le contrôleur de domaine racine de la forêt soit un catalogue global, il est généralement recommandé de décider que tous les contrôleurs de domaine en soient un.
Note
Un contrôleur de domaine n’est pas publié en tant que serveur de catalogue global tant qu’il n’a pas terminé une synchronisation complète de toutes les partitions de répertoire dans la forêt. Par conséquent, le contrôleur de domaine doit être forcé de répliquer avec chacun des contrôleurs de domaine restaurés dans la forêt.
Vérifiez dans le journal des événements du service de répertoire dans Observateur d’événements que vous ne voyez pas l’ID d’événement 1119, qui indique que ce contrôleur de domaine est un serveur de catalogue global, ou vérifiez que la clé de Registre suivante a la valeur 1 :
**HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Global Catalog
Promotion Complete**
Pour plus d’informations, consultez Ajout du catalogue global.
À ce stade, vous devez disposer d’une forêt stable, avec un contrôleur de domaine pour chaque domaine et un catalogue global dans la forêt. Vous devez effectuer une nouvelle sauvegarde de chacun des contrôleurs de domaine que vous venez de restaurer. Vous pouvez maintenant commencer à redéployer d’autres contrôleurs de domaine dans la forêt en installant AD DS et en configurant des serveurs de catalogue global supplémentaires.
Étapes suivantes
- Récupération de la forêt Active Directory : conditions préalables
- Récupération de forêt AD : concevoir un plan de récupération de forêt personnalisé
- Récupération de forêt AD : étapes de restauration de la forêt
- Récupération de forêt AD – Identification du problème
- Récupération de forêt AD – Identification de la procédure de récupération
- Récupération de forêt AD – Récupération initiale
- Récupération de la forêt Active Directory : procédures
- Récupération de forêt AD : forum aux questions (FAQ)
- Récupération de forêt AD : récupérer un domaine unique au sein d’une forêt multidomaine
- Récupération de forêt AD : redéployer les contrôleurs de domaine restants
- Récupération de la forêt Active Directory : virtualisation
- Récupération de forêt AD : nettoyage