Tipps zur Fehlerbehebung bei SPNEGO

Sie können HTTP-Anforderungen für gesicherte Ressourcen in WebSphere Application Server mit Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) sicher vereinbaren und authentifizieren. In diesem Artikel werden Probleme beschrieben, die bei der Verwendung von Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) als Webauthentifizierungsservice für WebSphere Application Server auftreten können.

SPNEGO-Probleme und mögliche Lösungen

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.
In diesem Artikel werden Probleme beschrieben, die bei der Verwendung von SPNEGO als Webauthentifizierungsservice für WebSphere Application Server auftreten können, und es werden mögliche Lösungen werden vorgestellt.

Kerberos-Principal-Name kann nicht aufgelöst werden

Es ist möglich, dass der Kerberos-Principal-Name, wie im folgenden Tracebeispiel gezeigt, nicht aufgelöst werden kann:

[11/11/03 1:42:29:795 EST] 1d01b21e GetKrbToken   > Negotiation (GSS): Begin handshake
[11/11/03 1:42:29:795 EST] 1d01b21e Context       > GSS Context init, servername:HTTP@johnwang5.jwcmd.com
[11/11/03 1:42:29:866 EST] 1d01b21e TraceNLS      u No message text associated with key Error.getting.the.Token,
.GSS.Exception:org.ietf.jgss.GSSException,.major.code:.13,.minor.code:.0
		major.string:.Invalid.credentials
		minor.string:.Cannot.get.credential.from.JAAS.Subject.for.principal:.HTTP/192.168.0.4@168.0.4 in bundle 
com.ibm.ejs.resources.security
[11/11/03 1:42:29:866 EST] 1d01b21e GetKrbToken   E Error getting the Token, GSS Exception:org.ietf.jgss.GSSException, 
major code: 13, minor code: 0
		major string: Invalid credentials
		minor string: Cannot get credential from JAAS Subject for principal: HTTP/192.168.0.4@168.0.4
[11/11/03 1:42:29:876 EST] 1d01b21e TraceNLS      u No message text associated with key SpnegoTAI.exits.due.to.an.exception. 
in bundle com.ibm.ejs.resources.security
[11/11/03 1:42:29:876 EST] 1d01b21e SpnegoTAI     E SpnegoTAI exits due to an exception. 

In diesem Fall fügen Sie die IP-Adresse des Servers der zugehörigen Hostdatei hinzu. Außerdem müssen Sie den Anwendungsserver stoppen und anschließend erneut starten, damit die neue Hostdatei geladen wird.

Systemzeit von WebSphere Application Server und Uhrzeit im AD-Domänencontroller (Active Directory) weichen mehr als 5 Minuten voneinander ab

Die Datei trace.log enthält Informationen ähnlich den folgenden zu diesem Problem:
[11/11/03 1:44:09:499 EST] 1d01b21e GetKrbToken   > Negotiation (GSS): Begin handshake
[11/11/03 1:44:09:499 EST] 1d01b21e Context       > GSS Context init, servername:HTTP@backendrc4.ibm.net
[11/11/03 1:44:09:499 EST] 1d01b21e Context       > GSS Context init, done.
[11/11/03 1:44:09:679 EST] 1d01b21e SpnegoTAI     > Server response token as follows...
0000:  6082014f 06062b06 01050502 a1820143     `?.O..+.....¡?.C
0010:  3082013f a0030a01 01a10b06 092a8648     0?.? ....¡...*?H
0020:  82f71201 0202a282 01290482 01256082     ?÷....¢?.).?.%`?
0030:  01210609 2a864886 f7120102 0203007e     .!..*?H?÷......~
0040:  82011030 82010ca0 03020105 a1030201     ?..0?.. ....¡...
0050:  1ea41118 0f323030 33313131 31303634     .¤...20031111064
0060:  3430395a a5050203 0a3548a6 03020125     409Z¥....5H¦...%
0070:  a90b1b09 4a57434d 442e434f 4daa2630     ©.....IBM.NETª&0
0080:  24a00302 0100a11d 301b1b04 48545450     $ ....¡.0...HTTP
0090:  1b136a6f 686e7761 6e67352e 6a77636d     ..backendrc4.ibm
00a0:  642e636f 6dab81ab 1b81a86f 72672e69     .net.«?«.?¨org.i
00b0:  6574662e 6a677373 2e475353 45786365     etf.jgss.GSSExce
00c0:  7074696f 6e2c206d 616a6f72 20636f64     ption, major cod
00d0:  653a2031 302c206d 696e6f72 20636f64     e: 10, minor cod
00e0:  653a2033 370a096d 616a6f72 20737472     e: 37..major str
00f0:  696e673a 20446566 65637469 76652074     ing: Defective t
0100:  6f6b656e 0a096d69 6e6f7220 73747269     oken..minor stri
0110:  6e673a20 436c6965 6e742074 696d6520     ng: Client time 
0120:  54756573 6461792c 204e6f76 656d6265     Tuesday, Novembe
0130:  72203131 2c203230 30332061 7420313a     r 11, 2003 at 1:
0140:  33353a30 3120414d 20746f6f 20736b65     35:01 AM too ske
0150:  776564                                  wed

