Dlaczego zdegradowany kontroler domeny nadal uwierzytelnia użytkowników?

Za każdym razem, gdy użytkownicy logują się na stacjach roboczych przy użyciu kont domeny, ten zdegradowany kontroler domeny uwierzytelnia je. Dziennik bezpieczeństwa pokazuje ich loginy, wylogowania i logowania specjalne. Dzienniki bezpieczeństwa naszych nowych kontrolerów domeny pokazują niektóre logowania do komputera i wylogowania, ale nie mają nic wspólnego z użytkownikami domeny.

tło

1. server1 (Windows Server 2008): Niedawno zdegradowany DC, serwer plików
2. server3 (Windows Server 2008 R2): Nowy kontroler domeny
3. server4 (Windows Server 2008 R2): Nowy kontroler domeny

Kłody

Zdarzenia dziennika bezpieczeństwa: http://imgur.com/a/6cklL .

Dwa przykładowe zdarzenia z serwera 1 :

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

Przykładowe zdarzenie zmiany zasad inspekcji z server3 ( w dzienniku znajdują się również zdarzenia zmian zasad inspekcji ze zmianami oznaczonymi jako „Dodano sukces”):

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

Próby rozwiązań

1. Naprawianie wpisów DNS. dcdiag /test:dnsna początku zwracał błędy po zdegradowaniu serwera server1 . Na przykład w naszych strefach wyszukiwania do przodu były nieaktualne wpisy serwera nazw. Skończyło się na tym, że otworzyłem DNS Managera i ręcznie usunąłem problematyczne wpisy, upewniając się również, że wpisy LDAP i Kerberos wskazują nowe serwery. Na przykład __ldap.Default-First-Site .__ sites.dc .__ msdcs.mydomain.local_ wskazuje na server3.mydomain.local .
2. Weryfikowanie wpisów DNS za pomocą nslookup. nslookup -type=srv _kerberos._udp.mydomain.localzwraca wpisy dla serwer3 i SERWER4 -Nic o server1 .
3. Czyszczenie metadanych. Po użyciu ntdsutiloczyścić metadane w sposób opisany w tym artykule TechNet , z ntdsutilpolecenia list servers in sitezwraca tylko dwa wpisy, które zarówno wygląd OK:
   1. 0 - CN = SERWER 4, CN = serwery, CN = domyślna pierwsza strona, CN = witryny, CN = konfiguracja, DC = moja domena, DC = lokalna
   2. 1 - CN = SERWER3, CN = serwery, CN = domyślna pierwsza strona, CN = witryny, CN = konfiguracja, DC = moja domena, DC = lokalna
4. Usuwanie server1 z witryn i usług Active Directory. Po obniżeniu poziomu serwera server1 zauważyłem, że pozostał on w Witrynach i usługach Active Directory, chociaż nie był już wymieniony jako wykaz globalny. Usunąłem go zgodnie z instrukcjami w tym artykule KB firmy Microsoft .
5. Przeniesienie ról wzorca operacji na serwer 3 . Role wzorca operacji są nieco poza moim zasięgiem, ale tego ranka ntdsutilprzenosiłem je wszystkie na server3 . Nie wystąpiły błędy, ale ponowne uruchomienie i testy wykazały, że serwer1 nadal wykonuje całą autoryzację.
6. Ponowna rejestracja za pomocą DNS i ponowne uruchomienie Netlogon . Post na forum sugeruje uruchomienie ipconfig /registerdnsi net stop netlogon && net start netlogonna nowych serwerach, aby rozwiązać związany z tym problem. To chyba nie pomogło.
7. Zapewnienie, że zwycięski obiekt zasad grupy na nowych kontrolerach domeny umożliwia inspekcję zdarzeń logowania i logowania na konto.

Inne prowadzi

• Ten sam problem opisano w tej serii postów na forum . Brak rozdzielczości.
• Jest to również opisane w tym pytaniu na temat wymiany ekspertów . Komentarz oznaczony jako odpowiedź brzmi: „Jeśli jego [sic] nie jest już kontrolerem domeny, nie ma możliwości przetworzenia żądań uwierzytelnienia”. To byłaby moja reakcja, ale uruchomienie dcdiagna serwerze 1 potwierdza, że serwer 1 nie uważa się za kontrolera domeny. Jednak nadal jest to jedyny serwer uwierzytelniający wszystkich.

Co tu się dzieje?

To serwer plików - czy użytkownicy łączą się z nim, aby uzyskać dostęp do plików? To prawdopodobnie to, co widzisz. Te pojawią się w logach bezpieczeństwa.

Opublikuj niektóre wpisy dziennika (w całości - zrzut tekstowy lub zrzut ekranu) z serwera server1, który pokazuje zachowanie, o które się martwisz.

/ Edytuj - Dziękujemy za potwierdzenie. Typ logowania 3 to „Sieć”. Najczęściej spotykane podczas uzyskiwania dostępu do udostępnionych plików lub drukarek na komputerze, który zarejestrował zdarzenie.

Obniżony kontroler domeny w żaden sposób nie będzie nadal uwierzytelniał logowania do domeny. To, co widzisz, to lokalne logowanie. Gdy zalogujesz się na serwerze członkowskim z poświadczeniem domeny, zobaczysz zdarzenia logowania lokalnie oraz odpowiadające im zdarzenia sprawdzania poprawności poświadczeń na DC.

Gdy logujesz się na serwerze członkowskim przy użyciu lokalnych poświadczeń, nadal widzisz zdarzenia logowania lokalnie, ale nie widzisz żadnych zdarzeń sprawdzania poprawności poświadczeń w DC.