Kontodomäne unterschiedlich zur Clientdomäne, EventID 4625
Hallo zusammen,
Wir haben hier ein seltsames Phänomen, bei dem wir nicht ganz durchsteigen oder wahrscheinlich einfach den Wald vor lauter Bäumen nicht sehen und ein paar Impulse von außen benötigen.
Kurz zu den Rahmenbedingungen: AD-Domäne, 2002 erstellt, seit dem immer wieder hochgezogen, aktuell allerdings auf 2012 R2 Funktionsebene, der letzte 2012 R2 DC wurde ende letzten Jahres erst auf 2022 hochgezogen und bis jetzt wurde noch kein hoch stufen eingeplant bzw. es wurde noch keine Analyse gemacht, was davon dann alles betroffen ist.
NTLMv1 wird geloggt, ist aber noch nicht vollständig abgeschaltet - weil es eben noch Legacy Software gibt, die NTLMv1 benötigt. NetBios ist generell per GPO deaktiviert, nbtstat liefert auch die erwarteten Ergebnisse (also nix bzw. Host nicht gefunden). Soweit funktioniert augenscheinlich alles - SMB Freigaben funktionieren mit Berechtigungen und verschachtelten Gruppen, GPOs werden entsprechend nach Gruppen und OUs gezogen, etc.
Nun ist es aber so, dass wir Software haben, die nicht auslesen kann, in welcher Gruppe der User ist um innerhalb der Software Rechte zu vergeben. Dazu gibt es einige Event-ID 4625 Einträge. Die Üblichen Google-Ergebnisse sind schon durch, wir haben auch keine übermäßig seltsamen Account Lockouts, die Konten sind nicht deaktiviert und können sich anmelden, die bekommen entsprechend auch ihre Laufwerke zugewiesen und entsprechende Fehlermeldungen beim Zugriff auf Freigaben, auf die sie keinen Zugriff haben.
Was allerdings sehr auffällig in den Logs ist, dass die "Account Domain" und die "Client Domain" unterschiedlich sind. Die Account Domain nutzt den alten NetBios Namen, also "BEISPIEL\XYZ", während die "Client Domain" das erwartete und korrekte "XYZ@BEISPIEL.DOMAIN" nutzt.
Bei genauerem nachforschen ist mir tatsächlich auch aufgefallen, dass an allen Clients die User entsprechend Ihres sAMAccountName angemeldet werden. Die Anmeldung per UPN funktioniert aber genau so problemlos.
Macht das überhaupt einen Unterschied in diesem Zusammenhang? Die Anmeldung per UPN/sAMAN müsste doch unabhängig vom NetBios sein?
Ein "net user XYZ /domain" funktioniert auch entsprechend wie erwartet. Kann das auch an der Software liegen, die hier genutzt wird?
Soweit wir ergründen konnten, ist das eine Mischung aus C++ und .net, die Befehle zum auslesen der AD Infos sollten ja eigentlich die gleichen sein, wie manuell über die PowerShell/CMD - oder?
Beim Event-ID 4625 steht interessanterweise auch ein "NULL SID" für die Security ID dabei...
Bin für alle Tipps dankbar und möglicherweise hatte jemand sowas ja schon mal und hat einen heißen Tipp...
Danke und Gruß!
Wir haben hier ein seltsames Phänomen, bei dem wir nicht ganz durchsteigen oder wahrscheinlich einfach den Wald vor lauter Bäumen nicht sehen und ein paar Impulse von außen benötigen.
Kurz zu den Rahmenbedingungen: AD-Domäne, 2002 erstellt, seit dem immer wieder hochgezogen, aktuell allerdings auf 2012 R2 Funktionsebene, der letzte 2012 R2 DC wurde ende letzten Jahres erst auf 2022 hochgezogen und bis jetzt wurde noch kein hoch stufen eingeplant bzw. es wurde noch keine Analyse gemacht, was davon dann alles betroffen ist.
NTLMv1 wird geloggt, ist aber noch nicht vollständig abgeschaltet - weil es eben noch Legacy Software gibt, die NTLMv1 benötigt. NetBios ist generell per GPO deaktiviert, nbtstat liefert auch die erwarteten Ergebnisse (also nix bzw. Host nicht gefunden). Soweit funktioniert augenscheinlich alles - SMB Freigaben funktionieren mit Berechtigungen und verschachtelten Gruppen, GPOs werden entsprechend nach Gruppen und OUs gezogen, etc.
Nun ist es aber so, dass wir Software haben, die nicht auslesen kann, in welcher Gruppe der User ist um innerhalb der Software Rechte zu vergeben. Dazu gibt es einige Event-ID 4625 Einträge. Die Üblichen Google-Ergebnisse sind schon durch, wir haben auch keine übermäßig seltsamen Account Lockouts, die Konten sind nicht deaktiviert und können sich anmelden, die bekommen entsprechend auch ihre Laufwerke zugewiesen und entsprechende Fehlermeldungen beim Zugriff auf Freigaben, auf die sie keinen Zugriff haben.
Was allerdings sehr auffällig in den Logs ist, dass die "Account Domain" und die "Client Domain" unterschiedlich sind. Die Account Domain nutzt den alten NetBios Namen, also "BEISPIEL\XYZ", während die "Client Domain" das erwartete und korrekte "XYZ@BEISPIEL.DOMAIN" nutzt.
Bei genauerem nachforschen ist mir tatsächlich auch aufgefallen, dass an allen Clients die User entsprechend Ihres sAMAccountName angemeldet werden. Die Anmeldung per UPN funktioniert aber genau so problemlos.
Macht das überhaupt einen Unterschied in diesem Zusammenhang? Die Anmeldung per UPN/sAMAN müsste doch unabhängig vom NetBios sein?
Ein "net user XYZ /domain" funktioniert auch entsprechend wie erwartet. Kann das auch an der Software liegen, die hier genutzt wird?
Soweit wir ergründen konnten, ist das eine Mischung aus C++ und .net, die Befehle zum auslesen der AD Infos sollten ja eigentlich die gleichen sein, wie manuell über die PowerShell/CMD - oder?
Beim Event-ID 4625 steht interessanterweise auch ein "NULL SID" für die Security ID dabei...
Bin für alle Tipps dankbar und möglicherweise hatte jemand sowas ja schon mal und hat einen heißen Tipp...
Danke und Gruß!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672469
Url: https://administrator.de/forum/kontodomaene-unterschiedlich-zur-clientdomaene-eventid-4625-672469.html
Ausgedruckt am: 15.04.2025 um 18:04 Uhr
4 Kommentare
Neuester Kommentar
Hi,
schau mal zuerst hier:
4625(F): An account failed to log on.
Da werden alle Einträge erklärt. Siehe z.B. "Failure Information"
schau mal zuerst hier:
4625(F): An account failed to log on.
Da werden alle Einträge erklärt. Siehe z.B. "Failure Information"
Na, irgendwas muss doch zutreffen, wenn er das meldet.
https://techcommunity.microsoft.com/blog/coreinfrastructureandsecuritybl ...
https://techcommunity.microsoft.com/blog/coreinfrastructureandsecuritybl ...
1. The username and password are correct, but there is an account restriction on the user account (such as valid workstation, valid logon hours, etc.). The value under SubStatus should provide the restriction details.
2. Active Directory Replication may not be complete
2. Active Directory Replication may not be complete
Account is disabled
Logon hours are restricted
Workstation restrictions
Account is expired
Logon hours are restricted
Workstation restrictions
Account is expired