fenris14
Goto Top

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:

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ß

Content-Key: 5631283340

Url: https://administrator.de/contentid/5631283340

Printed on: February 23, 2024 at 07:02 o'clock

Member: commodity
commodity Jan 26, 2023 at 01:16:51 (UTC)
Goto Top
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
Member: Fenris14
Fenris14 Jan 26, 2023 at 07:57:46 (UTC)
Goto Top
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.


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

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.
Member: commodity
commodity Jan 26, 2023 at 08:34:45 (UTC)
Goto Top
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
Member: Fenris14
Fenris14 Jan 26, 2023 at 08:40:28 (UTC)
Goto Top
Zitat von @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.
Member: Fenris14
Fenris14 Jan 26, 2023 at 09:13:40 (UTC)
Goto Top
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?
Member: commodity
commodity Jan 26, 2023 at 09:29:27 (UTC)
Goto Top
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
Member: Fenris14
Fenris14 Jan 26, 2023 at 10:06:44 (UTC)
Goto Top
Zitat von @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?
Member: commodity
commodity Jan 26, 2023 at 12:10:48 (UTC)
Goto Top
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
Member: Fenris14
Fenris14 Jan 26, 2023 at 12:36:47 (UTC)
Goto Top
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.
Member: commodity
commodity Jan 26, 2023 at 13:14:16 (UTC)
Goto Top
Dann ist es bestimmt ein Uhrzeitproblem gewesen.

Viele Grüße, commodity
Member: Fenris14
Fenris14 Jan 27, 2023 at 08:34:34 (UTC)
Goto Top
Zitat von @commodity:

Dann ist es bestimmt ein Uhrzeitproblem gewesen.

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.
Member: commodity
commodity Jan 27, 2023 at 09:00:52 (UTC)
Goto Top
Super!
Viele Grüße, commodity
Member: Fenris14
Fenris14 Jan 31, 2023 at 10:38:47 (UTC)
Goto Top
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:

{ 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.
Member: Fenris14
Fenris14 Jan 31, 2023 at 11:14:28 (UTC)
Goto Top
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.