工程师手记－关于KDC证书、10006事件以及userenv日志文件的问题

微软工程师手记，里面对问题的发现，分析判断，解决都有可参考之处，好文不独享，很早以前看过，最近为了找漫游用户配置的一些资料，一直找不到，昨晚终于挖出来了。

关于作者

陈英丽，微软技术支持工程师，长期从事微软系统平台、数据库、服务器迁移的技术支持工作，为企业客户提供产品部署咨询、疑难解答和故障排除服务。技术专长：Windows NT 4.0到Windows Server 2003的升级与迁移。

您可以通过[e-mail]与她联系。

工程师的话：

我作为微软的技术工程师，时常会遇到各种各样的问题，也需要不断学习新的知识，积累经验。有些问题的确不好解决，需要做长时间的查询、研究以及反复的测试。下面，我和大家分享三个疑难问题的经验。

案例1：KDC证书失效

作为网络管理员来说，经常查看系统和应用程序日志是你的日常工作。如果在系统和应用程序日志中发现错误怎么办？一般来说，我们会看日志中的详细信息。有的日志提供了详细信息可以使你一目了然地知道这个错误是由何程序及何原因引起的；但是我们也看到很多日志中没有详细的信息或者信息描述非常模糊，这样就需要花大量的时间做研究，来判断这个错误或警告是否很紧要或者是可以忽略的。

最近遇到了好几起事件号为20的警告，花了不少时间终于找到了最终问题，希望对大家有所帮助。

有好几个用户都说他们在系统日志中找到了这样的警告信息：

日志类型: 警告

事件源: KDC

事件类型: 无

事件ID: 20

日期: 9/13/2005

时间: 9:15:18 AM

用户: N/A

计算机: 计算机名

描述：当前所选的KDC证书曾经有效，但是现在无效，而且没有发现合适的替代证书。如果不解决这一问题，智能卡可能工作不正常。请求系统管理员检查域公钥结构的状态。链状态在错误数据中。

你可以在以下微软知识库文章中找到一模一样的日志描述：

如何排除RPC终结点映射程序错误

http://support.microsoft.com/kb/839880/zh-cn

但是否这篇文章就能解决这个问题呢？我也曾经查到过这篇文章，但我怎么看也与这篇文章描述的问题不像。一般这个问题是发生在安装了证书服务的域控制器上，我和客户确认了一下看看他们是否安装了证书，但是两个用户都回答没有。这就有点奇怪了。因为按照这个事件的描述“当前所选的KDC证书曾经有效，但是现在无效，而且没有发现合适的替代证书”，描述指出在当前的这台机器上有一张KDC的证书。那么有人就要问KDC证书究竟是什么证书呢？其实一般的域控制器就是KDC服务器，用来颁发kerbose验证时所需要的证书，所以KDC就是域控制器的计算机证书。很多人认为一台计算机装上AD成为域控制器以后，就应该自动生成KDC证书，为了验证这一点，我重新安装了一台新的计算机并把它提升为域控制器，用以下步骤来检验计算机证书：

1． 单击开始，然后单击运行。

2． 键入“MMC”（不带引号）并单击确定。

3． 在新创建的MMC中单击控制台，然后单击添加/删除管理单元。

4． 在新出现的窗口中，单击添加。

5． 突出显示证书，单击添加。

6． 选择计算机帐户选项并单击下一步。

7． 在下一屏幕上选择本地计算机，单击确定，单击关闭，然后单击确定。

展开证书->个人－>证书，却没有发现有任何证书，这说明一台安装AD的域控并没有KDC证书。那么现在我们来安装证书服务使这台计算机成为CA：打开控制面板*“添加或删除程序”*“Windows组件”，选择“证书”。

具体步骤可以看这里:

在中小型公司建立企业根证书颁发机构（CA）

http://www.microsoft.com/china/smallbusiness/issues/sgc/articles/build_ent_root_ca.mspx

然后打开MMC，可以看到计算机有一张KDC的证书（你可能需要刷新一下才能看到该证书）。这么看来，只有装过CA以后，CA才会给当前的域控制器颁发一张证书，并且这张证书的有效期是5年。根据客户的描述，他们当前的计算机上没有CA，那么我现在需要是和他们确认两个问题：

1． 当前的KDC证书是不是有效的。

2． 在当前域控制器上，是否以前装过CA，后来又卸载了呢？

客户的答复是：

1． KDC证书是有效的。

2． 的确安装过CA，后来卸载了。

