ibm tivoli_IBM Tivoli Access Manager：WebSEAL Kerberos连接

ibm tivoli

总览

IBM®Tivoli®Access Manager（TAM）v6.1引入了WebSEAL的Kerberos联结的概念。 Kerberos联结可用于对已启用Kerberos身份验证的Web服务器执行单点登录。 Kerberos STS模块（在Tivoili联合身份管理器（TFIM）v6.2中引入）管理Kerberos令牌的生成，该令牌用于执行SSO。 SSO操作期间使用的身份可以是已建立的TAM用户身份的身份，也可以是另一个映射的用户身份。此身份映射由TFIM控制。

TFIM使用Microsoft®Kerberos扩展来根据提供的用户身份生成有效的Kerberos令牌。这些扩展分为两个部分：

协议转换（或S4U2Self）允许根据所提供的用户身份进行模拟。
约束委派（或S4U2Proxy）允许创建Kerberos服务票证，以供单独的标识使用。

当结合使用时，这两个扩展提供了一种代表另一个用户创建Kerberos服务票证的方法，以便访问目标资源。换句话说，这些扩展使TFIM能够代表TAM用户创建Kerberos服务票证，然后可以使用该服务票证访问联结的Web服务器。

图1显示了建立TAM身份后执行Kerberos单点登录所涉及的典型步骤序列。

图1. SSO序列

本文分步详细介绍了针对Kerberos单点登录（SSO）的典型客户用户环境的配置。该环境在IBMWebSphere®集群环境中部署TFIM，但是如果TFIM在独立的WebSphere Application Server（WAS）中运行，则本文的大部分内容也适用。图2描述了环境的体系结构，本文通篇引用了该体系结构。

图2.环境概述

TFIM平台

TFIM Kerberos STS模块仅在Windows 2003平台及更高版本上可用，因为它利用了Microsoft的Kerberos扩展，只有Windows 2003和更高版本的操作系统才支持。当运行Windows Server 2003时，还请确保由于内存泄漏而安装了Service Pack 2，如下所述：
http://support.microsoft.com/kb/907524 。

本文不介绍整个环境的配置。特别是，它假定以下实体的配置已经完成：

Tivoli Access Manager v6.1：
- 用户注册表（任何受支持的注册表）
- TAM策略服务器
- WebSEAL（初始配置）
Tivoli Federated Identity Manager v6.2：
- 部署到WAS集群
- 已配置TFIM域，并且已将运行时部署到该域。
微软：
- 域控制器-包括Active Directory和Microsoft支持工具
- IIS 6.0或IIS 7.0-已启用Kerberos身份验证

本文还将概述在可能的情况下针对在Windows Server 2003上运行的IIS 6.0 Web服务器和在Windows Server 2008上运行的IIS 7.0进行配置之间的区别。

本文将重点介绍必须自定义的环境方面，以便从WebSEAL执行Kerberos单一登录。特别是，这将包括：

将IIS实例配置为以具有分配的服务主体名称的Active Directory用户身份运行。
使WebSphere-TFIM实例生成委托的Kerberos服务票证。
配置TFIM Kerberos STS模块和TFIM信任链。
配置与IIS服务器的TAMeb Kerberos联结以使用生成的委派Kerberos票证。

本文将以简短的故障排除部分作为结束语，该部分描述了在Kerberos单点登录失败时如何对环境进行故障排除。

步骤1：配置IIS

时间同步

Kerberos票证依靠嵌入式时间戳来使旧票证过期。因此，重要的是确保环境中所有计算机上的时钟都同步。

为了使受约束的委派正确运行，目标服务（即IIS）必须以Active Directory（AD）用户身份运行，该用户具有已分配的服务主体名称（SPN），并且配置为作为Kerberos服务运行。要以AD用户身份运行IIS，请完成以下步骤：

创建并初始化AD用户：
1. 在域控制器上，从“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” 。创建一个密码永不过期的新用户。
  
  图3. IIS用户创建
2. 在域控制器上，准备新用户，使其可以作为Kerberos服务执行。这是使用ktpass命令行实用程序完成的，该实用程序作为Windows支持工具的一部分提供。一旦为用户设置了SPN，登录名也将更改为反映SPN。清单1中显示了ktpass的语法。
  
  清单1. ktpass命令
