Warum authentifiziert ein herabgestufter Domänencontroller immer noch Benutzer?
Wenn sich Benutzer mit Domänenkonten an Arbeitsstationen anmelden, werden sie von diesem herabgestuften Domänencontroller authentifiziert. Das Sicherheitsprotokoll zeigt die Anmeldungen, Abmeldungen und speziellen Anmeldungen an. In den Sicherheitsprotokollen unserer neuen Domänencontroller werden einige Computeranmeldungen und -abmeldungen angezeigt, die jedoch nichts mit Domänenbenutzern zu tun haben.
Hintergrund
- server1 (Windows Server 2008): Kürzlich herabgestufter DC-Dateiserver
- Server3 (Windows Server 2008 R2): Neuer DC
- server4 (Windows Server 2008 R2): Neuer DC
Protokolle
Sicherheitsprotokollereignisse: http://imgur.com/a/6cklL .
Zwei Beispielereignisse von 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
Beispiel Audit - Richtlinienänderung Ereignis von server3 (es gibt auch Audit - Richtlinienänderung Ereignisse im Protokoll mit Änderungen markiert „Erfolg 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
Lösungsversuche
- DNS-Einträge korrigieren.
dcdiag /test:dnsZuerst wurden Fehler zurückgegeben, nachdem Server1 herabgestuft wurde. In unseren Forward-Lookup-Zonen gab es beispielsweise veraltete Nameserver-Einträge. Am Ende habe ich den DNS-Manager geöffnet und die Problemeinträge manuell entfernt, um sicherzustellen, dass LDAP- und Kerberos-Einträge auf die neuen Server verweisen. Zum Beispiel zeigt __ldap.Default-First-Site .__ sites.dc .__ msdcs.mydomain.local_ auf server3.mydomain.local . - Überprüfen von DNS-Einträgen mit
nslookup. Gibtnslookup -type=srv _kerberos._udp.mydomain.localEinträge für Server3 und Server4 zurück - nichts über Server1 . - Bereinigen von Metadaten. Nach der Verwendung
ntdsutilzum Bereinigen von Metadaten wie in diesem TechNet-Artikel beschrieben gibt derntdsutilBefehllist servers in sitenur zwei Einträge zurück, die beide in Ordnung aussehen:- 0 - CN = SERVER4, CN = Server, CN = Standard-First-Site, CN = Sites, CN = Konfiguration, DC = Mydomain, DC = lokal
- 1 - CN = SERVER3, CN = Server, CN = Standard-First-Site, CN = Sites, CN = Konfiguration, DC = Mydomain, DC = lokal
- Löschen von Server1 von Active Directory-Standorten und -Diensten . Nach dem Herabstufen von server1 stellte ich fest, dass es in Active Directory-Sites und -Diensten verbleibt, obwohl es nicht mehr als globaler Katalog aufgeführt ist. Ich habe es gemäß den Anweisungen in diesem Microsoft KB-Artikel gelöscht .
- Übertragen von Operationsmaster-Rollen auf Server3 . Operations Master-Rollen sind etwas jenseits meines Wissens, aber ich habe
ntdsutilsie heute Morgen alle auf Server3 übertragen . Es gab keine Fehler, aber Neustarts und Tests zeigten, dass Server1 immer noch die gesamte Authentifizierung durchführte. - Erneutes Registrieren bei DNS und Neustarten der Netzanmeldung . Ein Forum Post vorschlug läuft
ipconfig /registerdnsundnet stop netlogon && net start netlogonauf den neuen Server ein verwandtes Problem zu beheben. Es schien nicht zu helfen. - Stellen Sie sicher, dass das Gewinner-Gruppenrichtlinienobjekt auf den neuen Domänencontrollern die Überwachung auf Anmelde- und Kontoanmeldeereignisse ermöglicht.
Andere Leads
- Das gleiche Problem wird in dieser Reihe von Forenbeiträgen beschrieben . Es gibt keine Lösung.
- Es wird auch in dieser Frage auf Experts Exchange beschrieben . Der als Antwort gekennzeichnete Kommentar lautet: "Wenn der DC kein DC mehr ist, kann er auf keinen Fall Authentifizierungsanforderungen verarbeiten." Das wäre meine Reaktion, aber das Ausführen
dcdiagauf Server1 bestätigt, dass Server1 sich nicht als DC betrachtet. Dennoch ist es immer noch der einzige Server, der alle authentifiziert.
Was ist denn hier los?