SPNEGO 信任关联拦截器 (TAI) 故障诊断技巧(不推荐)

下面提供了故障诊断技巧的列表,这些技巧有助于对“简单且受保护的 GSS-API 协商” (SPNEGO) TAI 问题和异常进行诊断。

不推荐使用的功能部件 不推荐使用的功能部件:

在 WebSphere® Application Server V6.1 中引入了一个信任关联拦截器 (TAI),TAI 使用“简单且受保护的 GSS-API 协商机制” (SPNEGO) 来对安全资源的 HTTP 请求进行安全地协商和认证。现在,WebSphere Application Server 7.0 中已不推荐使用此功能。SPNEGO Web 认证已取代该 TAI,以提供动态重新装入 SPNEGO 过滤器的功能以及对应用程序登录方法启用回退。

depfeat
注: 本主题引用了一个或多个应用程序服务器日志文件。作为另一种建议采用的方法,您可以在分布式系统和 IBM® i 系统上配置服务器以使用高性能可扩展日志记录 (HPEL) 记录和跟踪基础结构,而不使用 SystemOut.logSystemErr.logtrace.logactivity.log 文件。您还可以将 HPEL 与本机 z/OS® 日志记录设施结合使用。如果要使用 HPEL,那么可从服务器概要文件 bin 目录使用 LogViewer 命令行工具来访问所有日志和跟踪信息。有关使用 HPEL 的更多信息,请参阅有关使用 HPEL 对应用程序进行故障诊断的信息。
IBM Java™ 类属安全性服务 (JGSS) 和 IBM 简单且受保护的 GSS-API 协商 (SPNEGO) 提供程序使用 Java 虚拟机 (JVM) 定制属性来控制跟踪信息。SPNEGO TAI 使用 JRas 工具以允许管理员仅跟踪特定类。应使用以下重要的跟踪规范或 JVM 定制属性来通过使用跟踪调试 TAI。
表 1. SPNEGO TAI 跟踪规范.

此表描述了 SPNEGO TAI 跟踪规范。

跟踪 用法
com.ibm.security.jgss.debug 将此 JVM 定制属性设置为 all 以通过 JGSS 代码进行跟踪。消息显示在 trace.log 文件和 SystemOut.log 中。
com.ibm.security.krb5.Krb5Debug 将此 JVM 定制属性设置为 all 以通过特定于 Kerberos5 的 JGSS 代码进行跟踪。消息显示在 trace.log 文件和 SystemOut.log 中。
com.ibm.ws.security.spnego.* 通过使用管理控制台 > 故障诊断 > 记录和跟踪 > server1 > 更改日志详细信息级别 > com.ibm.ws.security.spnego.* 打开此跟踪。消息显示在 trace.log 文件中。

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

症状 用户操作
[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 
解决此问题的首选方法是使 WebSphere Application Server 系统时间与 AD 服务器的时间同步在 5 分钟内。最优方法是使用时间服务器使所有系统保持同步。还可在 Kerberos 配置文件中添加或调整 clockskew 参数。
注: clockskew 参数的缺省值是 300 秒(或 5 分钟)。

问题:没有工厂可用于为机制 1.3.6.1.5.5.2 创建名称。

问题 症状 用户操作
发生异常:没有工厂可用于为机制 1.3.6.1.5.5.2 创建名称。没有工厂可用于为特定机制创建名称。
[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)
检查 java.security 文件,以确保它包含 IBMSPNEGO 安全性提供程序且正确定义了该提供程序。java.security 文件应包含类似于以下的行:
security.provider.6=com.ibm.security
 .jgss.mech.spnego.IBMSPNEGO

问题:在 JGSS 库尝试处理 SPNEGO 令牌时发生异常。

症状 描述 用户操作
在 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
此异常是使用一个密钥对凭单进行编码,然后尝试使用另一个密钥对该凭单进行解码的结果。此情况有几个可能的原因:
  1. 重新生成 Kerberos 密钥表文件之后,尚未将其复制到服务器。
  2. Kerberos 配置指向错误的 Kerberos 密钥表文件。
  3. Kerberos 服务主体名称 (SPN) 已对 Active Directory 定义了多次。您已使用同一 SPN 定义了另一个用户标识,或者使用同一 SPN 定义了另一个用户标识并且还定义了端口。以下示例说明如何会出现此情况:
    SPN 相同,但用户标识不同
    setspn -a HTTP/myHost.austin.ibm.com user1
    	setspn -a HTTP/myHost.austin.ibm.com user2
    SPN 和用户标识相同,但一个没有端口号,一个有端口号
    setspn -a HTTP/myHost.austin.ibm.com user
    	setspn -a HTTP/myHost.austin.ibm.com:9080 user
如果是 Kerberos 密钥表文件存在问题,那么重新生成该密钥表文件。如果是存在多个 SPN 定义的问题,那么请移除额外的或有冲突的 SPN,并确认不再向 Active Directory 注册 SPN,然后添加该 SPN。可能需要搜索 Active Directory 以获取其他定义了与该 SPN 冲突的 SPN 的条目。
要确认 SPN 是未注册的,请使用命令:
setspn –l userid
应该返回以下响应:
Cannot find account userid

问题:未执行单点登录。

症状 描述 用户操作
启用跟踪时,会显示以下消息:
[2/27/06 14:28:04:191 CST] 00000059 
SpnegoHandler < 
		com.ibm.ws.security.spnego
		.SpnegoHandler handleRequest: 
		Received a non-SPNEGO 
		Authorization Header RETURN
客户机返回 NT LAN 管理器(NTLM)对授权提问的响应,而不是返回 SPNEGO 令牌。发生此情况可能是由于以下任一原因:
  • 尚未正确配置客户机。
  • 客户机未在使用受支持的浏览器。例如,当使用 Microsoft Internet Explorer 5.5 时,SP1 以一个非 SPNEGO 认证头进行响应。
  • 用户尚未登录 Active Directory 域,尚未登录可信域或者所使用的客户机不支持在 Windows – 中进行集成认证;在这种情况下,SPNEGO TAI 能够正常运行。
  • 用户正在访问运行客户机的同一机器(本地主机)上定义的服务。Microsoft Internet Explorer 将 URL 的主机名解析为 http://localhostsomeURL 而不是标准名称。
  • 在 Active Directory 中找不到 SPN。SPN 的格式必须为 HTTP/server.realm.com。添加 SPN 的命令是
    setspn –a HTTP/server.realm.com userid
  • Kerberos 服务主体名称 (SPN) 已对 Active Directory 定义了多次。您已使用同一 SPN 定义了另一个用户标识,或者使用同一 SPN 来定义了另一个用户标识(定义了端口号)。以下类别描述了这些情况:
    SPN 相同,但用户标识不同
    • setspn -a HTTP/myappserver.austin.ibm.com user1
    • setspn -a HTTP/myappserver.austin.ibm.com user2
    SPN 相同,用户标识也相同,但每个用户标识都定义了一个端口号
    • setspn -a HTTP/myappserver.austin.ibm.com user3
    • setspn -a HTTP/myappserver.austin.ibm.com:9080 user3

如果 SPN 被错误地定义为 HTTP/server.realm.com@REALM.COM,即具有额外的 @REALM.COM,那么删除该用户,然后重新定义该用户和 SPN。

如果是 Kerberos 密钥表文件存在问题,那么重新生成该密钥表文件。

如果问题在于多个 SPN 定义的任一类别,那么请移除额外的或有冲突的 SPN,并确认不再向 Active Directory 注册 SPN,然后添加该 SPN。您可以在 Active Directory 中搜索其他导致多个 SPN 定义的 SPN 条目。以下命令可用于确定多个 SPN 定义:
setspn ?L userid
如果 SPN 未注册,那么返回消息 cannot find account userid
setspn -L
显示存在的 SPN。

问题:凭证授权不起作用。

症状 描述 用户操作
检测到无效选项。启用跟踪时,会显示以下消息:
com.ibm.security.krb5.KrbException,
 status code: 101 message:
 Invalid option in ticket request
未正确配置 Kerberos 配置文件。 确保 renewable 或 proxiable 设置为 true。

问题:无法通过使用 RC4-HMAC 加密使 SSO 起作用。

症状 描述 用户操作
检查打开跟踪时接收到的跟踪中的以下消息:
com.ibm.security.krb5.internal.crypto.
 KrbCryptoException, status code: 0
	message: Checksum error; received 
	checksum does not match computed 
	checksum
2003 Kerberos 密钥分发中心 (KDC) 之前的 Microsoft Windows 版本不支持 RC4-HMAC 加密。要确认此情况,请检查抛出异常处的跟踪和标识。入局凭单的内容在跟踪中应是可视的。尽管入局凭单是已加密的,但服务的 SPN 仍是可读的。如果使用 2003 KDC 之前的 Microsoft Windows 版本,并且系统已配置为使用 RC4-HMAC,那么会显示表示 userid@REALM(而不是期望的 HTTP/hostname.realm@REALM)的凭单的字符串。例如,以下是从 2003 KDC 之前的 Microsoft 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) 或使用 Microsoft Windows 2003 Server 获取 KDC。请记住要重新生成 SPN 和 Kerberos 密钥表文件。