```
ktpass -princ HTTP/<IIS Server Name>.<DNS domain name>@<AD DOMAIN NAME> \-mapuser <IIS User Name> -mapOp set
```
  图4显示了示例命令及其输出。
  
  图4.设置用户SPN
3. Windows Server 2003 / IIS 6.0：在IIS系统上，必须使AD用户成为本地IIS_WPG组的成员。为此，请从“开始”菜单的“管理工具”部分中选择“ 计算机管理” ，或者如果计算机是域控制器，请选择“ Active Directory用户和组”，然后在“ 内置用户”列表下找到IIS_WPG组，然后将新的AD用户添加到这个小组。
  
  图5. IIS_WPG组
  
  Windows Server 2008 / IIS 7.0：在IIS系统上，必须使AD用户成为本地IIS_IUSRS组的成员。为此，请从“开始”菜单的“管理工具”部分中选择“ 计算机管理” ，或者如果计算机是域控制器，请选择“ Active Directory用户和组”，然后在“ 内置用户”列表下找到IIS_IUSRS组，然后将新的AD用户添加到这个小组。
  
  图6. IIS_IUSRS组
默认情况下，计算机的安全策略将不允许AD用户执行本地服务。这需要更改，以便允许新的AD用户将IIS作为服务执行。从“开始”菜单的“管理工具”部分中选择“ 本地安全策略 ” ，然后扩展“作为服务登录”本地策略以包括新的AD用户。

图7.安全策略
配置IIS应用程序池以AD用户身份执行：
1. 在IIS系统上，使用IIS管理器更改用于执行请求的身份。
  注意：使用后端Web应用程序需要IIS以外的其他特定特权时，请在更改IIS服务用户帐户时参考您的产品文档。 Microsoft Office SharePoint是一个这样的示例，建议通过SharePoint管理中心控制台修改服务用户。
  
  在Windows Server 2003 / IIS 6.0上：通过编辑目标应用程序池的属性来执行此操作。
  
  图8. IIS 6.0应用程序池标识
  
  在Windows Server 2008 / IIS 7.0上：通过在“高级设置”对话框中修改标识来执行此操作。
  
  图9. IIS 7.0应用程序池标识
2. 在IIS系统上，使用IIS管理器来回收目标应用程序池，以便在上一步中所做的更改生效。
  在Windows Server 2003 / IIS 6.0上：可以通过“右键单击”应用程序池来完成，如图10所示。
  
  图10. IIS 6.0回收IIS应用程序池
  
  在Windows Server 2008 / IIS 7.0上：这可以通过在应用程序池“操作”窗格中选择“回收”来完成，如图11所示。
  
  图11. IIS 7.0回收IIS应用程序池
打开Web浏览器并访问Web服务器，以确保其仍然正常运行。还应检查Windows任务管理器中可用的进程列表，以确保每个适用的w3wp.exe进程都以新创建的AD用户身份执行，如图12所示。

图12. IIS验证

注意：在访问站点之前，该应用程序的IIS w3wp.exe服务可能不会出现在进程列表中。

如果您在带有IIS 6.0的Windows Server 2003上运行，则现在应该配置IIS，请继续执行步骤2：WebSphere TFIM配置。
如果您在带有IIS 7.0的Windows Server 2008上运行，则需要一些其他步骤才能支持WebSEAL Kerberos Junction配置。
Windows Server 2008 / IIS 7.0：在与每个站点连接的“身份验证”选项下，必须禁用基于内核的Kerberos身份验证。这是由于WebSEAL通过初始请求中的Kerberos凭据和基于内核的认证中的限制与IIS Web服务器联系的方式。可以通过在站点身份验证页面上“右键单击” Windows身份验证来禁用此功能，如图13所示。

图13. Kerberos高级设置

取消选中“启用内核模式身份验证”复选框，如图14所示。

图14. Kerberos高级设置对话框

在身份验证屏幕上，还确保如图13顶部所示启用了ASP.NET模拟。
当模拟和Kerberos一起使用时，IIS 7.0会生成警告，阻止该网站显示，如图15所示。

图15.集成的托管管道错误。

必须通过将清单2中所示的粗体 XML添加到IIS主机上的applicationHost.config文件中来抑制此错误。该文件的默认位置是： C:\Windows\System32\inetsrv\config\ 。或者，可以将其添加到每个适用的Web应用程序的web.config文件中，但是applicationHost.config文件将始终覆盖此内容。有关此主题的更多信息，请参见： http : //learn.iis.net/page.aspx/124/ 。

清单2.应用程序配置
```
<location path="Default Web Site"><system.webServer><security><authentication><anonymousAuthentication enabled="false" /><windowsAuthentication enabled="true" useKernelMode="false" /></authentication></security><validation validateIntegratedModeConfiguration="false" /></system.webServer>
</location>
```

同样，在<windowsAuthentication>块中，确保如果属性useAppPoolCredentials存在，则不要将其设置为“ true” 。

完成这些更改后，请回收应用程序池，如图11所示。

步骤2：WebSphere-TFIM用户配置

节点代理

如果使用WAS独立服务器而不是WAS ND，则应用程序服务器进程本身（而不是节点代理）必须在AD帐户下运行。在WAS ND中，节点代理负责启动和停止应用程序服务器进程，并且它们继承父进程的身份。这就是为什么在WAS ND环境中将nodeagent修改为使用活动目录帐户运行的原因。

承载Tivoli Federated Identity Manager运行时的WebSphere节点代理程序需要在Active Directory中的特殊帐户下运行。这是必需的，以便可以授予它权限以获取其他用户的Kerberos票证和一组受限制的目标。在Kerberos委托信任链可以工作之前，您需要创建帐户，设置适当的选项并修改WebSphere服务以使用该帐户。以下说明描述了如何完成此任务。

在域控制器上，确保将域功能级别设置为Windows Server 2003 。为了使Windows Kerberos约束委派起作用，必须执行此步骤。从“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” ，然后右键单击域并选择“ 属性”以查看域控制器正在运行的级别，此屏幕的示例如图16所示。如果此版本早于2003，则Kerberos约束委派将不起作用。要升级，请右键单击域，然后选择“ 提升域功能级别” 。

图16.域功能级别
创建并初始化AD用户：
1. 在域控制器上，从“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” 。创建一个配置了永不过期的密码的新用户。
  
  图17. TFIM用户创建
2. 在域控制器上，为新的AD用户设置SPN。这是使用setspn命令行实用程序完成的，该实用程序作为Windows支持工具的一部分提供。清单3中显示了setpn的语法。
  
  清单3. setspn命令
```
setspn -A tfim/<tfim user> <tfim user>
```
  图18显示了示例命令及其输出。
  
  图18.设置用户SPN
3. 在TFIM服务器上（或在每个服务器上，如果它们是群集的一部分），使AD TFIM用户成为本地Administrators组的成员。通过从“开始”菜单的“管理工具”部分中选择“ 计算机管理”来执行此操作。定位下本地用户和组管理员组- > 组，然后将新的AD用户添加到该组中所示图19 。
  注意：一些指南建议用户应该是Domain Admins组的成员，只要TFIM用户是本地计算机管理员，则不需要这样做。
  
  图19.管理员组
4. 还必须修改AD用户，以便可以信任它委派IIS服务。为此，请从域控制器上“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” 。打开新的AD用户的属性，选择“ 委托”选项卡，然后启用对本文图4中创建的IIS用户的委托。
  注意：搜索服务时，请确保按IIS用户名而不是服务器主机名进行搜索，然后选择“完全大写”中显示的HTTP服务。完成后，TFIM用户的Properties-Delete选项卡应类似于图20所示。
  
  图20.委托权限
5. 还必须将AD用户添加到Windows授权访问组对象。从域控制器上“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” 。选择Builtin对象，然后修改Windows Authorization Access Groups对象的属性，使新的AD用户成为该组的成员，如图21所示。
  
  图21. Windows授权访问组
6. 默认情况下，计算机的安全策略将不允许AD用户执行本地服务。更改此设置，以便允许新的AD用户将WebSphere作为服务执行。通过从“开始”菜单的“管理工具”部分中选择“ 本地安全策略” ，更新WAS服务器上的策略。需要修改“作为服务登录”本地策略，以包括新的AD用户。对于集群环境，必须在承载运行Tivoli Federated Identity Manager运行时的节点成员的所有机器上重复此步骤。图22中显示了一个示例。
  
  图22. TFIM用户-作为服务登录
