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.

Veraltetes Feature Veraltetes Feature:

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.

depfeat
Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.
Der IBM JGSS-Provider (Java Generic Security Service) und der IBM SPNEGO-Provider (Simple and Protected GSS-API Negotiation) steuern die Traceinformationen mit einer angepassten JVM-Eigenschaft. Der SPNEGO TAI ermöglicht einem Administrator mit der JRas-Einrichtung, einen Trace auf bestimmte Klassen zu beschränken. Die folgenden wichtigen Tracespezifikationen oder angepassten JVM-Eigenschaften sollten für ein TAI-Debug mit der Tracefunktion verwendet werden.
Tabelle 1. Tracespezifikationen für SPNEGO TAI.

In dieser Tabelle werden die Tracespezifikationen für SPNEGO TAI beschrieben.

Trace 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 Administrationskonsole > Fehlerbehebung > Protokollierung und Tracing > server1 > Detailstufe für Protokoll ändern > com.ibm.ws.security.spnego.* auswählen. Nachrichten erscheinen in der Datei trace.log.

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
[2/24/06 13:12:46:093 CST] 00000060 Context       2 com.ibm.ws.security.spnego.Context begin GSSContext accepted
[2/24/06 13:12:46:093 CST] 00000060 Context       E com.ibm.ws.security.spnego.Context begin
CWSPN0011E: An invalid SPNEGO token has been encountered while authenticating a HttpServletRequest:
0000:  60820160 06062b06 01050502 a1820154    `..` ..+. .... ...T
0010:  30820150 a0030a01 01a10b06 092a8648    0..P .... .... .*.H
0020:  82f71201 0202a282 013a0482 01366082    .... .... .:.. .6`.
0030:  01320609 2a864886 f7120102 0203007e    .2.. *.H. .... ...~
0040:  82012130 82011da0 03020105 a1030201    ..!0 .... .... ....
0050:  1ea41118 0f323030 36303232 34313931    .... .200 6022 4191
0060:  3234365a a5050203 016b48a6 03020125    246Z .... .kH. ...%
0070:  a9161b14 57535345 432e4155 5354494e    .... WSSE C.AU STIN
0080:  2e49424d 2e434f4d aa2d302b a0030201    .IBM .COM .-0+ ....
0090:  00a12430 221b0448 5454501b 1a773230    ..$0 "..H TTP. .w20
00a0:  30337365 63646576 2e617573 74696e2e    03se cdev .aus tin.
00b0:  69626d2e 636f6dab 81aa1b81 a76f7267    ibm. com. .... .org
00c0:  2e696574 662e6a67 73732e47 53534578    .iet f.jg ss.G SSEx
00d0:  63657074 696f6e2c 206d616a 6f722063    cept ion,  maj or c
00e0:  6f64653a 2031302c 206d696e 6f722063    ode:  10,  min or c
00f0:  6f64653a 2033370a 096d616a 6f722073    ode:  37. .maj or s
0100:  7472696e 673a2044 65666563 74697665    trin g: D efec tive
0110:  20746f6b 656e0a09 6d696e6f 72207374     tok en.. mino r st
0120:  72696e67 3a20436c 69656e74 2074696d    ring : Cl ient  tim
0130:  65204672 69646179 2c204665 62727561    e Fr iday , Fe brua
0140:  72792032 342c2032 30303620 61742031    ry 2 4, 2 006  at 1
0150:  3a31323a 34352050 4d20746f 6f20736b    :12: 45 P M to o sk
0160:  65776564                               ewed 
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.
[4/8/05 22:51:24:542 EDT] 5003e481 SystemOut     O [JGSS_DBG_PROV] Provider IBMJGSSProvider version 1.01 does not support mech 1.3.6.1.5.5.2
[4/8/05 22:51:24:582 EDT] 5003e481 ServerCredent > 
        com.ibm.ws.security.spnego
			 .ServerCredential initialize ENTRY
SPNEGO014: Kerberos initialization Failure: org.ietf.jgss.GSSException, major code: 2, 
        minor code: 0 
		major string: Unsupported mechanism
		minor string: No factory available to create name for mechanism 1.3.6.1.5.5.2
		at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:30)
		at com.ibm.security.jgss.GSSManagerImpl.a(GSSManagerImpl.java:36)
		at com.ibm.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:217)
	at com.ibm.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl
 .java:264)
Ü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:
security.provider.6=com.ibm.security
 .jgss.mech.spnego.IBMSPNEGO

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.
Error authenticating request. Reporting to client
Major code = 11, Minor code = 31
org.ietf.jgss.GSSException, major code: 11, minor code: 31
		major string: General failure, unspecified at GSSAPI level
		minor string: Kerberos error while decoding and verifying token: com.ibm.security.krb5.internal.KrbException, status code: 31
		message: Integrity check on decrypted field failed
Diese Ausnahme tritt ein, weil für die Codierung und Decodierung des Tickets verschiedene Schlüssel verwendet wurden. Dies kann verschiedene Ursachen haben:
  1. Die Kerberos-Chiffrierschlüsseldatei wurde nach der erneuten Generierung nicht auf die Servermaschine kopiert.
  2. Die Kerberos-Konfiguration zeigt auf die falsche Kerberos-Chiffrierschlüsseldatei.
  3. Der Kerberos-SPN (Service Principal Name) wurde mehr als einmal für Active Directory definiert. Sie haben eine andere Benutzer-ID für denselben SPN definiert oder denselben SPN zusätzlich mit einem Port definiert. Das folgende Beispiel veranschaulicht, wie dieser Fall eintreten konnte:
    Identischer SPN und unterschiedliche Benutzer-IDs
    setspn -a HTTP/myHost.austin.ibm.com user1
    		setspn -a HTTP/myHost.austin.ibm.com user2
    Identischer SPN und gleiche Benutzer-IDs, eine ohne Portnummer, eine mit Portnummer
    setspn -a HTTP/myHost.austin.ibm.com user
    		setspn -a HTTP/myHost.austin.ibm.com:9080 user
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:
setspn –l userid
Dieser Befehl müsste Folgendes zurückgebe:
Cannot find account userid

Problem: Single Sign-On kann nicht ausgeführt werden.

Symptom Beschreibung Benutzeraktion
Wenn die Tracefunktion aktiviert ist, erscheint die folgende Nachricht:
[2/27/06 14:28:04:191 CST] 00000059 
SpnegoHandler < 
		com.ibm.ws.security.spnego
				.SpnegoHandler handleRequest: 
				Received a non-SPNEGO 
				Authorization Header RETURN
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:
  • Der Client wurde nicht ordnungsgemäß konfiguriert.
  • Der Client verwendet keinen unterstützten Browser. Wenn beispielsweise Microsoft Internet Explorer 5.5 verwendet wird, antwortet SP1 mit einem Authentifizierungsheader, der kein SPNEGO-Authentifizierungsheader ist.
  • Der Benutzer hat sich nicht bei der Active Directory-Domäne oder einer anerkannten Domäne angemeldet, oder der verwendete Client unterstützt keine integrierte Authentifizierung unter Windows –. Im letztgenannten Fall funktioniert der SPNEGO TAI fehlerfrei.
  • Der Benutzer greift auf einen Service zu, der auf der Maschine definiert ist, auf dem der Client ausgeführt wird (lokaler Host). Microsoft Internet Explorer löst den Hostnamen des URL in http://localhostsomeURL auf und nicht in einen vollständig qualifizierten Namen.
  • Der SPN konnte nicht in Active Directory gefunden werden. Er muss das Format HTTP/server.realm.com haben. Der SPN muss mit folgendem Befehl hinzugefügt werden:
    setspn –a HTTP/server.realm.com userid
  • Der Kerberos-SPN (Service Principal Name) wurde mehr als einmal für Active Directory definiert. Sie haben eine andere Benutzer-ID für denselben SPN definiert oder denselben SPN zusätzlich mit einem Port definiert. Die folgenden Kategorien beschreiben diese Bedingungen:
    Identischer SPN und unterschiedliche Benutzer-IDs
    • setspn -a HTTP/myappserver.austin.ibm.com user1
    • setspn -a HTTP/myappserver.austin.ibm.com user2
    Identischer SPN und gleiche Benutzer-IDs, davon eine mit definierter Portnummer
    • setspn -a HTTP/myappserver.austin.ibm.com user3
    • setspn -a HTTP/myappserver.austin.ibm.com:9080 user3

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:
setspn ?L userid
Gibt die Nachrichtcannot find account userid zurück, wenn der SPN nicht registriert ist.
setspn -L
Zeigt die vorhandenen SPNs an.

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:
com.ibm.security.krb5.KrbException,
 status code: 101 message:
 Invalid option in ticket request
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:
com.ibm.security.krb5.internal.crypto.
 KrbCryptoException, status code: 0
		message: Checksum error; received checksum does not match computed checksum
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:
0000: 01 00 6e 82 04 7f 30 82  04 7b a0 03 02 01 05 a1  ..n...0.........
0010: 03 02 01 0e a2 07 03 05  00 20 00 00 00 a3 82 03  ................
0020: a5 61 82 03 a1 30 82 03  9d a0 03 02 01 05 a1 0a  .a...0..........
0030: 1b 08 45 50 46 44 2e 4e  45 54 a2 18 30 16 a0 03  ...REALM.COM.0..
0040: 02 01 01 a1 0f 30 0d 1b  0b 65 70 66 64 77 61 73  .....0...userid
0050: 75 6e 69 74 a3 82 03 6e  30 82 03 6a a0 03 02 01  .a.f...n0..j....
Der Realm ist REALM.COM. Der Servicename lautet userid. Ein korrekt geformtes Ticket für denselben SPN würde wie folgt aussehen:
0000: 01 00 6e 82 04 56 30 82  04 52 a0 03 02 01 05 a1  ..n..V0..R......
0010: 03 02 01 0e a2 07 03 05  00 20 00 00 00 a3 82 03  ................
0020: 82 61 82 03 7e 30 82 03  7a a0 03 02 01 05 a1 0a  .a...0..z.......
0030: 1b 08 45 50 46 44 2e 4e  45 54 a2 2a 30 28 a0 03  ..REALM.COM.0...
0040: 02 01 02 a1 21 30 1f 1b  04 48 54 54 50 1b 17 75  .....0...HTTP..u
0050: 73 31 30 6b 65 70 66 77  61 73 73 30 31 2e 65 70  serid.realm.com.
0060: 66 64 2e 6e 65 74 a3 82  03 39 30 82 03 35 a0 03  ...n.....90..5..
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:
Bad Request

Your browser sent a request that this server could not understand.
Size of request header field exceeds server limit.

Authorization: Negotiate YII……
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:
-Dcom.ibm.security.krb5.Krb5Debug=none

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:
"<html><head><title>An NTLM
Token was Received.
</title></head>"
	+ "<body>Your browser configuration is 
		correct, but you have not logged into
		a supported Windows Domain."
	+ "<p>Melden Sie sich über die normale Anmeldeseite an der Anmeldung an.</html>";

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.
****** SPNEGO TAI Property Name ******
                ****** HTML File Content ******
com.ibm.ws.security.spnego.SPN1.hostName               server.wasteched30.torolab.ibm.com
com.ibm.ws.security.spnego.SPN1.filterClass            com.ibm.ws.security.spnego.HTTPHeaderFilter
com.ibm.ws.security.spnego.SPN1.filter                 request-url!=noSPNEGO
com.ibm.ws.security.spnego.SPN1.NTLMTokenReceivedPage  File:///C:/temp/NTLM.html 
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.
<html>
<head>
<title>NTLM Authentication Received </title>
<script language="javascript">
		var purl=""+document.location;
if (purl.indexOf("noSPNEGO")<0) {
				if(purl.indexOf('?')>=0) purl+="&noSPNEGO";
				else purl+="?noSPNEGO";
	}
</script>
</head>
<body>
<p>An NTLM token was retrieved in response to
 the SPNEGO challenge. It is likely that
you are not logged into a Windows domain.<br>
Click on the following link to get the
requested website.
<script language="javascript">
	document.write("<a href='"+purl+"'>");
	document.write("Open the same page using
	 the normal authentication mechanism.");
	document.write("</a><br>");
</script>
You will not automatically be redirected.
</body>
</html>

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.

Die Traceerstellung kann zeigen, dass TAI nicht geladen wird und der folgende Ausnahmetext empfangen wird:
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.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_SPNEGO_trouble_shoot
Dateiname:rsec_SPNEGO_trouble_shoot.html