5
Sporadische Domain-User-Sperrungen - neue Domäne, Win7 + WinServer 2008 R2
Hallo Zusammen,
vielleicht kann mir einer von Euch helfen, da das Problem mehr als merkwürdig ist.
Wir haben eine neue Domäne mit Windows Server 2008 R2 und Windows 7 Clients hochgezogen. Es besteht noch eine alte Domäne mit einem Domänencontroller, der nur noch zu alten Systemen authenifiziert und DHCP + DNS macht. Es kommt immer wieder zwischenzeitlich vor, dass sich Benutzer melden, dass ihr Domänen-Benutzer-Konto gesperrt ist. Die User haben sich nachweislich nicht falsch angemeldet und das Password ist definitiv nicht abgelaufen. Teilweise sind es immer die gleichen Benutzer-Konten und es tritt nicht durchgehend auf und nicht in den gleichen zeitlichen Abständen. Teilweise sind die Konten bereits gesperrt, wenn der Rechner hochgefahren wird, teilweise auch wenn die Benutzer aus der Pause kommen.
Auf den Domänen-Controllern sind mehrere Kerberos-Authentifizierungsfehler des Benutzers zu sehen. Die Quell-IP-Adresse sind teilweise Clients und teilweise weitergeleitet von einem anderen Domänencontroller. Zum Zeitpunkt der Konto-Sperrung gibt es meist (aber nicht immer) fünf Log-Einträge hintereinander vom gesperrten Benutzer-Konto mit unten stehendem Fehler. Diese 5 Log-Einträge sind dann in der gleichen Millisekunde vermerkt. Der Benutzer tippt hier aber jedoch nach Password nur einmal auf ENTER. Er würde es außerdem gar nicht schaffen fünfmal innerhalb einer Millisekunde zu tippen. Entweder ist der Fehlercode 0x12 oder 0x18. Ereignis-ID ist immer 4771.
Laut Internet-Recherche heißt dies "Credentials revoked - Account disabled"(0x12) oder "Pre-authentication information was invalid - bad password" (0x18).
Beispiel-Log:
Fehler bei der Kerberos-Vorauthentifizierung.
Kontoinformationen:
Sicherheits-ID: Domain.local\Max.Mustermann
Kontoname: Max.Mustermann
Dienstinformationen:
Dienstname: krbtgt/Domain.local
Netzwerkinformationen:
Clientadresse: ::ffff:192.168.1.12 #Fantasie-IP-Adresse
Clientport: 50800
Weitere Informationen:
Ticketoptionen: 0x40810010
Fehlercode: 0x18
Typ vor der Authentifizierung: 2
Zertifikatsinformationen:
Zertifikatausstellername:
Seriennummer des Zertifikats:
Zertifikatfingerabdruck:
Zertifikatinformationen werden nur bereitgestellt, wenn ein Zertifikat zur Vorauthentifizierung verwendet wurde.
Vorauthentifizierungtypen, Ticketoptionen und Fehlercodes sind in RFC 4120 definiert.
Harte Fakten:
-Windows 7 Clients mit Domänenmitgliedschafft (neue Domäne) und Netzlaufwerkeinbindung bei der Anmeldung mit Fileserver
-1 alter Domänen-Controller Windows Server 2003 R2 mit alter Domäne + DHCP + Master-DNS (beinhaltet beide Domänen-Zonen als primär)
-3 Domänen-Controller(DC) Windows Server 2008 R2 mit neuer Domäne
-Vertrauensstellung zwischen beiden Domänen
-Alle neuen Server haben die Rolle "Active-Directory Domänendienste" installiert und einer davon noch DNS. Mehr nicht.
-1. DC AD-Rollen = RID, PDC, Infrastruktur-Master,
-2. DC AD-Rollen = Schema-Master, Domänen-Namen-Betriebsmaster, Global-Catalog
-3. DC AD-Rollen = Global-Catalog, sekundärer DNS (bezieht Zonen vom Master-DNS)
-DNS: Domänen-Zonen + _msdcs-Zonen sind vorhanden (beide Domänen)
-Server und Clients sind im gleichen lokalen Netz
-Gleiche Uhrzeit auf allen Systemen
Habe die AD-Rolle auf allen Server mit dem Best-Practice-Analyzer analysiert. Keine Feher.
Hat jemand von Euch vielleicht Ideen?
Gibt es hier vielleicht noch Rollen oder Dienste, die man installieren sollte oder wäre eine andere Konfiguration sinnvoll?
DNS und DHCP werden nach und nach migriert und sollen dann natürlich primär auf den 2008-R2's laufen mit allen Zonen.
Mit freundlichen Grüßen
Kevin Dreher
vielleicht kann mir einer von Euch helfen, da das Problem mehr als merkwürdig ist.
Wir haben eine neue Domäne mit Windows Server 2008 R2 und Windows 7 Clients hochgezogen. Es besteht noch eine alte Domäne mit einem Domänencontroller, der nur noch zu alten Systemen authenifiziert und DHCP + DNS macht. Es kommt immer wieder zwischenzeitlich vor, dass sich Benutzer melden, dass ihr Domänen-Benutzer-Konto gesperrt ist. Die User haben sich nachweislich nicht falsch angemeldet und das Password ist definitiv nicht abgelaufen. Teilweise sind es immer die gleichen Benutzer-Konten und es tritt nicht durchgehend auf und nicht in den gleichen zeitlichen Abständen. Teilweise sind die Konten bereits gesperrt, wenn der Rechner hochgefahren wird, teilweise auch wenn die Benutzer aus der Pause kommen.
Auf den Domänen-Controllern sind mehrere Kerberos-Authentifizierungsfehler des Benutzers zu sehen. Die Quell-IP-Adresse sind teilweise Clients und teilweise weitergeleitet von einem anderen Domänencontroller. Zum Zeitpunkt der Konto-Sperrung gibt es meist (aber nicht immer) fünf Log-Einträge hintereinander vom gesperrten Benutzer-Konto mit unten stehendem Fehler. Diese 5 Log-Einträge sind dann in der gleichen Millisekunde vermerkt. Der Benutzer tippt hier aber jedoch nach Password nur einmal auf ENTER. Er würde es außerdem gar nicht schaffen fünfmal innerhalb einer Millisekunde zu tippen. Entweder ist der Fehlercode 0x12 oder 0x18. Ereignis-ID ist immer 4771.
Laut Internet-Recherche heißt dies "Credentials revoked - Account disabled"(0x12) oder "Pre-authentication information was invalid - bad password" (0x18).
Beispiel-Log:
Fehler bei der Kerberos-Vorauthentifizierung.
Kontoinformationen:
Sicherheits-ID: Domain.local\Max.Mustermann
Kontoname: Max.Mustermann
Dienstinformationen:
Dienstname: krbtgt/Domain.local
Netzwerkinformationen:
Clientadresse: ::ffff:192.168.1.12 #Fantasie-IP-Adresse
Clientport: 50800
Weitere Informationen:
Ticketoptionen: 0x40810010
Fehlercode: 0x18
Typ vor der Authentifizierung: 2
Zertifikatsinformationen:
Zertifikatausstellername:
Seriennummer des Zertifikats:
Zertifikatfingerabdruck:
Zertifikatinformationen werden nur bereitgestellt, wenn ein Zertifikat zur Vorauthentifizierung verwendet wurde.
Vorauthentifizierungtypen, Ticketoptionen und Fehlercodes sind in RFC 4120 definiert.
Harte Fakten:
-Windows 7 Clients mit Domänenmitgliedschafft (neue Domäne) und Netzlaufwerkeinbindung bei der Anmeldung mit Fileserver
-1 alter Domänen-Controller Windows Server 2003 R2 mit alter Domäne + DHCP + Master-DNS (beinhaltet beide Domänen-Zonen als primär)
-3 Domänen-Controller(DC) Windows Server 2008 R2 mit neuer Domäne
-Vertrauensstellung zwischen beiden Domänen
-Alle neuen Server haben die Rolle "Active-Directory Domänendienste" installiert und einer davon noch DNS. Mehr nicht.
-1. DC AD-Rollen = RID, PDC, Infrastruktur-Master,
-2. DC AD-Rollen = Schema-Master, Domänen-Namen-Betriebsmaster, Global-Catalog
-3. DC AD-Rollen = Global-Catalog, sekundärer DNS (bezieht Zonen vom Master-DNS)
-DNS: Domänen-Zonen + _msdcs-Zonen sind vorhanden (beide Domänen)
-Server und Clients sind im gleichen lokalen Netz
-Gleiche Uhrzeit auf allen Systemen
Habe die AD-Rolle auf allen Server mit dem Best-Practice-Analyzer analysiert. Keine Feher.
Hat jemand von Euch vielleicht Ideen?
Gibt es hier vielleicht noch Rollen oder Dienste, die man installieren sollte oder wäre eine andere Konfiguration sinnvoll?
DNS und DHCP werden nach und nach migriert und sollen dann natürlich primär auf den 2008-R2's laufen mit allen Zonen.
Mit freundlichen Grüßen
Kevin Dreher
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 288062
Url: https://administrator.de/contentid/288062
Printed on: April 25, 2024 at 09:04 o'clock
5 Comments
Latest comment
Hi,
Irgendwie komme ich aber nicht vom alten Spruch los: 98% aller Computerfehler sitzen davor. Die Tatsache, dass Ihr jetzt eine neue Domäne habt, schreit förmlich danach, dass einige Anwender nicht damit klar kommen, dass sie in verschiedenen Domänen bei gleichem Loginnamen unterschiedliche Passwörter haben.
E.
Clientadresse: ::ffff:192.168.1.12 #Fantasie-IP-Adresse
Mit "Fantasie-IP-Adresse" meinst Du, dass Du Dir diese ausgedacht hast, um das hier posten zu können, oder erscheint im Log tatsächlich eine Adresse, dies es nicht geben dürfte?Irgendwie komme ich aber nicht vom alten Spruch los: 98% aller Computerfehler sitzen davor. Die Tatsache, dass Ihr jetzt eine neue Domäne habt, schreit förmlich danach, dass einige Anwender nicht damit klar kommen, dass sie in verschiedenen Domänen bei gleichem Loginnamen unterschiedliche Passwörter haben.
E.
Danke für deinen Beitrag.
Genau die IP-Adresse ist eine von mir ausgedacht, um die hier posten zu können. Dort befindet sich dann also die tatsächliche Client-IP-Adresse.
Es ist genau wie du sagst. Bei uns sind es meist sogar 99% der Fehler, die vor dem Computer sitzen
. In diesem Falle ist es aber ausnahmsweise nicht so. ;)
Neue und alte Domäne verwenden unterschiedliche Benutzernamen und Kennwort. In den Gruppenrichtlinien ist die Kontosperrung auf 5 fehlerhafte Anmeldeversuche eingestellt. Die Benutzer erhalten in dem besagten Fehlerfall beim ersten Anmeldeversuch, die Meldung, dass das Konto gesperrt ist auch wenn das Password richtig eingeben wurde. Genau das ist es, was wir nicht verstehen, warum dies so ist. Wie gesagt im Log sieht man manchmal 5 fehlerhafte Anmeldungen hintereinander innerhalb von der gleichen Millisekunde. Das schafft keiner. Es sind aber nicht immer 5 Einträge, gerne auch mal nur ein Eintrag und danach die Kontosperrung.
Genau die IP-Adresse ist eine von mir ausgedacht, um die hier posten zu können. Dort befindet sich dann also die tatsächliche Client-IP-Adresse.
Es ist genau wie du sagst. Bei uns sind es meist sogar 99% der Fehler, die vor dem Computer sitzen
. In diesem Falle ist es aber ausnahmsweise nicht so. ;)Neue und alte Domäne verwenden unterschiedliche Benutzernamen und Kennwort. In den Gruppenrichtlinien ist die Kontosperrung auf 5 fehlerhafte Anmeldeversuche eingestellt. Die Benutzer erhalten in dem besagten Fehlerfall beim ersten Anmeldeversuch, die Meldung, dass das Konto gesperrt ist auch wenn das Password richtig eingeben wurde. Genau das ist es, was wir nicht verstehen, warum dies so ist. Wie gesagt im Log sieht man manchmal 5 fehlerhafte Anmeldungen hintereinander innerhalb von der gleichen Millisekunde. Das schafft keiner. Es sind aber nicht immer 5 Einträge, gerne auch mal nur ein Eintrag und danach die Kontosperrung.
Scheduled Task?
Smartphones mit Active Sync?
Smartphones mit Active Sync?
Wird beides von den betroffenen Anwendern nicht benutzt. Habe ich geprüft.
Neuigkeiten:
Wir haben die DC's mit dcdiag überprüft. Uns wurde hier ein DNS-Fehler angezeigt. DNS-Fehler ist behoben. Leider besteht das Problem noch immer.
Unwillkürlich und sporadisch werden Userkonten gesperrt. Aktuell keine Fehler im DCDIAG. Ereignisanzeige zeigt noch immer Fehlercode 0x18 bei der Kerberosauthentifizierung.
Wir haben die DC's mit dcdiag überprüft. Uns wurde hier ein DNS-Fehler angezeigt. DNS-Fehler ist behoben. Leider besteht das Problem noch immer.
Unwillkürlich und sporadisch werden Userkonten gesperrt. Aktuell keine Fehler im DCDIAG. Ereignisanzeige zeigt noch immer Fehlercode 0x18 bei der Kerberosauthentifizierung.