在这种情况下，我查到几乎所有微软内部资料都提到了在命令行中运行如下命令：

"certutil - dcinfo deleteBad"

Certutil.exe是在Windows Server 2003家族产品中安装为“证书服务”一部分的命令行程序。可使用Certutil.exe转存并显示证书颁发机构（CA）配置信息，配置“证书服务”，备份和恢复CA组件，还可验证证书、密钥对和证书链。“certutil - dcinfo deleteBad” 这条命令是用来删除旧的域控制器证书。

关于Certutil命令的详细信息，可以查看以下两篇文档：

Certutil命令

http://www.microsoft.com/technet/prodtechnol/Windowsserver2003/zh-chs/library/ServerHelp/a3d5dbb9-1bf6-42da-a13b-2b220b11b6fe.mspx

Windows Server 2003 PKI 操作指南

http://www.microsoft.com/china/technet/prodtechnol/Windowsserver2003/technologies/security/ws03pkog.mspx

所以我让客户在他们的计算机上也运行这条命令，得到了如下的结果：

0: RKS_AS

1: DOGHS_FS

*** Testing DC[0]: RKS_AS

** Enterprise Root Certificates for DC RKS_AS

Certificate 0:

Serial Number: 073eaec8969bf5a24665c9a8ecf8e6bb

Issuer: CN=RKS LOCAL CA

Subject: CN=RKS LOCAL CA

Certificate Template Name: CA

CA Version: V0.0

Signature matches Public Key

Root Certificate: Subject matches Issuer

Template: CA, Root Certification Authority

Cert Hash（sha1）: d4 ac 12 29 44 6b f2 6b e0 67 b3 9d ca e3 43 33 f2 2b f2 2c

** KDC Certificates for DC RKS_AS

0 KDC certs for RKS_AS

No KDC Certificate in MY store

KDC certificates: Cannot find object or property. 0x80092004 （-2146885628）

*** Testing DC[1]: DOGHS_FS

** Enterprise Root Certificates for DC DOGHS_FS

Certificate 0:

Serial Number: 073eaec8969bf5a24665c9a8ecf8e6bb

Issuer: CN=RKS LOCAL CA

Subject: CN=RKS LOCAL CA

Certificate Template Name: CA

CA Version: V0.0

Signature matches Public Key

Root Certificate: Subject matches Issuer

Template: CA, Root Certification Authority

Cert Hash（sha1）: d4 ac 12 29 44 6b f2 6b e0 67 b3 9d ca e3 43 33 f2 2b f2 2c

** KDC Certificates for DC DOGHS_FS

0 KDC certs for DOGHS_FS

No KDC Certificate in MY store

KDC certificates: Cannot find object or property. 0x80092004 （-2146885628）

CertUtil: -DCInfo command FAILED: 0x80092004 （-2146885628）

CertUtil: Cannot find object or property.

咋一看，这输出结果很长，不知道该如何分析，我们来仔细的看以下重要信息：

0: RKS_AS

1: DOGHS_FS

表示当前有两台服务器，一台叫RKS_AS，另一台叫DOGHS_FS。看清楚了这点，你再看以上的输入，至少可以分清楚，这些输出是先输出了RKS_AS服务器的检测结果（从*** Testing DC[0]: RKS_AS开始），再输出了对DOGHS_FS服务器的检测结果（从** KDC Certificates for DC DOGHS_FS开始就是在描述DOGHS_FS服务器）。

那么我们接着来看对RKS_AS测试：

*** Testing DC[0]: RKS_AS

** Enterprise Root Certificates for DC RKS_AS ->RKS_AS的企业根证书

Certificate 0: ->证书0

Serial Number: 073eaec8969bf5a24665c9a8ecf8e6bb ->证书序号

Issuer: CN=RKS LOCAL CA ->证书颁布者

Subject: CN=RKS LOCAL CA ->主题

Certificate Template Name: CA ->模板

CA Version: V0.0 ->版本

…………

** KDC Certificates for DC RKS_AS ->检测RKS_AS的KDC证书

0 KDC certs for RKS_AS ->没有KDC证书

No KDC Certificate in MY store

KDC certificates: Cannot find object or property. 0x80092004 （-2146885628） ->返回一个错误号

通过对这段输出信息的分析，我们看到的事实是：在这台域控制器上KDC证书其实并不存在，却有一张根CA的证书。那么事件20的描述其实不完全正确。当计算机启动的时候，发现了一张根CA的证书，其实CA服务已经从这台计算机上删除了，所以系统日志中才报了这样的一个错误。看到这里，你们是不是可以预料到最后的解决方法呢？就是在证书服务的微软管理控制台中，将这张根CA的证书删除。要注意的是，你在删除之前最好做个证书备份，以免出现了误删除而导致无法恢复证书的情况。删除证书之前，打开证书的属性，看一下证书的序列号是否和刚才命令中输入的序列号相符合，在这个例子中，证书的序列号为d4 ac 12 29 44 6b f2 6b e0 67 b3 9d ca e3 43 33 f2 2b f2 2c。

通过这样的一个例子，我想总结一下这类系统日志是如何进行故障排除的：仔细查看事件日志的描述信息，判断它是和证书相关的。

查到微软技术文章以后，一定要看清楚是否和当前的问题相符合，不要盲目行动。

案例2：程序事件日志10006

刚才讲了系统警告20，现在来举个相对简单的例子——程序日志10006。

有个客户说打印有问题，服务器的性能也变差了。把系统MPSreport拿过来看（MPSrepor是最常用的用来收集客户信息的工具），检查系统日志和程序日志，发现了应用程序日志中有大量的DCOM错误，错误如下：

日志类型: 错误

事件源: DCOM

事件类型: 无

事件 ID: 10006

日期: 10/11/2005

时间: 8:39:04 AM

用户: N/A

计算机: 计算机名

描述:

当激活服务器时， 在计算机XXX上发现了一个DCOM 错误： “类未注册”

{5A5AA0AA-1DEB-4683-96B0-B43301E83971}

有了上个例子的经验，这个问题解决起来容易多了。我们来仔细看这个事件的错误，首先判断事件源是DCOM，仔细看事件的描述是类未注册，那么下面出现的这一串东西是什么呢？

{5A5AA0AA-1DEB-4683-96B0-B43301E83971}

其实这是类名或叫组件名。这样看来，{5A5AA0AA-1DEB-4683-96B0-B43301E83971}组件没有在DCOM中正确注册。怎么知道{5A5AA0AA-1DEB-4683-96B0-B43301E83971}是谁的类，在哪里呢？最简单的方法就是把这个组件名使用搜索引擎在Internet中查一下。很快就发现这是惠普打印机的驱动程序。那么这个错误就是由于惠普打印机驱动程序没有被正确注册造成的。用以下步骤来注册相应的dll文件就可以解决这个问题：

单击开始菜单，指向运行，在运行中输入：

CMD

打开DOS窗口，接着敲入以下命令（如果你安装的是Windows 2000的系统）：

Cd c:\winnt\system32

如果是Windows XP的系统，就敲入Cd c:\Windows\system32，转到系统目录下，然后运行：

hpbpro.exe -RegServer

如果重启计算机后错误仍然存在，则在CMD中运行以下命令，基本可以解决问题了：

hpbpro.exe -Service.

你可以在以下的网站中查到关于这个事件的详细信息：

"Event Log is Full" DCOM Error Message

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c00098371

案例三：如何分析userenv日志文件

刚刚讲了两个如何分析日志文件的案例，现在我们来看userenv日志文件，这个日志文件看起来相对复杂。

大家应该对用户配置文件（profile）比较熟悉，当一个用户登录到一台计算机时，会选择喜欢的壁纸，把文档保存在我的文档中，这些内容都会保存在当前用户的配置文件中。如果你在AD中新建一个帐号，然后该帐号在一台客户端机器上登录，你会发现在该计算机的c:\documents and settings这个目录下会新建一个含用户名的目录。

其实用户配置文件不仅仅会保存在你登录的这台计算机上，如果你使用漫游用户（roaming profile）或者强制用户（mandatory profile），那么用户配置文件就会同时被保存在服务器上以及客户端。一般来讲，漫游用户的配置文件时最有可能出问题的。比如当你登录到某台客户端的时候，可能会遇到以下错误信息：

Windows cannot copy file \\server\share\username\Recent1 to C:\Documents and Settings\username\Recent1. Contact your network administrator.

Windows cannot load the profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off.

这是一种很常见的错误信息，并且有多种步骤可以解决这个问题。

如果你不熟悉漫游用户的话，请参阅以下链接：

http://www.microsoft.com/technet/prodtechnol/Windowsserver2003/zh-chs/library/ServerHelp/647fb165-a4e4-4a92-856c-e2e92cbd148b.mspx