Sie können dieses Problem auf zwei Arten lösen. Die bevorzugte Methode ist die Synchronisation der WebSphere-Systemzeit auf eine Zeit, die maximal 5 Minuten von der Zeit des AD-Servers abweicht. Eine empfohlene Methode ist die Verwendung eines Zeitservers, um alle Systeme zu synchronisieren. Alternativ können Sie den Parameter "clockskew" in der Kerberos-Konfigurationsdatei hinzufügen bzw. anpassen. Die Standardeinstellung für diesen Parameter ist 300 Sekunden (5 Minuten).

Keine Factory für die Erstellung von Namen für Mechanismus 1.3.6.1.5.5.2 verfügbar

Die Datei systemout.log enthält einen Ausnahmefehler ähnlich dem folgenden:
[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 E com.ibm.issw.spnegoTAI.ServerCredential initialize() 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) 
.
. 
Stellen Sie sicher, dass die Datei java.security den Sicherheitsprovider IBMSPNEGO enthält und dass dieser ordnungsgemäß definiert ist. Die Datei sollte eine Zeile wie die folgende enthalten:
security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO

Beim Entschlüsseln und Prüfen des SPNEGO-Tokens wird ein Kerberos-Fehler ausgegeben

Sie können den folgenden Ausnahmefehler empfangen, wenn die JGSS-Bibliothek (Java™ Generic Security Service) 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
Dieser Fehler tritt auf, wenn das Ticket mit einem Schlüssel verschlüsselt wird und anschließend versucht wird, das Ticket mit einem anderen Schlüssel zu entschlüsseln. Es gibt mehrere mögliche Erklärungen für einen solchen Fall:
  • Die Chiffrierschlüsseldatei wurde nach der erneuten Generierung nicht auf die Servermaschine kopiert.
  • Die Kerberos-Konfiguration zeigt auf die falsche Chiffrierschlüsseldatei.
  • Der SPN wurde mehrfach in Active Directory definiert. Dies kann auch auf eine andere Benutzer-ID mit einem ähnlich definierten SPN zurückzuführen sein (derselbe Name oder ein anderer Name mit einem definierten Port im SPN).
  • Wenn DES als Verschlüsselungstyp verwendet wurde, ist es möglich, dass das Kennwort, das der Benutzer-ID für den Service zugeordnet ist, nur für die RC4-HMAC-Verschlüsselung vorhanden ist. Dieser Fall kann eintreten, wenn eine neue Benutzer-ID erstellt, der SPN definiert und der Chiffrierschlüssel mit der Option +DesOnly generiert wird. Das für diesen SPN generierte Serviceticket wird mit einem geheimen Schlüssel verschlüsselt, der nicht mit dem Schlüssel übereinstimmt, der im Chiffrierschlüssel vorhanden ist.
  • Es wird eine ältere Version des Microsoft-Tools "ktpass" verwendet. Ältere Versionen des Tools erstellen ungültige Chiffrierschlüsseldateien, die zu diesem Fehler führen können. Wenn Sie Windows Server 2003 als Domänencontroller verwenden, verwenden Sie die Version von ktpass.exe, die zu Windows Server 2003 SP 2 gehört (d. h. Version 5.2.3790.2825).

Wenn das Problem auf die Chiffrierschlüsseldatei zurückzuführen ist, beheben Sie es. Ist das Problem auf mehrere SPN-Definitionen zurückzuführen, entfernen Sie die zusätzlichen bzw. widersprüchlichen SPNs, vergewissern Sie sich, dass die SPNn nicht mehr bei AD registriert sind, und fügen Sie anschließend den gültigen SPN erneut hinzu. Weitere Informationen hierzu enthält der Artikel Kerberos-Service-Principal-Namen und eine Chiffrierschlüsseldatei erstellen. Möglicherweise müssen Sie Active Directory mit einem LDAP-Browser 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ückgeben:
Cannot find account userid

Wenn die Benutzer-ID und der Chiffrierschlüssel für DES-CBC-MD5 bestimmt sind, ändern Sie nach der Erstellung der Benutzer-ID das Kennwort für die Benutzer-ID, und erstellen Sie dann die Chiffrierschlüsseldatei. Wenn Sie Windows Server 2003 verwenden, führen Sie ein Upgrade auf die aktuelle Version von ktpass durch.

Es findet kein Single Sign-on statt

Wenn die Traceerstellung aktiviert ist, kann die folgende Fehlernachricht angezeigt werden:
Client sent back a non-SPNEGO authentication header, SpnegoTAI exits
Eine mögliche Ursache für diesen Fehler ist, dass der Client für die Autorisierungsanforderung ein NTLM-Token (NT LAN Manager) und kein SPNEGO-Token zurückgibt. Dies kann auf eines oder mehrere der folgende Probleme zurückzuführen sein:
  • Der Client wurde nicht ordnungsgemäß konfiguriert.
  • Der Client verwendet keinen unterstützten Browser. Benutzer von Internet Explorer 5.5 SP1 antworten beispielsweise mit einem Header, der kein SPNEGO-Authentifizierungsheader ist.
  • Der Benutzer hat sich nicht an der AD-Domäne oder an einer anerkannten Domäne angemeldet, oder der verwendete Client unterstützt keine integrierte Authentifizierung mit Windows. In diesem Fall arbeitet der TAI ordnungsgemäß.
  • Der Benutzer greift auf einen Service zu, der auf derselben Maschine definiert ist, auf der auch der Client ausgeführt wird (localhost). Internet Explorer löst den Hostnamen der URL in "http://localhost<beliebiger_URL>" auf und nicht in den vollständig qualifizierten Namen, der bereitgestellt wird.
  • Der SPN konnte nicht in Active Directory gefunden werden. Der SPN muss das Format "HTTP/server.realm.com" haben. Der Befehl zum Hinzufügen des SPN lautet wie folgt:
    setspn –a HTTP/server.realm.com userid

    Wenn der SPN nicht ordnungsgemäß mit "HTTP/server.realm.com@REALM.COM" und dem Zusatz "@REALM.COM" definiert wurde, löschen Sie den Benutzer, definieren Sie ihn erneut, und definieren Sie anschließend den SPN erneut.

  • Der Hostname wird in einen DNS-Alias und nicht in einen HOST-Datensatz aufgelöst. Ändern Sie den Hostnamen in einen HOST-Datensatz.
  • Der Account in AD, der den ServicePrincipalName enthält, befindet sich in einer AD-Domäne, die eine ferne AD-Domäne der AD-Domäne ist, an der sich der Benutzer angemeldet hat, und diese Domänen sind keine Domänen von Windows 2003. Migrieren Sie die Domänen auf Windows 2003, oder beschränken Sie SSO auf Benutzer, die sich in derselben Domäne wie die ServicePrincipalName-Benutzer-ID befinden.

Single Sign-on (SSO) kann nicht für die RC4-HMAC-Verschlüsselung verwendet werden

Wenn die Traceerstellung aktiviert ist, kann die folgende Fehlernachricht angezeigt werden:
com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0
	message: Checksum error; received checksum does not match computed checksum