7. 还需要向新的AD用户授予WAS服务器上的权限，以充当操作系统的一部分。通过从“开始”菜单的“管理工具”部分中选择“ 本地安全策略”来更新策略。用户权限分配条目的“充当操作系统的一部分”本地策略需要扩展，以包括新的AD用户。对于集群环境，必须在承载运行Tivoli Federated Identity Manager运行时的节点成员的所有机器上重复此步骤。图23中显示了一个示例。
  
  图23. TFIM用户-充当操作系统的一部分
然后必须将WebSphere节点代理服务配置为在上面创建的AD主体下作为进程运行。必须在承载运行Tivoli Federated Identity Manager运行时的节点成员的所有机器上重复以下步骤。
1. 通过执行位于WebSphere bin目录中的wasservice命令，使WebSphere进程能够作为Windows服务运行。示例命令及其输出如图24所示。
  注意：这可能是在安装过程中运行的，并且只有在该服务未在操作系统的“服务”窗格中列出（如下一步所示）时才有必要。
  
  图24.启用WAS服务
2. 需要修改WebSphere节点代理服务以作为新的TFIM AD用户运行。这可以通过“ 服务”控制面板（可从“开始”菜单的“管理工具”部分获得）并修改IBM WebSphere Application Server服务的属性来实现。运行时使用的用户名位于“ 登录”选项卡上，图25中显示了一个示例
  
  图25. WAS服务用户
3. 如果WebSphere在此阶段运行，则必须重新启动它以反映对Service属性的更改。这可以通过执行位于WebSphere bin目录中的stopnode和startnode命令来实现。这些命令的示例及其输出如图26所示。
  
  图26. WAS节点重启
检查以确保WAS服务以新的AD用户身份运行。应该检查Windows任务管理器提供的包含此信息的进程列表，以确保以新AD用户的身份执行java.exe和WasService.exe进程。如图27所示

图27. WAS运行时用户验证

步骤3：TFIM信任链

必须设置TFIM信任链，以便TFIM能够将提供的IV-Cred转换为Kerberos令牌。信任链配置包括按顺序执行的多个TFIM模块。 WebSEAL Kerberos联结所需的最小信任链包括IVCred令牌模块（用于从IV凭证中提取用户身份信息），其后是Kerberos委托模块（用于生成Kerberos令牌）。 IVCred令牌模块的默认模块实例可以在信任链中使用，但是必须创建并使用新的Keberos委托模块实例。如果希望在TAM用户ID和包含在生成的Kerberos令牌中的AD身份之间执行身份映射，则可以在IVCred令牌模块和Kerberos委托模块之间插入可选的映射模块。

图28.信任链

通过调用WebSphere控制台上的“创建”向导来创建Kerberos委托STS模块的实例：
1. 选择Tivoli Federated Identity Manager来展开它。
2. 然后选择“ 配置信任服务”以将其展开。
3. 然后选择“ 模块实例” 。
4. 在显示的“模块实例”页面上，单击“ 创建”按钮。
新的“ Kerberos委派STS模块”实例的配置信息由向导执行。在第一页（图29 ）上，选择com.tivoli.am.fim.trustserver.sts.modules.KerberosDelegationSTSModule模块类型。点击下一步。

图29. Kerberos委托STS模块向导步骤1。

在第二页（图30 ）上，为模块命名，例如Kerberos Token （记住此名称，因为我们将在信任链的构造中使用它）并提供类似于以下内容的描述：用于创建Kerberos Token的模块。点击下一步。

图30. Kerberos委托STS模块向导步骤2。

在第三页（图31 ）上，我们可以指定凭证缓存的最大大小，默认值在这里很好。单击完成。 注意：此凭据缓存是Kerberos本地安全授权（LSA）登录句柄的LRU集合。每次需要新的用户票证时，TFIM都会使用登录句柄，并且此缓存会维护一个现有登录名列表，以加快连续票证请求的生成。

图31. Kerberos委托STS模块向导步骤3。