我希望先为大家介绍一下用户配置文件究竟包括哪些主要文件和过程，只有对这些有所了解，你在遇到用户配置文件时才能从保持清晰的思路。

用户配置文件包括以下内容：

Registry Hive：NTUSER.DAT

NTUSER.DAT是一个hive文件，这个文件是隐藏在C:\Documents and Settings\%Username%\目录下的。当用户登录的时候，这个文件被装载到HKEY_CURRENT_USER注册表中。

配置文件的目录：就是我们刚才提到的C:\Documents and Settings\%Username%\。

由于用户配置文件在工作组和域中都存在，我们在这里讨论用户配置文件在一台域中客户端的情形，假定用户名为rebc

1． 使用本地用户配置文件

新用户：当一个新用户登录到某台客户端的情况十分简单。在登录中，客户端的机器会去检查：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

查看是否有rebc这个用户配置文件存在，由于是新用户，所以没有找到相应配置文件。因此客户端从服务器的NETLOGON共享目录中去找默认用户配置文件，并以此为模板为rebc创建配置文件。当rebc注销的时候，配置文件会被保存在C:\Documents and Settings\rebc下。

老用户：当rebc第二次登录这台客户端时，机器在检查ProfileList这个注册表键值时，就取到了rebc配置文件的保存路径从而把NTUSER.DAT hive文件中的内容加载到HKEY_CURRENT_USER注册表中。

2． 漫游用户

新用户：当rebc登录客户端的时候，客户端从服务器这里取到漫游用户配置文件的路径，例如这个路径：\\server\shares\。客户端会看这个路径下是否已经有配置文件存在，如果不存在，就在服务器上建立目录\\server\shares\user。客户端再检查客户端本地HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList的键值，看看本地有没有用户配置文件的缓存。如果没有，就去查看服务器上有没有已经存在的默认用户配置文件。

有人可能会觉得奇怪，刚刚不是已经发现这个用户配置文件不存在吗，怎么又去看服务器上有没有配置文件？请注意，这次到服务器上去看的是默认用户配置文件，正因为发现这是个新用户，所以需要给她建立一个配置文件。那么在域环境中，默认的用户配置文件是保存在域控制器的NETLOGON共享目录上的。因此，客户端从这个共享目录中copy一份默认用户配置文件到客户端的%Systemdrive%\Documents and Settings\user目录中。

配置文件中，NTUSER.DAT（这其实是个注册表的hive文件）就被导入HKEY_CURRENT_USER注册表，本地用户配置文件的环境变量也被更新了。

等到客户端本地的配置文件被更新了，比如你改了屏保、壁纸什么的，当你注销的时候，这些改变都被上传到服务器的相应配置文件。有人就问了：如果我在另外一台客户端B上登录了，改了不同的设置，而在这边客户端A先注销了怎么办？客户端A的改动这时被合并到服务器上的配置文件中去，等客户端B上也注销了，那么改动的内容也被合并到服务器上去；如果发生冲突，则后写入的覆盖掉前面的内容（last writer win）。

老用户：当rebc登录客户端的时候，客户端从服务器这里取到漫游用户配置文件的路径，客户端会看这个路径下是否已经有配置文件存在，如果不存在，就在服务器上建立目录\\server\shares\user，那么在这个例子中，客户端可以在服务器上找到相应用户配置文件。

客户端再检查客户端本地HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList的键值，看看本地有没有用户配置文件的缓存，这个例子中，Windows检测到本地有用户配置文件的缓存信息。接着，Windows把服务器上的用户配置文件和本地缓存中的配置文件作合并。

NTUSER.DAT（这其实是个注册表的hive文件）就被导入HKEY_CURRENT_USER注册表，本地用户配置文件的环境变量也被更新了。当用户登录后如对桌面配置做了变更如改动屏保、壁纸等等，在其注销时，这些改动都被合并到服务器的配置文件中。

因此当你看到刚才的错误信息时，知道该怎么做了吧？

这个错误信息非常明显地指出了当前使用的漫游用户不能从服务器上复制配置文件，所以Windows就使用了一个临时配置文件让当前用户登录，而这个配置文件在你登出客户端时是不会被保存到服务器上的。至于为什么配置文件不能从服务器复制到当前客户端，你就要检查网络连接是否有问题；服务器上的漫游用户配置文件的目录是否被正确创建了；该用户对配置文件的目录（当然是指在服务器上的目录）是否有正确的读写权限等等。

知道了原理以后，是不是感觉分析错误容易多了？这就叫知己知彼，百战不殆啊。:）