Single-Sign-On mit Kerberos Constrained Delegation, Teil 2 - Debugging

Hallo liebe Leser,

in meinem letzten Beitrag bin ich auf die Kerberos Constrained Delegation Konfiguration eingegangen und hatte darin bereits versprochen, in diesem Beitrag das Debugging als Thema zu wählen.

Dadurch, dass wir Abhängigkeiten mit anderen Komponenten haben, wird das Debuggen sicher nicht einfacher. Grundsätzlich sollte im Fehlerfall aber überprüft werden, ob die BIG-IP denn die Active Directory (AD) Infrastruktur erfolgreich erreichen kann und ob die Zeit der BIG-IP auch gleich der des Key Distribution Center (KDC) ist.

Hier hilft auf dem Command Line Interface (CLI) der Befehl „ntpq –pn“ um zu überprüfen, ob die Zeit richtig ist:

Die Namensauflösung ist enorm wichtig bei Kerberos, da es davon abhängig ist. Ebenso auch die Reverse-DNS Auflösung, da dies auch verwendet wird um den SPN (Service Principal Name) für jeden Server nach der Loadbalancing Entscheidung zu bestimmen. Sollten die Namen nicht richtig im DNS eingetragen sein, so kann man diese auch auf der BIG-IP statisch hinterlegen. Das ist aber nur ein Workaround und sollte eigentlich vermieden werden.

Hier ein Beispiel um einen Eintrag zu setzen:

# tmsh sys global-settings remote-host add { server1 { addr 1.1.1.1 hostname sven } }

Natürlich ist das auch über die GUI möglich.

Hier nun ein paar Beispiele, wie man die Namensauflösung überprüfen kann. Der Befehl „nslookup“ hilft einem dabei:

[root@bigip1-ve:Active] config # nslookup www.example.com

Server: 10.0.0.25

Address: 10.0.0.25#53

Name: www.example.com

Address: 10.0.0.250

[root@bigip1-ve:Active] config # nslookup 10.0.0.250

Server: 10.0.0.25

Address: 10.0.0.25#53

250.0.0.10.in-addr.arpa name = www.example.com.

[root@bigip1-ve:Active] config # nslookup w2008r2.example.com

Server: 10.0.0.25

Address: 10.0.0.25#53

** server can't find w2008r2.example.com: NXDOMAIN

[root@bigip1-ve:Active] config # nslookup 10.0.0.26

Server: 10.0.0.25

Address: 10.0.0.25#53

26.0.0.10.in-addr.arpa name = win2008r2.example.com.

Da Kerberos SSO sich für die KDC-Ermittlung auf DNS verlässt (sofern hier keine Adresse in der SSO Konfiguration eingetragen wurde), sollte der DNS-Server auch SRV-Records haben, die auf den KDC-Server für den Realm der Domain zeigen. Wir erinnern uns hier, dass ich dies in der Konfiguration des letzten Blogs eingetragen habe. Die Begründung war, dass es dann schneller geht: Schließlich erspart man sich genau diese Auflöse-Prozedur an der Stelle.

[root@bigip1-ve:Active] config # nslookup -type=srv _kerberos._tcp.example.com

Server: 10.0.0.25

Address: 10.0.0.25#53

_kerberos._tcp.example.com service = 0 100 88 win2008r2.example.com.

[root@bigip1-ve:Active] config # nslookup -type=srv _kerberos._udp.example.com

Server: 10.0.0.25

Address: 10.0.0.25#53

_kerberos._udp.example.com service = 0 100 88 win2008r2.example.com.

Sind diese grundlegenden Konfigurationen nun überprüft und korrekt, aber es funktioniert noch nicht, hilft ein Blick in das APM Logfile. Vorher sollte aber der Debug-Level höher eingestellt werden. Dies bitte nur während des debuggens machen und anschließend wieder zurück stellen.

Im Menü kann man unter System/Logs/Configuration/Options den Level einstellen. „Informational“ ist hier ein guter Start. „Debug“ kann man sicher auch verwenden, aber der Level ist schon extrem gesprächig und in der Regel reicht „Informational“ vollkommen.

Schauen wir uns doch mal einen Ausschnitt eines Anmeldeprozesses an.

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:862 Initialized UCC:user1@EXAMPLE.COM@EXAMPLE.COM, lifetime:36000 kcc:0x8ac52f0

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:867 UCCmap.size = 1, UCClist.size = 1

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1058 S4U ======> - NO cached S4U2Proxy ticket for user: user1@EXAMPLE.COM server: HTTP/win 2008r2.example.com@EXAMPLE.COM - trying to fetch

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1072 S4U ======> - NO cached S4U2Self ticket for user: user1@EXAMPLE.COM - trying to fetch

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1082 S4U ======> - fetched S4U2Self ticket for user: user1@EXAMPLE.COM

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1104 S4U ======> trying to fetch S4U2Proxy ticket for user: user1@EXAMPLE.COM server: HTTP/win2008r2.example.com@EXAMPLE.COM

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1112 S4U ======> fetched S4U2Proxy ticket for user: user1@EXAMPLE.COM server: HTTP/win2008r2.example.com@EXAMPLE.COM

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:1215 S4U ======> OK!

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:236 GSSAPI: Server: HTTP/win2008r2.example.com@EXAMPLE.COM, User: user1@EXAMPLE.COM

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:278 GSSAPI Init_sec_context returned code 0

