Préparer une forêt et un domaine pour l'installation du premier contrôleur de domaine sous Windows 2016

Préparer une forêt pour l'installation du premier contrôleur de domaine sous Windows 2016

La version du schéma d'une forêt active directory définit la version maximale du système d'exploitation d'un contrôleur de domaine supportée sur tous les domaines de la forêt.

Dans le tableau ci-dessous, toutes les valeurs possibles de la version schémas avec la version maximale du système d'exploitation:

La version du schéma	Système d’exploitation
13	Windows 2000
30	Windows 2003
31	Windows 2003 R2
44	Windows 2008
47	Windows 2008 R2
56	Windows 2012
69	Windows 2012 R2
87	Windows 2016

Les différentes méthodes possibles pour la préparation de la forêt:

L'augmentation de la version du schéma est irréversible, pour le retour en arrière, il faut restaurer toute la forêt.
Dans les grandes structures, pendant la préparation de la forêt ,il est recommandé de mettre le contrôleur de domaine maître du schéma (ou on doit lancer la préparation de la forêt) en mode déconnecté , afin de s'assurer que l'opération s'est bien déroulée localement avant de laisser la nouvelle version se propager via le mécanisme de la réplication active directory.

Via l'assistant :

A partir de la version Windows 2012, la préparation de la forêt peut s'effectuer automatiquement lors de la promotion du premier contrôleur via l'assistant d'installation en utilisant un compte membre du groupe administrateurs du schéma et de l'entreprise.
Cette méthode est utile surtout quand tous les contrôleurs du domaine root sont installés sur un système d'exploitation 32 bit.

Via la commande adprep:

Pour augmenter la version du schéma manuellement via la commande adprep , il faut préparer les prérequis suivants:

1. Utiliser un compte membre du groupe administrateurs du schéma et administrateurs de l'entreprise
2. Utiliser un CD d'installation Windows 2016 avec la même langue que le contrôleur de domaine maître du schéma pour lancer commande adprep.
3. Le système d'exploitation du maître du schéma soit 64 bit, les CD d'installation Windows 2016 ne propose pas une version adprep 32 bit.

Une fois que tous les prérequis sont présents, on peut lancer la préparation de la forêt via la commande ci-dessous depuis le CD d'installation du Windows 2016 :

d:\support\adprep\adprep /forestprep

Un message d'avertissement s'affiche pour demande la confirmation de la mise à jour du schéma :

Comment vérifier la préparation de la forêt:

Via l'invite de commande:

Pour vérifier la version du schéma et si on est capable d'ajouter un contrôleur de domaine sous Windows 2016, on peut lancer les deux commandes ci-dessous afin d'afficher la version du schéma actuelle:

dsquery * cn=schema,cn=configuration,dc=lab,dc=lan -scope base -attr Objectversion

schupgr

Il existe un autre attribut revision qui nous permet aussi de vérifier la préparation de la forêt qui doit être égale à 16 pour Windows 2016: 

dsquery * CN=ActiveDirectoryUpdate,CN=ForestUpdates,cn=configuration,dc=lab,dc=lan -scope base -attr revision

Via l'outil Adsiedit.msc:

Il est aussi possible d'utiliser l'outil Adsiedit.msc installé avec le module d'administration active directory pour connaitre la valeur de l'attribut ObjectVersion :

La même chose pour l'attribut Revision:

Préparer un domaine pour l'installation du premier contrôleur de domaine sous Windows 2016

Via l'assistant:

Lors de la promotion du premier contrôleur de domaine sous Windows 2016, la préparation du domaine sera lancé automatiquement via l'assistant de l’installation vue que le compte utilisé pour la promotion d'un contrôleur de domaine est déjà membre du groupe Domain Admins.

Via la commande adprep:

Dans le cas d'une mise à niveau sur place d'un contrôleur de domaine vers Windows 2016, il faut lancer en avance la préparation du domaine manuellement via la commande adprep depuis un CD d'installation Windows 2016.

Pour lancer la préparation du domaine manuellement via la commande adprep , il faut préparer les prérequis suivants:

1. Utiliser un compte membre du groupe Admins du domaine du domaine en question
2. Utiliser un CD d'installation Windows 2016 avec la même langue que le contrôleur de domaine maître du schéma pour lancer commande adprep.
3. Le système d'exploitation du maître d'infrastructure soit 64 bit, le CD d'installation Windows 2016 ne propose pas une version adprep 32 bit.

Une fois que tous les prérequis sont présents, on peut lancer la préparation du domaine à travers la commande ci-dessous depuis leCD d'installation du Windows 2016 :

d:\support\adprep\adprep /domainprep

Comment vérifier la préparation du domaine:

Via l'invite de commande:

On peut vérifier la préparation du domaine via la commande ci-dessous:

dsquery * CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,dc=lab,dc=lan -scope base -attr revision

Il faut avoir la valeur 15 pour Windows 2016.

Via l'outil adsiedit.msc:

Il est possible aussi de vérifier la valeur de l'attribut revision via l'outils adsiedit.msc:

  

Mise à niveau sur place d'un contrôleur de domaine

     Avec l'arrivé du Windows 2012, il est possible de lancer la mise à niveau sur place pour augmenter la version du système de l'exploitation du contrôleur de domaine.

Prérequis pour une mise à niveau sur place d'un contrôleur de domaine

• Choisir une version cible supportée:

le choix de la version cible dépend de celle du système d'exploitation du contrôleur de domaine.
Le tableau ci-dessous , présente tous les chemins de mise à niveau supportés.

Version de Windows	Version Windows cible supportée
Windows 2008 SP2 ou Windows 2008 R2 Standard et entreprise	Windows 2012 ou Windows 2012 R2 Standard ou Datacenter
Windows 2008 SP2 ou Windows 2008 R2 Datacenter	Windows 2012 ou Windows 2012 R2 Datacenter
Windows 2012 Standard	Windows 2012 R2 ou Windows 2016 Standard ou Datacenter
Windows 2012 Datacenter	Windows 2012 R2 ou Windows 2016 Datacenter
Windows 2012 Standard	Windows 2016 Standard ou Datacenter
Windows 2012 Datacenter	Windows 2016  Datacenter

Les versions d'évaluation ne peuvent être utilisées qu'avec les versions d’évaluation. Si non vous aurez ce message:

• La langue de la version du système d'exploitation cible:

Le système d'exploitation cible doit avoir la même langue utilisée par la version actuelle du contrôleur de domaine.

• Préparer la forêt et le domaine:

Quand on ajoute un nouveau contrôleur de domaine sous Windows 2012 ou plus pour la première fois, la préparation de la forêt et du domaine se lancent automatiquement lors de la promotion du contrôleur du domaine si on utilise un compte qui a les permissions nécessaires.

Par contre , la mise à niveau sur place nécessite une préparation de la forêt et du domaine  manuellement via la commande adprep depuis le CD d'installation du système d'exploitation cible.

Pour avoir plus de détails concernant la préparation de la forêt et du domaine active directory, je vous invite à consulter l'article suivant:

Préparer une forêt et un domaine pour l'installation du premier contrôleur de domaine sous Windows 2016

• Désinstaller les composants non-compatible:

Si vous avez des agents ou applications installés sur le contrôleur de domaine qui sont incompatible avec la version cible , il faut les désinstaller avant.

L'appartenance à un groupe et les tickets Kerberos

Les tickets Kerberos déjà délivrés avant le changement de l'appartenance à un groupe d'un compte utilisateur ou ordinateur ne prennent pas en compte ces modifications.

Pour la prise en compte les mises à jour de l'appartenance à un groupe, il faut attendre le prochain renouvellement du ticket kerberos après:

• La réouverture de session utilisateur s'il s'agit d'un compte utilisateur
• Le redémarrage de la machine s'il s'agit d'un compte ordinateur
• L'expiration des tickets Kerberos mis en cache
• La suppression des tickets Kerberos via la commande klist

Pour forcer le renouvellement immédiat du ticket kerberos , il faut juste purger tous les tickets kerberos en cache. Cela vous permettra d'éviter d'attendre la date de l'expiration la fermeture du session utilisateur ou le redémarrage du l'ordinateur.

On va expliquer comment  purger les tickets kerberos en cache liés au compte utilisateur ou ordinateur dans la suite de cet aricle.

