Ich versuche, einen Apache-Server zu kerberisieren und dem erstellten Server-Principal die Anmeldung beim Active Directory zu ermöglichen. Ich habe eines der zahlreichen Tutorials befolgt, die online verfügbar sind, und es scheint gut zu funktionieren. Ich bin auf der Linux-Seite des Projekts und Corporate IT auf der Windows-Seite.
Die IT hat mir ein Servicekonto und einen Service Principal dafür bereitgestellt. In diesem Beispiel werde ich es als HTTP/ bezeichnen.[email geschützt]. Sie haben mir eine Keytab-Datei für den besagten Auftraggeber bereitgestellt, was die Ausführung eines Tools namens ktpass.exe auf dem AD-Server erfordert.
Ich habe überprüft, dass die KVNOs des AD/KDC und der Keytab-Datei übereinstimmen. Alles ist in Ordnung.
Es gibt einen richtigen DNS-A-Eintrag für den Hostnamen und einen richtigen PTR-Eintrag für die IP. Beide Server sind zeitlich synchronisiert.
Ich kann mit der ausgegebenen Keytab-Datei wie folgt ein Ticket vom AD/KDC für den oben genannten Dienstprinzipal anfordern:
kinit -k -t http.keytab HTTP/[email protected]
Das funktioniert. Ich erhalte ein Ticket und kann dieses Ticket für Dinge wie die Abfrage des AD/LDAP-Verzeichnisses verwenden. Die Keytab funktioniert auch hervorragend für den Betrieb einer Single Sign-on-Apache-Site, was teilweise das Ziel dieser Übung ist.
Eine halbe Stunde vergeht.
Anmeldeversuche mit dem obigen Kinit-Befehl schlagen jetzt mit dieser Meldung fehl:
Client not found in Kerberos database
Ich kann mich nicht als Dienstprinzipal authentifizieren, so als ob der Prinzipal auf dem AD-Server gelöscht worden wäre.
Jetzt wird es, zumindest für mich, komisch:
Auf Anfrage führt der AD-Administrator das Tool ktpass.exe erneut aus und erstellt eine neue Keytab-Datei für meinen Dienst. Die KVNO (Key Version Number) wird auf dem Server erhöht, was dazu führt, dass unser Apache-Testserver die Validierung der Kerberos-Einzelanmeldung einstellt. Dies ist bei meiner aktuellen Konfiguration zu erwarten. Was uns alle überraschte, war, dass der Befehl kinit jetzt wieder funktionierte. Wir haben uns eine weitere halbe Stunde verschafft, und dann funktionierte er wieder nicht mehr.
Unsere IT-Abteilung ist hier ratlos und vermutet, dass es sich um ein Problem mit dem AD-Server selbst handelt. Ich denke, es liegt an der Konfiguration, aber laut ihnen gibt es in ihrem Setup keine Halbstundenbegrenzungen.
Ich bin gefolgthttp://www.grolmsnet.de/kerbtut/(siehe Abschnitt 7), aber die Methode scheint in allen von mir gefundenen Dokumentationen dieselbe zu sein. Ich habe keinen Hinweis auf Zeitlimits für Dienstprinzipale gefunden.
EDIT: Dies scheint ein Replikationsproblem zu sein. Obwohl im Replikationsprozess keine Fehler gemeldet werden, wird der SPN-Wert des Dienstkontos von "HTTP/[email geschützt]" Zu "[email geschützt]" nach 30 Minuten.
Antwort1
Vielen Dank für all eure Beiträge, Leute. Wir haben Microsoft an Bord geholt und sie haben uns geholfen, den Authentifizierungsprozess auf der AD-Seite zu debuggen. Alles hat wie vorgesehen funktioniert, ist aber nach dreißig Minuten ausgefallen.
Während wir eine Remote-Debugging-Sitzung durchführten, bemerkte einer der Teilnehmer, dass der UPN/SPN des Dienstkontos plötzlich neu gesetzt wurde vonHTTP/[email geschützt]Zu[email geschützt]. Nachdem wir eine Menge herumgesucht und die AD-Replikation debuggt hatten, fanden wir den Übeltäter:
Jemand hatte ein Skript geschrieben, das periodisch (oder wahrscheinlich ereignisgesteuert, da es genau dreißig Minuten nach dem Ausführen von ktpass.exe geschah) ausgeführt wurde und den UPN/PSN aktualisierte auf„Cloud-Konnektivität sicherstellen“. Nähere Informationen zu den Gründen hierfür liegen mir nicht vor.
Das Skript wurde geändert, um vorhandene UPN/SPN-Werte mit der Endung@mycorp.com, wodurch das Problem effektiv gelöst wird.
Tipps zum Debuggen von Problemen wie diesen:
- Stellen Sie sicher, dass alle Teilnehmer an der Authentifizierung dieselben Verschlüsselungstypen unterstützen. Vermeiden Sie DES – es ist veraltet und unsicher.
- Stellen Sie sicher, dass die AES-128- und AES-256-Verschlüsselung für das Dienstkonto aktiviert ist
- Beachten Sie, dass die Aktivierung von DES auf dem Dienstkonto bedeutet„für dieses Konto NUR DES verwenden“, auch wenn Sie eine der AES-Verschlüsselungen aktiviert haben. Suchen Sie nachUF_USE_DES_KEY_ONLYfür Einzelheiten hierzu.
- Stellen Sie sicher, dass der UPN/SPN-Wert korrekt ist und mit dem Wert in der ausgegebenen Keytab-Datei übereinstimmt (z. B. durch eine LDAP-Suche).
- Stellen Sie sicher, dass die KVNO (Key Version Number) in der Keytab-Datei mit der auf dem Server übereinstimmt.
- Überprüfen Sie den Datenverkehr zwischen Server und Client (z. B. mit tcpdump und/oder WireShark).
- Aktivieren Sie das Debuggen der Authentifizierung auf der AD-Seite - überprüfen Sie die Protokolle
- Aktivieren Sie das Debuggen der Replikation auf der AD-Seite - überprüfen Sie die Protokolle
Nochmals vielen Dank für Ihre Eingabe.
Antwort2
Ich habe auch Kerberos gelernt, angefangen mit mod_auth_kerbdem Tutorial von Achim Grolms, wirklich eine gute Dokumentation.
Die keytabDatei ersetzt nur die Kennwortauthentifizierung. Das Kennwort ist in der Datei codiert und diese Bytes werden bei der Authentifizierungsaufforderung mit KDC verwendet. Jede Kennwortänderung für das Dienstkonto macht die Keytab-Authentifizierung ungültig und erhöht außerdem die KVNO-Nummer.
Um zu bestätigen, dass ein SPN für ein Dienstkonto verfügbar ist, authentifiziere ich mich häufig mit dem Kennwort des Dienstkontos:
kinit HTTP/[email protected]
Wenn dies fehlschlägt, versuchen Sie zur Bestätigung, dass das Dienstkonto nicht deaktiviert ist, die Basisauthentifizierung:
kinit account
Wenn die Authentifizierung fehlschlägt, löschen Sie einfach das Konto und erstellen Sie ein neues mit einem anderen Anmeldenamen, um Probleme zu vermeiden.
Es besteht eine hohe Wahrscheinlichkeit, dass eine andere Software – beispielsweise ein anderes System mit einem alten generierten Keytab für denselben SPN – versucht, sich bei diesem Dienstkonto zu authentifizieren und das Konto wegen eines ungültigen Kennworts deaktiviert.
Beim Einrichten von Kerberos SSO können zu schnelle Vorgänge zu Inkonsistenzen im Active Directory führen. Meine allgemeine Richtlinie, wenn ich im Konfigurationsprozess feststecke, ist, diese Schritte zu befolgen:
- Löschen Sie „alte“ oder „fehlerhafte“ Dienstkonten für Test- und Produktionssysteme
- Überprüfen Sie, ob
kvnoder SPN, den Sie konfigurieren möchten, im Bereich nicht mehr vorhanden ist. - Überprüfen Sie, ob
setspn -Xes bei mehreren Konten zu Konflikten zwischen SPNs kommt - Erstellen Sie pro System ein Servicekonto, das einem einzigen vollqualifizierten SPN zugeordnet ist, mit einem brandneuen Anmeldenamen
- Verhindern Sie die Änderung und das Ablaufen von Passwörtern für das Dienstkonto.
- warten wir eine Weile auf die DC-Synchronisation
- Passwort
ktpassbeim Generieren der Keytab-Datei als Option festlegen - Überprüfen Sie FQDN SPN und Aliase mit
setspn -l account
Hier ist eine Reihe von Befehlen zum Konfigurieren des Dienstkontos auf DC:
ktpass -princ HTTP/[email protected] -mapuser [email protected]
-crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL
-pass long!$longp2ass3word -out c:\temp\http-mysite-mycorp-com.keytab
setspn -a HTTP/mysite mysiteAccount
setspn -l mysiteAccount
Wenn Vorgänge zwischen MMC und dem Ausführen von ktpass zur Keytab-Generierung in einer administrativen Befehlszeile zu schnell auf verschiedenen DCs ausgeführt werden, kann die DC-Synchronisierung zu unerwarteten Ergebnissen wie dem von Ihnen beschriebenen führen. Warten wir also eine Weile zwischen der Kontoerstellung und dann ktpassallen weiteren setspnBefehlen.
Und Befehle, die unter Linux ausgeführt werden können, um zu überprüfen, ob alles ordnungsgemäß funktioniert:
kinit [email protected]
kinit HTTP/[email protected]
kinit -k -t http-mysite-mycorp-com.keytab HTTP/[email protected]
kvno HTTP/mysite.mycorp.com
kvno HTTP/mysite