为Microsoft Dynamics CRM 2011开启Kerberos
授权协议的演进
Windows提供的Challenge/Response(NTLM)授权协议(更多)提供了向后兼容。正如早期最初实施时,验证通过Challenge/Response机制来执行。对于Microsoft Dynamics CRM,这意味着运行Windows的客户机通过发送用户名向应用服务器初始化一个连接。应用服务器会依次反馈一个随机产生的数字用于担任Challenge。客户端计算机会使用用户密码的哈希值来加密Challenge,并返回给服务器端。如果提供给服务器端的用户凭证与域控制器(Domain Controller)维护的信息一致,则用户被授权。
从Internet Information Server(IIS)5.0开始,Microsoft内置了一个更快速、可信和安全的默认安全提供者,Negotiate安全包(更多)。Negotiate安全包可以使用Kerberos(更多)或者NTLM,但它默认使用Kerberos。Kerberos授权最初是由客户端和应用服务器端来处理。这是前两个节点,它们会跳一些“安全舞”(更多),以此来验证是否每个节点都喜欢Kerberos曲调。如果任何一方无法使用Kerberos,授权协议将会默认使用NTLM。
使用Kerberos的好处
相对于NTLM,Kerberos因做了一些关键改进而使其成为更受推崇的授权机制:
- 授权更快且需要较少资源
- 授权是相互的,以至于客户端和服务器端都可以被要求进行授权处理
- Kerberos支持授权代理(这在报表服务器和SQL server服务器分离情况下是很需要的)
- Kerberos是一个开放标准
- Kerberos支持智能卡登录,因此是双因子授权
NTLM和Kerberos差异回顾
授权事件会被安全事件日志系统记录,你可以通过事件查看器(开始,运行,‘eventvwr’)查看。NTLM相关安全事件和Kerberos相关安全事件差异如下对比图所致:
图1.登录流程:NTLmSsp
图2.登录流程:Kerberos
现在来看Kerberos
对于那些无法使用Kerberos授权协议的部署来说,首先看下服务器(IIS安全配置)是否被设置成只支持NTLM,这种情况下你需要按如下教程配置附加授权提供者。如果服务器被设置成使用Negotiate安全包,由于一种或其他原因无法使用Kerberos,请复查配置并识别为什么Kerberos授权失败了。
在开发一个开启Kerberos授权的计划前,请先看下如下三个问题:
- CRM网站已配置的授权提供者是什么?
Kerberos授权仅能在你已配置使用它的IIS服务器运作。确保正确的授权提供者是成功配置Kerberos的第一步。
- CRM网站应用池(application pool)使用的身份(identity)是什么?
Kerberos授权发生在CRM网站应用池凭证之下。让执行授权的身份其作用,首先很重要的是知道目前使用的身份是哪个。
- Kernel模式授权是否开启?
Kernel模式授权是由系统帐号执行的,因此需要特别关注,特别是如果你使用一个服务帐号作为你的应用池的身份。
CRM网站已配置的授权提供者是什么?
Microsoft Dynamics CRM默认安装配置的IIS网站授权供应者是‘Negotiate’。‘Negotiate’供应者首先尝试使用Kerberos,但是如果客户端或者服务器端中一者无法使用Kerberos授权,则它会自动使用NTLM。很多情况下,特别是Microsoft Dynamics CRM部署安装使用默认设置,NTLM授权会被配置。
想识别目前使用的授权协议,执行如下步骤:
1.在IIS管理控制台(开始、运行、inetmgr),在Connections下,展开组织节点,展开Sites,然后点击Microsoft Dynamics CRM。
2.在屏幕中央,在IIS节点,双击Authentication。
3.在Name下,点击Windows Authentication,然后在右边,在Actions控制板中,验证Windows Authentication服务是否开启。
备注:如果Windows Authentication没有开启,在Actions控制板中,点击Enable。
4.在Actions控制板中,点击Providers。
5.在Providers对话框中,在Enabled Providers下,验证Negotiate是否是第一个入口。
备注:如果Negotiate没有出现,从选择框中添加Negotiate提供者,然后点击Add。
重要:提供者按优先级顺序罗列,所以当配置Kerberos时确保Negotiate出现在提供商列表顶部。
提醒下你还可以通过ApplicationHost配置文件来检查IIS网站授权提供者配置,你可以在%SystemDrive%\Windows\System32\inetsrv\config\ApplicationHost.config路径找到。在文件中,找到<location>和path="Microsoft Dynamics CRM"的节点。
在System.webServer\Authentication\windowsAuthentication下,你会发现已配置的服务者列表。注意windowsAuthentication节点事实上有一些附加属性(更多),例如useKernelMode。使用这些附加属性可能需要在某些特定场景下深入分析。
注意:一个很好的从安全视角查看发生了什么的途径是使用网络跟踪工具,它可以监听服务器端和客户端之间的交互。大多数这些网络跟踪工具提供一种过滤已收集的通信信息途径。如果你登录至客户端,开启网络监控工具,然后输入CRM网站地址,你会有一个很好的捕捉全部安全交易的机会。应用Kerberos通信过滤器(通过88端口发送)将会很快显示是否使用Kerberos。
CRM网站应用池(application pool)使用的身份(identity)是什么?
Microsoft Dynamics CRM网站将执行Kerberos流程的身份配置于应用池。因此,应用池的身份需要与正确的服务主体名称(Service Principal Names,SPNs)连接。应用池关联的身份可以是网络服务帐号或者是域用户帐号。
想查看CRM网站应用池使用的身份,执行如下步骤:
1.在IIS管理控制台(开始,运行,inetmgr),在Connections下,展开服务器节点,展开Sites,然后点击Microsoft Dynamics CRM。
2.在右边,Actions控制板中,点击Advanced Settings。
3.在Advanced Settings对话框中,在(General)下,注意Application Pool右边的值(默认情况下应用池名称是‘CRMAppPool’),然后关闭Advanced Settings对话框。
4.在IIS管理控制台中,Connections下,点击Application Pools,然后在控制台中央,选择如3步中提到的应用池入口关联名称,然后在Actions控制板中,点击Advanced Settings。
5.在Advanced Settings对话框中,Process Model下,注意Identity右边的值,这个值表示应用池使用的身份。
注意:所列身份是开启Kerberos的重要变量。一个最佳实践是使用域帐号。指定一个域帐号会对Kerberos配置产生影响,我们会在如下调查中进一步讲述。
Kernel模式授权是否开启?
Internet Information Services(IIS)7.0默认开启Kernel模式授权(更多),Windows Server 2008中,Kernel模式授权使用机器帐号运行。然而,Microsoft Dynamics CRM能够配置使用域帐号运行,所以Kerberos解密服务将会失败,如果Kernel模式授权开启(更多)。
想查看Microsoft Dynamics CRM部署是否使用Kernel模式授权,请执行如下步骤:
1.在IIS管理控制台(开始,运行,inetmgr),Connections下,展开组织节点,展开Sites,然后点击Microsoft Dynamics CRM。
2.在屏幕中央,在IIS节点,双击Authentication。
3.选择Windows Authentication,然后在右边,在Actions控制板,点击Advanced Settings。
4.在Advanced Settings对话框,如果Enable Kernel-mode authentication勾选款被选择(默认情况),然后部署就会使用Kernel模式授权。
注意无论是否开启Kernel-mode授权,Kerberos授权都可以使用。如果Kernel-mode授权被开启,它会强迫IIS使用机器帐号。如果配置使用域帐号,推荐使用执行IIS kernel-mode授权的帐号来使用应用池。
想配置IIS使用应用池帐号,在IIS服务器%SystemDrive%\Windows\System32\inetsrv\config\路径下的服务器文件(ApplicationHost.config)添加一个属性。寻找<location>和path等于“Microsoft
Dynamics CRM”节点,在System.webServer\Authentication下,添加一个“useAppPoolCredentials”属性,并配置值为‘true’。正确添加如下:
<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
你也可以使用appcmd命令行设置参数:
%windir%\system32\inetsrv\appcmd.exe set config-section:windowsAuthentication /useAppPoolCredentials:"True"/commit:apphost
放在一起看
一般来说,Microsoft
Dynamics CRM环境需要使用Kerberos有三种场景:
- CRM网站的应用池身份使用的是网络服务帐号。如果你使用网络服务帐号安装Microsoft Dynamics CRM,你最好开启Kernel-mode授权。总的来说使用所有默认配置会强迫IIS使用机器帐号加密Kerberos令牌并验证之,并默认使用可能在任何一台Windows服务器上的HOST服务主体名称(SPN)。
- CRM网站的应用池身份使用域帐号。如果你使用域帐号,你必须为这个帐号新建服务主体名称(SPN)(更多)。因为需要是你的域控制器(活动目录)找到CRM应用服务池身份(帐号)与SPN相匹配,并且新建为用户新建一个令牌。如果你配置CRM应用池身份为域帐号,并使用已验证的Kerberos,但是你仍然不停提示要求登录Microsoft Dynamics CRM,并且无法被授权访问,这有可能是SPNs缺失或者没有被正确配置。请验证在域帐号中有一个SPN被注册(没有重复)并且SPN被注册在HTTP/netbios,并且HTTP/netbios.fqdn DNS命名与你在浏览器地址栏中看到相关(更多)。如果你的Microsoft Dynamics CRM环境将多个服务部署与多个机器上,例如有一台专门报表服务器和SQL服务器,由于需要代理所以域帐号需要被信任(更多)。
- CRM网站配置成使用Kernel模式授权。如果你开启Kernel-mode授权并且你使用域帐号作为CRM应用池身份,请确认你在ApplicationHost文件中(见上)配置IIS了useAppPoolCredentials。
有一个简单提高Kerberos授权性能的途径。默认情况下,Kerberos需要验证每个HTTP请求。你能够通过保持一个相同的活动的会话来改变这个每次请求都要求验证的行为。这会降低网络堵塞并且占用更少的资源(更多)。
当开启Kerberos授权时,有一个途径来限制阻塞。默认情况下当你使用Kerberos授权协议时,IIS要求客户端为每次HTTP请求重新授权。这一行为会导致网络阻塞的增加。这一行为与IIS 5.0中不同。在IIS
5.0中,在HTTP保持活动的会话中一个初始HTTP保持被授权,客户端始终被Kerberos协议授权。
想开启这一改进,在IIS 7.0的服务器级别设置authPersistNonNTLM属性值为True,执行如下步骤:
- 点击Start,点击Run,输入cmd,然后点击OK。
- 在命令行中输入如下命令,然后点击ENTER:
cd %SystemRoot%\System32\inetsrv appcmd set config /section:windowsAuthentication /authPersistNonNTLM:true
注意:authPersistNonNTLM属性控制Kerberos授权的重新授权需求。默认这个值被设置成False。
重要:如果在开启Kerberos过程中你仍然碰到问题,参考如下blog中提供的问题解决详情Service Principal Name(SPN) checklist for Kerberos authentication with IIS 7.0/7.5.
更多信息
- 常被问道的Kerberos问题的回答
https://support.microsoft.com/kb/266080
- Kerberos 讲解
https://technet.microsoft.com/en-us/library/bb742516.aspx
- Netmon的 关于 Kerberos交互的观点, 在同一个forest的跨域资源访问
- IIS 7.0/7.5下Kerberos授权的服务主要名称(SPN) 检查清单
- Kerberos?Kerberos! ….en CRM ( 关于Kerberos的Dutch blog
https://blogs.microsoft.nl/blogs/stevenvlaanderen/archive/2011/12/30/kerberos-kerberos.aspx
- Dynamics CRM 4.0 Kerberos 配置
https://social.technet.microsoft.com/wiki/contents/articles/6450.aspx
谢谢!
Wilson Lou(娄森伟)
原文地址: