Wiki-Quellcode von Troubleshooting Kerberos

Zeige letzte Bearbeiter
1 {{content depth="4"/}}
2
3 == Problemlösung bei Kerberos ==
4
5 Folgend werden Lösungsmöglichkeiten für einige bekannte Probleme bei der Einrichtung und Verwendung von Kerberos aufgeführt.
6
7 === Fehlgeschlagener Login aufgrund fehlender SPN-Einträge ===
8
9 Wenn der Login bei Kerberos fehlschlägt ist es empfohlen als erstes zu prüfen ob sowohl der **Computer-Name des Anwendungsservers** als auch der **Host für die aufgerufene URL** entsprechende Service Prinzipal Name (SPN) im Kerberos-Server (KDC) registriert wurde.
10
11 (% class="wikigeneratedid" id="HVorgehenbeimMicrosoftActiveDirectory" %)
12 **Vorgehen beim Microsoft Active Directory**
13
14 Beim Active Directory ist für das Verwalten der SPN`s das Kommandozeilen-Tool SetSPN einsetzbar: [[//https:~~/~~/social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spn-setspn-syntax.aspx//>>url:https://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spn-setspn-syntax.aspx]]
15
16 Dieses steht auf dem Domain-Controller für verschiedene Funktionen zur Verfügung und kann dort wie folgt benutzt werden:
17
18 (% class="wikigeneratedid" id="HAnzeigederregistrierteSPNB4seinesAccounts" %)
19 **Anzeige der registrierte SPN´s eines Accounts**
20
21 {{code language="none"}}
22 setspn -L <kerberos-user-account>
23 {{/code}}
24
25 [[image:kerberos_registered_spn.png||alt="Anzeigen der registrierten SPN´s eines Accounts" height="80" width="751"]]
26
27 (% class="wikigeneratedid" id="HRegistriereneinesneuenSPN-Eintrags28entsprechendeBerechtigungenvorausgesetzt29" %)
28 **Registrieren eines neuen SPN-Eintrags (entsprechende Berechtigungen vorausgesetzt)**
29
30 {{code language="none"}}
31 setspn -s HTTP/<externer-host> <kerberos-user-account>
32 setspn -s HTTP/<computer-name>.<domain-name> <kerberos-user-account>
33 setspn -s HTTP/<computer-name> <kerberos-user-account>
34 {{/code}}
35
36 Der Platzhalter //<kerberos-user-account>// beschreibt den Nutzernamen, welcher in der Kerberos-Konfigurations-Oberfläche im Bereich Authentifizierung eingetragen wurde. Es ist zu beachten, dass ein SPN nur einem Benutzer zugeordnet werden darf. Die Mehrfachverwendung desselben SPN´s ist also untersagt und zu vermeiden!
37
38 Beispiel:
39
40 {{code language="none"}}
41 setspn -s HTTP/www.example.de ldap-login
42 setspn -s HTTP/server1.xima.de ldap-login
43 setspn -s HTTP/server1 ldap-login
44 {{/code}}
45
46 (% class="wikigeneratedid" id="HPrFCfungderTicket-Erzeugung" %)
47 **Prüfung der Ticket-Erzeugung**
48
49 Ist auf Rechner mit welchem das Formular aufgerufen wird das Tool **//kinit//** installiert (wir z.B. mit Java ausgeliefert), so lässt sich das Erzeugen eines Kerberos-Tickets hierrüber testen:
50
51 {{code language="none"}}
52 kinit <Benutzername>@<REALM/DOMAIN>
53 {{/code}}
54
55 Ferner lassen sich mit dem Befehl **//klist//** die Liste der aktuellen Kerberos-Tickets ausgeben:
56
57 {{code language="none"}}
58 klist
59 {{/code}}
60
61 Unter Linux lässt sich mit folgendem Befehl auch der Aufruf des geschützten Formulars direkt simulieren:
62
63 {{code language="none"}}
64 curl --negotiate -v -L -o out.html -u <Benutzername> https://<FORMCYCLE-Server>/form/provide/<Fomrular-ID>/
65 {{/code}}
66
67 * //-u// Aufruf als angegebener Benutzer. Für diesen erfolgt eine Passwortabfrage
68 * //-v// Ausgabe von mehr Informationen
69 * //-L// HTTP-Redirects werden gefolgt
70 * //-o// Rückgabe in die Datei out.html schreiben
71
72 Dieser Aufruf kann für die Fehlersuche auch auf einem vorgeschalteten Webserver/Proxy verwendet werden.
73
74 Als Ergebnis ist in der Datei **//out.html//** das eigentliche Formular in HTML-Format sowie die Ausgabe des HTTP-Statuscode 200 zu erwarten. Ist dies der Fall, ist damit nachgewiesen, dass die prinzipielle Kommunikation mit dem KDC sowie der registrierte SPN korrekt funktionieren.
75
76 === Es konnte keine Verbindung zum Key Distribution Center (KDC) aufgebaut werden ===
77
78 ==== Benutzername zu lang ====
79
80 Es kann unter Umständen sein, dass der Benutzername eine Limitierung von 20 Zeichen hat. Sollte der Service Account Name länger sein, kann dies dazu führen, dass der Benutzer nicht gefunden wird und folglich kein Login möglich ist. Es muss nun entweder der Name gekürzt werden oder unter der Konto-Einstellung Benutzeranmeldename (Prä Windows 2000) ein verkürzte Angabe erfolgen. Diese muss dann auch unter Authentifizierung als Nutzername eingetragen werden.
81
82 === Keine Benutzerdaten nach erfolgreichem Login ===
83
84 Kerberos selbst liefert keine Nutzerdaten, sondern lediglich einen Kerberos-Login nach dem Muster //<Benutzername >(/<Instanz>)@<REALM>// zurück. Der konkrete Wert kann im Formular über die Konsole (F12) mittels //XFC_METADATA.user.id// ausgelesen werden. Die Nutzerdaten, welche per //XFC_METADATA//-Objekt und über den [%$USER%]-Platzhalter zu Verfügung gestellt werden, werden anhand dieses Logins über LDAP ermittelt. Hierbei ist folgendes zu beachten:
85
86 * Über die angegebene BaseDN in den Kerberos Einstellungen ist der gesuchte Benutzer ermittelbar
87 * Für die LDAP-Abfrage wird standardmäßig der Kerberos-Login gegen die Attribute **//sAMAccountName//**, **//userPrincipalName//**, **//uid//** und **//DN//** geprüft.
88
89 Entspricht keiner der Benutzer-Attribute dem Kerberos-Login, kommt es dazu, dass der Benutzer nicht per LDAP ermittelt werden kann und somit keine weiterführenden Daten zur Verfügung stehen. Dies ist z.B. oft bei der Verwendung eines Domain-Alias der Fall. Um dieses Problem zu lösen ist es seit FORMCYCLE Version 6.6.5 möglich den entsprechenden Standard-LDAP-Filter zu überschreiben. (siehe [[Konfigurationsdateien>>doc:Formcycle.SystemSettings.ConfigFiles.ApplicationProperties||anchor="HLDAP" target="_blank"]]).
90
91 Hierfür wird in der Datei //application.properties// ein entsprechender Eintrag ergänzt. Den Pfad zur Konfigurationsdatei können Sie in den [[Serverinformationen >>doc:Formcycle.SystemSettings.UserInterface.ServerInformation||target="_blank"]]unter Systempfade innerhalb von FORMCYCLE auslesen.
92
93 Um die Benutzersuche zum Beispiel nur auf das Attribute **//sAMAccountName//** und den Benutzernamen aus dem Kerberos-Login zu beschränken kann z.B. folgender Eintrag verwendet werden:
94
95 {{code language="none"}}
96 ldap.override.filter.kerberos.user=(sAMAccountName={2})
97 {{/code}}
98
99 Ein Neustart ist nicht erforderlich. Sobald nun ein Benutzer mit dem entsprechenden Attribut gefunden wurde sollten das //XFC_METADATA//-Objekt sowie der entsprechende Platzhalter mit Daten gefüllt sein.
100
101 Ein konkretes Beispiel:
102
103 {{info}}
104 Benutzer-Eingabe im Login-Prompt: test oder [[test@example.com>>path:mailto:test@example.com]] inkl. Passwort
105
106 Zurückgegebener Kerberos-Login: test/admin@EXAMPLE.COM
107
108 Extrahierter Benutzername: test
109
110 Resultierender LDAP-Filter: (sAMAccountName=test)
111 {{/info}}
112
113 === Fehlgeschlagener oder nicht automatischer Login aufgrund fehlender Browser-Einstellungen ===
114
115 Je nach Browser sind für die Benutzung von Kerberos verschiedene Einstellungen nötig. Sollten diese nicht durchgeführt werden, ist der Login entweder nicht erfolgreich, wird nicht automatisch ausgeführt oder es kommt beim Fomular-Aufruf sofort zur Anzeige einer Fehlerseite.
116
117 ==== Google Chrome, Microsoft Internet Explorer und Microsoft Edge ====
118
119 Sowohl Google Chrome, der Microsoft Internet Explorer als auch der Microsoft Edge benutzen für ihre Kerberos-Einstellung die Betriebssystem-eigene Konfiguration. Um einen Kerberos-Login zu ermögliche muss hierfür die aufgerufene Seite als sicher eingestuft werden. Im folgenden Beispiel wird dies in Microsoft Windows über das Hinzufügen dieser Seite in die Intranet-Zone demonstriert:
120
121 1. Öffnen Sie die Internetoptionen und wechseln Sie in den Tab „Sicherheit“
122 [[image:kerberos_settings_internet.png||height="500"]]
123 1. Wählen Sie die Zone „Lokales Intranet“ und öffnen Sie die dafür zugehörigen Einstellungen über die Schaltfläche „Stufe anpassen“. Prüfen Sie in dieser Liste unter „Benutzerauthentifizierung“ -> „Anmeldung“ ob die Option „Automatisches Anmelden für die Intranetzone“ aktiviert ist.
124 [[image:kerberos_security_settings.png||height="400" width="331"]]
125 1. Fügen Sie nun die FORMCYCLE-URL zu den vertrauenswürdigen Intranet-Seiten hinzu.
126 Öffnen Sie hierfür in der „Lokales Intranet“-Zone über die Schaltfläche „Sites“ folgenden Dialog:
127 [[image:kerberos_local_intranet.png||height="200" width="346"]]
128 1. Über die Schaltfläche „Erweitert“ gelangen Sie schließlich in den Dialog zum Definieren der vertrauenswürdigen Seiten. Fügen Sie hier die entsprechende FORMCYCLE-URL hinzu und bestätigen Sie alle Fenster mit „Schließen“ bzw. „OK“
129 [[image:kerberos_local_intranet_extended.png]]
130
131 ==== Microsoft Edge ====
132
133 Unter Microsoft Edge kann es je nach Konfiguration unter den Gruppenrichtlinen notwendig sein, dass auch hier die FORMCYCLE-URL hinterlegt werden muss. Dies ist aber nur erforderlich, wenn unter den Gruppenrichtlinien Einschränkungen vorgenommen worden, ansonsten sind alle URLs erlaubt. Die aktuelle Einstellung kann unter //**edge:~/~/policy **//geprüft werden.
134
135 [[image:kerberos_edge_richtlinien.png||height="466" width="951"]]
136
137 Über "Richtlinien neu laden" können diese im Browser nachträgliche aktualisiert werden. Unter folgenden [[Link >>https://stackoverflow.com/questions/57034199/integrated-windows-authentication-in-microsoft-edge||rel="noopener noreferrer" target="_blank"]]wird die Lösung genauer erläutert.
138
139 ==== Firefox ====
140
141 Im Gegensatz zu Google Chrome oder den Microsoft Browsern benutzt Firefox eine Betriebssystem-unabhängige Konfiguration. Dementsprechend muss für den Einsatz von Kerberos auch hier die FORMCYCLE-Seite aus vertrauenswürdig hinzugefügt werden. Dies geschieht wie folgt:
142
143 1. Öffnen Sie Firefox und rufen Sie die URL **//about:config//** auf
144 1. Bestätigen Sie ggf. erscheinende Sicherheitshinweise
145 1. Filtern Sie die Liste der Konfigurationen nach dem Begriff **//negotiate//**
146 1. Tragen Sie in dem Attribut// **network.negotiate-auth.trusted-uris**// die gewünschten und erlauben Domains Komma-separiert ein und bestätigen Sie die Eingabe über den blauen Haken.
147 [[image:kerberos_setting_firefox.png||height="300"]]
148
149 === Weitere bekannte Fehler und Probleme ===
150
151 ==== Es erscheint kein Login-Prompt und der Benutzer ist nicht am Formular angemeldet ====
152
153 Hierbei handelt es sich wahrscheinlich um ein Konfigurations-Problem. Häufigste Ursachen sind hierbei eine zu geringe HTTP-Header-Größe und eine nicht erlaubte Verschlüsselung der Kerberos-Tickets. Um diese zu beheben können Sie wie folgt vorgehen
154
155 1. Erhöhung der zulässigen Größe von HTTP-Headern im Apache Tomcat Server
156 11. Folgen Sie der Anleitung unter [[Beschränkung HTTP-Header Größe ändern>>https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#libdefaults||rel="noopener noreferrer" target="_blank"]]
157 1. Erhöhung der zulässigen Packet-Größe bei der Verwendung des Apache Tomcats in Kombination mit einem Webserver (hier z.B. Apache HTTP) über den AJP-Connector
158 11. Öffnen Sie die Datei server.xml innerhalb des config-Ordners Ihrer Tomcat-Installation
159 11. Ergänzen Sie am verwendeten AJP-Connector das Attribut **//packetSize="65536"//** (Standardwert: 8192 Byte)
160 11. Passen Sie an den verwendeten Worker-Konfigurationen oder innerhalb der Apache-Proxy-Konfiguration die entsprechende Packet-Size ebenso auf **//65536//** an (siehe [[Proxy-Einstellungen>>https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#ProxyIOBufferSize]] bzw. unter [[Worker-Einstellungen>>http://tomcat.apache.org/connectors-doc/reference/workers.html]] > "max_packet_size")
161 11. Fügen Sie innerhalb des Webservers in der entsprechenden Konfigurations-Datei des VirtualHosts die Direktive **//LimitRequestFieldSize//** mit dem Wert **//65536//** ein.
162 11. Um die getroffenen Einstellungen zu übernehmen ist es erforderlich den Tomcat-Server neu zu starten und beim Webserver mindestens ein Reload der Einstellungen anzustoßen
163 1. Anpassung der erlaubten Ticket-Verschlüsselungen
164 11. Standardmäßig werden von FORMCYCLE die als sicher geltenden Verschlüsselungen für die Kerberos-Tickets angeboten und konfiguriert. Sollten diese nicht ausreichen da die Gegenstelle (also das KDC) noch veraltete und unsichere Algorithmen verwendet, ist es möglich diese wieder zu aktivieren. Öffnen Sie hierfür die Oberfläche für die Kerberos-Konfiguration innerhalb von FORMCYCLE.
165 11. Ergänzen Sie im Bereich „Datei krb5.conf“ unter den Punkten **//default_tkt_enctypes//**//, **default_tgs_enctypes**// und **//permitted_enctypes//** die gewünschten Algorithmen. Für ältere Active Directory Versionen fehlt hier meist der Wert „rc4-hmac“. Weitere Werte entnehmen Sie bitte [[unter>>https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/krb5_conf.html#libdefaults||rel="noopener noreferrer" target="_blank"]].
166
167 ==== Im Firefox erscheint ohne Login sofort eine Fehlermeldung ====
168
169 Firefox ist in diesem Fall nicht für den Login mittels Kerberos konfiguriert und versucht deswegen einen Login per Basic-Auth oder NTLM durchzuführen. Da diese nicht erlaubt sind erscheint sowohl die Fehlermeldung im Browser als auch im Anwendungs-Log. Prüfen Sie die Konfiguration Ihres Browsers und Testen Sie den Login ggf. mit einem anderen Browser.
170
171 ==== Nach dem Abbrechen des Login-Dialogs erscheint eine leere Seite oder eine Browsermeldung ====
172
173 Dieses Verhalten ist korrekt da seitens FORMCYCLE kein Inhalt beim Abbrechen der Anmeldung ausgeliefert werden kann. Je nach Browser verbleibt der vorherige Inhalt oder es kommt zur beschriebenen Anzeige einer leeren Seite bzw. einer Browsermeldung.
174
175 ==== Erfolglose Login-Versuche aufgrund von Zertifikatsproblemen ====
176
177 Kommt es bei erfolglosen Login-Versuchen im Anwendungs-Log zu folgender Fehlermeldung deutet dies auf ein Zertifikats-Problem hin:
178
179 {{code language="none"}}
180 [info] [ERROR] [Date+Time] [http-nio-8080-exec-5] (KerberosTicketValidatorImpl.java:48) - Error while validating kerberos login
181
182 [info] java.security.PrivilegedActionException: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
183 {{/code}}
184
185 Ursache kann hierbei z.B. ein selbst signiertes oder nicht mehr valides Zertifikat sein. Prüfen Sie hier Ihr verwendetes Zertifikat und tauschen Sie dies ggf. gegen ein valides aus. Wird ein selbst signiertes Zertifikat verwendet, so muss dieses dem Java Keystore hinzugefügt werden. Eine genauere Beschreibung dazu finden Sie [[hier>>doc:Formcycle.Installation.ImportCertificatesToKeyStores||target="_blank"]].
186
187 ==== Vorgeschalteter Proxyserver leitet Kerberos-Ticket nicht weiter ====
188
189 Wenn vor das FORMCYCLE ein (Reverse-) Proxy vorgeschaltet wird, kann es je nach Konfiguration des Proxyservers sein, dass der Request mit dem Kerberos-Ticket für die Authentifizierung nicht bis zum FORMCYCLE Server durchgereicht wird bzw. Aufgrund von Limitierungen bei der maximalen Paketgröße nicht durchgereicht werden kann. Falls dies der Fall ist, muss die Konfiguration des Proxyservers entsprechend so angepasst werden, dass der Aufruf (vollständig) an den FORMCYCLE Server gesendet wird.
190
191 === Debug-Modus aktivieren ===
192
193 Sollten keine der beschriebenen Maßnahmen zu einem erfolgreichen Kerberos-Login führen ist es meist hilfreich das Debug-Log von Kerberos zu aktivieren. Dies führt dazu, dass die einzelnen Schritte und auch ggf. auftretenden Fehler ausführlicher im Server-Log protokoliert werden. Um das Debug-Log zu aktivieren gehen Sie wie folgt vor:
194
195 1. Öffnen Sie die Oberfläche zur Kerberos-Konfiguration in FORMCYCLE
196 1. Fügen Sie im Bereich „Datei krb5.conf“ in den nicht funktionierenden Realms den Eintrag **//debug=true//** ein
197 [[image:kerberos_debug_krb5_conf.png||height="350" width="407"]]
198 1. Fügen Sie im Bereich „Datei login.conf“ unter dem Punkt „spnego-server“ den Eintrag **//debug=true//** ein
199 [[image:kerberos_debug_login_conf.png||height="350" width="404"]]