Pourquoi un contrôleur de domaine rétrogradé authentifie-t-il toujours les utilisateurs?
Chaque fois que les utilisateurs se connectent à des postes de travail avec des comptes de domaine, ce contrôleur de domaine rétrogradé les authentifie. Son journal de sécurité affiche leurs connexions, déconnexions et connexions spéciales. Les journaux de sécurité de nos nouveaux contrôleurs de domaine montrent des ouvertures et des fermetures de session sur les machines, mais rien à voir avec les utilisateurs du domaine.
Contexte
- server1 (Windows Server 2008): DC récemment rétrogradé, serveur de fichiers
- server3 (Windows Server 2008 R2): Nouveau DC
- server4 (Windows Server 2008 R2): Nouveau DC
Journaux
Événements du journal de sécurité: http://imgur.com/a/6cklL .
Deux exemples d'événements de server1 :
Audit Success,3/31/2014 11:06:14 AM,Microsoft-Windows-Security-Auditing,4624,Logon,"An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
New Logon:
Security ID: MYDOMAIN\auser
Account Name: auser
Account Domain: MYDOMAIN
Logon ID: 0x8b792ce
Logon GUID: {54063226-E9B7-D357-AD58-546793C9CA59}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name:
Source Network Address: 192.168.20.143
Source Port: 52834
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
[ ... ]
Audit Success,3/31/2014 11:06:06 AM,Microsoft-Windows-Security-Auditing,4624,Logon,"An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
New Logon:
Security ID: MYDOMAIN\anotheruser
Account Name: anotheruser
Account Domain: MYDOMAIN
Logon ID: 0x8b74ea5
Logon GUID: {7E74986A-7A4D-B6E0-5D6F-D8CF78E8C718}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name:
Source Network Address: 192.168.20.203
Source Port: 53027
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
Exemple d' événement Audit Policy Change de server3 (il y a aussi des événements Audit Policy Change dans le journal avec des changements marqués "Success Added"):
System audit policy was changed.
Subject:
Security ID: SYSTEM
Account Name: SERVER3$
Account Domain: MYDOMAIN
Logon ID: 0x3e7
Audit Policy Change:
Category: Account Logon
Subcategory: Kerberos Authentication Service
Subcategory GUID: {0cce9242-69ae-11d9-bed3-505054503030}
Changes: Success removed
Solutions tentées
- Correction des entrées DNS.
dcdiag /test:dnsa d'abord renvoyé des erreurs après la rétrogradation de server1 . Par exemple, il y avait des entrées de serveur de noms obsolètes dans nos zones de recherche directe. J'ai fini par ouvrir le Gestionnaire DNS et supprimer manuellement les entrées problématiques, en veillant également à ce que les entrées LDAP et Kerberos pointent vers les nouveaux serveurs. Par exemple, __ldap.Default-First-Site .__ sites.dc .__ msdcs.mydomain.local_ pointe vers server3.mydomain.local . - Vérification des entrées DNS avec
nslookup.nslookup -type=srv _kerberos._udp.mydomain.localrenvoie des entrées pour server3 et server4 - rien sur server1 . - Nettoyage des métadonnées. Après avoir utilisé
ntdsutilpour nettoyer les métadonnées comme décrit dans cet article TechNet , lantdsutilcommandelist servers in sitene renvoie que deux entrées, qui semblent toutes les deux OK:- 0 - CN = SERVER4, CN = Servers, CN = Default-First-Site, CN = Sites, CN = Configuration, DC = mydomain, DC = local
- 1 - CN = SERVER3, CN = Servers, CN = Default-First-Site, CN = Sites, CN = Configuration, DC = mydomain, DC = local
- Suppression de server1 des sites et services Active Directory. Après rétrogradation de server1 , j'ai remarqué qu'il restait dans les sites et services Active Directory, bien qu'il ne soit plus répertorié comme catalogue global. Je l'ai supprimé conformément aux instructions de cet article Microsoft KB .
- Transfert des rôles de maître d'opérations vers le serveur 3 . Les rôles de maître d'opérations sont un peu au-delà de mes limites, mais je les
ntdsutiltransférais tous à server3 ce matin. Il n'y a pas eu d'erreur, mais les redémarrages et les tests ont montré que server1 faisait toujours toute l'authentification. - Réenregistrement avec DNS et redémarrage de netlogon . Un message du forum a suggéré de lancer
ipconfig /registerdnsetnet stop netlogon && net start netlogonsur les nouveaux serveurs pour résoudre un problème connexe. Cela n'a pas semblé aider. - S'assurer que l'objet de stratégie de groupe gagnant sur les nouveaux contrôleurs de domaine permet l'audit des événements de connexion et de connexion au compte.
Autres pistes
- Le même problème est décrit dans cette série de messages sur le forum . Il n'y a pas de résolution.
- Il est également décrit dans cette question sur Experts Exchange . Le commentaire marqué comme une réponse se lit comme suit: "Si ce n'est plus un contrôleur de domaine, il n'y a aucun moyen qu'il puisse traiter des demandes d'authentification." Ce serait ma réaction, mais courir
dcdiagsur server1 confirme que server1 ne se considère pas comme un DC. Pourtant, c'est toujours le seul serveur authentifiant tout le monde.
Que se passe t-il ici?