现在已配置Kerberos委托模块。
现在应创建将被调用以生成Kerberos令牌的实际信任链。如前所述，最小信任链将由两个模块实例组成：默认的IV Cred Token模块实例和在上一步中创建的新的Kerberos模块实例。必须在“验证”模式下创建IV-Cred令牌模块实例，并且必须在“问题”模式下创建Kerberos模块实例。为了使TFIM正确选择要调用的信任链，信任链配置中包含某些选择条件。通过调用WebSphere控制台上的“创建”向导来创建信任链：
1. 选择Tivoli Federated Identity Manager来展开它。
2. 然后选择“ 配置信任服务”以将其展开。
3. 然后选择“ 信任服务链” 。
4. 在显示的“信任服务链”页面上，单击“ 创建”按钮。
下图中描述了各个向导步骤的配置信息。

注意：在创建信任链期间，将显示警告，指出模块链不符合建议的链结构。忽略此警告并继续创建信任链是安全的。

在向导的第一页上，阅读“ 简介”后单击“下一步” 。
图32显示了向导的第二页，其中要求我们命名和描述我们的信任链。将此链命名为WebSEAL Kerberos Junction，并提供与Trust链类似的描述，以为WebSEAL Kerberos Junction生成令牌。点击下一步。

图32.信任链向导页面2

向导第三页上的重要字段，如图33所示：
1. 与WebSEAL “适用于”配置条目相对应的“适用于地址”字段。在此示例中，这对应于结的完整路径。如果您在同一台计算机上有多个联结，则可以在此处使用通配符'*'。
2. 与WebSEAL “服务名称”配置条目相对应的“ AppliesTo服务名称”字段。从WebSEAL发送的RST中包含的服务名称将与“服务名称”字段的第二部分匹配（即，在冒号之后出现的部分）。在上面给出的示例中，已为“服务名称”的两个部分提供了“ *”字符，以便所有具有相同地址的请求都将匹配。
3. “发行人地址”应始终设置为“ amwebrte-sts-client” 。
图33.信任链向导页面3

完成第四页图34与向导的第2页类似。

图34.信任链向导页面4

在第5页上，我们为信任链组装了两个模块。
1. 首先在验证模式下添加默认的IVCred令牌模块。
2. 其次，添加我们之前在发布模式下创建的Kerberos令牌模块。
图35显示了结果。点击下一步。忽略显示的警告，然后单击继续。

图35.信任链向导页面5

在“ IVCred模块配置”页面上，不需要任何选项，如图36所示。

图36.信任链向导页面6

在“ Kerberos委派模块”配置页面上，选择选项“ 将计算机DNS域作为后缀添加到用户名” ，如图37所示。

图37.信任链向导页面7

在最后一页上查看配置，然后单击“完成”以创建TFIM Kerberos委派信任链。

TFIM配置更改

确保加载TFIM配置更改，以使新的信任链生效。有时需要完全重启集群才能应用TFIM配置更改。如果重新加载后更改似乎没有生效，请尝试重新启动集群。

将配置更改加载到TFIM中后，应验证新的信任链，以确保它可以成功创建Kerberos令牌。这可以通过建立并向TFIM发出RST请求来实现。如果发生错误，则应检查WebSphere stdout日志文件以获取对该问题的更完整描述。本文已包含对名为testuser的用户的示例RST请求rst.xml 。清单4中的以下示例显示了如何使用curl客户端发出RST请求。如果一切都已正确配置，则此命令应返回RSTR响应，其中包含Kerberos令牌。
在运行下面的命令之前，请修改XML，以使<wsa：Address>与TFIM信任链中提供的地址匹配，并且<wsa：ServiceName>与委托的SPN（例如HTTP / server1.jkhle.com ）匹配。

清单4.示例curl命令