Einige der möglichen Ursachen für diesen Fehler sind im Folgenden beschrieben:
  • Die RC4-HMAC-Verschlüsselung wird für das KDC in Windows-Versionen vor 2003 nicht unterstützt. Ob diese Situation vorliegt, können Sie feststellen, indem Sie den Trace an der Stelle untersuchen, an der die Ausnahme ausgelöst wird. Der Inhalt des eingehenden Tickets müsste im Trace sichtbar sein. Der Inhalt ist zwar verschlüsselt, aber der SPN-Name für den Service ist lesbar. Wenn ein KDC einer 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@REALMinstead" darstellt, anstelle der erwarteten Angabe "HTTP/hostname.realm@REALM" gezeigt. Im Folgenden sehen Sie ein Beispiel für den Anfang des Tickets, das von einem KDC einer 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 Windows Server 2003 als KDC verwenden. Denken Sie daran, dass Sie den SPN und die Chiffrierschlüsseldatei neu generieren müssen.

  • Die RC-HMAC-Verschlüsselung funktioniert nicht, wenn das Feature für Berechtigungsdelegierung verwendet wird. Aktivieren Sie die JGSS- und Krb5-Traceerstellung, um festzustellen, ob dieses Problem vorliegt. Wenn der SPN-Name korrekt ist, können Nachrichten wie die folgenden angezeigt werden:
    [JGSS_DBG_CTX] Successfully decrypted ticket
    [JGSS_DBG_CTX] Put authz info in cache
    [JGSS_DBG_CTX] Session key type = rc4-hmac
    …
    [JGSS_DBG_CTX] Successfully decrypted authenticator
    [JGSS_DBG_CTX] Error authenticating request. Reporting to client
    …
    Major code = 11, Minor code = 0
    org.ietf.jgss.GSSException, major code: 11, minor code: 0
    		major string: General failure, unspecified at GSSAPI level
    		minor string: Kerberos error converting KRBCred: com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0
    		message: Checksum error; received checksum does not match computed checksum

    Diese Nachrichten zeigen an, dass der im SPNEGO-Token enthaltene delegierte Berechtigungsnachweis nicht mit dem richtigen Schlüssel verschlüsselt wurde.

    Fordern Sie APAR IY76826 an. Dieser APAR ersetzt die Datei ibmjgssprovider.jar durch eine Version, die den von Microsoft definierten RC4-verschlüsselten delegierten Berechtigungsnachweis akzeptieren kann.

  • Das Kennwort, das für die Generierung der Chiffrierschlüsseldatei mit ktpass verwendet wurde, stimmt nicht mit dem Kennwort überein, das dem Service-Account zugeordnet ist. Wenn sich das Kennwort ändert, müssen Sie die Schlüssel neu generieren und neu verteilen, selbst wenn eine Rücksetzung auf dasselbe Kennwort vorgenommen wurde.
    Außerdem kann das Tool "ktpass" eine Chiffrierschlüsseldatei mit einem nicht übereinstimmenden Kennwort generieren, wie es in den folgenden Situationen der Fall ist:
    • Wenn das in ktpass eingegebene Kennwort mit dem Kennwort für den Service-Account übereinstimmt, funktioniert die erzeugte Chiffrierschlüsseldatei nicht.
    • Wenn das in ktpass eingegebene Kennwort nicht mit dem Kennwort für den Service-Account übereinstimmt und kürzer als 7 Zeichen ist, wird ktpass gestoppt und keine Chiffrierschlüsseldatei erzeugt.
    • Wenn das in ktpass eingegebene Kennwort nicht mit dem Kennwort für den Service-Account übereinstimmt und länger als sechs Zeichen ist, wird ktpass nicht gestoppt. Stattdessen wird eine Chiffrierschlüsseldatei erzeugt, die einen ungültigen Schlüssel enthält. Wird dieser Schlüssel zum Entschlüsseln eines SPNEGO-Tokens verwendet, wird der zuvor aufgelistete Kontrollsummenfehler erzeugt.

    Verwenden Sie ein Kennwort, das kein Nullwert ist, für den Service-Account, und verwenden Sie dieses Kennwort anschließend, wenn Sie ktpass aufrufen.

  • Die ktpass-Version 1830 (in Support Tools SP1) kann den Fehler in einigen Umgebungen von Windows 2003 Server erzeugen. Verwenden Sie SP2-Version des Tools, um den Fehler zu vermeiden.

    Verwenden Sie die ktpass-Version von Support Tools SP2, um die Chiffrierschlüsseldatei zu generieren.

Delegierung der Berechtigungsnachweise funktioniert möglicherweise wegen einer ungültigen Option in der Ticketanforderung nicht

Wenn die Traceerstellung aktiviert ist und die Fehlernachricht
com.ibm.security.krb5.KrbException, status code: 101 message: Invalid option in ticket request

ausgegeben wird, ist die Kerberos-Konfigurationsdatei möglicherweise nicht ordnungsgemäß konfiguriert. Stellen Sie sicher, dass weder "renewable" noch "proxiable" auf true gesetzt ist.

Probleme beim Zugriff auf einen geschützten URL mit SPNEGO-SSO (Single Sign-on)

Sie können eine Fehlernachricht wie die folgende empfangen, wenn Sie über SPNEGO-SSO auf einen geschützten URL zugreifen:
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 und weist darauf hin, dass der vom Browser zurückgegebene Berechtigungsheader zu groß ist. Die lange Zeichenfolge, die dem Wort " Negotiate" folgt ist das SPNEGO-Token. Dieses SPNEGO-Token ist ein Wrapper für das Windows-Kerberos-Token. Windows schließt die PAC-Informationen des Benutzers in das Kerberos-Token ein. 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. IBM HTTP Server 2.0 (wie auch Apache 2.0 und IBM HTTP Server 6.0) beschränken die Größe gültiger HTTP-Header auf 8 KB. In 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. Die kumulative Programmkorrektur PK01070 für IBM HTTP Server 2.0.47 ermöglicht HTTP-Header mit einer Größe der Microsoft-Begrenzung von 12 K und darüber hinaus.

Nach dem Anwenden des Fix müssen Sie den Parameter "LimitRequestFieldSize" in der Datei httpd.conf angeben, um die Größe zulässiger Header vom Standardwert auf 8192 zu erhöhen.

Trotz inaktiviertem JGSS-Trace erscheinen in SystemOut.log einige KRB_DBG_KDC-Nachrichten

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". Der Standardwert der krb5-Eigenschaft sieht vor, dass einige Nachrichten in SystemOut.log ausgegeben werden.

Wenn alle KRB_DBG_KDC-Nachrichten aus SystemOut.log entfernt werden sollen, setzen Sie die JVM-Eigenschaft auf "-Dcom.ibm.security.krb5.Krb5Debug=none".

ktpass kann die Benutzer-ID nicht finden

Wenn Sie ktpass verwenden, kann eine Fehlernachricht wie die folgende angezeigt werden:
DsCrackNames hat 0x2 im Namenseintrag für server3 zurückgegeben.
Fehler beim Abrufen einer Zieldomäne für den angegebenen Benutzer.

In einer Active Directory-Gesamtstruktur hat die von ktpass.exe verwendete Suchfunktion für Benutzer-IDs keinen Standardomänennamen. Dieser Fehler tritt nicht auf, wenn der Domänencontroller nicht in einer Gesamtstruktur enthalten ist.

Zur Behebung des Problems verwenden Sie an Stelle der Option -mapUser Benutzer-ID die Option -mapUser Benutzer-ID@Domäne. Geben Sie beispielsweise –mapUser server3@WIBM.NET an.

Die Delegierung von Berechtigungsnachweisen funktioniert nicht jede Benutzer-ID.

Wenn in der Datei "trace.log" eine Fehlerausnahme wie
> com.ibm.issw.spnegoTAI.Context getDelegateCred() Entry
d com.ibm.issw.spnegoTAI.Context getDelegateCred() unable to get Delegate Credential
< com.ibm.issw.spnegoTAI.Context getDelegateCred() Exit
W com.ibm.issw.spnegoTAI.SpnegoHandler handleRequest() SPNEGO021: No delegated credentials were found for user: nauser@NA.IBM.NET

aufgezeichnet wird, ist für den Domänenaccount, dem der SPN zugeordnet ist, nicht die Eigenschaft "Konto wird für Delegierung anerkannt" definiert.

Zur Behebung dieses Problems stellen Sie sicher, dass für den Domänenaccount die Eigenschaft "Account wird für Delegierung anerkannt" definiert ist.

Ein Benutzer wird zur Angabe von Berechtigungsnachweisen aufgefordert, obwohl der Browser ordnungsgemäß konfiguriert ist