问题:当通过 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 令牌是 Microsoft Windows Kerberos 令牌的包装器。Microsoft Windows 将用户的 PAC 信息包括在 Kerberos 令牌中。用户所属的安全组越多,那么 Kerberos 令牌中插入的 PAC 信息就越多,并且 SPNEGO 会变得越大。IBM HTTP Server 2.0(以及 Apache 2.0 和 IBM HTTP Server 6.0)将任何可接受的 HTTP 头的大小限制为 8K。在具有许多组并且用户在许多组中具有成员资格的 Microsoft Windows 域中,用户的 SPNEGO 令牌的大小可能超过 8K 限制。 如果可能,减少该用户所属的安全组数。IBM HTTP Server 2.0.47 修订包 PK01070 允许 HTTP 头大小达到并超过 Microsoft 12K 的限制。WebSphere Application Server V6.0 用户可在修订包 6.0.0.2 中获取此修订。
注: 基于非 Apache 的 Web 服务器可能需要不同的解决方案。

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

症状 描述 用户操作
检查 SystemOut.log 并注意到即使禁用了 JGSS 跟踪,也仍会出现一些 KRB_DBG_KDC 消息。 虽然 JGSS 跟踪的大部分由 com.ibm.security.jgss.debug 属性控制,但仍有一小部分消息由 com.ibm.security.krb5.Krb5Debug 属性控制。com.ibm.security.krb5.Krb5Debug 属性的缺省值是将某些消息放置到 SystemOut.log 中。 要从 SystemOut.log 中除去所有 KRB_DBG_KDC 消息,请按如下所示设置 JVM 属性:
-Dcom.ibm.security.krb5.Krb5Debug=none

问题:应用程序包含定制 HTTP 401 错误页,SPNEGO TAI 生成的 HTTP 响应页未显示在浏览器中。

症状 描述 用户操作
当应用程序包含定制 HTTP 401 错误页时,简单且受保护的 GSS-API 协商机制 (SPNEGO) 信任关联拦截器 (TAI) 生成的 HTTP 响应页未显示在浏览器中。 当应用程序包含定制 HTTP 401 错误页时,SPNEGO TAI 生成的 HTTP 响应页未显示在浏览器中。相反,显示的是定制 HTTP 401 错误页。 可以定制 HTTP 401 页以包含有关如何将浏览器配置为使用 SPNEGO 的信息。有关更多信息,请参阅将客户端浏览器配置为使用 SPNEGO TAI(不推荐)SPNEGO TAI 定制属性配置(不推荐)