curl --header "soapaction: blah" --data-binary @rst.xml \http://<TFIM server>:<TFIM Port>/TrustServerWST13/services/RequestSecurityTokenResult:<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope ...><soapenv:Header><ns1:Security ...><ns1:Timestamp><ns1:Created>2008-11-19T01:53:36Z</ns1:Created></ns1:Timestamp></ns1:Security></soapenv:Header><soapenv:Body><wst:RequestSecurityTokenResponseCollection ...><wst:RequestSecurityTokenResponse Context="" ...><wst:TokenType>http://docs.oasis-open.org/wss/...</wst:TokenType><wsp:AppliesTo ...><wsa:EndpointReference ...><wsa:Address>http://server2.jkhle.com/iis</wsa:Address><wsa:ServiceName>:HTTP/server1.jkhle.com</wsa:ServiceName></wsa:EndpointReference></wsp:AppliesTo><wst:RequestedSecurityToken><wss:BinarySecurityToken ...>YIIFqQYJKoZIhvcSAQICAQBuggWYMIIFlKADAgEK6gFw0/z3pi90VY6570BNi1kTyP+3e6Cp7yOpOdqmtNKIZJYkAUWfQ1eaS+B0n9OJgbi5lyNAc1dgDlgI+X2Ca7hi4FkXl2x5b/esLl+wVLBFoLgN12XP2oG3UVf2sPEozxlfSn0oiiPcZ488tmGuzOetyQ2p9c2CXL+JgWbR5elPzoLP9LYVpppQlJ9yxw/8IK429ylzRFR8kPuEIHjuBdKpvBBpn7y78xeeRnXg9ydQjVbHIcjmr+ArMrY7fkCrNvcYVQhq7p5CbBSOmSuFw0/z3pi90VY6570BNi1U5f4cTb+Va3DLJZTDyEHUwdeDKk4VlgT4zjjloBL1SkzIBSnNsny7FWH/sS75TmUv8FUoYGvlPpXqEPAC2hAT43yzdJ8VsN5vlqYbUtXjYPWs27wpMrUHohA7LpuzO7lZ1DJ0OVL9uedsv3+OUWcMDovuPXYFUmpAY0lNCNo2sotS3IurJ1X5cU28ACrkr8yX2uBVv3ri0nFV6Z/Q0jptheQBleI2d1+CK9pYJNkPM8aGFnqRG45hUxx9nfMdLQ7lY6L1y7vM3ne31E47PpGjG0ulZLXXEXn6pEuvBDoeCWlWN8VKCCVm5wEM4kD4ny92gn9czJjIY4z6hzia5Ct45vMmEz4ZpF7KdnciLX52eVPQvS+grSdMIRtbC/4yp9nWokzP5+pjxR8pmFRXjCpUQ4dQ6xnQX3jgPuYEdDi4rUAHWBI2vCo+7e82xTUCNbXTbdEEM/LsixzOWwBna/I10K13sdKk8shL7ybhSXyyRS0z17SiXdLqTyChhPzYz1Y/uEt6mynZo+qRKRuNPTiy...4mDLqM59vj4DwGWfxj6nZOCAKzweVGA8Tfm+OSCtbBdLQ7lY6L1y7vM3dLQ7lYocAAeDdzeFRhHIYWmdc1bFDTMZEIhJGE17ScLw==</wss:BinarySecurityToken></wst:RequestedSecurityToken><wst:Lifetime ...><wsu:Expires>2008-11-19T02:03:42Z</wsu:Expires></wst:Lifetime></wst:RequestSecurityTokenResponse></wst:RequestSecurityTokenResponseCollection></soapenv:Body>
</soapenv:Envelope>

步骤4：WebSEAL Kerberos连接

现在TFIM已正确配置了Kerberos信任链，配置的最后一步是为WebSEAL创建启用Kerberos的联结。以下步骤显示了如何配置WebSEAL Kerberos联结。

WebSEAL配置文件中包含WebSEAL Kerberos联结的配置。必须先完成此配置，然后才能创建结点本身。配置文件中有两个节必须修改： [tfimsso：<jct-id>]和[tfim-cluster：<cluster>] 。第一个节包含Kerberos联结的常规配置详细信息，而第二个节包含用于与TFIM连接和通信的配置详细信息。

在高可用性环境中，有两种方法可以在多个WebSphere Application Server之间配置负载平衡和故障转移。第一种方法是使用所有集群节点的知识来配置WebSphere Web Server插件。在这种情况下，WebSEAL将仅与单个服务器进行通信，然后该服务器处理各个集群节点之间的请求分配。第二种方法是让WebSEAL通过在WebSEAL配置文件中指定多个服务器URL本身来执行请求的分发。

清单5显示了本文记录的环境的配置。它仅包括实际上已从缺省WebSEAL模板配置更改的那些配置条目。

清单5. WebSEAL配置文件提取

