Ich habe Apache HTTPD 2.4 mit mod_auth_kerb eingerichtet, ein Dienstkonto im Active Directory erstellt, einen SPN für meinen HTTP-Hostnamen hinzugefügt, eine Keytab-Datei auf der Linux-Maschine erstellt und SSO funktioniert nun reibungslos für Benutzer, die sich über IE bei der AD-Domäne angemeldet haben. Alles war gut!
Allerdings werden Benutzer etwa jede Woche nicht auf der Website angemeldet, sondern erhalten stattdessen eine HTTP-Basisauthentifizierungsaufforderung, die ihre Anmeldeinformationen nicht akzeptiert. In den HTTPD-Serverprotokollen finden wir Einträge wie:
[auth_kerb:error] [pid 8040] [client 192.168.100.100:54460] gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, Key version number for principal in key table is incorrect)
Was anscheinend passiert ist, ist, dass die KVNO (Kerberos Key Version Number) auf AD hochgezählt wurde, sodass der Keytab ungültig ist. Wir können das sehen, indem wir etwas wie Folgendes tun:
$ kinit '[email protected]'
Password for [email protected]
$ kvno HTTP/sso.example.com
HTTP/[email protected]: kvno = 12
$ klist -k krb5-keytab
Keytab name: FILE:krb5-keytab
KVNO Principal
---- ---------------------------------------------
11 HTTP/[email protected]
Der von AD gemeldete KVNO wurde irgendwie erhöht und ist um eins höher als der in der von Apache verwendeten Keytab, was dazu führt, dass das Kerberos-SSO fehlschlägt.
Wenn wir die Keytab neu erstellen, etwa mit:
$ kinit '[email protected]'
Password for [email protected]
$ KEYTAB=krb5-keytab
$ SN="HTTP/[email protected]"
$ KVNO=`kvno $SN | awk -F'kvno = ' '{print $2}'`
$ echo "KVNO for $SN is $KVNO"
KVNO for HTTP/[email protected] is 12
$ rm $KEYTAB
$ ktutil
addent -password -p HTTP/[email protected] -k 12 -e arcfour-hmac
wkt krb5-keytab
$ chown apache.apache $KEYTAB
$ chmod 440 $KEYTAB
$ chcon -u system_u -t httpd_config_t $KEYTAB
$ service httpd restart
Dann funktioniert Kerberos SSO wieder und alles ist gut! Etwa eine Woche lang, bis es plötzlich wieder nicht funktioniert, da sich KVNO still und heimlich auf AD um einen Wert erhöht hat ...
Was muss ich also tun, entweder in AD oder bei der Erstellung der Kerberos-Keytab-Datei unter Linux, damit sich KVNO nicht alle 1–2 Wochen zufällig erhöht und somit allen unseren Benutzern der Zugriff auf die Site verweigert wird?
Antwort1
Active Directory erhöht KVNO gemäß RFC 4120. Microsoft hat die Implementierung im Dokument MS-KILE, Abschnitt 3.1.5.8, dokumentiert.
Active Directory ignoriert KVNOs grundsätzlich. (Außer bei schreibgeschützten DCs – wenn ein RODC kompromittiert wird, können die darin enthaltenen Schlüssel nicht für einen anderen DC wiederverwendet werden.) Mein Punkt ist also, dass AD im Allgemeinen egal ist, was Ihr KVNO ist – obwohl es weiterhin KVNOs verwaltet – es kümmert sich nur darum, ob Ihr Ticket gültig und nicht abgelaufen ist. (Ob Ihr Linux-Client KVNOs streng prüft, weiß ich allerdings nicht. Offenbar tut er das.)
Active Directory versucht, mit dem aktuellsten Schlüssel zu entschlüsseln/validieren, den es für diesen Principal hat. Wenn das nicht funktioniert, versucht es es mit dem vorherigen (sofern der vorherige Schlüssel noch gültig ist). Wenn das nicht funktioniert, schlägt die Anfrage fehl. Unabhängig davon, welche KVNO der Client sendet. Denken Sie jedoch daran, dass nicht alle Domänencontroller Ihre KVNO-1 (also die vorherige KVNO) haben, sondern nur der Domänencontroller, der Ihr Ticket zuletzt ausgestellt hat.
KVNO wird erhöht, wenn der Clientcomputer sein Kennwort ändert, sein Ticket erneuert oder sein Ticket abläuft. Standardmäßig verwendet Active Directory 7 Tage als maximale Zeit, in der ein Ticket erneuert werden kann, was Ihrer Beschreibung von entspricht"es funktioniert ungefähr eine Woche lang."
Es gibt keinen Mechanismus, der Active Directory daran hindert, KVNO zu erhöhen, wenn es eine gültige Kennwortänderung oder Ticketrotation von einem Domänenmitgliedscomputer empfängt. Mein Punkt ist also, dass Active Directory KVNO nicht „auf mysteriöse Weise“ aktualisiert – es tut dies aus bestimmten Gründen.
Mir scheint, dass Ihr Linux-Rechner immer noch versucht, sein (jetzt abgelaufenes) Ticket nach dessen maximaler Gültigkeitsdauer von 7 Tagen zu verwenden. (Oder Active Directory wurde für eine kürzere Gültigkeitsdauer konfiguriert.)
Sehen Sie in Ihrem /etc/krb5.confActive Directory nach und überprüfen Sie, ob die maximale Ticketlebensdauer innerhalb der in Active Directory angegebenen maximalen Ticketlebensdauer liegt (die Kerberos-Richtlinie in der Standarddomänengruppenrichtlinie). Sie müssen Ihr Ticket innerhalb des in AD angegebenen Intervalls erneuern (und Ihr KVNO muss erhöht werden).
Antwort2
Sie sind wahrscheinlich auf diesen Fehler gestoßen https://bugzilla.samba.org/show_bug.cgi?id=6750
Es gibt ein paar Änderungen in der Samba-Konfiguration, die das Problem lösen. Ich habe
kerberos method = secrets and keytab