Inhalt

Folgend werden Lösungsmöglichkeiten für einige bekannte Probleme bei der Einrichtung und Verwendung von Kerberos aufgeführt.

Fehlgeschlagener Login aufgrund fehlender SPN-Einträge

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.

Vorgehen beim Microsoft Active Directory

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

Dieses steht auf dem Domain-Controller für verschiedene Funktionen zur Verfügung und kann dort wie folgt benutzt werden:

Anzeige der registrierte SPN´s eines Accounts

setspn -L <kerberos-user-account>

Registrieren eines neuen SPN-Eintrags (entsprechende Berechtigungen vorausgesetzt)

setspn -s HTTP/<externer-host> <kerberos-user-account>
setspn -s HTTP/<computer-name>.<domain-name> <kerberos-user-account>
setspn -s HTTP/<computer-name> <kerberos-user-account>

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!

Beispiel:

setspn -s HTTP/www.example.de ldap-login
setspn -s HTTP/server1.xima.de ldap-login
setspn -s HTTP/server1 ldap-login

Prüfung der Ticket-Erzeugung

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:

kinit <Benutzername>@<REALM/DOMAIN>

Ferner lassen sich mit dem Befehl klist die Liste der aktuellen Kerberos-Tickets ausgeben:

klist

Unter Linux lässt sich mit folgendem Befehl auch der Aufruf des geschützten Formulars direkt simulieren:

curl --negotiate -v -L -o out.html -u <Benutzername> https://<FORMCYCLE-Server>/form/provide/<Fomrular-ID>/

• -u Aufruf als angegebener Benutzer. Für diesen erfolgt eine Passwortabfrage
• -v Ausgabe von mehr Informationen
• -L HTTP-Redirects werden gefolgt
• -o Rückgabe in die Datei out.html schreiben

Dieser Aufruf kann für die Fehlersuche auch auf einem vorgeschalteten Webserver/Proxy verwendet werden.

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.

Es konnte keine Verbindung zum Key Distribution Center (KDC) aufgebaut werden

Benutzername zu lang

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.

Keine Benutzerdaten nach erfolgreichem Login

Kerberos selbst liefert keine Nutzerdaten, sondern lediglich einen Kerberos-Login nach dem Muster (/)@ 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:

• Über die angegebene BaseDN in den Kerberos Einstellungen ist der gesuchte Benutzer ermittelbar
• Für die LDAP-Abfrage wird standardmäßig der Kerberos-Login gegen die Attribute sAMAccountName, userPrincipalName, uid und DN geprüft.

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). Ab formcycle Version 8 kann der Filter-Wert über die Oberfläche gepflegt werden.

Um die Benutzersuche zum Beispiel nur auf das Attribut sAMAccountName und den Benutzernamen aus dem Kerberos-Login zu beschränken kann z.B. folgender Eintrag im Feld Nutzer-Filter eingetragen werden:

(sAMAccountName={2})

Sobald nun ein Benutzer mit dem entsprechenden Attribut gefunden wurde, sollten das XFC_METADATA-Objekt sowie der entsprechende Platzhalter mit Daten gefüllt sein.

Ein konkretes Beispiel:

Benutzer-Eingabe im Login-Prompt: test oder test@example.com inkl. Passwort 
Zurückgegebener Kerberos-Login: test/admin@EXAMPLE.COM 
Extrahierter Benutzername: test 
Resultierender LDAP-Filter: (sAMAccountName=test)

Fehlgeschlagener oder nicht automatischer Login aufgrund fehlender Browser-Einstellungen

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.

Google Chrome, Microsoft Internet Explorer und Microsoft Edge

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:

1. Öffnen Sie die Internetoptionen und wechseln Sie in den Tab „Sicherheit“
   
2. 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.
   
3. Fügen Sie nun die formcycle-URL zu den vertrauenswürdigen Intranet-Seiten hinzu.
   Öffnen Sie hierfür in der „Lokales Intranet“-Zone über die Schaltfläche „Sites“ folgenden Dialog:
   
4. Ü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“
   

Microsoft Edge

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.

Über "Richtlinien neu laden" können diese im Browser nachträgliche aktualisiert werden. Unter folgenden Link wird die Lösung genauer erläutert.

Firefox

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:

1. Öffnen Sie Firefox und rufen Sie die URL about:config auf
2. Bestätigen Sie ggf. erscheinende Sicherheitshinweise
3. Filtern Sie die Liste der Konfigurationen nach dem Begriff negotiate
4. 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.
   

Weitere bekannte Fehler und Probleme

Es erscheint kein Login-Prompt und der Benutzer ist nicht am Formular angemeldet

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

1. Erhöhung der zulässigen Größe von HTTP-Headern im Apache Tomcat Server
   1. Folgen Sie der Anleitung unter Beschränkung HTTP-Header Größe ändern
2. 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
   1. Öffnen Sie die Datei server.xml innerhalb des config-Ordners Ihrer Tomcat-Installation
   2. Ergänzen Sie am verwendeten AJP-Connector das Attribut packetSize="65536" (Standardwert: 8192 Byte)
   3. Passen Sie an den verwendeten Worker-Konfigurationen oder innerhalb der Apache-Proxy-Konfiguration die entsprechende Packet-Size ebenso auf 65536 an (siehe Proxy-Einstellungen bzw. unter Worker-Einstellungen > "max_packet_size")
   4. Fügen Sie innerhalb des Webservers in der entsprechenden Konfigurations-Datei des VirtualHosts die Direktive LimitRequestFieldSize mit dem Wert 65536 ein.
   5. 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
3. Anpassung der erlaubten Ticket-Verschlüsselungen
   1. 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.
   2. Ergänzen Sie im Bereich „Datei krb5.conf“ unter [libdefaults] die Punkte 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“. Eine beispielhafte Konfigurationsangabe finden Sie hier. Weitere Werte entnehmen Sie bitte unter.

Im Firefox erscheint ohne Login sofort eine Fehlermeldung

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.

Nach dem Abbrechen des Login-Dialogs erscheint eine leere Seite oder eine Browsermeldung

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.

Erfolglose Login-Versuche aufgrund von Zertifikatsproblemen

Kommt es bei erfolglosen Login-Versuchen im Anwendungs-Log zu folgender Fehlermeldung deutet dies auf ein Zertifikats-Problem hin:

[info] [ERROR] [Date+Time] [http-nio-8080-exec-5] (KerberosTicketValidatorImpl.java:48) - Error while validating kerberos login

[info] java.security.PrivilegedActionException: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)

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.

Vorgeschalteter Proxyserver leitet Kerberos-Ticket nicht weiter

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.

Server unterstützt nur ältere, unsichere Verschlüsselungscipher

Um eine Kerberos-Anmeldung mit veralteten und unsicheren Ciphern wie zum Beispiel RC4-HMAC mit aktuellen Java-Versionen zu ermöglichen, muss dem Java per Parameter explizit mitgeteilt werden, dass diese Cipher akzeptiert werden sollen. Hierzu muss in der krb5.conf unter [libdefaults] eine Zeile mit dem folgenden Eintrag eingefügt werden:

allow_weak_crypto = true

org.ietf.jgss.GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)

sun.security.krb5.KrbCryptoException: Checksum failed
    at java.security.jgss/sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Aes256CtsHmacSha1EType.java:102) ~[java.security.jgss:?]

java.security.GeneralSecurityException: Checksum failed
    at java.security.jgss/sun.security.krb5.internal.crypto.dk.AesDkCrypto.decryptCTS(AesDkCrypto.java:453) ~[java.security.jgss:?]

Debug-Modus aktivieren

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 protokolliert werden. Um das Debug-Log zu aktivieren gehen Sie wie folgt vor:

1. Öffnen Sie die Oberfläche zur Kerberos-Konfiguration in formcycle 
2. Fügen Sie im Bereich „Datei krb5.conf“ in den nicht funktionierenden Realms den Eintrag debug=true ein
   
3. Fügen Sie im Bereich „Datei login.conf“ unter dem Punkt „spnego-server“ den Eintrag debug=true ein