[tfimsso:/iis]#
# This stanza is used to hold the TFIM single sign-on configuration information
# for a single junction.
#
# For standard junctions the stanza name will be qualified with the name of the
# junction point (including the leading '/').  An example stanza name might be:
# [tfimsso:/junction_a]
#
# For virtual host junctions the stanza name will be qualified with the
# virtual host label.  An example stanza name might be:
# [tfimsso:www.ibm.com]
## The 'applies-to' search criteria used when locating the appropriate STS
# module within TFIM.  Generally this entry should be of the format:
# http://<webseal-server>/<junction> (similar to the URL which is used to
# access the junction).
applies-to = http://server2.jkhle.com/iis# The service-name configuration entry will be used:
#   1. By TFIM when searching for a matching trust chain.  This configuration
#      entry will be compared against the configured 'AppliesTo' service name
#      value for each trust chain.  The second field within the 'AppliesTo'
#      service name configuration entry should be set to either '*' to match
#      all service names, or it should be set to the value defined by this
#      configuration item.  Refer to the TFIM documentation for further
#      details on configuring Trust Chains.
#   2. As the service principal name of the delegating user when creating the
#      Kerberos token.  The service principal name can be determined by
#      executing the Microsoft utility 'setspn', i.e. setspn -L <user>,
#      where <user> is the identity of the user which the junctioned Web server
#      is running as.
service-name = HTTP/server1.jkhle.com# This boolean value is used to indicate whether a security token should be
# sent for every HTTP request, or whether WebSEAL should wait for a 401
# response from the back-end Web server before adding the security token.  This
# configuration item is used to avoid the unnecessary overhead of generating
# and adding a security token to every request if the back-end Web server is
# capable of maintaining user sessions.
always-send-tokens = true# The name of the WAS cluster which houses this TFIM service.  There should
# also be a corresponding [tfim-cluster:<cluster>] stanza which contains the
# definition of the cluster.
tfim-cluster-name = jkhle[tfim-cluster:jkhle]#
# This stanza contains definitions for a particular cluster of TFIM
# servers.
##
# A specification for the server which is used when communicating with a
# single TFIM server which is a member of this cluster.  Values for this
# entry are defined as follows:
#
#       {[0-9],}<URL>
#
# Where the first digit (if present) represents the priority of the server
# within the cluster (9 being the highest, 0 being lowest).  If the priority
# is not specified, a priority of 9 is assumed.  The <URL> can be any
# well-formed HTTP or HTTPS URL.
#
# Multiple server entries can be specified for failover and load balancing
# purposes.  The complete set of these server entries defines the
# membership of the cluster for failover and load balancing.
#
# server = 9,http://tfim.example.com/TrustServerWST13/services/RequestSecurityToken
server = 9,http://server2.jkhle.com/TrustServerWST13/services/RequestSecurityToken

一旦使用联结配置更新了WebSEAL配置文件并且重新启动了WebSEAL服务，就可以创建实际的联结本身。使用pdadmin服务器任务<server-name> create命令执行此操作。使用-Y联结标志指示该联结应启用Kerberos。
注意：还请确保在此处也添加与您的后端应用程序相关的任何其他标志。清单6显示了基于TCP的Kerberos连接的创建。

清单6.连接创建命令

pdadmin sec_master> s t default-webseald-server2.jkhle.com create -t tcp \-h server1.jkhle.com -Y /iis
Created junction at /iispdadmin sec_master> server task default-webseald-server2.jkhle.com show /iisJunction point: /iisType: TCPJunction hard limit: 0 - using global valueJunction soft limit: 0 - using global valueActive worker threads: 0Basic authentication mode: filterForms based SSO: disabledTFIM junction SSO: yesAuthentication HTTP header: do not insertRemote Address HTTP header: do not insertStateful junction: noBoolean Rule Header: noScripting support: noPreserve cookie names: noCookie names include path: noTransparent Path junction: noDelegation support: noMutually authenticated: noInsert WebSphere LTPA cookies: noInsert WebSEAL session cookies: noRequest Encoding: UTF-8, URI EncodedServer 1:ID: 98fa4d16-3e73-11dd-b339-000c2944bd3bServer State: runningOperational State: OnlineHostname: server1.jkhle.comPort: 80Virtual hostname: server1.jkhle.comServer DN:local IP address:Query_contents URL: /cgi-bin/query_contentsQuery-contents: unknownCase insensitive URLs: noAllow Windows-style URLs: yesCurrent requests : 0Total requests : 25

