RSS

what is up:在域控上无法使用outlook正常的登陆用户邮箱

19 Mar

这篇问题是原创,回答非原创。感谢卖存储的支持。

问题

dc 2003entr2sp2补丁最新
ex 2007sp1+rollup6

登陆用户为域管理员。分别在dc和exchange以及一台成员机上使用outlook2007登陆aaa用户邮箱,在check name步骤会重复要求输入用户名密码。

参照下面两片进行测试
http://support.microsoft.com/kb/927612
http://support.microsoft.com/kb/956531

只有在使用ntlm验证方式的时候才能进入aaa邮箱。negotiate以及kerberos方式都无法登陆邮箱。

在域控上,无论是以administrator登陆然后新建aaa的profile,或者以aaa登陆,以aaa的profile登陆 都会出现重复要求输入用户名密码。 而在非域控域成员机上,都可以自动pass。
1、在域成员机上,使用outlook2007,自动配置,在check name的时候能成功,用户能进入邮箱。
2、在exchange上,使用outlook2007,自动配置,在check name的时候能成功,用户能进入邮箱。
3、在dc上,使用outlook2007,自动配置,在check name的时候失败。
4、在dc上,使用outlook2007,手动配置,将exchange服务器名写上dc hostname,check name成功,然后反复提示要求输入用户名密码
5、在dc上,使用outlook2007,手动配置,将exchange服务器名写上dc hostname,check name成功,然后提示要求输入用户名密码,忽略输入后,进入more settings选项将验证方式选为ntlm验证,最后确定该配置。重新开启outlook,这是用户可以正确登陆自己的邮箱。
6、重复5的步骤,我发现当验证方式为协商以及kerberos验证方式都会失败,用户无法正确登陆自己的邮箱。

这里的问题可以归结为 协议验证有问题。 ntlm和kerberos还有协商三种认证方式究竟在配置outlook配置的时候,是如何对dc以及exchange进行查询的详细步骤,以便我找到问题发生的root cause?

=======================

套用蔡明小姐的一句话,这是为什么呢?

讲答案之前,请先复习以下几个基础概念。有兴趣的可以去复习下面的老文档我就不再赘述了。
1. DSProxy
2. DS Referal
3. DSAccess
4. NSPI – Name Service Provider Interface

请注意,这部分概念性的基础部件,基本没什么大变化。

老文档:
http://support.microsoft.com/kb/256976/EN-US/
http://technet.microsoft.com/en-us/library/bb123968.aspx
http://technet.microsoft.com/en-us/library/bb124887(EXCHG.65).aspx

要点:
1. 客户端如果使用 Exchange client, Outlook 97, 98等老MAPI客户连接Exchange:
Exchange将会始终使用 DSProxy 部件,将客户端的所有目录请求代理给GC的NSPI.

2. 客户端如果使用 Outlook 2000 SR2以后版本:
第一次配置/生成 outlook profile时,Outlook 客户端需要先通过Exchange服务器上的 DSProxy 部件,把信息proxy给GC的NSPI,进而要求 referral 信息,获取信息后,在客户端的注册表里生成referral的相关信息。以后再打开Outlook时,Outlook会跟据注册表里的信息,直接去联络 GC上的 NSPI,而不再通过 Exchange来做 DSProxy。换言之,如果你在配outlook profile的时候check name总是通不过,那多半原因就是 NSPI连不上(NSPIbind failure)。

然而, Exchange上的DSProxy 部件有一个天生的限制,当outlook 装在DC上时,DSProxy 不能把验证信息proxy去GC的NSPI,从而导致在绑定nspi服务(NSPIBind )的时候,GC返回 access denied 的错误。这里请注意,此处无关 NTLM或者Kerberos, 问题只是 DSProxy造成的。

看到这里,问题就清楚了。我们逐条来看:
1、在域成员机上,使用outlook2007,自动配置,在check name的时候能成功,用户能进入邮箱。

此条无需回答。

2、在exchange上,使用outlook2007,自动配置,在check name的时候能成功,用户能进入邮箱。

此条无需回答。

3、在dc上,使用outlook2007,自动配置,在check name的时候失败。

答案:由于上述原因,无法通过 DSProxy 来绑定 NSPI服务,check name失败。

4、在dc上,使用outlook2007,手动配置,将exchange服务器名写上dc hostname,check name成功,然后反复提示要求输入用户名密码
答案:check name的时候输入 GC名字,outlook将直接去连接该GC的 NSPI端口(local RPC call),而不使用Exchange的 DSProxy,因此 checkname通过。

5、在dc上,使用outlook2007,手动配置,将exchange服务器名写上dc hostname,check name成功,然后提示要求输入用户名密码,忽略输入后,进入more settings选项将验证方式选为ntlm验证,最后确定该配置。重新开启outlook,这是用户可以正确登陆自己的邮箱。

答案:check name的时候输入 GC名字,outlook将直接去连接该GC的 NSPI端口,而不使用Exchange的 DSProxy,因此 checkname通过。因此,在注册表里已经生成了 referral的信息,打开Outlook时,outlook将会直接去访问 GC的 NSPI端口(local RPC call),而不通过 Exchange DSProxy.

6、重复5的步骤,我发现当验证方式为协商以及kerberos验证方式都会失败,用户无法正确登陆自己的邮箱。

答案: 貌似这个问题本身有毛病。 经过我的测试,只要使用GC来通过 check name后,其实无所谓配置kerberos或者NTLM. 都可以登陆。原因是在注册表里已经生成了 referral的信息,打开Outlook时,outlook将会直接去访问 GC的 NSPI端口(local RPC call),而不通过 Exchange DSProxy.

总结,这个故事再次告诉我们,不要在DC上装其他东西,保持一个干净的DC/GC,是对成员服务器性能,功能,以及快速灾难恢复的有力保障。

Advertisements
 
 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: