SPNEGO 故障诊断技巧

使用简单且受保护的 GSS-API 协商机制 (SPNEGO),可以对 WebSphere® Application Server 中受保护资源的 HTTP 请求进行安全的协商和认证。将简单且受保护的 GSS-API 协商机制 (SPNEGO) 用作 WebSphere Application Server 的 Web 认证服务时,可能会遇到一些问题。

SPNEGO 问题及其可能的解决方案

注: 本主题引用了一个或多个应用程序服务器日志文件。作为另一种建议采用的方法,您可以在分布式系统和 IBM® i 系统上配置服务器以使用高性能可扩展日志记录 (HPEL) 记录和跟踪基础结构,而不使用 SystemOut.logSystemErr.logtrace.logactivity.log 文件。您还可以将 HPEL 与本机 z/OS® 日志记录设施结合使用。如果要使用 HPEL,那么可从服务器概要文件 bin 目录使用 LogViewer 命令行工具来访问所有日志和跟踪信息。有关使用 HPEL 的更多信息,请参阅有关使用 HPEL 对应用程序进行故障诊断的信息。

无法解析 Kerberos 主体名称

如果无法解析 Kerberos 主体名称,如以下跟踪示例中所示:

[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. 

请在服务器的主机文件中添加该服务器的 IP 地址。要装入新的主机文件,还必须重新启动应用程序服务器。

WebSphere Application Server 和 Active Directory (AD) 域控制器上的时间未同步在 5 分钟内

此问题的 trace.log 文件类似于以下内容:
[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

可以用两种方法中的一种来解决此问题。首选方法是使 WebSphere 系统时间与 AD 服务器的时间同步在 5 分钟内。最佳做法是使用时间服务器使所有系统保持同步。或者也可以在 Kerberos 配置文件中添加或调整 clockskew 参数。请注意缺省值为 300 秒(5 分钟)。

没有工厂可用于为机制 1.3.6.1.5.5.2 创建名称

如果 systemout.log 文件包含类似于以下内容的异常错误:
[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) 
.
. 
请确保 java.security 文件包含 IBMSPNEGO 安全提供程序并且该文件已正确定义。它应包含类似于以下内容的行:
security.provider.6=com.ibm.security.jgss.mech.spnego.IBMSPNEGO

解码及验证 SPNEGO 令牌时接收到 Kerberos 错误

当 Java™ 类属安全性服务 (JGSS) 库尝试处理 SPNEGO 令牌时,可能接收到以下异常错误:
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
当使用一个密钥编码凭单,然后尝试使用另一个密钥对该凭单解码时,会导致此错误。此问题有多种可能的解释:
  • 重新生成密钥表文件之后,未将该文件复制到服务器。
  • Kerberos 配置指向错误的密钥表文件。
  • SPN 已多次定义到 Active Directory。这也会由于具有以类似方式定义的 SPN 的其他用户标识所导致(名称相同,或区别为具有定义为 SPN 一部分的端口)。
  • 如果加密类型为 DES,那么与服务用户标识相关的密码可能仅对于 RC4-HMAC 加密存在。当创建新用户标识,定义 SPN 并使用 +DesOnly 选项生成密钥表时,会发生此情况。为此 SPN 生成的服务凭单使用与密钥表中找到的密钥不匹配的密钥加密。
  • 使用的是较早版本的 Microsoft ktpass 工具。该工具的较早版本创建的密钥表文件不正确,可能会导致此错误。如果使用 Windows Server 2003 作为域控制器,请使用 Windows Server 2003 SP 2 中包含的 ktpass.exe 版本(具体为 V5.2.3790.2825)。

如果是密钥表文件存在问题,请修复该文件。如果是存在多个 SPN 定义的问题,请除去额外的或冲突的 SPN,并确认 SPN 不再向 AD 注册,然后再次添加该 SPN。有关更多信息,请参阅创建 Kerberos 服务主体名称和密钥表文件。可能需要使用 LDAP 浏览器在 Active Directory 中搜索定义的 SPN 与该 SPN 冲突的其他条目。

要确认 SPN 未注册,请输入以下命令:
setspn –l userid
应返回:
Cannot find account userid

如果用户标识和密钥表用于 DES-CBC-MD5,当您创建用户标识后,请更改该用户标识的密码,然后创建密钥表文件。如果使用 Windows Server 2003,请升级到最新版本的 ktpass。

无法进行单点登录

当开启跟踪时,可能显示以下错误消息:
Client sent back a non-SPNEGO authentication header, SpnegoTAI exits
此错误的一个可能原因是,客户机返回对授权提问的 NT LAN 管理器 (NTLM) 响应,而不是返回 SPNEGO 令牌。发生此情况可能是因为一个或多个以下问题:
  • 客户机未正确配置。
  • 客户机未在使用受支持的浏览器。例如,Internet Explorer 5.5 SP1 用户使用非 SPNEGO 认证头响应。
  • 用户未登录 AD 域或未登录可信域,或所使用的客户机不支持使用 Windows 的集成认证。在这种情况下,TAI 将正常工作。
  • 用户访问运行客户机的同一机器(本地主机)上定义的服务。Internet Explorer 将 URL 的主机名解析为 http://localhost<someURL> 而非所提供的标准名称。
  • 在 Active Directory 中找不到 SPN。SPN 的格式必须为 HTTP/server.realm.com。添加 SPN 的命令为:
    setspn –a HTTP/server.realm.com userid

    如果将 SPN 错误地定义为 HTTP/server.realm.com@REALM.COM(即,带有额外的 @REALM.COM),请删除用户,然后重新定义该用户和 SPN。

  • 主机名解析为 DNS 别名,而非 HOST 记录。将主机名更改为 HOST 记录。
  • AD 中保存 ServicePrincipalName 的帐户位于用户已登录的 AD 域的某个远程 AD 域中,而且这些域并非 Windows 2003 域。将这些域迁移到 Windows 2003,或将 SSO 限制用于与 ServicePrincipalName 用户标识位于同一域中的用户。

无法将单点登录 (SSO) 与 RC4-HMAC 加密结合使用

当开启跟踪时,可能接收到以下错误消息:
com.ibm.security.krb5.internal.crypto.KrbCryptoException, status code: 0
message: Checksum error; received checksum does not match computed checksum
此错误的某些可能原因包括以下内容:
  • 对于版本低于 2003 KDC 的 Windows,RC4-HMAC 加密不受支持。要确认这会导致出现问题,请检查抛出异常的先前跟踪。入局凭单的内容在跟踪中应是可视的。尽管入局凭单已加密,但该服务的 SPN 名称是可读的。如果使用 2003 之前的 Windows 版本的 KDC,并且系统已配置为使用 RC4-HMAC,那么将显示表示 userid@REALM(而非期望的 HTTP/hostname.realm@REALM)的凭单的字符串。例如,以下是从版本低于 2003 KDC 的 Windows 中接收到的凭单的开头部分:
    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....
    领域为 REALM.COM。服务名称为 userid。相同 SPN 的正确格式的凭单为:
    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..

    要纠正此问题,请使用单一 DES 加密,或对 KDC 使用 Windows Server 2003。请记住要重新生成的 SPN 和密钥表文件。

  • 使用凭证委派功能时,RC-HMAC 加密不工作。要确定是否具有此问题,请启用 JGSS 和 Krb5 跟踪。如果 SPN 名称正确,那么可能会显示类似以下内容的消息:
    [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

    这表示 SPNEGO 令牌中包含的委派凭证未使用正确的密钥加密。

    获取 APAR IY76826。它使用可接受 Microsoft 定义的 RC4 加密委派凭证的版本替换 ibmjgssprovider.jar

  • 使用 ktpass 生成密钥表文件时所使用的密码与指定给服务帐户的密码不匹配。当密码更改时,即使是重置为相同的密码,您也应重新生成并重新分发密钥。
    此外,ktpass 工具可能会使用不匹配的密码生成密钥表文件,如以下示例中所示:
    • 如果向 ktpass 输入的密码与服务帐户的密码匹配,那么生成的密钥表文件可以使用。
    • 如果向 ktpass 输入的密码与服务帐户的密码不匹配,并且长度少于 7 个字符,那么 ktpass 将停止并且不会生成密钥表文件。
    • 如果向 ktpass 输入的密码与服务帐户的密码不匹配,并且长度超过 6 个字符,那么 ktpass 不会停止。相反,它将生成包含无效密钥的密钥表文件。使用此密钥对 SPNEGO 令牌进行解密将导致出现上文列出的校验和错误。

    为服务帐户使用非空密码,然后在调用 ktpass 时使用该密码。

  • ktpass V1830(支持工具 SP1 中)在某些 Windows 2003 Server 环境中可能会生成错误。请使用该工具的 SP2 版本以避免错误。

    使用 ktpass 的支持工具 SP2 版本以生成密钥表文件。

凭证委派可能由于凭单请求中的无效选项而无法工作

当开启跟踪时,如果显示以下错误消息:
com.ibm.security.krb5.KrbException, status code: 101 message: Invalid option in ticket request

Kerberos 配置文件未正确配置。请确保没有将 renewable 和 proxiable 设置为 true

通过 SPNEGO 单点登录 (SSO) 访问受保护的 URL 时发生的问题

通过 SPNEGO SSO 访问受保护的 URL 时,可能会收到类似于以下内容的错误:
Bad Request

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

Authorization: Negotiate YII……

此消息由 Apache/IBM HTTP Server 生成,并表明浏览器返回的授权头过大。单词 Negotiate 后面的长字符串是 SPNEGO 令牌。此 SPNEGO 令牌是 Windows Kerberos 令牌的包装器。Windows 将用户的 PAC 信息包含在 Kerberos 令牌中。如果用户所属的安全组越多,那么 Kerberos 令牌中插入的 PAC 信息就越多,并且 SPNEGO 会变得越大。IBM HTTP Server 2.0(以及 Apache 2.0 和 IBM HTTP Server 6.0)将任何可接受的 HTTP 头的大小限制为 8K。在具有许多组并且用户在许多组中都具有成员资格的 Windows 域中,用户的 SPNEGO 令牌的大小可能会超过 8K 限制。

如果可能,请减少该用户所属的安全组数。IBM HTTP Server 2.0.47 累计修订 PK01070 允许 HTTP 头大小达到并超过 Microsoft 12K 的限制。

应用该修订后,必须指定 httpd.conf 文件中的 LimitRequestFieldSize 参数,以增大可允许头大小的缺省值 8192。

即使禁用了 JGSS 跟踪,SystemOut.log 中仍会出现一些 KRB_DBG_KDC 消息

虽然 JGSS 跟踪的大部分由 com.ibm.security.jgss.debug 属性控制,但仍有一小部分消息由 com.ibm.security.krb5.Krb5Debug 属性控制。krb5 属性的缺省值为将某些消息发送到 SystemOut.log。

要从 SystemOut.log 中除去所有 KRB_DBG_KDC 消息,请将 JVM 属性设置为 -Dcom.ibm.security.krb5.Krb5Debug=none。

ktpass 无法找到用户标识

使用 ktpass 时,可能会收到类似于以下内容的错误消息:
DsCrackNames returned 0x2 in the name entry for server3
Failed getting target domain for specified user.

在 Active Directory 森林中,ktpass.exe 使用的用户标识查询没有要使用的缺省域名。当域控制器不在森林中时,不会发生这种情况。

要解决此问题,请使用 -mapUser userid@domain,而非指定选项 -mapUser userid。例如,指定 –mapUser server3@WIBM.NET

凭证委派对于任何用户标识都不起作用

如果在 trace.log 中显示了类似以下内容的错误异常:
> 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

SPN 所连接的域帐户未定义“帐户已信任可进行委派”属性。

要解决此问题,请确保域帐户已定义“帐户已信任可进行委派”属性。

即使浏览器已正确配置,也会向用户要求凭证

即使浏览器已正确配置,可能也会向用户要求凭证。TAI 可能已从 SPNEGO 令牌获取了用户的凭证,并且用户可能登录失败。在 trace.log 中,显示了类似以下内容的异常错误:
< 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: An unexpected exception occurred when trying to create a LoginContext. The LoginModule alias is system.WEB_INBOUND 
and the exception is...
WebSphere 使用的注册表中不存在该用户标识(在上例中为 lansche)。在发生以下情况时可能导致此问题:
  • WebSphere 使用的注册表不是 Active Directory 域 LDAP 或 Global Catalogue,而是某些其他虚拟注册表,例如基于文件的定制用户注册表。
  • 定制 IClientToServerUseridMapper 实现修改了用户名,使得所映射到的名称在注册表中不存在。
  • 由 WebSphere LDAP 用户过滤器属性映射到的属性不正确。

要解决此问题,请确保由 TAI 插入到 WebSphere Application Server 中的用户是已配置的 WebSphere 注册表。

使用 Novell 客户机的用户无法使用 SPNEGO 认证

如果使用 Novell 客户机的用户无法使用 SPNEGO 进行认证,那么他们可能 会接收到“已接收到 NTLM 令牌。”消息。

用户可能已登录到 Novell 客户机,但未执行 Windows Kerberos 登录(这可以使用 Kerbtray 实用程序确认)。如果用户已登录 Windows 域并具有 Kerberos 凭单,那么该用户无法使用 SPNEGO 认证。

要解决此问题,请除去 Novell 客户机并使用缺省 Windows 域登录。

通过某些高速缓存代理服务器访问 SPNEGO 站点可能导致 SPNEGO 认证问题

如果通过某些高速缓存代理服务器访问 SPNEGO 站点,可能无法使用 SPNEGO 认证。可能会显示消息“此客户机不支持 SPNEGO 认证”。

可能高速缓存代理正在更改 HTTP 401 认证协商响应上返回的主机名。

如果具有此问题,请与代理供应商联系以获取可能的解决方案。

虚拟专用网 (VPN) 软件和防火墙可能干扰 SPNEGO 操作

您可能会遇到可能干扰 SPNEGO 操作的 VPN 软件和防火墙的相关问题。

要解决这些问题,请与 VPN 和/或防火墙供应商联系以获取可能必要的任何配置更改。

访问 SPNEGO 保护的应用程序时,可能发生浏览器问题

如果使用一个密码(例如,passwordA)登录域计算机,然后通过更改原始密码(例如,可能在第二台域计算机上将密码更改为 passwordB)来登录另一台域计算机,那么可能会发生浏览器问题。

当您返回到原始域计算机上时,可能无法获取对于协商提问的 SPNEGO/Kerberos 或 NTLM 响应。两次尝试后,浏览器将显示 HTTP 404 错误消息。

要解决此问题,请从原始域计算机上注销,并使用新密码 (passwordB) 重新登录。

Internet Explorer 6.0 可能发生浏览器问题

使用 SPNEGO 配置 WebSphere Application Server 并且对请求启用回退时,Internet Explorer 6.0 可能无法登录表单登录页面。

要避免出现此情况,请完成下列其中一项操作:
  • 全局安全性 > SPNEGO Web 认证面板中,如果已选中允许回退至应用程序认证机制选项,请将其取消。
  • 升级到 Internet Explorer V7.0
  • 将 Internet Explorer V6.0 配置为使用其他认证页面。此问题伴随基本认证,并针对表单登录首选项。

为 NTLMTokenReceivedPage 或 SpnegoNotSupportedPage 属性定义的错误页面从 http:// URL 装入

为 NTLMTokenReceivedPage 或 SpnegoNotSupportedPage 属性定义的错误页面从 http:// URL 装入。可能显示以下跟踪消息:
Could not load the SPNEGO not supported content, going with the default content. 
Exception received: java.net.ProtocolException: Server redirected too many  times (20)

当装入的文件执行自动重定向时,会发生此问题。不能既从 Web 服务器装入该文件又使用自动重定向

要解决此问题,请从 file:/// URL 而非 http:// URL 装入内容。

客户机浏览器单点登录 (SSO) 尝试无法进行认证

如果您将 SPNEGO 令牌与 Microsoft Internet Security Acceleration Server 配合使用,那么当客户机浏览器单点登录 (SSO) 尝试无法向 WebSphere Application Server 进行认证时,会发生错误

启用跟踪时,将显示以下消息:
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO 
ENTRY Negotiate                                                  
com.ibm.ws.security.spnego.SpnegoHandler isAuthHeaderNotSPNEGO 
Client sent back a non-SPNEGO authentication header

如果 Microsoft Internet Security Acceleration Server (ISA) 存在于客户机浏览器和 WebSphere Application Server 之间,那么 ISA 可能会拦截客户机浏览器请求中的 SPNEGO 认证头。ISA 会将 SPNEGO 对象标识 (OID) 转换为 Kerberos OID。向 WebSphere Application Server 的认证尝试将失败,因为 SPNEGO OID 已进行转换,因而现在缺少该标识。

有关如何解决此问题的信息,请参阅 Microsoft Corporation Support 站点中的“如果 ISA Server 2006 中发布的 Web 站点只接受 SPNEGO 认证包,那么用户无法访问该 Web 站点”主题。

缺省情况下 Microsoft Windows V7 和 Internet Explorer V8 禁用 DES 加密类型

如果您将 Microsoft Windows V7 与 Internet Explorer V8 配合使用,并且无法让 SPNEGO 单点登录 (SSO) 工作,那么可能的原因是缺省情况下 Windows V7 已对 Kerberos 禁用 DES 加密类型。启用跟踪时,将显示以下消息:
Client sent back a non-SPNEGO authentication header....

建议您将加密类型更改为 RC4-HMAC 或 AES。但是,如果您仍然选择使用 DES 加密类型,那么必须参阅 Windows 7 文档以获取有关如何启用 DES 加密类型的帮助内容。

以下是关于如何将加密类型从 DES 更改为 RC4 的示例:

  1. 请确保对于您用于映射到 SPN 的 Microsoft Active Directory 帐户,未选中对此帐户使用 DES 加密类型框。在 Microsoft Active Directory 机器上,完成以下步骤:
    1. 单击开始 > 程序 -> 管理工具 > Active Directory 用户和计算机 > 用户
    2. 单击您要用于映射到 SPN 的 Microsoft Active Directory 帐户。
    3. 选择该帐户,然后确保未选中对此帐户使用 DES 加密类型框。
  2. 重置您要用于映射到 SPN 的 Microsoft Active Directory 帐户的密码。可以将其重置为同一密码。
  3. 使用 RC4 加密类型重新生成密钥表。
  4. 将新密钥表文件复制到 WebSphere Application Server 服务器中。
  5. 更新 Kerberos 配置 (krb5.ini/krb5.conf) 文件,以便首先对 default_tkt_enctypes 和 default_tgs_enctypes 属性列示 RC4。
    例如:
    default_tkt_enctypes = rc4-hmac des-cbc-md5
    default_tgs_enctypes = rc4-hmac des-cbc-md5
    .
  6. 停止并重新启动所有 WebSphere Application Server 服务器。
注: 如果您有多个要用于映射到不同的 SPN 的 Microsoft Active Directory 帐户,那么必须对每个 SPN 重复步骤 1 到 3 并重复所有密钥表文件的合并。

建立非受限策略,然后使用 AES256 加密

您可以在建立非受限策略后使用 AES256 加密。完成以下步骤:
  1. 停止应用程序服务器。
  2. 下载并安装新的策略文件。
    要点: 您的产地国对加密软件的进口、拥有、使用或再次出口到其他国家可能有一些限制。 在下载或使用非受限策略文件前,您必须检查您所在国家关于加密软件的进口、拥有、使用和再出口的相关法律、法规和政策的规定,以确定合规性。
    1. 单击相应的 SDK 级别。
    2. 向下滚动页面,然后单击 IBM SDK 策略文件。将显示 SDK Web 站点的非受限 JCE 策略文件。
    3. 单击登录并提供您的 IBM.com 标识和密码。
    4. 选择 SDK 的非受限 JCE 策略文件,然后单击继续
    5. 查看许可证并单击 I Agree 以继续。
    6. 解压缩 ZIP 文件中打包的无限制管辖区域策略文件。该 ZIP 文件包含 US_export_policy.jar 文件和 local_policy.jar 文件。
    7. 在 WebSphere Application Server 安装中,切换到 $JAVA_HOME/lib/security 目录并备份现有的 US_export_policy.jarlocal_policy.jar 文件。
    8. US_export_policy.jarlocal_policy.jar 文件替换为您从 IBM.com Web 站点下载的两个文件。
    注: 替换这些文件前,请进行备份。要使用的路径的示例为 WAS_Install/java/jre/lib/security
  3. 启动应用程序服务器。

指示主题类型的图标 参考主题



时间戳记图标 最近一次更新时间: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_SPNEGO_troubles
文件名:rsec_SPNEGO_troubles.html