Partager via

Restauration de forêt Active Directory en mode Core (fr-FR)

  • Article

Cet article présente la méthodologie de restauration d’une forêt Active Directory en mode Core.

Cette méthodologie s’appuie sur la procédure officielle de restauration de forêt disponible dans le lien suivant : Windows Server 2012: Planning for Active Directory Forest Recovery

L’environnement restauré dans cette procédure présente les caractéristiques suivantes :

  • Forêt mono-domaine nommée RESTAU.ADDS
  • Niveau Fonctionnel de forêt 2008 R2
  • 2 Contrôleurs de domaine Windows Server 2008 R2 SP1 Standard Core US
  • DNS Intégré AD
  • Rôles FSMO répartis entre les 2 Contrôleurs de domaine
  • Pas de relation d’approbation
  • Sauvegarde de type BMR

 

La procédure ne traite pas la partie restauration du BMR et débute au démarrage du 1er Contrôleur de domaine restauré.

Premier demarrage

Se connecter avec le compte Administrateur (RID 500).

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh6.ggpht.com%2F-8MZmVw1I0WQ%2FU-qCtkC1ZfI%2FAAAAAAAABVo%2FYJKIZcvfs34%2Fimage_thumb%2525255B1%2525255D.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Vérifier la configuration du Contrôleur de domaine avec sconfig.

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh5.ggpht.com%2F-KNKnN1DI7q0%2FU-qCvyffNNI%2FAAAAAAAABV4%2F14sXioGAU28%2Frestau001_thumb%2525255B1%2525255D.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Désactiver la synchronisation initiale si le Contrôleur de domaine héberge un des rôles FSMO.

Créer une nouvelle entrée de type DWORD dans le registre : HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations

Lui attribuer la valeur “0”.

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh5.ggpht.com%2F-Uj7L9IQrF60%2FU-qCx_E_VNI%2FAAAAAAAABWI%2FTx9USxXf97k%2Fimage25_thumb%2525255B1%2525255D.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Redémarrer le Contrôleur de domaine :

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh6.ggpht.com%2F-FYfG7yHzdL0%2FU-qCy3uEj1I%2FAAAAAAAABWY%2FhiN1hKIC6WA%2Fimage19_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 Se reconnecter avec le compte Administrateur (RID 500).

Nous allons maintenant faire une restauration autoritaire du SYSVOL en utilisant le module Powershell ActiveDirectory.

Restauration autoritaire du SYSVOL

Vérifier la valeur des attributs suivants pour le serveur restauré :

  • msDFSR-Enabled = True
  • msDFSR-Options = 0

Vous pouvez utiliser la commande suivante pour vérifier ces valeurs :
Get-ADObject –Filter {ObjectClass –eq “msDFSR-Subscription”} –Properties msDFSR-Enabled, msDFSR-Options  

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh4.ggpht.com%2F-59qyl29Ay1M%2FU-qCzwnCsYI%2FAAAAAAAABWk%2Fzgzv9wTZfjw%2Fimage30_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Modifier la valeur des attributs suivants pour le serveur restauré :

  • msDFSR-Enabled = False
  • msDFSR-Options = 1

Vous pouvez utiliser les commandes suivantes pour modifier ces valeurs :
$DFSRSub = Get-ADObject –Identity “DN de l’objet msDFSR-Subscription” –Properties msDFSR-Enabled, msDFSR-Options

$DFSRSub.’msDFSR-Enabled’ = $False

$DFSRSub.’msDFSR-Options’ = 1

Set-ADObject –Instance $DFSRSub

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh6.ggpht.com%2F-SOkMtUFJG0U%2FU-qC09AMM6I%2FAAAAAAAABW4%2FiQIxvjlIu5w%2Fimage38_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

Vérifier la modification avec la commande suivante :
Get-ADObject –Filter {ObjectClass –eq “msDFSR-Subscription”} –Properties msDFSR-Enabled, msDFSR-Options

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-KX5Ylm_1QWk%2FU-qC2IMYUxI%2FAAAAAAAABXE%2FcMVSJ7-Zcqg%2Fimage42_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

Redémarrer le service DFSR avec la commande suivante :

Restart-Service DFSR

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-jmWlX-Y_6Sg%2FU-qC3BSwdSI%2FAAAAAAAABXU%2FoQLQhUCnHE8%2Fimage46_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

