Prise de contrôle des rôles FSMO depuis un contrôleur de domaine Windows défaillant

Windows Server & IT Pro Active Directory & Entra ID
1

J’ai vu d’autres questions et documents à ce sujet, mais certaines choses me déroutent encore. Voici les documents et questions que j’ai consultés :

L’environnement contient deux serveurs Windows et de nombreux clients. Le contrôleur de domaine est Windows 2003 SP2 fonctionnant avec un AD natif Windows 2000. L’autre serveur (pas du tout un DC) est Windows 2000 SP4 (il héberge un utilitaire antivirus).

Résultats de netdom query fsmo :

Schema owner                missing.office.local

Domain role owner           myself.office.local

PDC role                    missing.office.local

RID pool manager            missing.office.local

Infrastructure owner        missing.office.local

The command completed successfully.

Résultats de dcdiag :

Domain Controller Diagnosis

Performing initial setup:
   Done gathering initial info.

Doing initial required tests

   Testing server: Default-First-Site\MYSELF
      Starting test: Connectivity
         The host 841d395a-2139-49d9-82c1-7c7e31ccb33b._msdcs.office.local could not be resolved to an
         IP address.  Check the DNS server, DHCP, server name, etc
         Although the Guid DNS name
         (841d395a-2139-49d9-82c1-7c7e31ccb33b._msdcs.office.local) couldn't be
         resolved, the server name (MYSELF.office.local) resolved to the IP
         address (192.168.9.101) and was pingable.  Check that the IP address
         is registered correctly with the DNS server.
         ......................... MYSELF failed test Connectivity

Doing primary tests

   Testing server: Default-First-Site\MYSELF
      Skipping all tests, because server MYSELF is
      not responding to directory service requests

   Running partition tests on : ForestDnsZones
      Starting test: CrossRefValidation
         ......................... ForestDnsZones passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones passed test CheckSDRefDom

   Running partition tests on : DomainDnsZones
      Starting test: CrossRefValidation
         ......................... DomainDnsZones passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones passed test CheckSDRefDom

   Running partition tests on : Schema
      Starting test: CrossRefValidation
         ......................... Schema passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Schema passed test CheckSDRefDom

   Running partition tests on : Configuration
      Starting test: CrossRefValidation
         ......................... Configuration passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Configuration passed test CheckSDRefDom

   Running partition tests on : office
      Starting test: CrossRefValidation
         ......................... office passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... office passed test CheckSDRefDom

   Running enterprise tests on : office.local
      Starting test: Intersite
         ......................... office.local passed test Intersite
      Starting test: FsmoCheck
         Warning: DcGetDcName(PDC_REQUIRED) call failed, error 1355
         A Primary Domain Controller could not be located.
         The server holding the PDC role is down.
         ......................... office.local failed test FsmoCheck

Voici mes questions (pardonnez-moi si elles sont trop basiques) :

  • Les rôles listés par netdom query fsmo sont-ils les mêmes que ceux que j’ai vus mentionnés ailleurs ? Par exemple, Domain role owner est-il identique à Domain Naming Master ? RID Pool Manager est-il identique au rôle RID ?

  • Quels sont les problèmes qui pourraient survenir si je prends le contrôle de l’un de ces rôles ?

  • Les utilisateurs le remarqueront-ils ?

  • Cette configuration fonctionne depuis longtemps et les gens travaillent plus ou moins normalement ; la prise de contrôle du rôle PDC va-t-elle changer quelque chose ?

  • Certains de ces documents prédisent de graves conséquences si tous les rôles sont sur un seul DC. Avec une base de clients de maximum 20 - et peut-être moins de 10 la plupart des jours - est-ce que concentrer tous les rôles sur un seul DC est un vrai problème ?

  • Y a-t-il des mises en garde concernant le processus de nettoyage recommandé par Microsoft pour supprimer l’ancien DC d’Active Directory ?

Aussi - une question presque tangentielle - si je devais mettre à niveau le domaine vers un AD Windows 2003 (maintenant ou à l’avenir), cela changerait-il quelque chose dans la prise de contrôle des rôles FSMO ?

PS : Je soupçonne que les problèmes DNS sont liés à la tentative d’utilisation d’un DNS non-Microsoft qui ne prenait pas en charge le DNS dynamique de Microsoft ; je pense qu’un DNS Windows fonctionne mais je n’ai pas encore vérifié son bon fonctionnement et sa configuration.

Source : Server Fault

2

Les rôles listés par netdom query fsmo sont-ils les mêmes que ceux que j’ai vus mentionnés ailleurs ? Par exemple, Domain role owner est-il identique à Domain Naming Master ? RID Pool Manager est-il identique au rôle RID ?

Oui, exactement. Je ne sais pas pourquoi les noms sont légèrement différents dans cet affichage particulier.

Quels sont les problèmes qui pourraient survenir si je prends le contrôle de l’un de ces rôles ?

La prise de contrôle en elle-même ? Pas grand-chose. La plupart des problèmes potentiels signalés concernent la remise en marche de l’ancien DC après la saisie de son rôle - et même dans ce cas, il y a beaucoup d’alarmisme pour pas grand-chose ; il faut des scénarios assez étranges pour casser quoi que ce soit avec une saisie au lieu d’un transfert de rôle. Pour faire une parenthèse, passons en revue les rôles et les risques potentiels :

Maître de schéma : Celui-ci rend tout le monde nerveux, mais le casser n’est pas un scénario très probable. La documentation dit que vous ne devez jamais, au grand jamais, rallumer l’ancien maître de schéma après avoir saisi le rôle, ce que je considère comme alarmiste. L’ancien serveur sera informé du changement de rôle, et dès qu’il le sera, il abandonnera le rôle. Le risque potentiel ici est si des modifications sont apportées au nouveau maître de schéma, puis l’ancien maître de schéma est remis en ligne, puis avant qu’il ne réplique depuis les autres DC, des modifications de schéma différentes et conflictuelles sont effectuées sur l’ancien serveur. Cette situation est improbable, mais détruirait votre domaine.

Maître de nommage : Même principe que pour le maître de schéma, il faudrait effectuer des modifications (dans ce cas, créer un nouveau domaine dans la forêt) sur l’ancien DC, après avoir saisi son rôle mais avant qu’il ne prenne connaissance de la saisie.

Émulateur PDC : Aucun risque, il n’est responsable de rien qui risque de provoquer une divergence.

Maître RID : Il faudrait une structure de réplication défaillante pour casser celui-ci - imaginez que vous avez 2 DC ; un ancien maître RID qui ne sait pas que son rôle a été saisi, et un nouveau maître RID. Dans cette situation, il faudrait créer suffisamment d’objets pour épuiser le pool RID sur les deux (ils sont distribués par lots de 500), et leur faire attribuer des pools qui se chevauchent. Créez des objets avec des RID identiques, reconnectez les contrôleurs de domaine, et regardez l’apocalypse se dérouler.

Maître d’infrastructure : Honnêtement, probablement 50% des domaines dans le monde n’ont même pas un maître d’infrastructure fonctionnel, puisqu’il ne fonctionne pas lorsqu’il est sur un GC. Dans tous les cas, vous ne pouvez pas le casser avec une saisie.

Les utilisateurs le remarqueront-ils ?

Ils ne devraient pas.

Cette configuration fonctionne depuis longtemps et les gens travaillent plus ou moins normalement ; la prise de contrôle du rôle PDC va-t-elle changer quelque chose ?

Non. Avec un seul DC, aucune des fonctions du PDC ne manque, sauf peut-être le fait que votre DC non-PDC ne puisse pas synchroniser l’heure avec la source souhaitée (le PDC manquant).

De plus :

  • Vous ne remarquerez l’absence du maître de schéma que lorsque vous essaierez de mettre à jour le schéma

  • Vous ne remarquerez l’absence du maître de nommage que lorsque vous essaierez de créer un nouveau domaine dans la forêt

  • Vous ne remarquerez l’absence du maître RID que lorsque vous créerez trop d’objets et épuiserez le pool RID de votre DC (c’est probablement le cas le plus probable pour vous si vous continuez tel quel)

  • Vous ne remarquerez l’absence du maître d’infrastructure que pour les mises à jour de groupes du catalogue global dans une forêt multi-domaines

Certains de ces documents prédisent de graves conséquences si tous les rôles sont sur un seul DC. Avec une base de clients de maximum 20 - et peut-être moins de 10 la plupart des jours - est-ce que concentrer tous les rôles sur un seul DC est un vrai problème ?

Non - mais ajoutez un second DC. Vous ne voulez pas que votre unique DC tombe en panne.

Y a-t-il des mises en garde concernant le processus de nettoyage recommandé par Microsoft pour supprimer l’ancien DC d’Active Directory ?

Oui - soyez prudent. Mais affûtez vos outils ntdsutil et supprimez les anciennes données - des données superflues n’aident pas à la maintenabilité du domaine.