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

1. server1 (Windows Server 2008): DC récemment rétrogradé, serveur de fichiers
2. server3 (Windows Server 2008 R2): Nouveau DC
3. 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

1. 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 .
2. 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 .
3. Nettoyage des métadonnées. Après avoir utilisé ntdsutilpour nettoyer les métadonnées comme décrit dans cet article TechNet , la ntdsutilcommande list servers in sitene renvoie que deux entrées, qui semblent toutes les deux OK:
   1. 0 - CN = SERVER4, CN = Servers, CN = Default-First-Site, CN = Sites, CN = Configuration, DC = mydomain, DC = local
   2. 1 - CN = SERVER3, CN = Servers, CN = Default-First-Site, CN = Sites, CN = Configuration, DC = mydomain, DC = local
4. 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 .
5. 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.
6. Réenregistrement avec DNS et redémarrage de netlogon . Un message du forum a suggéré de lancer ipconfig /registerdnset net stop netlogon && net start netlogonsur les nouveaux serveurs pour résoudre un problème connexe. Cela n'a pas semblé aider.
7. 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?

Il s'agit d'un serveur de fichiers - les utilisateurs s'y connectent-ils pour accéder aux fichiers? C'est probablement ce que vous voyez. Ceux-ci apparaîtront dans les journaux de sécurité.

Publiez des entrées de journal (dans leur intégralité - vidage de texte ou capture d'écran) à partir de server1 qui montre le comportement qui vous préoccupe.

/ Modifier - Merci d'avoir confirmé. Le type d'ouverture de session 3 est «Réseau». Le plus souvent vu lors de l'accès aux fichiers partagés ou aux imprimantes sur l'ordinateur qui a enregistré l'événement.

Un contrôleur de domaine rétrogradé ne continuera en aucun cas à authentifier les ouvertures de session de domaine. Ce que vous voyez, ce sont des événements d'ouverture de session locaux . Lorsque vous vous connectez à un serveur membre avec des informations d'identification de domaine, vous verrez les événements d'ouverture de session localement, ainsi que les événements de validation des informations d'identification correspondants sur DC.

Lorsque vous vous connectez au serveur membre avec des informations d'identification locales, vous voyez toujours les événements d'ouverture de session localement, mais vous ne verrez aucun événement de validation des informations d'identification sur DC.