Vérifier dans les journaux d’évènements que le dossier SYSVOL n’est plus répliqué avec la commande suivante :

Get-EventLog –LogName “dfs replication” –Newest 10 | ? {$_.eventid –eq 4114} | fl

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-dLa1V6J5pxI%2FU-qC4WeLGZI%2FAAAAAAAABXk%2F-rWZkTjxOOc%2Fimage50_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Modifier la valeur des attributs suivants pour le serveur restauré :

  • msDFSR-Enabled = True

Vous pouvez utiliser les commandes suivantes pour modifier ces valeurs :

$DFSRSub = Get-ADObject –Identity “DN de l’objet msDFSR-Subscription” –Properties msDFSR-Enabled, msDFSR-Options

$DFSRSub.’msDFSR-Enabled’ = $True

Set-ADObject –Instance $DFSRSub

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-MY9MneqBECk%2FU-qC5SnPLPI%2FAAAAAAAABX0%2FkNwgaP3uBOc%2Fimage54_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Vérifier la modification avec la commande suivante :

Get-ADObject –Filter {ObjectClass –eq “msDFSR-Subscription”} –Properties msDFSR-Enabled, msDFSR-Options

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh5.ggpht.com%2F-u5urfEQ4Vts%2FU-qC6yzDChI%2FAAAAAAAABYE%2FHXlQRF0m56U%2Fimage58_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Forcer l’interrogation de la configuration DFSR avec la commande suivante :

dfsrdiag pollad

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-ga5CDUb4GWw%2FU-qC7uzmSII%2FAAAAAAAABYU%2Ft_3yD7PQrS0%2Fimage62_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Vérifier dans les journaux d’évènements que la restauration s’est bien déroulée avec la commande suivante :

Get-EventLog –LogName “dfs replication” –Newest 10 | ? {$_.eventid –eq 4602} | fl

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh5.ggpht.com%2F-OJ7QL8BEjyw%2FU-qC9S-R2jI%2FAAAAAAAABYo%2FlqGhEzspww0%2Fimage66_thumb21.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*  Nous avons fini la restauration autoritaire du SYSVOL.

Transfert force des roles FSMO

Nous allons maintenant faire un transfert forcé des rôles FSMO

Vérifier que l’utilisateur est membre des groupes :

  • Domain Admins
  • Enterprise Admins
  • Schema Admins

Pour cela, vous pouvez utiliser la commande suivante :

Whoami /groups

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-5ixMRxn-sHQ%2FU-qC_GdokuI%2FAAAAAAAABY4%2Fx73tWecqB1s%2Fimage70_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Vérifier le placement des rôles FSMO avec la commande suivante :

Netdom query fsmo

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh6.ggpht.com%2F-watGjXG7iWg%2FU-qDAHof1II%2FAAAAAAAABZI%2F-GF8wKkmUYM%2Fimage74_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Effectuer un transfert forcé pour les rôles qui ne sont pas hébergés par le Contrôleur de domaine restauré.

Vous pouvez utiliser la commande suivante :

Move-ADDirectoryServerOperationMasterRole –Identity “Nom du DC” –OperationMasterRole “Numéro des Rôles à transferer”–Force

La correspondance des rôles FSMO est la suivante :

  • PDCEmulator = 0
  • RIDMaster = 1
  • InfrastructureMaster = 2
  • SchemaMaster = 3
  • DomainNamingMaster = 4

Puis vérifier que les rôles ont bien été transférés avec la commande suivante :

Netdom query fsmo

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh6.ggpht.com%2F-bnXCVttRmrU%2FU-qDBpTB4ZI%2FAAAAAAAABZU%2FR_Qn8uvcAoU%2Fimage78_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Metadata cleanup

Nous allons maintenant effectuer le Metadata Cleanup.

Je ne vais pas décrire ici chaque étape du Metadata cleanup, pour plus d’informations voir : How to remove data in Active Directory after an unsuccessful domain controller demotion

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh6.ggpht.com%2F-BGyASguSP1s%2FU-qDDjAReAI%2FAAAAAAAABZo%2FnVU1ImPkXRY%2Fimage82_thumb1.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh4.ggpht.com%2F-hM3eChMKqOE%2FU-qDEu5vqrI%2FAAAAAAAABZ0%2FpXtX3sPqp0U%2Fimage86_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Vérifier que le nettoyage a bien été effectué et qu’il ne reste que le DC restauré avec les commandes suivantes :