最后，可以测试新的Kerberos联结。为了测试本文中记录的环境，对IIS配置进行了以下更改：
- 使用IIS管理控制台启用了Windows集成身份验证。
- 修改了IIS站点，以启用身份模拟。
- 编写了一个简单的whoami.aspx脚本，该脚本在响应中包含身份。此脚本使用“ <％Response.Write（System.Security.Principal.WindowsIdentity.GetCurrent（）。Name）％> ”获得身份。
客户端可用于在联结的Web服务器上请求新的whoami.aspx脚本。 WebSEAL应该要求认证，而联结的Web服务器则不需要认证。清单7显示了使用curl作为客户端的请求结果。为了进行其他验证，还可以检查IIS请求日志以确保身份信息正确。

清单7.连接验证
```
>curl -v -u testuser:passw0rd http://server2.jkhle.com/iis/whoami.aspx
* About to connect() to server2.jkhle.com port 80 (#0)
*   Trying 10.251.140.101... connected
* Connected to server2.jkhle.com (10.251.140.101) port 80 (#0)
* Server auth using Basic with user 'testuser'
> GET /iis/whoami.aspx HTTP/1.1
> Authorization: Basic dGVzdHVzZXI6bWVyY3VyeTE=
> User-Agent: curl/7.18.0 (i486-pc-linux-gnu) libcurl/7.18.0 OpenSSL/0.9.8g
> Host: server2.jkhle.com
> Accept: */*
>
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< date: Fri, 20 Jun 2008 04:16:32 GMT
< p3p: CP="NON CUR OTPi OUR NOR UNI"
< server: Microsoft-IIS/6.0
< x-old-content-length: 43
< transfer-encoding: chunked
< x-powered-by: ASP.NET
< x-aspnet-version: 1.1.4322
< cache-control: private
< Set-Cookie: PD-H-SESSION-ID=4_dpeEwDcJaQak23zeDAwtB...; Path=/
<<h1>I am: JKHLE\testuser</h1>* Connection #0 to host server2.jkhle.com left intact
* Closing connection #0
```
也可以在Windows事件查看器的Windows日志 -> 安全下看到Kerberos委派。参见图38 ，重要字段是Logon字段，其中显示用户名，并且通过TFIM进行的委派显示为中转服务。

图38. Windows事件查看器

故障排除

如本文所示，Kerberos联结的环境配置很复杂。如果遵循本文中包含的所有步骤，则正确配置环境应该没有真正的困难。但是，如果确实发生问题，则以下提示可能对解决问题有帮助：

Kerberos令牌使用时间戳来确保不使用旧令牌进行身份验证。如果WebSEAL尝试访问Kerberos联结上的资源并返回错误页面，指出没有可用的令牌，请检查所有机器上的时间戳以确保它们均在合理范围内。理想情况下，应该在环境中使用时间同步服务器。
重新启动WAS-TFIM实例后，即使Windows服务指出服务已启动，服务器也可能需要花费几分钟来准备生成令牌。
检查环境中各种服务器的日志文件。应该特别注意WebSphere Application Server SystemOut.log文件和WebSEAL日志文件。
可以启用Kerberos STS模块的TFIM跟踪，以提供有关Kerberos令牌生成的更多信息。通过标准的WebSphere日志记录机制（通过WAS控制台控制）来管理此跟踪。重要的组件名称是com.tivoli.am.fim.sts.module.KerberosDelegationSTSModule 。参见图39 。

图39.对TFIM Kerberos委派进行故障排除
可以启用TFIM客户端的WebSEAL跟踪，以提供有关WebSEAL尝试从TFIM检索Kerberos令牌的更多信息。通过Tivoli Access Manager跟踪机制（由“ pdadmin服务器任务<server-name> trace”命令控制）来管理此跟踪。重要的跟踪组件是pdweb.sso.tfim 。
确保在webseald-default.conf中列出的服务与清单8中所示的命令列出的服务相对应，并确保已使用正确的委派权限正确配置了TFIM用户。

清单8. setspn -L

C:\Users\Administrator>setspn -L <IIS USERNAME>Result:
Registered ServicePrincipalNames for CN=<IIS USERNAME>,CN=Users,DC=jkhle,DC=com:HTTP/server1.jkhle.com

翻译自: https://www.ibm.com/developerworks/tivoli/library/t-tamwkj/index.html

ibm tivoli