本文内容为Microsoft? Internet Security and Acceleration (ISA) Server 2006如何管理身份验证。内容涉及ISA所支持的身份验证和方式等信息以及如何处理身份验证。
文档内容概括:
· 新的身份验证特性。
· 描述ISA Server 2006中可用的身份验证处理和验证选项。
· 身份验证集合总结表。
最新信息
ISA Server 2006提供下列新的身份验证:
· 单点登陆(SSO)。用户经过 ISA Server
一次身份验证后不需要重新验证便可以访问任何ISA Server 后端的服务器。
· 采用基于表单和客户端证书的
双因素身份验证。
· 基于表单的身份验证支持发布任何Web服务器。
· 可自定义的基于表单验证的表单和用于移动客户端的表单,使用每用户代理的验证机制。
· 用于非浏览器客户端的从基于表单的验证回滚到基本身份验证。
· 使用NTLM或Kerberos验证进行凭据委派。
· Kerberos限制的委派。
· 凭据缓存。
· 密码管理,借此ISA Server可以检查用户帐户的状态并把状态报告给用户。该功能可以配置为让用户可以修改密码。
· SSL客户端证书限制。
· 具备分配不同的数字证书给每个网络适配器上的IP地址的功能。
· 基于表单验证的新类型: 用户名验证码/密码,在此验证码用于ISA Server验证而密码用于验证委派。
· 使用LDAP支持Active Directory?目录服务验证,当ISA Server在工作组环境中或在没有包含用户帐户的森林中时允许Active Directory验证。ISA Server也支持多播配置,这样用户可以在一组不同的LDAP服务器上进行验证 。
· 单次密码支持远程验证拨入用户服务(RADIUS)。在ISA Server 2004中,该支持仅为RSA SecureID提供。
· 默认阻止验证委派。
单点登陆
当点登陆实现用户经过ISA Server一次验证后,可以访问所有ISA在指定侦听器上发布的带有相同后缀名的Web服务器,无需经过重复验证。Web服务器指的是 Microsoft Outlook? Web Access服务器和运行Microsoft Office SharePoint? Portal Server 2003的服务器,以及运行IIS的标准服务器。
单点登陆的典型例子就是登录到OWA的用户提供表单凭据。用所户接收的电子邮件消息可能是连接到存储在SharePoint Portal服务器上文档的链接。用户点击链接,打开文档,并不需要额外的验证请求。这个例子依赖于持续的cookies,见ISA Server帮助。
安全注意项
· 只要用户的浏览器程序仍在运行,表明用户处于登录状态。比如,一位用户登录到OWA。在 IE菜单上,用户打开新的浏览器窗口并转链接到另外一个站点。 关闭OWA窗口并不会关闭会话,而用户仍处于登陆状态。
· 启用单点登陆后,必须提供指定的单点登陆域。提供一个未经注册的域名,比如.co.uk,会导致Web浏览器发送ISA Server单点登陆cookie到该域中的任意Web站点,带来安全风险。
· 在你使用基于表单验证和RSA SecureID创建Web侦听器并启用表单中
收集附加委派凭据的场景中,不论用户给凭据输 入的是名还是不同的名称ISA Server不会激活。
注意
:
|
在不同的Web侦听器之间不提供单点登陆支持。发布的服务器必须共用同一个域名系统后缀。比如,可以在发布mail.fabrikam.com 和team.fabrikam.com时配置单点登陆,而在发布mail.fabrikam.com和 mail.contoso.com时就不可以配置单点登陆。DNS后缀名包括了紧跟第一个点的整个字符串。比如在 mail.detroit.contoso.com和 mail.cleverland.contoso.com两者之间配置单点登陆时,就应该使用DNS后缀名。
|
双因素验证
双因素验证安全性较高,因为它要求用户满足两种验证标准:一个用户名/密码连同令牌环或者证书,就好比
你拥有的即是你所知道的。 在下列场景中,ISA Server 支持双因素身份验证:
· 用户拥有证书。
· 用户拥有SecurID令牌环提供验证码。
· 用户拥有单次密码令牌环提供验证码。
带证书的双因素验证的典型例子就是Smart Card的使用。Smart Card包含了证书,ISA可以在包含用户和证书信息的服务器上验证。按照把用户信息(用户名和密码)及所提供的证书做比较的方式,服务器进行凭据的验 证,而ISA进行用户的验证。
重点
:
|
部署在工作组的ISA Server不支持使用客户端证书的双因素验证。
|
凭据缓存
ISA Server 2006 能缓存基本和基于表单用户凭据,提高了为其他用户凭据进行重验证的性能。采用凭据缓存后,即对于第一个HTTP会话请求ISA Server都会在每个TCP会话中验证凭据,然后缓存验证的凭据。对于后续的HTTP请求,ISA采用将请求的凭据和第一次验证并缓存的凭据对比的形式 做验证。
在Web侦听器属性里启用凭据缓存,默认情况下该功能是禁用的。
活动目录验证支持凭据缓存,通常通过LDAP和RADIUS验证而且仅当客户端使用HTTP基本验证方式或基于表单验证提供凭据。
验证过程
在ISA验证过程当中有三个步骤:
· 接收客户端凭据
· 使用验证器验证客户端凭据,验证器包括Active Directory,RADIUS或SecurID 验证管理器。
· 验证委派给ISA后端的Web服务器,比如运行SharePoint Portal Server 2003的服务器。
注意
:
|
在Web侦听器里配置前两个步骤并可以接收客户端请求。第三个步骤在发布规则上配置。 也即您可以在不同的规则上使用相同的侦听器且可以使用不同类型的委派。
|
下图中说明了基于表单验证的过程。注意这仅仅是个简单的过程描述,说明了主要步骤。
第一步
接收客户端凭据:客户端在Internet网络中发送请求连接到公司OWA服务器。客户端 以HTML形式来提供凭据。
第二步和第三步
发送凭据:ISA发送凭据到验证器,比如用于活动目录验证的域控制器,或者 RADIUS服务器,并接收验证用户的验证器的知识。
第四步
验证委派:
ISA转送客户端请求给OWA服务器,并使用客户端凭据在 OWA服务其上进行自身验证。OWA服务其会再次验证这些凭据,通常都使用相同的验证器。
注意
:
|
Web服务器必须配置为使用匹配ISA所使用的委派方式的验证方式 。
|
第五步
服务器回复:OWA服务器发送回复给客户端,ISA服务器会侦听回复。
第六步
转发回复:ISA转发回复给客户端。
注意
· 如果对访问验证的用户不作限制,在此情况下当允许访问规则适用于所有的用户时,ISA就不会验证用户的凭据了。ISA 会依据配置委派方法使用用户的凭据来验证Web服务器。
· 我们建议把每条发布规则应用到所有经过验证的客户或者指定的用户集,不建议选择
请求所有用户在
Web
侦 听器上进行验证,因为这种方法要求任何用户通过连接侦听器进行验证。
客户端验证方法用于接收客户端凭据
ISA Server的Web侦听器接受以下几种客户端验证:
· 无验证
· 基于表单的验证
· HTTP验证(在HTTP 头中接收)
· 客户端证书验证
无验证
选择要求无验证。采用这种方式,就不可以在使用Web侦听器的规则上配置委派方式。
基于表单的验证
ISA基于表单的验证可用于发布任何Web服务器。ISA中有三种基于表单验证:
·
密码形式。用户在表单上输入用户名和密码,这是活动目录、LDAP和RADIUS凭据验证所需的凭据类型。
·
验证码形式。用户在表单上输入用户名和验证码。该类型凭据适用于SecureID和RADIUS单次密码验证。
·
验证码
/
密码形式。用户输入用户名和验证码以及用户名和密码。用户名和验证码用于采用 SecureID或RADIUS单次密码验证方式的ISA验证,而用户名和密码用于委派。
回滚到基础验证
默认当基于表单的验证不能被指定用户使用时,ISA要求使用基本的验证替代。在ISA Server用户代理映射收集FPCRuleElements.UserAgentMappings的 COM中进行配置。
针对移动客户端的表单
ISA给各种移动客户端提供表单。这些表单在CHTML和XHTML (表示 XHTML-MP 表单)文件夹中,位于
ISA Server Installation Directory\CookieAuthTemplates\ISA。ISA服务器决定所要提供的表 单的类型,类型基于移动客户端提供的用户代理头。
在基于表单验证里的密码管理
使用基于表单的验证时,ISA可以提示用户关于密码即将过期(密码时间期限由管理员配置的),而且允许用户修改他们的密码。这两种功能可以独立 使用也可以联合使用。比如,可以提示用户他们的密码即将过期,但不允许他们修改密码。或者,可以允许他们修改密码,但是不给予密码即将过期的提示。
当允许用户修改密码时,登陆表单会出现该选项并且可用。当配置ISA提示用户密码即将过期,用户接收独立的警告页,在警告页中他们可以选择是否 修改密码。
注意
· 基于表单验证的表单格式可以完全自定义。
· 当ISA配置为需要验证时,由于发布规则适用到指定的用户集或者
所有验证过的用户,或者Web侦听器配置为
要求所有用 户验证,ISA在转发请求之前验证凭据。
· 默认,客户端浏览器语言设置决定了ISA提供的语言格式。ISA提供26种语言。 ISA也可以忽略浏览器语言以指定的语言配置为服务器表单。
安全注意项
· 当配置基于表单验证的超出时间时,我们建议超出时间应该短于发布的服务器强加的超出时间。如果发布的服务器在ISA之前超出时间,用户会误以为会话结束。 这就让攻击者有使用会话的可趁之机,因为会话在用户主动关闭前或者由ISA在表单设置配置时间超出关闭前仍处于打开状态。
· 确保在使用ISA Server发布Web应用程序的设计可防止session riding攻击(也称作垮站点请求,跨占嗲内请求伪造,引诱攻击) ,因为客户端通过ISA防火墙访问Web站点时必须使用相同的信任级别。
· 在采用基于表单验证且要求客户端证书的场景中,用户拒绝提供证书,虽然用户可以访问登陆表单,但是ISA拒绝登陆,因为客户端不存在证书。
· 表单自定义包括可对Strings.txt文件进行修改。如果提供Strings.txt文件到第三方进行修改,验证非文本附加项不会在文件中生效,因为 这些可能会为网络攻击提供机会。
HTTP
验证
该类型的HTTP验证支持:
· 基本验证
· 摘要式和W摘要式验证
· 集成的Windows 验证
基本验证
基本验证方法基于行业标准且使用广泛,主要用于收集用户名和密码信息。基本验证方式以可读的文本文字形式发送和接收用户信息。尽管密码和用户名 经过加密处理,基本验证不采用加密形式
安全事项
:
|
密码通过基本验证传输,安全性不高,在传输过程中可以读取。如果使用基本验证,建议使用SSL来加密数据流。
|
下面的步骤概括了如何使用基本验证来验证客户端:
1. 提示用户输入Windows帐户用户名和密码,也就是所说的凭据。
2. ISA 接收带有凭据的HTTP请求,如果规则需要的话,需要通过指定的验证器验证凭据
3. ISA根据配置的委派方式把凭据依靠传送HTTP请求到Web服务器上的方式进行验证。Web服务器必须配置为使用匹配ISA所使用的委派方式的验证方式 。明文密码在通过网络发送之前使用 Base64编码。
安全事项
:
|
Base64编码不是加密,如果Base64编码密码在网络中被网络嗅探器拦截的话,未授权的用户可以解码并重新使用密码。
|
4. 当ISA确定用户名和密码与有效的Windows用户帐户相关 (Active Directory 或 LDAP) 或者RADIUS帐户,连接开始生效。
基本验证的优势:它是HTTP规范的一部分,而且被几乎所有的HTTP客户端支持。其劣势在:Web浏览器以非加密的形式使用基本验证传输密 码。攻击者和威胁用户利用监控网络通信采用共用的工具来拦截和解码这些密码。因此,通常不推荐使用基本验证,除非网络的安全性绝对可靠,比如专线或者 SSL连接。
摘要式和
W
摘要式验证
HTTP验证包括摘要式验证和新版本的摘要式验证—W摘要式验证 。
摘要式验证
摘要式验证提供了和基本验证相同的特性,不同的是有不同的方式来传输验证凭据:
1. 验证凭据通过单一路径程序,通常叫做哈希算法。这个过程叫做哈希或者消息摘要,并且摘要不能解密—原始的文本不能从哈希值解密。
2. 附加信息也会在处理哈希算法之前加入到密码信息里,因此没有人可以获取密码哈希值来冒充真实用户。
3. 加入的值可以帮助确定用户,用户的计算机和用户登录的域。
4. 加入的时间戳可以阻止用户在密码失效后仍然使用该密码。相对于基本验证,其优势比较明显,因为未授权的用户是无法拦截和使用密码。
摘要式验证依赖于HTTP1.1协议,该协议在Wide Web Consortium (W3C) Web 站点的 RFC 2617明细中定义 。由于摘要式验证需要HTTP1.1的一致性,并不是所有的浏览器都支持。假如当摘要式验证启用后,非HTTP1.1符合浏览器请求文件,由于摘要式验证 不支持客户端,所以请求会遭到决绝.
摘要式验证仅仅在Windows域中可用,摘要式验证仅仅在Microsoft Windows Server? 2003 和 Windows? 2000 Server域帐户中有效,而且可能需要帐户以加密明文的形式存储密码。
重点
:
|
仅仅在域控制器有发出请求的用户存储在活动目里里面的逆向加密(明文)副本的时候,摘要式验证才能成功。为允许密码存储在明文中,需要在活动目 录用户
帐户标签里使用可逆加密设置激活存储密码 。另外,可以设置组策略来启用此功能,做好设置以后,需要设置新的密码来激活改特性,因为旧的密码无效。
|
W
摘要式验证
和常规的摘要式验证不同的是,W摘要式验证不需要以可逆向加密的形式存储密码。ISA 2006 支持W摘要式验证。
使用W摘要式验证,用户和域名是区分大小写的。用户必须准确输入他们存储在活动目录中的的用户名(和域名)。这和摘要式、基本和集成 Windows身份验证都有区别的,因为这些验证仅仅输入的密码需要区分大小写。
当ISA和域控制器都运行Windows Server 2003操作系统时,默认的验证方式是W摘要式。那么当在Windows Server 2003操作系统环境下选择摘要式验证的话,实际上选中的是W摘要式验证。
客户端验证过程
以下步骤概括了客户端如何使用摘要式验证来进行验证。
1. 客户端提出请求。
2. ISA拒绝请求并向客户端询问验证信息
3. 域控制器告知ISA验证结果。
4. 如果客户端通过验证,ISA检查防火墙策略,看情况决定是否接受目标。
集成
Windows
验证
集成Windows验证使用NTLM, Kerberos,和协商验证机制。这些验证机制比较安全,印文用户名和密码在发送到网络中传输之前都会被经过哈希处理。启用 NTLM, Kerberos, 或者协商验证,用户的浏览器通过与Web服务器密码交换证明密码的正确性, 包括哈希算法。
注意
:
|
使用Windows集成验证方式,用户所在域必须一直提供用户名,采用
域名
\
用户名的格式
|
客户端验证程序
以下步骤概括了客户端如何使用集成Windows验证的:
1. 依赖于浏览器配置,刚开始验证可能不会提示用户名和密码.当前的Windows用户信息在客户端计算机上用于验证。
2. 如果验证交换起初确认用户失败,浏览器提示用户输入Windows用户名和密码,过程都是由集成Windows验证来处理的
3. Web浏览器在用户输入有效用户名和密码或者关闭提示对话框之前,都会继续提示用户 。
安全注意项
· 由于用于外部连接的验证都是用NTLM验证,建议ISA和客户端之间的通信都使用SSL加密。每次连接都需要NTLM 验证,而且加密会阻止Internet网上老化的代理设备对连接不合理的重复使用。
· 注意集成Windows验证依赖于活动目录服务器来验证客户端凭据,当有客户端验证请求的时候ISA都会与活动目录服务器通信。因此,建议给活动目录和 ISA创建受保护的网络来阻止用户(内部和外部) 访问通信。
客户端证书验证
在客户端证书验证的情况下,证书往往由客户端提供,ISA依靠该证书来验证客户端。证书可能潜入到智能卡或者证书由移动设备自带,这样移动设备 可以连接到Microsoft ActiveSync?。当客户端证书验证配置好后,需要考虑下面的条件。
一台客户端计算机上安装多个客户端证书
当用户计算机上安装有多个客户端证书时,Web侦听器所选择的客户端验证方法是SSL客户端验证,用户在访问发布的Web服务器时,必须在
选 择数字证书对话框里选择正确的证书。
单点登陆和客户端验证
在两个发布的应用程序之间使用不同的主机名配置好单点登陆后,比方说portal.contoso.com 和owa.contoso.com,而Web侦听器所选择的
客户端验证方式是
SSL
客户端验证方式,这样当用 户从一个发布的Web站点跳到另外一个发不的Web站点时,会有提示用户需要再次选择他们的证书。只要用户在同一个浏览器应用程序进程上打开发布的Web 服务器,会提示用户仅需要提供他们第一次他们选择的证书PIN码。
这个问题不影响共享同一个主机名的发布的Web站点,比如[url]https://public.contoso.com /owa[/url] 和 [url]https://public.contoso.com/portal.[/url]
域成员
仅当ISA计算机或者阵列在域中,那么客户端验证就可用。
验证客户端凭据的方法
可以配置ISA如何验证客户端凭据,ISA支持这些验证中心和协议::
· 无验证(允许内部服务器处理验证)
· Windows Active Directory
· Active Directory采用LDAP协议
· RADIUS
· RADIUS 单次密码
· SecurID
注意
:
|
带有Web侦听器的使用指定的凭据验证形式的发布规则必须使用用户集以保持和验证形式一致性。比如,带侦听器使用LDAP凭据验证的发布规则必 须同时使用包含LDAP用户的用户集,而不能包括活动目录用户。
|
凭条以及客户端凭据验证的配置
可以在Web侦听器上为发布规则配置凭条和客户端凭据验证。
在新的Web侦听其定义向导中,使用
验证设置页,和Web侦听器属性里,适用
验证标签。
重点
:
|
当在一个域里使用相同的Web侦听器发布超过一个应用程序时,在不启用单点登陆的情况下,在一个应用程序里验证过的用户也可以访问其他应用程 序。
|
Windows Active Directory
在Windows Active Directory验证中,用户输入的凭据传输到域控制器,域控制器在活动目录用户列表中检查凭据。客户端因此必须输入域控制器能识别的凭据,可采用以下 格式:
· SAM 帐户名(
域
\
用户名)
· 可分辨名
Active Directory验证仅仅在ISA是域成员的情况下有效 (要么是相同的域或者信任域)。
Active Directory
采用
LDAP
协议
该验证方式和Windows Active Directory验证方式有相同之处。ISA通过LDAP协议(LDAP, LDAPS, LDAP-GC,和LDAPS-GC都支持)连接到LDAP服务器 。注意每个域控制器都是LDAP服务器。LDAP服务器中有活动目录用户凭据的存储。因为每个域控制器仅仅能验证自己域中用户,ISA默认情况下查询森林 全局目录来验证用户凭据 。
客户端必须输入可被活动目录识别的凭据,包括下面几种格式:
· SAM帐户名 (
域
\
用户名
)
· 可分辨名
RADIUS
RADIUS用来提供凭据验证。当ISA作为RADIUS客户端时,它以RADIUS消息的形式发送用户凭据和连接参数信息给RADIUS服务 器。RADIUS服务器验证RADIUS客户端请求,并发送回RADIUS消息回复。
由于 RADIUS服务器除了验证客户端,并验证客户端凭据,ISA所接收的来自RADIUS服务器的回复指示客户端凭据没有通过,可能实际上是指示 RADIUS服务器没有验证客户端。甚至凭据经过验证,ISA可能拒绝客户端请求,基于RADIUS服务器验证策略。
Note:
|
RADIUS用户提供凭据给ISA,凭据必须以
domain\
user格式发送 (而不是
user@
domain).
|
可以配置ISA使用指定的RADIUS服务器,该服务器执行RADIUS用户验证。
RADIUS
验证出站请求
当把IAS作为RADIUS服务器时,确保启用加密验证,即密码验证协议(PAP), 在ISA远程访问策略的拨入属性中。启用IAS用于密码验证协议是每属性IAS设置。所有匹配策略条件的RADIUS客户端可以使用PAP连接到IAS服 务器。
配置
ISA
使用
RADIUS
验证
当在ISA上配置Web侦听器时,选择RADIUS验证作为验证器。添加RADIUS服务器时,必须做以下配置:
·
服务器名。RADIUS服务器主机名或者IP地址。
·
Secret 。RADIUS客户端和RADIUS服务器共享一个机密,这个机密用来加密在他们之间传递的消息。必须在ISA服务器和IAS服务器上配置相同的共用机 密。
·
验证端口。ISA使用UDP协议端口发送验证请求,而RADIUS服务器在侦听此端口。默认情况下把IAS安装成 RADIUS服务器时,1812默认值不需要修改。
注意
:
|
配置ISA用于RADIUS验证时,RADIUS服务器的配置可用于所有使用RADIUS验证的规则或者网络对象。
|
安全考虑因素
RADIUS 用户密码隐藏机制也许在密码方面做得不够安全。RADIUS隐藏机制使用RADIUS共用机密,请求验证器,以及使用MD5哈希算法来加密用户密码和其他 属性,比如隧道加密和MS-CHAP-MPPE-Keys。RFC2865记录潜在需求用于评估威胁环境并决定是否启用额外的安全。
对于隐藏的属性,可以使用IPsec连同Encapsulating Security Payload (ESP)和加密算法(比如Triple DES),提供额外的保护和提供数据机密性用于整个RADIUS消息。按照以下步骤:
· 使用IPsec来提供额外的安全用于RADIUS客户端和服务器。
· 要求使用强密码策略。
· 使用验证计数和帐户锁定来帮助字典查询攻击用户密码。
· 使用长共享机密,字母、数字和标点随机组合。每隔段时间做一次修改,这样可以很好地包括IAS服务器。
· 使用基于密码的验证时,在网络上强制强密码策略,这样字典查询攻击不容易成功。
RADIUS
单次密码
ISA可以使用RADIUS单次密码来验证凭据。单次密码机制通常包括端口服务(物理令牌环)和服务器。服务期和设备都以指定的频率产生新的验 证码。每个设备都有指定的验证码 (不会有两台形同的设备共用相同的验证码)。验证验证码的服务器安装在RADIUS服务器上 并可以连接当前的RADIUS客户端。每个验证码只能使用一次。
用户输入由端口设备提供用户名和验证码,格式由ISA来提供。ISA发送用户名和验证码到RADIUS服务器进行验证。
由于验证码不能第二次使用,ISA不用给每个请求验证凭据。而是,ISA发送cookie给客户端,不用重新验证也可以通信。
在用户多次登陆失败并达到一定次数时,一些RADIUS服务器可以锁住登录。如果恶意用户使用正确的用户名和错误的密码故意多次尝试登陆,那么 用户就会被锁定在系统之外,直到重新设置用户访问。建议在RADIUS单次密码服务器上禁用锁定功能,这样以上的事情就不会发生了。ISA的
每分钟 每
IP
地址
HTTP
请求设置
(在ISA淹没缓解设置属性里配置) 缓解恶意强制密码猜测攻击,所以可以安全地禁用RADIUS锁定功能。
SecurID
ISA 可以使用SecurID 用于凭据验证。来自RSA的SecurID 产品强制要求远程用户必须提供下列条件来访问受保护的资源。
· 个人身份号码 (PIN)
· 物理令牌环产生限时和单次密码
仅PIN或者仅令牌环所产生的单次密码都不能授权孤立访问对方,两者缺一不可。
当用户尝试访问Web页时,受到RSA SecureID的保护,ISA 计算机,代表When a user attempts to access Web pages that are protected by RSA SecurID, the ISA Server computer, on behalf of the server running IIS that it secures, checks for a cookie. This cookie will only be present if the user has authenticated recently, and it is not persistent. If the user's cookie is missing, the user is prompted for a user name and passcode for SecurID. The passcode consists of a combination of the user's PIN and tokencode. The RSA ACE/Agent? on the ISA Server computer passes these credentials to the RSA Authentication Manager? computer for validation. If the credentials are successfully validated, a cookie is delivered to the user's browser for subsequent activity during the session, and the user is granted access to the content.
注意
· 对于SecurID委派,ISA服务器产生cookie与RSA验证代理5.0兼容。 当使用SecureID委派时,必须使用SecureID委派,配置验证代理计算机信任这些cookie。这样做,在验证代理计算机注册,在注册表位置 HKLM\Software\SDTI\RSAAgent添加字符串值
Agent50CompatibleCookies。
· 如果ISA配置多网络适配器并且启用RSA SecureID验证来创建Web侦听器 ,就应该通过ISA连接到做验证处理的RSA验证器明确地配置网络适配器地址,否则,ISA 服务器在做SecureID时会失败。在注册表位置HKEY_LOCAL_MACHINE\SOFTWARE\SDTI\AceClient \PrimaryInterfaceIP指定IP地址,输入字符串值。
· 建议使用SSL来机密客户端和ISA服务器之间的通信。
· RSA验证器安装可以参考 [url]http://www.rsasecurity.com[/url].
· RSA SecurID基于RSA Security Inc.公司的技术。
用于
RSA SecurID
的验证如何起作用
下面的专业术语在这个部分使用:
·
RSA
验证管理器。该计算机保留用户、组、主机和令牌环信息。对于每个用户,RSA验证器保留着用户登录到 的主机名单和登录名,这些登录名可已把主机区分开来。
·
RSA ACE/
代理
。该计算机提供Web内容( ISA计算机或者阵列), 并且请求用户提供凭据用于RSA SecureID。
·
客户端。通常,它指的是接收Web内容的Web浏览器。
客户端发送GET /x 请求到ISA时,下列的程序出现:
1. ISA 服务器用于基于表单验证(基于表单的过滤器)的Web过滤器阻断请求,并返回RSA SecureID验证表单给客户端。
2. 要求客户端填写表单,包括登录名和验证码。另外,还要求客户端提供凭据用做委派。
3. 浏览器使用HTTP Post方式来返回表单给Web过滤器。
4. 基于表单的验证过滤器传送这些详细信息给RSA验证器,以确定用户可以使用ISA计算机被允许访问。如果答案是否定的,Web过滤器返回回复给客户端,回 复消息包括Set-Cookie。
5. Set-Cookie 头写入cookie到浏览器内存。Cookie包括用户信息,该信息带有仅仅ISA能识别的机密。那么cookie不能被其他用户修改。
6. 回复包括刷新头,刷新头可以指导重新发送原始的GET/x请求给服务器。
7. 当Web过滤器接收带有cookie的请求后,它通过检查下面几项来确定cookie是有效的:
· 过期时间
· IP address (如果有指定的话)
· 签名(保证数据不会被修改)
验证委派
验证凭据以后,可以配置发布规则来使用下面方式之一委派凭据给发布的服务器:
· 无委派,但是客户端需要直接验证
· 无委派,但是客户端不能直接验证
· 基本的
· NTLM
· NTLM/Kerberos(协商的)
· SecureID
· Kerberos约束委派
配置验证委派
在发布规则上委派客户端凭据。在发布规则向导中,在
验证委派页面配置该功能。在发布规则属性中,验证设置在
验证委派标 签中。
无委派,但是客户端不能直接验证
这是ISA2006新增的功能,在此功能下,凭据不会被委派。这样做的目的在于有人进行嗅探时阻止无意委派凭据到公司。这是ISA发布向导的默 认设置,所以如果需要委派凭据的话,必须修改默认设置。
无委派,但是客户端可以直接验证
选择委派方式为
无委派,但是客户端可以直接验证,无需在ISA上进行额外的操作用户凭据就可以传送到目标服务器上。然后客户端和 目标服务器协商验证。
基本的
在基本的委派中,凭据以明文形式转发到请求凭据的服务器上。如果验证失败,ISA服务器使用由Web侦听器使用的验证进行委派替换 。如果服务器需要不同来型的凭据,ISA便会触发警报。
NTLM
在NTLM验证中,ISA使用NTLM挑战/应答式验证协议来委派凭据。如果验证失败,ISA使用由Web侦听器使用的验证类型进行委派替换。 如果服务器要求不同类型的凭据,ISA会触发警报。
NTLM/Kerberos
(协商式)
选择协商式委派方式,ISA首先尝试从域控制器上为客户端获得Kerberos票据。如果ISA不接收Kerberos票据,它就会采取协商的 方式使用NTLM来委派凭据。如果ISA接收Kerberos票据,它就会采取协商的方式使用Kerberos进行委派验证。如果验证失败,ISA提供服 务器失败通知给客户端。如果服务器需要不同类型的凭据,ISA便会触发警报。
用来获取票据的默认服务规则名(SPN)是http/
internalsitename。在服务器场的情况下,SPN就是场名。 默认的SPN可以在ISA管理规则中
验证委派标签里修改。
注意
:
|
在Microsoft Exchange Server 2003里,IIS在网络服务帐户下运行。ISA使用通配符 SPN HTTP\*,使用已发布的站点的主机名取代星号。
|
SecurID
客户端提供SecurID凭据时,可以使用SecurID 验证委派。ISA传递专用SecureID cookie到发布的服务器里。注意ISA和发布的服务器必须拥有同样的域机密和cookie名。
Kerberos
约束委派
ISA 2006引进了Kerberos约束委派,详见 Kerberos Protocol Transition and Constrained Delegation。如果没有Kerberos 约束委派,ISA仅仅在客户端使用基本或者基于表单验证方式的时候委派凭据。有了Kerberos约束委派,ISA可以接受其他类型的客户端凭据,比如客 户端证书。在域控上必须启用ISA使用Kerberos约束委派 (约束为指定的服务规则名)。
如果验证失败,ISA服务器提供服务器失败通知给客户端。如果服务器要求不同类型的凭据,ISA便会触发警报。
注意
· 使用Kerberos约束委派要求配置为AD将ISA看作信任的委派对象。
· 获取票据的默认的SPN是 http/
internalsitename。在服务器场的情况下,SPN就是场名。默认的可以 在ISA管理规则的
验证委派标签上修改。
· 要使用Kerberos约束委派,域必须运行在Windows Server 2003域功能级别下。
· Kerberos验证依赖于通常为片段的UDP包。如果ISA计算机或者阵列(企业版)在域环境下,并启用阻止IP片断,Kerberos验证便会失败。 比如,在用户登录时,如果计算机使用Kerberos 用于验证,不会登陆成功。建议在使用Kerberos验证的场景下不要启用阻止包含IP片断的包。
· SharePoint Portal Server 2003默认情况下饮用Kerberos ,因此NTLM/Kerberos (协商式)和Kerberos 约束委派在SharePoint发布时不起作用。如何启用Kerberos, 参考 Microsoft Help and Support。
· 在Microsoft Exchange Server 2003环境下, IIS运行在网络服务帐户下面,而且 ISA 使用通配符SPN HTTP\*,并使用发布的站点主机名取代星号。
客户端凭据和委派方式的有效组合
并不是每个委派方式在特定的客户端凭据里都有效。下表总结了有效的组合。
接收客户端凭据
|
验证器
|
委派
|
基于表单的验证(仅仅是密码)
基本的
|
Active Directory (Windows)
Active Directory (LDAP)
RADIUS
|
无委派,但是客户端需要直接验证
无委派,但是客户端不能直接验证
基本的
NTLM
协商的
Kerberos约束委派
|
摘要式
集成的
|
Active Directory (Windows)
|
无委派,但是客户端需要直接验证
无委派,但是客户端不能直接验证
Kerberos 约束委派
|
带验证码的基于表单的验证
|
SecurID
RADIUS 单次密码
|
无委派,但是客户端需要直接验证
无委派,但是客户端不能直接验证
SecurID
Kerberos 约束委派
|
基于表单的验证(验证码和密码)
|
SecurID
RADIUS单次密码
|
无委派,但是客户端需要直接验证
无委派,但是客户端不能直接验证
基本的
NTLM
协商的
SecurID
|
客户端证书
|
Active Directory (Windows)
|
无委派,但是客户端需要直接验证
无委派,但是客户端不能直接验证
Kerberos约束委派
|