Get-ADObject –Filter {ObjectClass –eq “nTDSDSA”} –SearchBase “DN de la partition de Configuration” –SearchScope Subtree | fl

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh5.ggpht.com%2F-XmQwzIpLjo0%2FU-qDGNCytmI%2FAAAAAAAABaE%2F8DlVzEeJTvI%2Fimage90_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Get-ADDomainController –Filter * | ft

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-dCkiveRd8pU%2FU-qDHGqEWEI%2FAAAAAAAABaY%2F8nYYM9Ch5ZA%2Fimage94_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Vérifier les objets de type Server dans les Sites avec la commande suivante :
Get-ADObject –Filter {ObjectClass –eq “Server”} –SearchBase “DN du conteneur Sites dans la partition de Configuration” –SearchScope Subtree | fl

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh4.ggpht.com%2F-oi27v_auLfI%2FU-qDIHOVIqI%2FAAAAAAAABak%2FpHX_LCStidU%2Fimage98_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

Puis les nettoyer avec la commande suivante si besoin :
Remove-ADObject “DN de l’objet de type server”

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh6.ggpht.com%2F-XvzbCfS3fZk%2FU-qDJAKHuoI%2FAAAAAAAABa0%2FNLyP150PfQI%2Fimage102_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

Vérifier qu’il ne reste que le serveur restauré avec la commande suivante :

Get-ADObject –Filter {ObjectClass –eq “Server”} –SearchBase “DN du conteneur Sites dans la partition de Configuration” –SearchScope Subtree | fl

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-rtm9NcXZ5zo%2FU-qDKPdcxNI%2FAAAAAAAABbE%2F7_bipDEbtfQ%2Fimage106_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Correction des partitions d'application

Si vous avez des partitions d’application (c’est notre cas avec le DNS intégré AD) il est possible que le Maitre d’Infrastructure ne soit plus présent.

Vous pouvez le vérifier avec la commande suivante :

(Get-ADForest).ApplicationPartitions | %{Get-ADObject –Filter {ObjectClass –eq “InfrastructureUpdate”} –SearchBase $_ –Properties fsmoroleowner} |fl

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh6.ggpht.com%2F-F00xAN74geI%2FU-qDLZD6x4I%2FAAAAAAAABbY%2F23a0U2dq0Js%2Fimage8_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

On peut voir ici que l’attribut fsmoroleowner fait référence à un Contrôleur de domaine supprimé.

Il faut les remplacer par un Contrôleur de domaine  qui héberge ces NDNC (Non Domain Naming Context).

On peut le vérifier avec la commande suivante :

Get-ADRootDSE –Server “Nom du Contrôleur de domaine restauré”  | Select –ExpandProperty namingContexts

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh5.ggpht.com%2F-mPiWQV8HPVc%2FU-qDMybD-RI%2FAAAAAAAABbk%2FRPyvN1a67Tk%2Fimage11_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Il faut maintenant modifier l’attribut fsmoroleowner en spécifiant le Distinguished Name de l'objet ntDSDSA du Contrôleur de domaine restauré.

Pour effectuer la modification, vous pouvez utiliser les commandes suivantes :

$dsServiceName = (Get-ADRootDSE –Server “Nom du DC restauré”).dsServiceName

$InfrastructureUpdate = Get-ADObject “DN de l’objet InfrastructureUpdate de la partition d’application”

$InfrastructureUpdate.fsmoroleowner = $dsServiceName

Set-ADObject –Instance $InfrastructureUpdate

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh4.ggpht.com%2F-qwh6WXZ1GpM%2FU-qDOIGZyBI%2FAAAAAAAABb4%2F5Agecpm-rmI%2Fimage15_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Cette modification est a faire pour chaque Partition d’application.

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-sPejsG7MPM0%2FU-qDPUcP9jI%2FAAAAAAAABcI%2F6b2I32ALOAk%2Fimage191_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Vérifier avec la commande suivante que la modification a bien été effectuée :

