Perché un controller di dominio degradato sta ancora autenticando gli utenti?

Ogni volta che gli utenti accedono a workstation con account di dominio, questo DC declassato li autentica. Il registro di sicurezza mostra i loro accessi, disconnessioni e accessi speciali. I log di sicurezza dei nostri nuovi controller di dominio mostrano alcuni accessi e disconnessioni della macchina, ma nulla a che fare con gli utenti del dominio.

sfondo

1. server1 (Windows Server 2008): DC, file server recentemente retrocesso
2. server3 (Windows Server 2008 R2): nuovo controller di dominio
3. server4 (Windows Server 2008 R2): nuovo controller di dominio

logs

Eventi del registro di sicurezza: http://imgur.com/a/6cklL .

Due eventi di esempio dal 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

Esempio di evento di modifica della politica di controllo dal server3 ( nel registro sono presenti anche eventi di modifica della politica di controllo con le modifiche contrassegnate come "Aggiunta riuscita"):

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

Tentativo di soluzioni

1. Correzione di voci DNS. dcdiag /test:dnsinizialmente restituito errori dopo che il server1 è stato retrocesso. Ad esempio, c'erano voci del server dei nomi obsolete nelle nostre aree di ricerca diretta. Ho finito per aprire DNS Manager e rimuovere manualmente le voci problematiche, assicurando anche che le voci LDAP e Kerberos indicassero i nuovi server. Ad esempio, __ldap.Default-First-Site .__ sites.dc .__ msdcs.mydomain.local_ punta a server3.mydomain.local .
2. Verifica delle voci DNS con nslookup. nslookup -type=srv _kerberos._udp.mydomain.localrestituisce le voci per server3 e server4 —nulla di server1 .
3. Pulizia dei metadati. Dopo aver usato ntdsutilper ripulire i metadati come descritto in questo articolo TechNet , il ntdsutilcomando list servers in siterestituisce solo due voci, che sembrano entrambe a posto:
   1. 0 - CN = SERVER4, CN = Server, CN = Default-First-Site, CN = Sites, CN = Configuration, DC = mydomain, DC = local
   2. 1 - CN = SERVER3, CN = Server, CN = Default-First-Site, CN = Sites, CN = Configuration, DC = mydomain, DC = local
4. Eliminazione di server1 da siti e servizi di Active Directory. Dopo aver retrocesso il server1 , ho notato che rimaneva in siti e servizi di Active Directory, sebbene non fosse più elencato come catalogo globale. L'ho eliminato secondo le istruzioni in questo articolo di Microsoft KB .
5. Trasferimento di ruoli master operazioni su server3 . I ruoli di master operazioni sono un po 'oltre la mia comprensione, ma stamattina ntdsutilli trasferivo tutti su server3 . Non si sono verificati errori, ma riavvii e test hanno dimostrato che server1 stava ancora eseguendo tutta l'autenticazione.
6. Registrare nuovamente con DNS e riavviare netlogon . Un post sul forum ha suggerito di eseguire ipconfig /registerdnse net stop netlogon && net start netlogonsui nuovi server per risolvere un problema correlato. Non sembra aiutare.
7. Garantire che l'oggetto Criteri di gruppo vincente sui nuovi controller di dominio consenta il controllo degli eventi di accesso e di accesso all'account.

Altri cavi

• Lo stesso problema è descritto in questa serie di post sul forum . Non c'è risoluzione.
• È anche descritto in questa domanda sullo scambio di esperti . Il commento contrassegnato come una risposta recita "Se il suo non è più un controller di dominio, non è possibile elaborare alcuna richiesta di autenticazione". Questa sarebbe la mia reazione, ma l'esecuzione dcdiagsu server1 conferma che server1 non si considera un controller di dominio. Eppure è ancora l'unico server che autentica tutti.

Cosa sta succedendo qui?

È un file server: gli utenti si connettono ad esso per ottenere l'accesso ai file? Questo è probabilmente quello che stai vedendo. Quelli sarebbero mostrati nei registri di sicurezza.

Pubblica alcune voci di registro (nella loro interezza - dump di testo o screenshot) dal server1 che mostra il comportamento di cui ti preoccupi.

/ Modifica - Grazie per aver confermato. Tipo di accesso 3 è "Rete". Più spesso visualizzato quando si accede a file condivisi o stampanti sul computer che ha registrato l'evento.

Un controller di dominio declassato non continuerà in alcun modo ad autenticare gli accessi al dominio. Quello che vedi sono gli eventi di accesso locali . Quando si accede a un server membro con credenziali di dominio, verranno visualizzati gli eventi di accesso localmente, oltre agli eventi di convalida delle credenziali corrispondenti su DC.

Quando si accede al server membro con credenziali locali, vengono comunque visualizzati gli eventi di accesso localmente, ma non verranno visualizzati eventi di convalida delle credenziali su DC.