Ein Benutzer kann zur Angabe von Berechtigungsnachweisen aufgefordert, obwohl der Browser ordnungsgemäß konfiguriert ist. Dies kann darauf zurückzuführen sein, dass der TAI die Berechtigungsnachweise des Benutzers aus dem SPNEGO-Token abgerufen, der Benutzer sich aber nicht angemeldet hat. In der Datei "trace.log" wird ein Ausnahmefehler ähnlich dem folgenden aufgezeichnet:
< com.ibm.issw.spnegoTAI.SpnegoTAI getAuthenticatedUsername(): lansche Exit
d com.ibm.issw.spnegoTAI.SpnegoTAI negotiateValidateandEstablishTrust(): Handshake finished, sending 200 :SC_OK
< com.ibm.issw.spnegoTAI.SpnegoTAI negotiateAndValidateEstablishedTrust Exit
A SECJ0222E: Es ist eine unerwartete Ausnahme eingetreten, als versucht wurde, einen LoginContext zu erstellen.
Der Aliasname des LoginModule ist system.WEB_INBOUND.
Ausnahme: ...
Die Benutzer-ID (in diesem Beispiel "lansche") ist nicht in der Registry vorhanden, die von WebSphere verwendet wird. Dieses Problem kann auf folgende Ursachen zurückzuführen sein:
  • Die von WebSphere verwendete Registry ist nicht das Active Directory-Domänen-LDAP oder Global Catalogue, sondern eine andere virtuelle Registry (z. B. eine dateibasierte angepasste Benutzerregistry).
  • Eine angepasste IClientToServerUseridMapper-Implementierung ändert den Benutzernamen, sodass der Name, dem die Implementierung zugeordnet wird, nicht in der Registry vorhanden ist.
  • Das über die WebSphere-Eigenschaft für den LDAP-Benutzerfilter zugeordnete Attribut ist nicht gültig.

Zur Behebung dieses Problems stellen Sie sicher, dass der Benutzer, den der TAI WebSphere Application Server zusichert, in der konfigurierten WebSphere-Registry enthalten ist.

Ein Benutzer, der den Novell-Client verwendet, kann sich nicht mit SPNEGO authentifizieren

Wenn ein Benutzer, der den Novell-Client verwendet, sich nicht mit SPNEGO authentifizieren kann, wird möglicherweise die Nachricht "An NTLM token is received." ausgegeben.

Der Benutzer hat sich möglicherweise am Novell-Client angemeldet, aber keine Windows-Kerberos-Anmeldung (über das Kerberos-Dienstprogramm) durchgeführt. Wenn sich ein Benutzer an der Windows-Domäne angemeldet und ein Kerberos-Ticket hat, kann der Benutzer die SPNEGO-Authentifizierung nicht verwenden.

Zur Behebung dieses Problems entfernen Sie den Novell-Client, und verwenden Sie dann die Windows-Standardomänenanmeldung.

Der Zugriff auf SPNEGO-Sites über einige Caching-Proxy-Server kann zu Problemen bei der SPNEGO-Authentifizierung führen

Beim Zugriff auf SPNEGO-Sites über einige Caching-Proxy-Server ist eine Authentifizierung über SPNEGO nicht möglich. Die Nachricht "SPNEGO-Authentifizierung wird auf diesem Client nicht unterstützt" kann angezeigt werden.

Es ist möglich, dass der Caching-Proxy den Hostnamen ändert, der in der Antwort "HTTP 401 Authenticate Negotiate" zurückgegeben wird.

In diesem Fall müssen Sie sich für eine mögliche Lösung an Ihren Proxy-Anbieter wenden.

VPN-Software (Virtual Private Network, virtuelles privates Netz) und Firewalls können sich störend auf SPNEGO-Operationen auswirken

Es können Probleme mit VPN-Software und Firewalls auftreten, die sich störend auf SPNEGO-Operationen auswirken.

Zur Behebung dieser Probleme wenden Sie sich an die Anbieter Ihrer VPN-Software und Firewalls, um möglicherweise erforderliche Konfigurationsänderungen vorzunehmen.

Potenzielles Browserproblem beim Zugriff auf eine mit SPNEGO geschützte Anwendung

Es kann ein Problem im Browser auftreten, wenn Sie sich an einer Domänenmaschine mit einem Kennwort (z. B. KennwortA) anmelden und sich anschließend an einer zweiten Domänenmaschine anmelden und Ihr ursprüngliches Kennwort ändern (z. B. in KennwortB).

Wenn Sie zur ursprünglichen Domänenmaschine zurückkehren, sind Sie möglicherweise nicht in der Lage, eine SPNEGO/Kerberos- oder NTLM-Antwort auf die Negotiate-Abfrage abzurufen. Nach zwei Versuchen zeigt der Browser eine HTTP-Fehlernachricht 404 an.

Zur Behebung dieses Problems melden Sie sich an der ursprünglichen Domänenmaschine ab und anschließend erneut mit dem neuen Kennwort KennwortB) an.

Mögliches Browserproblem mit Internet Explorer 6.0