(Get-ADForest).ApplicationPartitions | %{Get-ADObject –Filter {ObjectClass –eq “InfrastructureUpdate”} –SearchBase $_ –Properties fsmoroleowner} |fl

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh6.ggpht.com%2F-yUfc9lj3VGk%2FU-qDQUSWIWI%2FAAAAAAAABcY%2FBvT4Hq7AdsQ%2Fimage24_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

Nettoyage des enregistrements DNS

Nous allons maintenant effectuer le nettoyage des enregistrements DNS

Le nettoyage des enregistrements DNS est assez difficile avec un DNS Intégré AD en mode Core.

On peut toutefois utiliser dnscmd pour lister les enregistrements puis les supprimer.

Attention ce n’est pas quelque chose de trivial et une erreur peut vite arriver.

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-fTrhDA4maKU%2FU-qDRkSCJAI%2FAAAAAAAABco%2FXGkVeZUb9jo%2Fimage28_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F* 

 

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-D0VtxSZLI0g%2FU-qDS8StxfI%2FAAAAAAAABc4%2FTtu4bSH5ysE%2Fimage32_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

Incrementation du Pool RID

Nous allons maintenant faire l’incrémentation du Pool RID

Vérifier la valeur du Pool RID avec la commande suivante :

Get-ADObject –Filter {ObjectClass –eq “rIDManager”} –Properties rIDAvailablePool

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh4.ggpht.com%2F-d7R1bKo2FSU%2FU-qDUHPtP6I%2FAAAAAAAABdE%2FzDnM4tQz9EI%2Fimage110_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Incrémenter la valeur du Pool RID de 100 000 avec les commandes suivantes :

$RIDManager = Get-ADObject –Filter {ObjectClass –eq “rIDManager”} –Properties rIDAvailablePool

$RIDManager.rIDAvailablePool = $RIDManager.rIDAvailablePool + 100000

Set-ADObject –Instance $RIDManager

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-FFMFf5Xxqvo%2FU-qDUwI51VI%2FAAAAAAAABdU%2FVFGu-gHrvzM%2Fimage114_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Vérifier la valeur du Pool RID a bien été incrémenté avec la commande suivante :

Get-ADObject –Filter {ObjectClass –eq “rIDManager”} –Properties rIDAvailablePool

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-lRTkzs9XGlE%2FU-qDV3vdEWI%2FAAAAAAAABdk%2FflllWaUTlNc%2Fimage118_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Reinitialisation du mot de passe Machine

Réinitialiser 2 fois le mot de passe Machine du Contrôleur de domaine avec la commande suivante :

Netdom /resetpwd /server:”Nom du DC” /uD:”Compte Administrateur” /pD:”Mot de passe du compte Administrateur”

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh3.ggpht.com%2F-NcITbMnM5AY%2FU-qDXFiYpfI%2FAAAAAAAABd0%2FxCN4X1LK2DY%2Fimage122_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

Reinitialisation du mot de passe du compte KRBTGT

Réinitialiser 2 fois le mot de passe du compte “krbtgt” avec la commande suivante :

Set-ADAccountPassword –Identity “krbtgt” –Reset

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh4.ggpht.com%2F-4H2OSITntrM%2FU-qDYOuhu7I%2FAAAAAAAABeI%2FGwD6PV0v--0%2Fimage126_thumb.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

Dans notre cas il n’y a pas de relation d’approbation donc nous n’effectuons pas de réinitialisation du mot de passe des relations d’approbation.

De  même étant dans une forêt mono-domaine nous n’enlevons pas le catalogue global du Contrôleur de domaine.

Fin de la restauration

Nous pouvons maintenant réactiver la synchronisation initiale en modifiant la valeur  de l’entrée HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations

Lui attribuer la valeur “1”.

https://images-blogger-opensocial.googleusercontent.com/gadgets/proxy?url=http%3A%2F%2Flh4.ggpht.com%2F-m3v5v_JtFYY%2FU-qDbQcwNSI%2FAAAAAAAABeY%2Fz9qRptrKODE%2Fimage134_thumb1.png%3Fimgmax%3D800&container=blogger&gadget=a&rewriteMime=image%2F*

 

On peut redémarrer notre Contrôleur de domaine, la restauration de la forêt est terminée.

Il faut maintenant vérifier l’état du Contrôleur de domaine (net share, dcdiag, …), refaire une nouvelle sauvegarde puis promouvoir un second contrôleur de domaine.