问题:当单步执行到用户标识/密码登录时,在与 SPNEGO TAI 交互期间丢失 HTTP Post 参数。

症状 描述 用户操作
当单步执行到用户标识/密码登录时,在与 SPNEGO TAI 交互期间,会丢失 HTTP Post 参数。

“逐步执行到用户标识/密码登录”指的是 Microsoft Internet Explorer 尝试最初使用 SPNEGO 令牌进行响应。如果此响应不成功,那么 Microsoft Internet Explorer 将尝试使用通过用户标识/密码提问获取的 NTLM 令牌进行响应。

Microsoft Internet Explorer 在用户请求期间保持状态。如果某个请求得到的响应为“HTTP 401 认证协商”,并且浏览器采用通过用户标识/密码提问获得的 NTLM 令牌进行响应,那么浏览器会重新提交该请求。如果这第二个请求得到的响应为一个 HTML 页面,并且该页面包含指向相同 URL 但具有新参数的重定向(通过 Javascript),那么浏览器不会重新提交 POST 参数。
注: 要避免此问题,关键是不要执行自动重定向。如果用户单击链接,那么不会发生此问题。

浏览器使用 NTLM 令牌而不是 SPNEGO 令牌来响应认证/协商提问。SPNEGO TAI 查看 NTLM,并返回 HTTP 403 响应以及“HTML”页面。 当浏览器运行 JavaScript redirTimer 函数时,原始请求中存在的任何 POST 或 GET 将丢失。

通过使用 SPN<id>.NTLMTokenReceivedPage 属性,可将相应的消息页面返回给用户。(当不存在用户定义的属性时)返回的缺省消息为:
“<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>Please login to the application using 
		the normal login page.</html>”;

通过使用 SPN<id>.NTLMTokenReceivedPage 属性,您可以定制确切的响应。关键是返回的 HTML 不要执行重定向。

当 SPNEGO TAI 已配置为将交付的缺省 HTTPHeaderFilter 类用作 SPN<id>.filterClass 时,SPN<id>.filter 可用于允许第二个请求直接流入正常的 WebSphere Application Server 安全性机制。以这种方式,用户将经历正常的认证机制。

下面是这种配置的一个示例,显示了必需的 SPNEGO TAI 属性和 HTML 文件内容。
****** 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 
注: 注意,filter 属性指示 SPNEGO TAI 不要拦截任何包含字符串“noSPNEGO”的 HTTP 请求。
以下是一个生成有用响应的示例。
<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>

问题:信任关联拦截器 (TAI) 不调用 initialize(Properties) 方法

跟踪可能显示 TAI 已装入,但是未调用 initialize(Properties) 方法。启动期间似乎仅调用了 getVersion() 方法。

当为 TAI 定义了定制属性时,WebSphere 的 TAI 处理仅调用 initialize(Properties)。

要解决此问题,请定义一个未使用的 TAI 定制属性,例如 com.ibm.issw.spnegoTAI.NumberOfServers=0。

问题:信任关联拦截器 (TAI) 未正确装入

跟踪可能显示 TAI 未装入,并可能收到以下异常文本:
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)
…

此问题的可能原因是 JVM 定制属性 javax.security.auth.useSubjectCredsOnly 未设置为值 false

要解决此问题,请在为 TAI 启用的每个 JVM 上定义一个 JVM 定制属性 javax.security.auth.useSubjectCredsOnly=false。

问题:用于添加信任关联拦截器 (TAI) 参数的 JACL 脚本缺省字符可能导致问题

用于添加 TAI 参数的 JACL 脚本接受位置参数。为了接受缺省值,指定了“.”。在某些 WebSphere 平台上,如果指定 “.” ,可能导致添加具有“.”值的属性。

不论哪种平台,请始终使用管理控制台确认添加的属性是否如预期一样。如果并非预期,请手动进行修正。


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



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