14
Samba AD mit PIV Yubikey EventID 4625
Hallo,
ich versuche gerade eine AD mit Samba zu realisieren. Soweit klappt auch das meiste. Jetzt wollte ich versuchen die SmartCard-Funktionalität per PIV zu implementieren. Ziel ist es eine Art vereinfachten Login für die User und 2FA einzuführen.
Als SmartCard dient ein Yubikey 5. Samba in der Version 4.17.
Bei der Installation und Einrichtung von PIV habe ich mich an diese Anleitung gehalten:
https://wiki.samba.org/index.php/Samba_AD_Smart_Card_Login#Allowing_Smar ...
Nun hakt es beim Login. Ich habe pkcs12 Cert auf den Yubikey installiert und wenn ich das am Testrechner einstecke, kommt: "Ihre Anmeldeinformationen konnten nicht überprüft werden."
Im Log steht EventID 4625, anfangs noch mit völlig falschen Anmeldeoptionen, das hatte ich korrigiert. Im Status von der EventID steht jetzt aber immer noch: 0xC000006D
Laut MS...
https://learn.microsoft.com/de-de/windows/security/threat-protection/aud ...
...ist es folgendes: "Die Ursache ist entweder ein ungültiger Benutzername oder Authentifizierungsinformationen."
Inhalt des Events komplett:
Was immer noch darauf schließen lässt das das Zertifikat nicht richtig angelegt wurde. Die Frage ist: Wie lege ich es richtig an?
Was auffällt ist, das im Eventlog in der Meldung zur 4625 kein "Kontodomäne" hinterlegt ist. Aber wie soll die den ins Zertifikat gestellt werden?
Ich lege die Zertifikate so hier an, Beispiel:
Vorname Max
Nachname Mustermann
Domäne test.contoso.com
Der Common Name und die Email lautet dann: m.mustermann@test.contoso.com
Mit diesem und dem dazugehörigen Passwort kann ich mich auch ganz normal an einem Domänen-Member anmelden. Windows erkennt dann automatisch, das der Shortname der Domäne TEST lautet.
Sobald ich aber die Smartcard verwende und die PIN eingebe, kommt die Fehlermeldung. Jemand noch eine Idee?
Gruß
ich versuche gerade eine AD mit Samba zu realisieren. Soweit klappt auch das meiste. Jetzt wollte ich versuchen die SmartCard-Funktionalität per PIV zu implementieren. Ziel ist es eine Art vereinfachten Login für die User und 2FA einzuführen.
Als SmartCard dient ein Yubikey 5. Samba in der Version 4.17.
Bei der Installation und Einrichtung von PIV habe ich mich an diese Anleitung gehalten:
https://wiki.samba.org/index.php/Samba_AD_Smart_Card_Login#Allowing_Smar ...
Nun hakt es beim Login. Ich habe pkcs12 Cert auf den Yubikey installiert und wenn ich das am Testrechner einstecke, kommt: "Ihre Anmeldeinformationen konnten nicht überprüft werden."
Im Log steht EventID 4625, anfangs noch mit völlig falschen Anmeldeoptionen, das hatte ich korrigiert. Im Status von der EventID steht jetzt aber immer noch: 0xC000006D
Laut MS...
https://learn.microsoft.com/de-de/windows/security/threat-protection/aud ...
...ist es folgendes: "Die Ursache ist entweder ein ungültiger Benutzername oder Authentifizierungsinformationen."
Inhalt des Events komplett:
Fehler beim Anmelden eines Kontos.
Antragsteller:
Sicherheits-ID: SYSTEM
Kontoname: TEST$
Kontodomäne: TEST
Anmelde-ID: 0x3E7
Anmeldetyp: 2
Konto, für das die Anmeldung fehlgeschlagen ist:
Sicherheits-ID: NULL SID
Kontoname: m.mustermann@test.contoso.com
Kontodomäne:
Fehlerinformationen:
Fehlerursache: Bei der Anmeldung ist ein Fehler aufgetreten.
Status: 0xC000006D
Unterstatus:: 0x0
Prozessinformationen:
Aufrufprozess-ID: 0x628
Aufrufprozessname: C:\Windows\System32\svchost.exe
Netzwerkinformationen:
Arbeitsstationsname: TEST
Quellnetzwerkadresse: 127.0.0.1
Quellport: 0
Detaillierte Authentifizierungsinformationen:
Anmeldeprozess: User32
Authentifizierungspaket: Negotiate
Übertragene Dienste: -
Paketname (nur NTLM): -
Schlüssellänge: 0
Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde.
Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe".
Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk).
Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde.
Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben.
Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung.
- Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren.
- Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an.
- Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0.Was immer noch darauf schließen lässt das das Zertifikat nicht richtig angelegt wurde. Die Frage ist: Wie lege ich es richtig an?
Was auffällt ist, das im Eventlog in der Meldung zur 4625 kein "Kontodomäne" hinterlegt ist. Aber wie soll die den ins Zertifikat gestellt werden?
Ich lege die Zertifikate so hier an, Beispiel:
Vorname Max
Nachname Mustermann
Domäne test.contoso.com
Der Common Name und die Email lautet dann: m.mustermann@test.contoso.com
Mit diesem und dem dazugehörigen Passwort kann ich mich auch ganz normal an einem Domänen-Member anmelden. Windows erkennt dann automatisch, das der Shortname der Domäne TEST lautet.
Sobald ich aber die Smartcard verwende und die PIN eingebe, kommt die Fehlermeldung. Jemand noch eine Idee?
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5631283340
Url: https://administrator.de/contentid/5631283340
Ausgedruckt am: 24.11.2024 um 14:11 Uhr
14 Kommentare
Neuester Kommentar
Ist mein nächstes Projekt. Wenn es nicht eilt: Ich komme drauf zurück.
Die Anleitung von Yubico hast Du berücksichtigt?
https://support.yubico.com/hc/en-us/articles/360013707820-YubiKey-Smart- ...
Vielleicht steckt da schon der Hase im Pfeffer.
Viele Grüße, commodity
Die Anleitung von Yubico hast Du berücksichtigt?
https://support.yubico.com/hc/en-us/articles/360013707820-YubiKey-Smart- ...
Vielleicht steckt da schon der Hase im Pfeffer.
Viele Grüße, commodity
Es ist echt bisschen komisch. In der Doku von Samba4 steht zwar drin das man beim ersten Login etwas Geduld haben muss, aber das bisherige Verhalten erklärt sich damit nicht.
Das ist das erste was ich mir durchgelesen habe im Bezug auf den Yubikey. Aber es ist halt angelehnt Richtung reine MS-Struktur die ich nunmal nicht habe. Deshalb ist mehr als die Hälfte der Artikel unbrauchbar.
Folgendes habe ich jetzt gemacht:
Ich habe einen anderen User genommen und das Zertifikat folgendermaßen angelegt...
Common Name: TEST\a.mustermann
Email: a.mustermann@test.contoso.com
Als ich mich am Test-Rechner mit dem nicht-funktionierenden User abgemeldet habe und dann mit dem neuen per SmartCard, welch Wunder, es funktioniert. Dann habe ich das Zertifikat von m.mustermann genauso abgeändert wie von a.mustermann. Der Login funktionierte wieder nicht. Dann dachte ich, ok, dann muss es einen Unterschied bei den Usern geben. Da ich keine Lust hatte dem ewig nachzugehen, habe m.mustermann neu angelegt. Der Login funktionierte weiterhin nicht. Dann wurde es ganz verrückt: Am nächsten Tag, weil ich keine Lust mehr hatte, wollte ich nochmals mit dem funktionierenden User anmelden... es ging nicht.
Die Maschine wurde dann neugestartet und danach funktionierte es wieder. Nun bin ich mir nicht sicher woran das liegen kann. In den Logs steht nichts brauchbares drin. Es sagt schlichtweg das die Anmeldung fehlgeschlagen ist, leider gibt es zum Status keinen Unterstatus woran man vielleicht weiter Fehler suchen könnte.
Aber wenn das darauf hinaus läuft, das es mal funktioniert und mal nicht. Dann sind Anrufe von den Usern bei mir vorprogrammiert.
Zitat von @commodity:
Ist mein nächstes Projekt. Wenn es nicht eilt: Ich komme drauf zurück.
Die Anleitung von Yubico hast Du berücksichtigt?
https://support.yubico.com/hc/en-us/articles/360013707820-YubiKey-Smart- ...
Vielleicht steckt da schon der Hase im Pfeffer.
Viele Grüße, commodity
Ist mein nächstes Projekt. Wenn es nicht eilt: Ich komme drauf zurück.
Die Anleitung von Yubico hast Du berücksichtigt?
https://support.yubico.com/hc/en-us/articles/360013707820-YubiKey-Smart- ...
Vielleicht steckt da schon der Hase im Pfeffer.
Viele Grüße, commodity
Das ist das erste was ich mir durchgelesen habe im Bezug auf den Yubikey. Aber es ist halt angelehnt Richtung reine MS-Struktur die ich nunmal nicht habe. Deshalb ist mehr als die Hälfte der Artikel unbrauchbar.
Folgendes habe ich jetzt gemacht:
Ich habe einen anderen User genommen und das Zertifikat folgendermaßen angelegt...
Common Name: TEST\a.mustermann
Email: a.mustermann@test.contoso.com
Als ich mich am Test-Rechner mit dem nicht-funktionierenden User abgemeldet habe und dann mit dem neuen per SmartCard, welch Wunder, es funktioniert. Dann habe ich das Zertifikat von m.mustermann genauso abgeändert wie von a.mustermann. Der Login funktionierte wieder nicht. Dann dachte ich, ok, dann muss es einen Unterschied bei den Usern geben. Da ich keine Lust hatte dem ewig nachzugehen, habe m.mustermann neu angelegt. Der Login funktionierte weiterhin nicht. Dann wurde es ganz verrückt: Am nächsten Tag, weil ich keine Lust mehr hatte, wollte ich nochmals mit dem funktionierenden User anmelden... es ging nicht.
Die Maschine wurde dann neugestartet und danach funktionierte es wieder. Nun bin ich mir nicht sicher woran das liegen kann. In den Logs steht nichts brauchbares drin. Es sagt schlichtweg das die Anmeldung fehlgeschlagen ist, leider gibt es zum Status keinen Unterstatus woran man vielleicht weiter Fehler suchen könnte.
Aber wenn das darauf hinaus läuft, das es mal funktioniert und mal nicht. Dann sind Anrufe von den Usern bei mir vorprogrammiert.
Aber es ist halt angelehnt Richtung reine MS-Struktur die ich nunmal nicht habe.
Ich auch nicht. Ich melde mich, wenn ich da weiter bin.Funktioniert denn a.mustermann kontinuierlich oder auch nur mal so und mal so?
Viele Grüße, commodity
Zitat von @commodity:
Funktioniert denn a.mustermann kontinuierlich oder auch nur mal so und mal so?
Viele Grüße, commodity
Aber es ist halt angelehnt Richtung reine MS-Struktur die ich nunmal nicht habe.
Ich auch nicht. Ich melde mich, wenn ich da weiter bin.Funktioniert denn a.mustermann kontinuierlich oder auch nur mal so und mal so?
Viele Grüße, commodity
a.mustermann hatte am Tag wo ich den zum ersten Mal angelegt habe, sofort funktioniert. Am nächsten Tag plötzlich nicht mehr. Danach habe ich den Rechner neugestartet, weil er die Nacht durchlief, da hat es dann wieder funktioniert. Ich vermute mittlerweile das es ein Kerberos-Problem ist und das dann irgendwann in einem Timeout mündet, weil die Authentifizierung nicht erneuert wurde. Aber leider geben weder das Windows Log noch das Kerberos-Log irgendeinen Hinweis darauf. Zur Zeit ist es nur eine Vermutung.
Ich werde den Rechner jetzt mal angemeldet lassen, nach paar Stunden eine Wiederanmeldung probieren.
Ich habe vielleicht einen Grund gefunden. Ich habe zwei DC, auf dem ersten PDC, betreibe ich die PKI und dort wurden auch Zertifikate installiert. Gekoppelt mit seiner GUID. Weil ich davon ausging das die CLients sich für die Authentifizierung sowieso sich dorthin wenden. Der zweite DC, als wirklich reiner Backup, hat kein installiertes DC Zertifikat.
Kann das ein Problem sein?
Kann das ein Problem sein?
Stefan Kania schreibt in SAMBA 4 (sehr zu empfehlen):
Ich würde den zweiten DC so lange ausschalten, bis es auf dem ersten funktioniert.
Viele Grüße, commodity
Sollte die Authentifizierung nicht funktionieren, dann prüfen Sie als Erstes, ob Sie auf dem neuen Domaincontroller auch wirklich den ersten Domaincontroller als DNS-Server eingetragen haben. Denn nur dann kann der Kerberos-Client den KDC derDomäne finden und die Authentifizierung durchführen
Trifft jetzt nicht ganz Deine Frage, ich verstehe das aber so, dass auch der zweite DC bestimmte Bedingungen erfüllen muss.Ich würde den zweiten DC so lange ausschalten, bis es auf dem ersten funktioniert.
Viele Grüße, commodity
Zitat von @commodity:
Stefan Kania schreibt in SAMBA 4 (sehr zu empfehlen):
Ich würde den zweiten DC so lange ausschalten, bis es auf dem ersten funktioniert.
Viele Grüße, commodity
Stefan Kania schreibt in SAMBA 4 (sehr zu empfehlen):
Sollte die Authentifizierung nicht funktionieren, dann prüfen Sie als Erstes, ob Sie auf dem neuen Domaincontroller auch wirklich den ersten Domaincontroller als DNS-Server eingetragen haben. Denn nur dann kann der Kerberos-Client den KDC derDomäne finden und die Authentifizierung durchführen
Trifft jetzt nicht ganz Deine Frage, ich verstehe das aber so, dass auch der zweite DC bestimmte Bedingungen erfüllen muss.Ich würde den zweiten DC so lange ausschalten, bis es auf dem ersten funktioniert.
Viele Grüße, commodity
Muss der nicht genauso konfiguriert werden wie der PDC?
Bei mir ist auch der 2. DC sein eigener DNS. Weiß grad nicht, was er meint.
Ich würde den Backup ausschalten.
Und: AD ist ja sehr zeitsensibel. Sind alle Beteiligten mit korrekten Uhrzeiten ausgestattet?
Viele Grüße, commodity
Ich würde den Backup ausschalten.
Und: AD ist ja sehr zeitsensibel. Sind alle Beteiligten mit korrekten Uhrzeiten ausgestattet?
Viele Grüße, commodity
Ich habe den zweiten DC jetzt genauso im AD konfiguriert, mit eigenen Zertifikaten inklusive Kerberos Config, wie der PDC. Es spielt auch erstmal keine Rollen wie ich festgestellt habe, weil im DNS steht wer der KDC ist. Kann man mit nslookup prüfen. Danach richten sich die Clients und da steht bei mir eindeutig der PDC drin.
Aber ich habe jetzt immer wieder mal probiert: Seitdem ich heute neugestartet habe, funktionieren alle Test-User bisher ohne Probleme.
Aber ich habe jetzt immer wieder mal probiert: Seitdem ich heute neugestartet habe, funktionieren alle Test-User bisher ohne Probleme.
Dann ist es bestimmt ein Uhrzeitproblem gewesen.
Viele Grüße, commodity
Viele Grüße, commodity
Ich habe jetzt das selbe Szenario nochmal durchgespielt: Rechner über Nacht angelassen und am nächsten Morgen versucht wieder anzumelden. Was beim ersten Versuch nicht funktionierte, hat jetzt ohne Probleme geklappt. Komisch, Zeit Problem konnte ich nicht verifizieren. Aber egal, es klappt nun sicher.
Super!
Viele Grüße, commodity
Viele Grüße, commodity
Ok. Ich habe das Problem jetzt wieder. Dieses Mal habe ich das Auth Log im Samba aktiviert.
Fehler lautet dann: "NT_STATUS_PKINIT_FAILURE"
Ich bin dann sogar den Ausschnitt des Source Codes durchgegangen. Ergebnis war, das dieser Fehler direkt in Verbindung mit dem SmartCard-Login steht.
Da steht folgendes:
Die Frage ist, was hier für ein "system event" gemeint ist. Ich gehe mal vom Windows Client aus. Wenn damit nur die Ereignisanzeige gemeint sein sollte, ist diese wie weiter oben beschrieben, nicht weiter aussagekräftig. Uhrzeiten und Sync habe ich überprüft... der CLient hat als Zeitserver den DC eingetragen. Von daher solltees keine Probleme in diese Richtung geben. Es bleibt spannend.
Fehler lautet dann: "NT_STATUS_PKINIT_FAILURE"
Ich bin dann sogar den Ausschnitt des Source Codes durchgegangen. Ergebnis war, das dieser Fehler direkt in Verbindung mit dem SmartCard-Login steht.
Da steht folgendes:
{ N_("The Kerberos protocol encountered an error while validating the KDC \
certificate during smart card logon. There is more information in the system event \
log."), NT_STATUS_PKINIT_FAILURE }, Die Frage ist, was hier für ein "system event" gemeint ist. Ich gehe mal vom Windows Client aus. Wenn damit nur die Ereignisanzeige gemeint sein sollte, ist diese wie weiter oben beschrieben, nicht weiter aussagekräftig. Uhrzeiten und Sync habe ich überprüft... der CLient hat als Zeitserver den DC eingetragen. Von daher solltees keine Probleme in diese Richtung geben. Es bleibt spannend.
Beim Herumbuddeln habe ich noch folgendes gefunden: Wenn das Ereignis 4625 mit Status 0xc000006d kommt noch ein FailureReason mit "%%2304"... das soll soviel heißen wie "An Error occured during Logon."
Anhand der Formulierung könnte man jetzt spekulieren, das es nicht am DC oder dem Kerberos liegt, sondern eher ein Problem am Client vorliegt.
Anhand der Formulierung könnte man jetzt spekulieren, das es nicht am DC oder dem Kerberos liegt, sondern eher ein Problem am Client vorliegt.
