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序列
![SSO序列](https://i-blog.csdnimg.cn/blog_migrate/167bc3c970a6adffb58804d0a09c725a.png)
本文分步详细介绍了针对Kerberos单点登录(SSO)的典型客户用户环境的配置。 该环境在IBMWebSphere®集群环境中部署TFIM,但是如果TFIM在独立的WebSphere Application Server(WAS)中运行,则本文的大部分内容也适用。 图2描述了环境的体系结构,本文通篇引用了该体系结构。
图2.环境概述
![环境概况](https://i-blog.csdnimg.cn/blog_migrate/207be6cb8a66d5f109063f222662259d.png)
本文不介绍整个环境的配置。 特别是,它假定以下实体的配置已经完成:
- 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
为了使受约束的委派正确运行,目标服务(即IIS)必须以Active Directory(AD)用户身份运行,该用户具有已分配的服务主体名称(SPN),并且配置为作为Kerberos服务运行。 要以AD用户身份运行IIS,请完成以下步骤:
- 创建并初始化AD用户:
- 在域控制器上,从“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” 。 创建一个密码永不过期的新用户。
图3. IIS用户创建
- 在域控制器上,准备新用户,使其可以作为Kerberos服务执行。 这是使用ktpass命令行实用程序完成的,该实用程序作为Windows支持工具的一部分提供。 一旦为用户设置了SPN,登录名也将更改为反映SPN。 清单1中显示了ktpass的语法。
清单1. ktpass命令
图4显示了示例命令及其输出。ktpass -princ HTTP/<IIS Server Name>.<DNS domain name>@<AD DOMAIN NAME> \ -mapuser <IIS User Name> -mapOp set
图4.设置用户SPN
- Windows Server 2003 / IIS 6.0:在IIS系统上,必须使AD用户成为本地IIS_WPG组的成员。 为此,请从“开始”菜单的“管理工具”部分中选择“ 计算机管理” ,或者如果计算机是域控制器,请选择“ Active Directory用户和组”,然后在“ 内置用户”列表下找到IIS_WPG组,然后将新的AD用户添加到这个小组。
图5. IIS_WPG组
图6. IIS_IUSRS组
- 在域控制器上,从“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” 。 创建一个密码永不过期的新用户。
- 默认情况下,计算机的安全策略将不允许AD用户执行本地服务。 这需要更改,以便允许新的AD用户将IIS作为服务执行。 从“开始”菜单的“管理工具”部分中选择“ 本地安全策略 ” ,然后扩展“作为服务登录”本地策略以包括新的AD用户。
图7.安全策略
- 配置IIS应用程序池以AD用户身份执行:
- 在IIS系统上,使用IIS管理器更改用于执行请求的身份。
注意:使用后端Web应用程序需要IIS以外的其他特定特权时,请在更改IIS服务用户帐户时参考您的产品文档。 Microsoft Office SharePoint是一个这样的示例,建议通过SharePoint管理中心控制台修改服务用户。
在Windows Server 2003 / IIS 6.0上:通过编辑目标应用程序池的属性来执行此操作。图8. IIS 6.0应用程序池标识
图9. IIS 7.0应用程序池标识
- 在IIS系统上,使用IIS管理器来回收目标应用程序池,以便在上一步中所做的更改生效。
在Windows Server 2003 / IIS 6.0上:可以通过“右键单击”应用程序池来完成, 如图10所示 。图10. IIS 6.0回收IIS应用程序池
图11. IIS 7.0回收IIS应用程序池
- 在IIS系统上,使用IIS管理器更改用于执行请求的身份。
- 打开Web浏览器并访问Web服务器,以确保其仍然正常运行。 还应检查Windows任务管理器中可用的进程列表,以确保每个适用的w3wp.exe进程都以新创建的AD用户身份执行, 如图12所示。
图12. IIS验证
如果您在带有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用户配置
承载Tivoli Federated Identity Manager运行时的WebSphere节点代理程序需要在Active Directory中的特殊帐户下运行。 这是必需的,以便可以授予它权限以获取其他用户的Kerberos票证和一组受限制的目标。 在Kerberos委托信任链可以工作之前,您需要创建帐户,设置适当的选项并修改WebSphere服务以使用该帐户。 以下说明描述了如何完成此任务。
- 在域控制器上,确保将域功能级别设置为Windows Server 2003 。 为了使Windows Kerberos约束委派起作用,必须执行此步骤。 从“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” ,然后右键单击域并选择“ 属性”以查看域控制器正在运行的级别,此屏幕的示例如图16所示。 如果此版本早于2003,则Kerberos约束委派将不起作用。 要升级,请右键单击域,然后选择“ 提升域功能级别” 。
图16.域功能级别
- 创建并初始化AD用户:
- 在域控制器上,从“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” 。 创建一个配置了永不过期的密码的新用户。
图17. TFIM用户创建
- 在域控制器上,为新的AD用户设置SPN。 这是使用setspn命令行实用程序完成的,该实用程序作为Windows支持工具的一部分提供。 清单3中显示了setpn的语法。
清单3. setspn命令
图18显示了示例命令及其输出。setspn -A tfim/<tfim user> <tfim user>
图18.设置用户SPN
- 在TFIM服务器上(或在每个服务器上,如果它们是群集的一部分),使AD TFIM用户成为本地Administrators组的成员。 通过从“开始”菜单的“管理工具”部分中选择“ 计算机管理”来执行此操作。 定位下本地用户和组 管理员组- > 组 ,然后将新的AD用户添加到该组中所示图19 。
注意:一些指南建议用户应该是Domain Admins组的成员,只要TFIM用户是本地计算机管理员,则不需要这样做。图19.管理员组
- 还必须修改AD用户,以便可以信任它委派IIS服务。 为此,请从域控制器上“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” 。 打开新的AD用户的属性,选择“ 委托”选项卡,然后启用对本文图4中创建的IIS用户的委托。
注意:搜索服务时,请确保按IIS用户名而不是服务器主机名进行搜索,然后选择“完全大写”中显示的HTTP服务。 完成后,TFIM用户的Properties-Delete选项卡应类似于图20所示。图20.委托权限
- 还必须将AD用户添加到Windows授权访问组对象。 从域控制器上“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” 。 选择Builtin对象,然后修改Windows Authorization Access Groups对象的属性,使新的AD用户成为该组的成员, 如图21所示。
图21. Windows授权访问组
- 默认情况下,计算机的安全策略将不允许AD用户执行本地服务。 更改此设置,以便允许新的AD用户将WebSphere作为服务执行。 通过从“开始”菜单的“管理工具”部分中选择“ 本地安全策略” ,更新WAS服务器上的策略 。 需要修改“作为服务登录”本地策略,以包括新的AD用户。 对于集群环境,必须在承载运行Tivoli Federated Identity Manager运行时的节点成员的所有机器上重复此步骤。 图22中显示了一个示例。
图22. TFIM用户-作为服务登录
- 还需要向新的AD用户授予WAS服务器上的权限,以充当操作系统的一部分。 通过从“开始”菜单的“管理工具”部分中选择“ 本地安全策略”来更新策略。 用户权限分配条目的“充当操作系统的一部分”本地策略需要扩展,以包括新的AD用户。 对于集群环境,必须在承载运行Tivoli Federated Identity Manager运行时的节点成员的所有机器上重复此步骤。 图23中显示了一个示例。
图23. TFIM用户-充当操作系统的一部分
- 在域控制器上,从“开始”菜单的“管理工具”部分中选择“ Active Directory用户和计算机” 。 创建一个配置了永不过期的密码的新用户。
- 然后必须将WebSphere节点代理服务配置为在上面创建的AD主体下作为进程运行。 必须在承载运行Tivoli Federated Identity Manager运行时的节点成员的所有机器上重复以下步骤。
- 通过执行位于WebSphere bin目录中的wasservice命令,使WebSphere进程能够作为Windows服务运行。 示例命令及其输出如图24所示。
注意:这可能是在安装过程中运行的,并且只有在该服务未在操作系统的“服务”窗格中列出(如下一步所示)时才有必要。图24.启用WAS服务
- 需要修改WebSphere节点代理服务以作为新的TFIM AD用户运行。 这可以通过“ 服务”控制面板(可从“开始”菜单的“管理工具”部分获得)并修改IBM WebSphere Application Server服务的属性来实现。 运行时使用的用户名位于“ 登录”选项卡上, 图25中显示了一个示例
图25. WAS服务用户
- 如果WebSphere在此阶段运行,则必须重新启动它以反映对Service属性的更改。 这可以通过执行位于WebSphere bin目录中的stopnode和startnode命令来实现。 这些命令的示例及其输出如图26所示。
图26. WAS节点重启
- 通过执行位于WebSphere bin目录中的wasservice命令,使WebSphere进程能够作为Windows服务运行。 示例命令及其输出如图24所示。
- 检查以确保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.信任链
![信任链](https://i-blog.csdnimg.cn/blog_migrate/1e4759e2393b19695d3b67f28e449e48.png)
- 通过调用WebSphere控制台上的“创建”向导来创建Kerberos委托STS模块的实例:
- 选择Tivoli Federated Identity Manager来展开它。
- 然后选择“ 配置信任服务”以将其展开。
- 然后选择“ 模块实例” 。
- 在显示的“模块实例”页面上,单击“ 创建”按钮。
图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控制台上的“创建”向导来创建信任链:
- 选择Tivoli Federated Identity Manager来展开它。
- 然后选择“ 配置信任服务”以将其展开。
- 然后选择“ 信任服务链” 。
- 在显示的“信任服务链”页面上,单击“ 创建”按钮。
注意:在创建信任链期间,将显示警告,指出模块链不符合建议的链结构。 忽略此警告并继续创建信任链是安全的。
在向导的第一页上,阅读“ 简介”后单击“下一步” 。
图32显示了向导的第二页,其中要求我们命名和描述我们的信任链。 将此链命名为WebSEAL Kerberos Junction,并提供与Trust链类似的描述, 以为WebSEAL Kerberos Junction生成令牌 。 点击下一步。图32.信任链向导页面2
向导第三页上的重要字段, 如图33所示:- 与WebSEAL “适用于”配置条目相对应的“适用于 地址”字段。 在此示例中,这对应于结的完整路径。 如果您在同一台计算机上有多个联结,则可以在此处使用通配符'*'。
- 与WebSEAL “服务名称”配置条目相对应的“ AppliesTo服务名称”字段。 从WebSEAL发送的RST中包含的服务名称将与“服务名称”字段的第二部分匹配(即,在冒号之后出现的部分)。 在上面给出的示例中,已为“服务名称”的两个部分提供了“ *”字符,以便所有具有相同地址的请求都将匹配。
- “发行人地址”应始终设置为“ amwebrte-sts-client” 。
图33.信任链向导页面3
完成第四页图34与向导的第2页类似。图34.信任链向导页面4
在第5页上,我们为信任链组装了两个模块。- 首先在验证模式下添加默认的IVCred令牌模块。
- 其次,添加我们之前在发布模式下创建的Kerberos令牌模块。
图35.信任链向导页面5
在“ IVCred模块配置”页面上,不需要任何选项, 如图36所示。图36.信任链向导页面6
在“ Kerberos委派模块”配置页面上,选择选项“ 将计算机DNS域作为后缀添加到用户名” ,如图37所示。图37.信任链向导页面7
在最后一页上查看配置,然后单击“完成”以创建TFIM Kerberos委派信任链。
将配置更改加载到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/RequestSecurityToken
Result:
<?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/z3pi90VY6570BNi1
kTyP+3e6Cp7yOpOdqmtNKIZJYkAUWfQ1eaS+B0n9OJgbi5lyNAc1dgDlgI+X2C
a7hi4FkXl2x5b/esLl+wVLBFoLgN12XP2oG3UVf2sPEozxlfSn0oiiPcZ488tm
GuzOetyQ2p9c2CXL+JgWbR5elPzoLP9LYVpppQlJ9yxw/8IK429ylzRFR8kPuE
IHjuBdKpvBBpn7y78xeeRnXg9ydQjVbHIcjmr+ArMrY7fkCrNvcYVQhq7p5CbB
SOmSuFw0/z3pi90VY6570BNi1U5f4cTb+Va3DLJZTDyEHUwdeDKk4VlgT4zjjl
oBL1SkzIBSnNsny7FWH/sS75TmUv8FUoYGvlPpXqEPAC2hAT43yzdJ8VsN5vlq
YbUtXjYPWs27wpMrUHohA7LpuzO7lZ1DJ0OVL9uedsv3+OUWcMDovuPXYFUmpA
Y0lNCNo2sotS3IurJ1X5cU28ACrkr8yX2uBVv3ri0nFV6Z/Q0jptheQBleI2d1
+CK9pYJNkPM8aGFnqRG45hUxx9nfMdLQ7lY6L1y7vM3ne31E47PpGjG0ulZLXX
EXn6pEuvBDoeCWlWN8VKCCVm5wEM4kD4ny92gn9czJjIY4z6hzia5Ct45vMmEz
4ZpF7KdnciLX52eVPQvS+grSdMIRtbC/4yp9nWokzP5+pjxR8pmFRXjCpUQ4dQ
6xnQX3jgPuYEdDi4rUAHWBI2vCo+7e82xTUCNbXTbdEEM/LsixzOWwBna/I10K
13sdKk8shL7ybhSXyyRS0z17SiXdLqTyChhPzYz1Y/uEt6mynZo+qRKRuNPTiy
...
4mDLqM59vj4DwGWfxj6nZOCAKzweVGA8Tfm+OSCtbBdLQ7lY6L1y7vM3dLQ7lY
ocAAeDdzeFRhHIYWmdc1bFDTMZEIhJGE17ScLw==
</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 /iis pdadmin sec_master> server task default-webseald-server2.jkhle.com show /iis Junction point: /iis Type: TCP Junction hard limit: 0 - using global value Junction soft limit: 0 - using global value Active worker threads: 0 Basic authentication mode: filter Forms based SSO: disabled TFIM junction SSO: yes Authentication HTTP header: do not insert Remote Address HTTP header: do not insert Stateful junction: no Boolean Rule Header: no Scripting support: no Preserve cookie names: no Cookie names include path: no Transparent Path junction: no Delegation support: no Mutually authenticated: no Insert WebSphere LTPA cookies: no Insert WebSEAL session cookies: no Request Encoding: UTF-8, URI Encoded Server 1: ID: 98fa4d16-3e73-11dd-b339-000c2944bd3b Server State: running Operational State: Online Hostname: server1.jkhle.com Port: 80 Virtual hostname: server1.jkhle.com Server DN: local IP address: Query_contents URL: /cgi-bin/query_contents Query-contents: unknown Case insensitive URLs: no Allow Windows-style URLs: yes Current requests : 0 Total requests : 25
- 最后,可以测试新的Kerberos联结。 为了测试本文中记录的环境,对IIS配置进行了以下更改:
- 使用IIS管理控制台启用了Windows集成身份验证。
- 修改了IIS站点,以启用身份模拟。
- 编写了一个简单的whoami.aspx脚本,该脚本在响应中包含身份。 此脚本使用“ <%Response.Write(System.Security.Principal.WindowsIdentity.GetCurrent()。Name)%> ”获得身份。
清单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