Tipps zur Fehlerbehebung für den SPNEGO TAI (veraltet)
Dieser Artikel enthält eine Liste mit Tipps zur Fehlerbehebung, die Sie bei der Diagnose von Problemen und Ausnahmen des SPNEGO TAI unterstützen sollen.

In WebSphere Application Server Version 6.1 wurde ein TAI eingeführt, der SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) nutzt, um HTTP-Anforderungen für geschützte Ressourcen sicher auszuhandeln und zu authentifizieren. Diese Funktion wird in WebSphere Application Server 7.0 nicht weiter unterstützt. Die SPNEGO-Webauthentifizierung wird jetzt genutzt, um SPNEGO-Filter dynamisch neu zu laden und den Rückgriff auf die Methode der Anwendungsanmeldung zu ermöglichen.
depfeatTrace | Verwendung |
---|---|
com.ibm.security.jgss.debug | Setzen Sie diese angepasste JVM-Eigenschaft auf all, um einen Trace für den gesamten JGSS-Code durchzuführen. Die Nachrichten erscheinen in den Dateien trace.log und SystemOut.log. |
com.ibm.security.krb5.Krb5Debug | Setzen Sie diese angepasste JVM-Eigenschaft auf all, um einen Trace für den gesamten Kerberos-5-spezifischen JGSS durchzuführen. Die Nachrichten erscheinen in den Dateien trace.log und SystemOut.log. |
com.ibm.ws.security.spnego.* | Setzen Sie diesen Trace, indem Sie trace.log. | auswählen. Nachrichten erscheinen in der Datei
Problem: Die Systemzeit von WebSphere Application Server und die Zeit des AD-Domänencontrollers (Active Directory) werden nicht innerhalb von 5 Minuten synchronisiert.
Symptom | Benutzeraktion |
---|---|
|
Die bevorzugte Methode, diesen Fehler zu beheben, ist eine bis auf 5 Minuten genaue Synchronisierung der Systemzeit von WebSphere
Application Server mit der Zeit des AD-Servers.
Am besten verwenden Sie für die Synchronisation aller Systeme einen Zeitserver. Sie können aber auch den Parameter clockskew
in der Kerberos-Konfiguration anpassen bzw. einen solchen Parameter zur Datei hinzufügen. Anmerkung: Der Standardwert für den Parameter clockskew
liegt bei 300 Sekunden (oder 5 Minuten).
|
Problem: Es wird die Ausnahme "No factory available to create a name for mechanism 1.3.6.1.5.5.2" empfangen.
Problem | Symptom | Benutzeraktion |
---|---|---|
Es wird die Ausnahme "No factory available to create a name for mechanism 1.3.6.1.5.5.2" empfangen. Es ist keine Factory verfügbar, die die Erstellung eines Namens für den spezifischen Mechanismus verarbeiten konnte. |
|
Überprüfen Sie die Datei java.security, um sicherzustellen,
dass sie den IBMSPNEGO-Sicherheitsprovider enthält, und dass dieser Provider ordnungsgemäß definiert ist. Die Datei java.security
sollte eine Zeile ähnlich der folgenden enthalten:
|
Problem: Es wird eine Ausnahme empfangen, während die JGSS-Bibliothek versucht, das SPNEGO-Token zu verarbeiten.
Symptom | Beschreibung | Benutzeraktion |
---|---|---|
Der folgende Fehler wird angezeigt, während die JGSS-Bibliothek versucht, das SPNEGO-Token zu verarbeiten.
|
Diese Ausnahme tritt ein, weil für die Codierung und Decodierung des Tickets verschiedene Schlüssel verwendet wurden. Dies kann verschiedene Ursachen haben:
|
Falls das Problem durch die Kerberos-Chriffrierschlüsseldatei verursacht wird, generieren Sie die Datei neu. Sollte das Problem auf mehrere SPN-Definitionen zurückzuführen sein, entfernen Sie den zusätzlichen SPN bzw. den SPN, der zu dem Konflikt führt. Stellen Sie sicher, dass der SPN nicht mehr in Active Directory
registriert ist, bevor Sie ihn hinzufügen. Möglicherweise müssen Sie Active Directory nach weiteren Einträgen mit SPNs durchsuchen, deren Definition mit diesem
SPN in Kollision gerät. Geben Sie den folgenden Befehl ein, um sicherzustellen, dass der SPN nicht registriert ist:
Dieser Befehl müsste Folgendes
zurückgebe:
|
Problem: Single Sign-On kann nicht ausgeführt werden.
Symptom | Beschreibung | Benutzeraktion |
---|---|---|
Wenn die Tracefunktion aktiviert ist, erscheint die folgende Nachricht:
|
Der Client gibt für die autorisierte
Anforderung ein NTLM-Token (NT LAN Manager) zurück und kein SPNEGO-Token. Diese Situation kann einen der folgenden Gründe haben:
|
Wenn der SPN fälschlicherweise als HTTP/server.realm.com@REALM.COM definiert (also mit dem Zusatz @REALM.COM versehen) wurde, müssen Sie den Benutzer löschen und neu definieren und im Anschluss den SPN erneut definieren. Falls das Problem durch die Kerberos-Chriffrierschlüsseldatei verursacht wird, generieren Sie die Datei neu. Sollte
das Problem auf mehrere SPN-Definitionen zurückzuführen sein, entfernen Sie den zusätzlichen SPN bzw. den SPN,
der zu dem Konflikt führt. Stellen Sie sicher, dass der SPN nicht mehr in Active Directory
registriert ist, bevor Sie ihn hinzufügen. Sie können Active Directory nach weiteren SPN-Einträgen durchsuchen, die mehrere SPN-Definitionen
erzeugen. Die folgenden Befehle sind für die Bestimmung mehrerer SPN-Definitionen nützlich:
|
Problem: Die Delegierung von Berechtigungsnachweisen funktioniert nicht.
Symptom | Beschreibung | Benutzeraktion |
---|---|---|
Es wurde eine ungültige Option gefunden. Wenn die Tracefunktion aktiviert ist, wird die folgende Nachricht angezeigt:
|
Die Kerberos-Konfigurationsdatei ist nicht ordnungsgemäß definiert. | Stellen Sie sicher, dass "renewable" (erneuerbar) oder "proxiable" (Proxy-fähig) auf "true" gesetzt ist. |
Problem: SSO funktioniert nicht mit der Verschlüsselung RC4-HMAC.
Symptom | Beschreibung | Benutzeraktion |
---|---|---|
Überprüfen Sie die folgende Nachricht im Trace, die Sie erhalten, wenn die Tracefunktion aktiviert ist:
|
Die RC4-HMAC-Verschlüsselung wird für das 2003 Kerberos Key Distribution Center (KDC)
in Microsoft Windows-Versionen vor
2003 nicht unterstützt.
Ob diese Situation vorliegt, können Sie feststellen, indem Sie
den Trace untersuchen und herausfinden, wo die Ausnahme ausgelöst wird.
Der Inhalt des eingehenden Tickets müsste im Trace sichtbar sein. Das eingehende Ticket ist zwar verschlüsselt, aber der SPN für den Service
ist lesbar. Wenn ein KDC einer Microsoft Windows-Version
vor 2003 verwendet wird und das System für die Verwendung von RC4-HMAC konfiguriert ist,
wird die Zeichenfolge, die das Ticket für
userid@REALM darstellt, anstelle
der erwarteten Angabe HTTP/hostname.realm@REALM angezeigt.
Im Folgenden sehen Sie ein Beispiel für den Anfang des Tickets, das von einem KDC einer
Microsoft Windows-Version vor
2003 empfangen wird:
Der Realm ist REALM.COM. Der Servicename lautet userid. Ein korrekt geformtes Ticket für denselben
SPN würde wie folgt aussehen:
|
Um das Problem zu beheben, müssen Sie entweder die Single-DES-Verschlüsselung oder Microsoft Windows Server 2003 als KDC verwenden. Vergessen Sie nicht, den SPN und die Kerberos-Chiffrierschlüsseldatei neu zu generieren. |
Problem: Der Benutzer empfängt folgende Nachricht, wenn er mit SPNEGO SSO auf einen geschützten URL zugreift.
Symptom | Beschreibung | Benutzeraktion |
---|---|---|
Überprüfen Sie die folgende Nachricht:
|
Diese Nachricht wird von Apache/IBM HTTP Server generiert. Dieser Server gibt an, dass der vom Browser des Benutzers zurückgegebene Berechtigungsheader zu lang ist. Die lange Zeichenfolge, die sich (in der obigen Fehlernachricht) an das Wort "Negotiate" anschließt, ist das SPNEGO-Token. Dieses SPNEGO-Token ist ein Wrapper für das Microsoft Windows-Kerberos-Token. Microsoft Windows nimmt die PAC-Informationen des Benutzers in das Kerberos-Token auf. Je mehr Sicherheitsgruppen der Benutzer angehört, desto mehr PAC-Informationen werden in das Kerberos-Token aufgenommen. Das SPNEGO-Token wird dadurch entsprechend verlängert. In IBM HTTP Server 2.0 (sowie in Apache HTTP Server 2.0 und IBM HTTP Server 6.0) ist die Größe eines akzeptablen HTTP-Headers auf 8 KB beschränkt. In Microsoft Windows-Domänen mit vielen Gruppen und Benutzern, die zu mehreren Gruppen gehören, kann die Größe des Benutzer-SPNEGO-Tokens die Grenze von 8 KB überschreiten. | Verringern Sie nach Möglichkeit die Anzahl der Sicherheitsgruppen, zu denen der Benutzer gehört. Das Fixpack
PK01070 für IBM HTTP Server 2.0.47 ermöglicht HTTP-Header mit einer Größe bis zur
Microsoft-Begrenzung von 12 K und darüber hinaus. Benutzer von WebSphere Application Server
Version 6.0 erhalten diese Korrektur mit dem Fixpack 6.0.0.2. Anmerkung: Web-Server, die nicht Apache-basiert sind, erfordern möglicherweise eine andere
Lösung.
|
Problem: Trotz inaktiviertem JGSS-Trace erscheinen in SystemOut.log einige KRB_DBG_KDC-Nachrichten.
Symptom | Beschreibung | Benutzeraktion |
---|---|---|
Überprüfen Sie die Datei SystemOut.log und beachten Sie, dass einige KRB_DBG_KDC-Nachrichten hier auch bei inaktiviertem JGSS-Trace angezeigt werden. | Der JGSS-Trace wird überwiegend von der Eigenschaft "com.ibm.security.jgss.debug" gesteuert, ein kleiner Teil der Nachrichten jedoch von der Eigenschaft "com.ibm.security.krb5.Krb5Debug". Die Eigenschaft "com.ibm.security.krb5.Krb5Debug" gibt standardmäßig einige Nachrichten in die Protokolldatei SystemOut.log aus. | Wenn Sie alle KRB_DBG_KDC-Nachrichten aus der Datei SystemOut.log
entfernen möchten, setzen Sie
die JVM-Eigenschaft wie folgt:
|
Problem: Wenn eine Anwendung eine angepasste Fehlerseite für einen HTTP-401-Fehler enthält, wird die von SPNEGO-TAI generierte HTTP-Antwortseite nicht in einem Browser angezeigt.
Symptom | Beschreibung | Benutzeraktion |
---|---|---|
Wenn eine Anwendung eine angepasste Fehlerseite für einen HTTP-401-Fehler enthält, wird die von SPNEGO-TAI generierte HTTP-Antwortseite nicht in einem Browser angezeigt. | Wenn eine Anwendung eine angepasste Fehlerseite für einen HTTP-401-Fehler enthält, wird die von SPNEGO-TAI generierte HTTP-Anwortseite nicht in einem Browser angezeigt. Stattdessen wird die angepasste HTTP-401-Fehlerseite angezeigt. | Sie können Ihre HTTP-401-Seite so anpassen, dass sie Informationen darüber enthält, wie Sie Ihren Browser konfigurieren müssen, damit er SPNEGO verwendet. Weitere Informationen hierzu finden Sie in den Artikeln Client-Browser für die Verwendung von SPNEGO konfigurieren (nicht mehr unterstützt) und Angepasste JVM-Konfigurationseigenschaften für SPNEGO TAI (veraltet). |
Problem: Während der Interaktion mit SPNEGO TAI gehen beim Rückgriff auf die Anmeldung mit Benutzer-ID und Kennwort HTTP-Portparameter verloren.
Symptom | Beschreibung | Benutzeraktion |
---|---|---|
Während der Interaktion mit SPNEGO TAI gehen beim Rückgriff auf die Anmeldung mit Benutzer-ID und Kennwort HTTP-Portparameter verloren. "Rückgriff auf die Anmeldung mit Benutzer-ID und Kennwort" bedeutet, dass Microsoft Internet Explorer zunächst versucht, mit einem SPNEGO-Token zu antworten. Führt dies nicht zum Erfolg, versucht er mit einem NTLM-Token zu antworten, das über eine Benutzer-ID-/Kennwortanforderung abgerufen wird. |
Microsoft Internet Explorer speichert während einer Benutzeranforderung den Status.
Wenn auf eine Anforderung hin "HTTP 401 Authenticate Negotiate" erscheint und der Browser mit einem NTLM-Token antwortet,
das er während der Benutzer-ID-/Kennwortanforderung empfangen hat,
übergibt der Browser die Anforderung erneut. Wird diese zweite Anforderung mit einer HTML-Seite beantwortet, die
mit neuen Argumenten (via JavaScript) eine Umleitung zu demselben URL enthält, übergibt der Browser die POST-Parameter nicht erneut. Anmerkung: Dieses Problem kann letztlich nur vermieden werden, wenn KEINE
automatische Umleitung erfolgt. Wenn der Benutzer auf einen Link klickt, tritt das Problem nicht auf.
|
Der Browser antwortet auf die Authentifizierungs-/Verhandlungsanforderung mit einem NTLM-Token und nicht mit einem SPNEGO-Token. Der SPNEGO TAI sieht das NTLM-Token und gibt zusammen mit der HTML-Seite die HTTP-Antwort 403 zurück. Wenn der Browser die JavaScript-Funktion redirTimer ausführt, gehen alle in der ursprünglichen Anforderung enthaltenen POST- oder GET-Parameter verloren. Durch
Verwendung der Eigenschaft "SPN<id>.NTLMTokenReceivedPage" kann eine Seite mit entsprechenden Nachrichten an den Benutzer
zurückgegeben werden. Standardmäßig wird (bei fehlender benutzerdefinierter Eigenschaft)
folgende Nachricht zurückgegeben:
Mit der Eigenschaft "SPN<id>.NTLMTokenReceivedPage" können Sie den genauen Inhalt der Antwort anpassen. Es ist von entscheidender Bedeutung, dass die zurückgegebene HTML keine automatische Umleitung ausführt. Wenn der SPNEGO TAI für die Verwendung der Klasse "HTTPHeaderFilter" als "SPN<id>.filterClass" konfiguriert ist (Standardeinstellung bei Auslieferung des Produkts), kann mit SPN<id>.filter erreicht werden, dass die zweite Anforderung direkt zum normalen Sicherheitsmechanismus von WebSphere Application Server transportiert wird. Auf diese Weise durchläuft der Benutzer das normale Authentifizierungsverfahren. Es folgt
ein Beispiel für eine solche Konfiguration, das die erforderlichen SPNEGO-TAI-Eigenschaften und den Inhalt der
HTML-Datei zeigt.
Anmerkung: Wie Sie sehen können,
weist die Eigenschaft "filter" den SPNEGO TAI an, keine
HTTP-Anforderungen abzufangen, die die Zeichenfolge "noSPNEGO" enthalten.
Im folgenden Beispiel wird
das Generieren einer hilfreichen Antwort
gezeigt.
|
Problem: Der Trust Association Interceptor (TAI) ruft die Methode "initialize(Properties)" nicht auf.
Die Traceerstellung kann zeigen, dass der TAI geladen ist, aber dass die Methode "initialize(Properties)" nicht aufgerufen wird. Während des Starts scheint nur die Methode "getVersion()" aufgerufen zu werden.
Die TAI-Verarbeitung von WebSphere ruft die Methode "initialize(Properties)" nur auf, wenn angepasste Eigenschaften für den TAI definiert sind.
Zur Behebung des Problems definieren Sie eine nicht verwendete angepasste TAI-Eigenschaft, wie z. B. "com.ibm.issw.spnegoTAI.NumberOfServers=0".
Problem: Der Trust-Association-Interceptor (TAI) wird nicht ordnungsgemäß geladen.
SPNEGO014: Kerberos initialization Failure: org.ietf.jgss.GSSException, major code: 13, minor code: 0
major string: Invalid credentials
minor string: SubjectKeyFinder: no JAAS Subject
at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:12)
…
Eine mögliche Ursache für dieses Problem ist, dass für die angepasste JVM-Eigenschaft "javax.security.auth.useSubjectCredsOnly" nicht der Wert false gesetzt ist.
Definieren Sie zur Behebung des Problems eine angepasste JVM-Eigenschaft in jeder für den TAI aktivierten JVM: javax.security.auth.useSubjectCredsOnly=false.
Problem: Standardzeichen in JACL-Scripts für das Hinzufügen von TAI-Parametern können Probleme verursachen.
JACL-Scripts für das Hinzufügen von TAI-Parametern akzeptieren positionsgebundene Parameter. Zum Akzeptieren der Standardwerte wird "." angegeben. Auf einigen WebSphere-Plattformen kann die Angabe von "." dazu führen, dass die Eigenschaft mit dem Wert "." hinzugefügt wird.
Vergewissern Sie sich (unabhängig von der Plattform) stets, dass die Eigenschaften wie erwartet über die Administrationskonsole hinzugefügt wurden. Wenn dies nicht der Fall ist, korrigieren Sie sie manuell.