Wenn WebSphere Application Server mit SPNEGO konfiguriert ist und Fallback (Rückübertragung) für eine Anforderung aktiviert ist, kann die Anmeldung bei den formularbasierten Anmeldeseiten in Internet Explorer 6.0 fehlschlagen.

Zur Vermeidung dieser Situation führen Sie eine der folgenden Aktionen aus:
  • Rufen Sie die Anzeige Globale Sicherheit > SPNEGO-Webauthentifizierung auf, und wählen Sie die Option Zurücksetzung auf Authentifizierungsverfahren der Anwendung zulassen ab, falls sie ausgewählt ist.
  • Führen Sie ein Upgrade auf Internet Explorer Version 7.0 durch.
  • Konfigurieren Sie Internet Explorer Version 6.0 für die Verwendung einer anderen Authentifizierungsseite. Das Problem betrifft die Basisauthentifizierung gegenüber der Vorgabe der formularbasierten Authentifizierung.

Für die Eigenschaften "NTLMTokenReceivedPage" und "SpnegoNotSupportedPage" definierte Fehlerseiten werden nicht über einen URL des Typs http:// geladen

Die Fehlerseiten, die für die Eigenschaft "NTLMTokenReceivedPage" oder "SpnegoNotSupportedPage" definiert sind, werden nicht über einen URL des Typs "http://" geladen. Die folgende Tracenachricht kann angezeigt werden:
Could not load the SPNEGO not supported content, going with the default content. 
Exception received: java.net.ProtocolException: Server redirected too many  times (20)

Dieses Problem tritt auf, wenn die geladene Datei eine automatische Umleitung durchführt. Es ist nicht möglich, die Datei von einem Web-Server zu laden und gleichzeitig eine automatische Umleitung zu verwenden.

Zur Behebung des Problems laden Sie den Inhalt über einen URL des Typs "file:///" und nicht über einen URL des Typs "http://".

Ein Single Sign-on (SSO) des Client-Browsers kann nicht authentifiziert werden

Wenn ein Single Sign-on (SSO) des Client-Browsers nicht bei WebSphere Application Server authentifiziert werden kann, während ein SPNEGO-Token mit Microsoft Internet Security Acceleration Server verwendet wird, kann ein Fehler auftreten.

Wenn die Tracefunktion aktiviert ist, wird folgende Nachricht zurückgegeben:
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO 
ENTRY Negotiate                                                  
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO 
Client sent back a non-SPNEGO authentication header

Wenn zwischen einem Client-Browser und WebSphere Application Server ein Microsoft Internet Security Acceleration Server (ISA) verwendet wird, kann der ISA den SPNEGO-Authentifizierungsheader aus der Client-Browser-Anfrage abfangen. ISA wandelt die SPNEGO-Objekt-ID (OID) in eine Kerberos-OID um. Die Authentifizierung mit WebSphere Application Server scheitert, weil die SPNEGO-OID umgewandelt wurde und jetzt nicht mehr vorhanden ist.

Informationen zur Behebung dieses Problems finden Sie im Artikel "Users cannot access a web site that is published in ISA Server 2006 if the web site accepts only the SPNEGO authentication package" auf der Unterstützungssite der Microsoft Corporation.

In Microsoft Windows Version 7 und Internet Explorer Version 8 ist der Verschlüsselungstyp DES standardmäßig inaktiviert

Wenn Sie Microsoft Windows Version 7 mit Internet Explorer Version 8 verwenden und SPNEGO Single Sign On (SSO) nicht funktioniert, kann dies darauf zurückzuführen sein, dass der Verschlüsselungstyp DES für Kerberos in Windows Version 7 standardmäßig inaktiviert ist. Wenn Sie den Trace aktivieren, erscheint die folgende Nachricht:
Client sent back a non-SPNEGO authentication header....

Es wird empfohlen, den Verschlüsselungstyp in RC4-HMAC oder AES zu ändern. Wenn Sie sich jedoch dafür entscheiden, den Verschlüsselungstyp DES weiterhin zu verwenden, müssen Sie in der Dokumentation zu Windows 7 nachlesen, wie der Verschlüsselungtyp DES aktiviert wird.

