# Single-Sign-On mit Kerberos Constrained Delegation, Teil 2 - Debugging **URL:** \ **Category:** F5 Technical Articles\ **Tags:** germany, industry, microsoft\ **Created:** [March 25, 2013, 9:36am UTC](https://community.f5.com/t/single-sign-on-mit-kerberos-constrained-delegation-teil-2-debugging/68066 "2013-03-25T09:36:12Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Sven\_Mueller](https://d1p9zq3aats0t8.cloudfront.net/user_avatar/community.f5.com/sven_mueller/32/8872_2.png) [@Sven\_Mueller](https://community.f5.com/u/Sven_Mueller)\ **Post date:** [March 25, 2013, 9:36am UTC](https://community.f5.com/t/single-sign-on-mit-kerberos-constrained-delegation-teil-2-debugging/68066/1 "2013-03-25T09:36:12Z")
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: [![image_287098.png](https://d20hrnpixdzcsd.cloudfront.net/original/2X/c/cd2f85db18c99a010d830b19b6bb8120b3c86995.png)](https://community.f5.com/Portals/0/images/metapost/News-Articles/smu/2013/Mar/Windows-Live-Writer-3090e169f03e_94CF-clip_image001_2.png) 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](http://www.example.com)** Server: 10.0.0.25 Address: 10.0.0.25#53 Name: [www.example.com](http://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](http://www.example.com). **[root@bigip1-ve:Active] config # nslookup [w2008r2.example.com](http://w2008r2.example.com)** Server: 10.0.0.25 Address: 10.0.0.25#53 \*\* server can’t find [w2008r2.example.com](http://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](http://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](http://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](http://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. [![image_287098.png](https://d20hrnpixdzcsd.cloudfront.net/original/2X/d/d66a2779a60cc2698763b41a66148925ed340d83.png)](https://community.f5.com/Portals/0/images/metapost/News-Articles/smu/2013/Mar/Windows-Live-Writer-3090e169f03e_94CF-clip_image002_2.png) 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](mailto:user1@EXAMPLE.COM) server: HTTP/win [2008r2.example.com@EXAMPLE.COM](mailto: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](mailto: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](mailto: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](mailto:user1@EXAMPLE.COM) server: [HTTP/win2008r2.example.com@EXAMPLE.COM](mailto: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](mailto:user1@EXAMPLE.COM) server: [HTTP/win2008r2.example.com@EXAMPLE.COM](mailto: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](mailto:HTTP/win2008r2.example.com@EXAMPLE.COM), User: [user1@EXAMPLE.COM](mailto: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: [![image_287098.jpg](https://d20hrnpixdzcsd.cloudfront.net/original/2X/7/79361af0a6d77e63d47beba23d2d1e1703ca8ee4.jpeg)](https://community.f5.com/Portals/0/images/metapost/News-Articles/smu/2013/Mar/Windows-Live-Writer-3090e169f03e_94CF-clip_image004_2.jpg) 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](mailto: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](mailto: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](mailto: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](mailto: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](mailto: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](mailto: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**](https://peterpan.f5net.com/twiki/bin/edit/TMOS/S4U2Self?topicparent=TMOS.ApmKerberosSSOFS;nowysiwyg=0) **ticket for user** [**a@REALM.COM**](mailto:a@REALM.COM) **- Client not found in Kerberos database (-1765328378)** – Es gibt den User ‘a’ nicht in der Domain [REALM.COM](http://REALM.COM). **Kerberos: can’t get** [**S4U2Self**](https://peterpan.f5net.com/twiki/bin/edit/TMOS/S4U2Self?topicparent=TMOS.ApmKerberosSSOFS;nowysiwyg=0) **ticket for user** [**qq@REALM.COM**](mailto: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](https://peterpan.f5net.com/twiki/bin/edit/TMOS/S4U2Self?topicparent=TMOS.ApmKerberosSSOFS;nowysiwyg=0) ticket for user** **[aa@realm.com](mailto: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**](https://peterpan.f5net.com/twiki/bin/edit/TMOS/S4U2Proxy?topicparent=TMOS.ApmKerberosSSOFS;nowysiwyg=0) **ticket for server [HTTP/webserver.realm.com@REALM.COM](mailto: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**](https://peterpan.f5net.com/twiki/bin/edit/TMOS/S4U2Proxy?topicparent=TMOS.ApmKerberosSSOFS;nowysiwyg=0) **ticket for server [HTTP/webserver.realm.com@REALM.COM](mailto:HTTP/webserver.realm.com@REALM.COM) - KDC can’t fulfill requested option (-1765328371)** – Der Delegation Account in [REALM.COM](http://REALM.COM) hat keinen Service für [webserver.real.com](http://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](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 ---
**Author:** ![Abdessamad1](https://avatars.discourse-cdn.com/v4/letter/a/d6d6ee/32.png) [@Abdessamad1](https://community.f5.com/u/Abdessamad1)\ **Post date:** [February 10, 2016, 4:28pm UTC](https://community.f5.com/t/single-sign-on-mit-kerberos-constrained-delegation-teil-2-debugging/68066/2 "2016-02-10T16:28:18Z")
Hello, Any idea on this error msg? Kerberos: can’t get S4U2Self ticket for user [user123@DOMAIN1.COMPANY.BE](mailto:user123@DOMAIN1.COMPANY.BE) - Generic error (see e-text) (-1765328324) Thanks.