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
- Kerberos-Principal-Name kann nicht aufgelöst werden
- Systemzeit von WebSphere Application Server und Uhrzeit im AD-Domänencontroller (Active Directory) weichen mehr als 5 Minuten voneinander ab
- Keine Factory für die Erstellung von Namen für Mechanismus 1.3.6.1.5.5.2 verfügbar
- Beim Entschlüsseln und Prüfen des SPNEGO-Tokens wird ein Kerberos-Fehler ausgegeben
- Es findet kein Single Sign-on statt
- Single Sign-on (SSO) kann nicht für die RC4-HMAC-Verschlüsselung verwendet werden
- Probleme beim Zugriff auf einen geschützten URL mit SPNEGO-SSO (Single Sign-on)
- Trotz inaktiviertem JGSS-Trace erscheinen in SystemOut.log einige KRB_DBG_KDC-Nachrichten
- ktpass kann die Benutzer-ID nicht finden
- Delegierung der Berechtigungsnachweise funktioniert möglicherweise wegen einer ungültigen Option in der Ticketanforderung nicht
- Ein Benutzer wird zur Angabe von Berechtigungsnachweisen aufgefordert, obwohl der Browser ordnungsgemäß konfiguriert ist
- Ein Benutzer, der den Novell-Client verwendet, kann sich nicht mit SPNEGO authentifizieren
- Der Zugriff auf SPNEGO-Sites über einige Caching-Proxy-Server kann zu Problemen bei der SPNEGO-Authentifizierung führen
- VPN-Software (Virtual Private Network, virtuelles privates Netz) und Firewalls können sich störend auf SPNEGO-Operationen auswirken
- Potenzielles Browserproblem beim Zugriff auf eine mit SPNEGO geschützte Anwendung
- Mögliches Browserproblem mit Internet Explorer 6.0
- Für die Eigenschaften "NTLMTokenReceivedPage" und "SpnegoNotSupportedPage" definierte Fehlerseiten werden nicht über einen URL des Typs http:// geladen
- Ein Single Sign-on (SSO) des Client-Browsers kann nicht authentifiziert werden
- In Microsoft Windows Version 7 und Internet Explorer Version 8 ist der Verschlüsselungstyp DES standardmäßig inaktiviert
- Nicht eingeschränkte Richtlinie bei Verwendung der AES256-Verschlüsselung erstellen
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
[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
[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)
.
.
security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO
Beim Entschlüsseln und Prüfen des SPNEGO-Tokens wird ein Kerberos-Fehler ausgegeben
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
- 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.
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
Client sent back a non-SPNEGO authentication header, SpnegoTAI exits
- 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
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 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
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)
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
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.
> 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
< 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 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.
- Rufen Sie die Anzeige Zurücksetzung auf Authentifizierungsverfahren der Anwendung zulassen ab, falls sie ausgewählt ist. auf, und wählen Sie die Option
- 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
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.
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
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:
- 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:
- Klicken Sie auf .
- Klicken Sie auf den Account von Microsoft Active Directory, den Sie für die Zuordnung zum SPN verwenden.
- Wählen Sie den Account aus, und stellen Sie sicher, dass das Feld DES-Verschlüsselungstypen für dieses Konto verwenden abgewählt ist.
- 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.
- Generieren Sie den Chiffrierschlüssel mit dem Verschlüsselungstyp RC4 erneut.
- Kopieren Sie die neue Chiffrierschlüsseldatei in die Server von WebSphere Application Server.
- 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
- Stoppen Sie alle Server von WebSphere Application Server, und starten Sie sie anschließend erneut.
Uneingeschränkte Richtlinie bei Verwendung der AES256-Verschlüsselung erstellen
- Stoppen Sie den Anwendungsserver.
- 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.
- Klicken Sie auf die entsprechende SDK-Version.
- 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.
- Klicken Sie auf Sign in und geben Sie Ihre ID und Ihr Kennwort für IBM.com ein.
- Wählen Sie unrestricted JCE policy files for SDK aus, und klicken Sie auf Continue.
- Lesen Sie die Lizenzvereinbarung, und klicken Sie anschließend auf I Agree.
- 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.
- 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.
- 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. - Starten Sie den Anwendungsserver.