Oct 28 12:06:46 bigip1-ve debug /usr/bin/websso[400]: 01490000:7: <0xf1c75b90>:Modules/HttpHeaderBased/Kerberos.cpp:316 GSSAPI token of length 1451 bytes will be sent back

Hilfreich ist es natürlich auch die Logfiles des IIS anzuschen. Hier kann man sich auch den Usernamen anzeigen lassen (C:\inetpub\logs\LogFiles\W3SVC1):

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken

2011-10-27 21:29:23 10.0.0.25 GET / - 80 EXAMPLE\user2 10.0.0.28 Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+Trident/5.0) 200 0 0 15

Eine weitere Fehleranalysemöglichkeit ist natürlich sich anzuschauen, was denn für Daten über die Leitung gehen. Tcpdump und Wireshark sind hierbei unsere Freunde,

# tcpdump –i internal –s0 –n–w /tmp/kerberos.pcap host 10.0.0.25

-i: das VLAN, die es zu belauschen gilt. Wählt man hier „0.0“ wird auf allen Schnittstellen gesniffert und man sieht die Pakete entsprechend oft. bzw. auch die Veränderungen, die ein Paket ggf. beim Durchlaufen der BIG-IP erfährt.

-s0: bedeutet, dass das gesamte Paket aufgezeichnet werden soll

-n: keine Namensauflösung

-w /tmp/kerberos.pcap: Die Aufzeichnungen in die Datei /tmp/kerberos.cap speichern

host 10.0.0.25: nur Pakete mit der Quell- oder Ziel-IP 10.0.0.25 aufzeichnen.

Im Wireshark sieht eine Aufzeichnung dann etwa so aus:

Wireshark versteht das Kerberos Protokoll und gibt somit gute Hinweise auf mögliche Probleme.

Da APM die Kerberos Tickets cached, kann dies natürlich beim Testen zu unerwünschten Effekten führen. Das bedeutet es macht durchaus Sinn, während der Tests die Ticket Lifetime von standardmässig 600 Minuten runter zu setzen. Zudem kann man auch den Cache mit folgenden Befehl leeren:

# bigstart restart websso

Zum guten Schluß möchte ich dann noch ein paar Fehlermeldungen erläutern, die man im Log bei Problemen finden kann:

Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Cannot find KDC for requested realm (-1765328230) – Hier sollte man überprüfen ob DNS funktioniert und der DNS Server alle SRV/A/PTR Records der involvierten Realms hat. In der Datei /etc/krb5.conf auch bitte überprüfen, ob dns_lookup_kdc auf True gesetzt ist. Den Eintrag findet man in dem Bereich [libdefaults].

Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Preauthentication failed (-1765328360) – Das Delegation Account Passwort ist falsch.

Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Client not found in Kerberos database (-1765328378) – Der Delegation Account existiert nicht im AD.

Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - Clients credentials have been revoked (-1765328366) – Der Delegation Account ist im AD abgeschaltet.

Kerberos: can't get TGT for host/apm.realm.com@realm.com - KDC reply did not match expectations (-1765328237) – Der Realm Name in der SSO Konfiguration muss groß geschrieben sein.

Kerberos: can't get TGT for host/apm.realm.com@REALM.COM - A service is not available that is required to process the request (-1765328355) – Die Verbindung mit dem KDC ist nicht möglich. Gründe können z.B. sein: Firewall, TGS Service auf dem KDC läuft nicht oder es ist der falsche KDC angegeben…

Kerberos: can't get S4U2Self ticket for user a@REALM.COM - Client not found in Kerberos database (-1765328378) – Es gibt den User 'a' nicht in der Domain REALM.COM.

Kerberos: can't get S4U2Self ticket for user qq@REALM.COM - Ticket/authenticator don't match (-1765328348) – Der Delegation Account hat die Form UPN/SPN und entspricht nicht der verwendeten REALM Domain. Achtung, wenn man hier mit Cross-Realms arbeitet!

Kerberos: can't get S4U2Self ticket for user aa@realm.com - Realm not local to KDC (-1765328316) – Das KDC Feld muss leer gelassen werden in der SSO Konfiguration, wenn man mit Cross-Realm SSO arbeitet. Also wenn ein User einen Server in einem anderen Realm erreichen muss.

Kerberos: can't get S4U2Proxy ticket for server HTTP/webserver.realm.com@REALM.COM - Requesting ticket can't get forwardable tickets (-1765328163) – Der Delegation Account ist nicht für Constrained Delegation und/oder Protocol Transition konfiguriert.

Kerberos: can't get S4U2Proxy ticket for server HTTP/webserver.realm.com@REALM.COM - KDC can't fulfill requested option (-1765328371) – Der Delegation Account in REALM.COM hat keinen Service für webserver.real.com in seiner Konfiguration.

Damit Sie Kerberos auf der Windows Seite debuggen können, hilft vielleicht dieser Artikel:

• http://www.microsoft.com/downloads/details.aspx?FamilyID=7DFEB015-6043-47DB-8238-DC7AF89C93F1&displaylang=en

So, ich hoffe natürlich, dass Sie keine Probleme bei der Konfiguration des SSO mit Constrained Delegation haben, aber falls doch, hilft Ihnen hoffentlich dieser Blog-Beitrag, um dem Problem schneller auf die Spur zukommen.

Ihr F5-Blogger, Sven Müller