Im Folgenden wird anhand eines Beispiels veranschaulicht, wie Sie den Verschlüsselungstyp von DES in RC4 ändern:

  1. Stellen Sie sicher, dass in dem Account von Microsoft Active Directory, den Sie für die Zuordnung des SPN verwenden, das Feld DES-Verschlüsselungstypen für dieses Konto verwenden abgewählt ist. Führen Sie auf der Maschine mit Microsoft Active Directory die folgenden Aktionen aus:
    1. Klicken Sie auf Start > Programme -> Verwaltung > Active Directory-Benutzer und -Computer > Benutzer.
    2. Klicken Sie auf den Account von Microsoft Active Directory, den Sie für die Zuordnung zum SPN verwenden.
    3. Wählen Sie den Account aus, und stellen Sie sicher, dass das Feld DES-Verschlüsselungstypen für dieses Konto verwenden abgewählt ist.
  2. Setzen Sie das Kennwort für den Account von Microsoft Active Directory zurück, den Sie für die Zuordnung zum SPN verwenden möchten. Sie können das Kennwort auf dasselbe Kennwort zurücksetzen.
  3. Generieren Sie den Chiffrierschlüssel mit dem Verschlüsselungstyp RC4 erneut.
  4. Kopieren Sie die neue Chiffrierschlüsseldatei in die Server von WebSphere Application Server.
  5. Aktualisieren Sie die Kerberos-Konfigurationsdateien (krb5.ini/krb5.conf), und listen Sie RC4 für die Attribute "default_tkt_enctypes" und "default_tgs_enctypes" als ersten Typ auf.
    Beispiel:
    	default_tkt_enctypes = rc4-hmac des-cbc-md5
    default_tgs_enctypes = rc4-hmac des-cbc-md5
    .
  6. Stoppen Sie alle Server von WebSphere Application Server, und starten Sie sie anschließend erneut.
Anmerkung: Wenn Sie mehrere Accounts von Microsoft Active Directory haben, die Sie für die Zuordnung zu verschiedenen SPNs verwenden möchten, müssen Sie die Schritte 1 bis 3 für jeden SPN und die Zusammenführung aller Chiffrierschlüsseldateien wiederholen.

Uneingeschränkte Richtlinie bei Verwendung der AES256-Verschlüsselung erstellen

Wenn Sie eine nicht eingeschränkte Richtlinie erstellt haben, können Sie die AES256-Verschlüsselung verwenden. Gehen Sie wie folgt vor:
  1. Stoppen Sie den Anwendungsserver.
  2. Laden Sie die neuen Richtliniendateien herunter, und installieren Sie sie.
    Wichtig: In Ihrem Herkunftsland gibt es möglicherweise Beschränkungen für den Import, den Besitz oder den Reexport von Verschlüsselungssoftware in ein anderes Land. Bevor Sie die Dateien der nicht eingeschränkten Richtlinie herunterladen oder verwenden, müssen Sie die Gesetze und Richtlinien Ihres Landes in Bezug auf den Import, den Besitz und den Reexport von Verschlüsselungssoftware prüfen, um festzustellen, ob dies zulässig ist.
    1. Klicken Sie auf die entsprechende SDK-Version.
    2. Blättern Sie nach unten, und klicken Sie auf IBM SDK policy files. Die Website mit den Dateien der nicht eingeschränkten JCE-Richtlinie für SDK erscheint.
    3. Klicken Sie auf Sign in und geben Sie Ihre ID und Ihr Kennwort für IBM.com ein.
    4. Wählen Sie unrestricted JCE policy files for SDK aus, und klicken Sie auf Continue.
    5. Lesen Sie die Lizenzvereinbarung, und klicken Sie anschließend auf I Agree.
    6. Extrahieren Sie die Dateien mit den uneingeschränkten Verschlüsselungsklassen aus der ZIP-Datei. Die ZIP-Datei enthält eine Datei US_export_policy.jar und eine Datei local_policy.jar.
    7. Wechseln Sie im Installationsverzeichnis von WebSphere Application Server in das Verzeichnis $JAVA_HOME/lib/security, und sichern Sie die vorhandenen Dateien US_export_policy.jar und local_policy.jar.
    8. Ersetzen Sie die Dateien US_export_policy.jar und local_policy.jar durch die beiden Dateien, die Sie von der Website IBM.com heruntergeladen haben.
    Anmerkung: Führen Sie eine Sicherung durch, bevor Sie diese Dateien ersetzen. Es könnte beispielsweise der Pfad WAS_Install/java/jre/lib/security verwendet werden.
  3. Starten Sie den Anwendungsserver.

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_troubles
Dateiname:rsec_SPNEGO_troubles.html