Pour afficher tous les tickets kerberos d'un utilisateur, il suffit de lancer la commande suivante:

klist

Pour purger les tickets kerberos liés au compte utilisateur, il faut lancer la commande suivante:

klist purge

Pour afficher les tickets kerberos liés au compte ordinateur, il faut exécuter la commande suivante:

klist -li 0x3e7

Pour purger les tickets kerberos liés au compte ordinateur , il faut lancer la commande suivante:

klist -li 0x3e7 purge

Bug d'affichage du niveau fonctionnel Windows Server 2016

Quand vous installer le premier contrôleur de domaine sous Windows 2016 dans un nouveau domaine, dans la liste des niveaux fonctionnels, vous pouvez trouver Windows Server Preview à la place du Windows 2016:

N'inquiétez pas , c'est juste un bug d'affichage , pour le corriger, il suffit d'installer les dernières mises à jour :

Gérer l'emplacement des rôles FSMO

Transférer les rôles FSMO vers un autre contrôleur de domaine:

Le rôle Gestionnaire du pool RID , le Maitre d'infrastructure et le PDC sont gérés au niveau du domaine. Pour les déplacer il faut utiliser un compte membre du groupe Admins du domaine.

Le rôle contrôleur de schéma, est géré au niveau du domaine root de la forêt. Pour le déplacer, il faut utiliser un compte membre du groupe Administrateur du schéma.

Le rôle maître des noms du domaine, est géré au niveau du domaine root de la forêt. Pour le déplacer, il faut utiliser un compte membre du groupe Administrateur de l'entreprise.

Déplacer les rôles FSMO via l'interface graphique:

Transférer les rôles gestionnaires du pool RID ,PDC et maître d'infrastructure via l'interface graphique:

Ouvrir la console Utilisateurs et ordinateurs active directory, se connecter sur le contrôleur de domaine cible, cliquer sur le bouton droit sur le nom du domaine et cliquer sur maîtres d'opération:

Une fenêtre s'affiche avec trois onglets (RID,PDC,Infrastructure), dans chaque onglet cliquer sur Change et puis sur close:

Transférer le rôle maître des noms de domaine:

Depuis la console Domains and Trusts, se connecter sur le contrôleur de domaine cible, puis cliquer sur le bouton droit sur Active Directory Domains and trusts et cliquer sur Operations Master:

Une fenêtre s'affiche indiquant l'emplacement actuel du rôle Domain naming operation master , cliquer sur Change pour le transférer vers le contrôleur de domaine cible :

Transférer le contrôleur du schéma via l'interface graphique:

Pour activer la console Active Directory Schema , taper la commande regsvr32 schmmgmt.dll:

Pour ouvrir la console Active Directory Schema, taper la commande mmc:

Cliquer sur File puis sur ADD/Remove Snap-in:

Sélectionner la console Active Directory Schema et cliquer sur Add puis sur OK:  

Depuis la console Active Directory Schema , se connecter sur le contrôleur de domaine cible, cliquer avec le bouton droit sur Active Directory Schema, puis sur Operation Master:

Une fenêtre s'affiche indiquant l'emplacement actuel du rôle contrôleur du schéma, cliquer sur Change transférer le rôle:

Déplacer les rôles FSMO via PowerShell:

Pour transférer les rôles FSMO via PowerShell , il faut utiliser Windows 8.1, Windows 10, Windows 2012 R2 ,Windows 2016 ou bien installer PowerShell 4.0.

Pour transférer un rôle FSMO vers un autre contrôleur de domaine via PowerShell, il faut lancer cette commande:

Move-ADDirectoryServerOperationMasterRole -Identity Target_DC_Name -operationMasterrole fsmo_role_name

Ci-dessous un exemple d'une commande pour déplacer le rôle Schema Master vers le contrôleur de domaine DC1:

Il est possible également de déplacer plusieurs rôle à travers une seule commande powershell:

Move-ADDirectoryServerOperationMasterRole -Identity Target_DC_Name -operationMasterrole fsmo_role_name1, fsmo_role_name2, fsmo_role_name3, fsmo_role_name4, fsmo_role_name5

Ci-dessous un exemple de basculement de tous les rôles FSMO vers le contrôleur de domaine DC2:

Déplacer les rôles FSMO via l'invite de commande:

Pour déplacer les rôles FSMO via l'invite, il suffit d'exécuter cette commande:

ntdsutil "roles" "connections" "connect to server Tagget_DC_Name" q "transfer fsmo_role_name" q q q

Ci-dessous un exemple pour déplacer le rôle schema master vers le contrôleur de domaine DC2:

Il est possible d'utiliser la même commande pour déplacer plusieurs rôles:

ntdsutil "roles" "connections" "connect to server Tagget_DC_Name" q "transfer fsmo_role_name1" "transfer fsmo_role_name2" "transfer fsmo_role_name3" "transfer fsmo_role_name4" "transfer fsmo_role_name5" q q q

Dans l'exemple ci-dessous, une seule commande qui a été lancée pour transférer tous les rôles FSMO vers le contrôleur de domaine DC2:

Seizing de rôles FSMO :

Si un contrôleur de domaine avec un ou plusieurs rôles FSMO ne peut plus contacter ses partenaires suite à un problème hardware ou réseaux, pour récupérer les rôles FSMO sur un autre domaine on ne peut pas lancer l'opération de transfert (expliquée ci-dessus) , vue que le contrôleur de domaine source est injoignable. Dans ce cas il faut lancer l'opération de Seizing via cette commande :

ntdsutil "roles" "connections" "connect to server Tagget_DC_Name" q "Seize fsmo_role_name" q q q

Dans l'exemple ci-dessous, une commande pour le lancer l'opération du Seizing du rôle Schema master vers DC2:

On peut également lancer l'opération de Seizing de plusieurs rôles FSMO via une seule commande:

ntdsutil "roles" "connections" "connect to server Tagget_DC_Name" q "Seize fsmo_role_name1" "Seize  fsmo_role_name2" "Seize  fsmo_role_name3" "Seize  fsmo_role_name4" "Seize  fsmo_role_name5" q q q

Dans l'exemple ci-dessous, une commande pour lancer le seizing de tous des rôles vers DC2:

NB : Si vous avez lancé le seizing d'un ou plusieurs rôles FSMO, il ne faut pas  reconnecter  l’ancien serveur au réseau, pour le réutiliser, il faut le rétrograder manuellement via la procédure Metadata CleanUp ensuite le réinstaller à nouveau .

Problème de réplication active directory suite à une restauration USN (Rollback USN)

 USN (Update Sequence Number):

L'USN (Update Sequence Number) permet de gérer la réplication des modifications effectuées sur les objets active directory.
Chaque contrôler de domaine incrémente son propre nombre USN à chaque modification d'un objet.
A la prochaine réplication, ses partenaires vont détecter les modifications effectuées grâce à la nouvelle valeur d'USN qui est supérieur à l'USN de la dernière réplication.

La restauration d'un contrôleur de domaine à travers une solution de sauvegarde non supporté  pourra créer un problème au niveau de la réplication suite à une restauration USN (Rollback USN).

Comment connaitre les symptômes de la restauration USN (Update Sequence Number):

•  Pas de réplication:

Si vous avez le problème USN Rollback, le premier symptôme constaté est le blocage de la réplication.
Comme l'indique la figure ci-dessous, quand vous lancer la commande repadmin /showrepl, vous aurez un message d'erreur indiquant que "le serveur de destination rejette actuellement les demandes de réplication":

Il est aussi impossible de forcer la réplication à travers la commande repadmin /syncall en cas de Rollback USN, comme l'indique la figure ci-dessous:

• Incohérence au niveau de l'USN du contrôleur de domaine endommagé:

 La vérification du nombre USN  permet de détecter et identifier la restauration USN.
Si la valeur de l'USN local d'un contrôleur de domaine est inférieure à celle enregistrée sur les autres contrôleurs de domaine cela veut dire qu'il y a une de restauration USN.

La commande repadmin /showutdvec * "dc=domain,dc=lan" permet d'afficher la valeur USN de chaque contrôleur de domaine sur tous les contrôleurs de domaine comme l'indique la figure ci-dessous:

• Le journal d'événement:

Dans le journal d'événement du contrôleur de domaine endommagé par restauration USN, on trouve l'événement d'ID 2095 et Source ActiveDirectory_DomainServices qui explique bien que la réplication a été bloquée suite à un problème Rollback USN:

Comment résoudre le problème du Rollback USN:

Pour résoudre le problème du Rollback USN, il faut arrêter et forcer la suppression du contrôleur de domaine endommagé via la procédure Metadacleanup comme l'explique le lien suivant :

Forcer la suppression d'un contrôleur de domaine via Metadata Cleanup.

Pour déterminer le contrôleur de domaine endommagé, il faut trouver les deux symptômes suivants:

•  L'événement d'ID 2095 et Source ActiveDirectory_DomainServices dans le journal d'événement du contrôleur de domaine endommagé
• Incohérence du nombre USN du contrôleur de domaine endommagé affiché via la commande suivante: repadmin /showutdvec * "dc=domain,dc=lan"
• La valeur 4 dans la clé de registre suivante :HKLM\System\CurrentControlSet\Services\NTDS\Parameters\DSA not Writable

Gérer le mot de passe du compte administrateur de restauration des services active directory DSRM

Modifier le mot de passe du compte administrateur de restauration des services active directory (DSRM) via l'invite de commande :

Pour modifier le mot de passe administrateur de restauration active directory sur un contrôleur de domaine ,ouvrir l'invite de commande et taper la commande suivante :

ntdsutil "set dsrm password" "reset password on server NULL"

Ensuite saisir le nouveau mot de passe deux fois et et taper Q pour quitter:

Utiliser un compte de domaine pour modifier le mot de passe du compte administrateur de restauration des services active directory (DSRM) :

A partir du Windows 2008, il est possible de synchroniser le mot de passe du compte administrateur de restauration des services active directory avec un compte utilisateur du domaine.

 

Pour lancer la synchronisation, il suffit de lancer la commande ci-dessous (dsrm-account est le nom du compte utilisateur de domaine):

 

ntdsutil "set dsrm password" "Sync from domain account DSRM-account" quit quit

 Synchroniser le mot de passe du compte administrateur de restauration des services active directory (DSRM) de tous les contrôleur de domaine avec un seul compte de domaine via Group Policy Preferences:

Si vous avez plusieurs contrôleurs de domaine, la gestion du compte DSRM via la commande ntdsutil devient compliquée .

Pour simplifier  la gestion du mot de passe DSRM de tous les contrôleurs de domaine, vous pouvez déployer une tâche planifiée via GPP sur tous les contrôleurs de domaine, pour forcer la synchronisation du mot de passe DSRM avec un seul compte utilisateur active directory.
Si vous gérer plusieurs domaines, il faut créer un compte active directory et une GPO par domaine.

Dans l'exemple ci-dessous,nous allons montrer comment centraliser et simplifier la gestion du mot de passe DSRM de tous les contrôleurs de domaine à travers un seul compte utilisateur de domaine:

1. Créer un compte utilisateur active directory DSRM.

2. Créer une nouvelle GPO nommé DSRM et l'attacher à l'OU Domain Controllers:

3. Editer le GPO, et aller vers Computer Configuration => Preferences => Control Panel Settings , puis cliquer sur le bouton droit sur Scheduled Tasks =>New => Scheduled Task (At least Windows 7) comme indiqué dans la figure ci-dessous:

Remarque:

Si vous choisissez l'option Scheduled Task , la tâche planifiée sera créée que sur les contrôleurs de domaine installés sous Windows 2008 et Windows 2008R2.

Si vous avez des contrôleurs de domaine sous Windows 2012 R2 ou plus , il faut choisir l'option Scheduled Task (At least Windows 7).

4. Configurer la tâche planifiée en indiquant le nom de tâche et le compte NT AUTHORITY\SYSTEM  pour l'exécuter et cocher l'option Run whether user is logged on or not:

5. Définir la fréquence de l'exécution de la tâche depuis l'onglet Triggers:

6. Dans l'onglet Actions, cliquer sur new pour créer une nouvelle action:

Dans la fenêtre New Action ,  il faut définir les valeurs mentionnées dans la figure ci-dessous :

Action => Start a program 

Program/script => ntdsutil

Add arguments (optional) => "Set DSRM Password" "Sync from domain account dsrm" quit quit