为什么 DirectoryEntry 属性需要 10 个小时才能返回？答案

【问题标题】：Why would it take 10 hours for DirectoryEntry Properties to return?为什么 DirectoryEntry 属性需要 10 个小时才能返回？
【发布时间】：2015-10-13 15:14:56
【问题描述】：

我们正在枚举测试广告中的数千名用户。整个过程可以在大约一个小时内运行。但是有时候，对于单个用户来说，下面几行代码会卡住10个小时左右。

这并不总是发生，当它发生时，它可能发生在任何 AD 用户身上。

        using (DirectoryEntry de = new DirectoryEntry(String.Format(@"LDAP://{0}/<GUID={1}>", host, objectGUID), admin, password, server.AuthenticationMethod))
        {
            try
            {
                dn = (string)de.Properties["distinguishedName"][0];
            }
            catch
            {
                // log it...
            }
        }

在漫长的延迟之后，事情继续，好像什么都没有发生一样。

什么可能导致这种延迟？

【问题讨论】：

发生这种情况时服务器上还发生了什么？
似乎没什么大不了的。 AD 服务器的 CPU 或内存使用率不高。 NETSTAT 没有显示端口耗尽的迹象。客户端也在运行内部 ASP.NET 网站，但没有任何负担。
事件查看器中是否显示任何错误？发生这种情况时，活动目录是否有任何事件？
事件查看器中的任何一方都没有错误。在事件查看器之外，如何使用您提到的活动目录检查事件？
你的尝试没有任何问题，这段代码甚至不应该编译。我假设你没有给我们完整的图片。

标签： c# active-directory ldap directoryservices

【解决方案1】：

TL;DR 启用 AuthenticationTypes.Secure 以解决此问题。

我创建了一个能够按需重现此问题的测试应用程序。测试应用程序所做的只是启动 4 个线程，每个线程都包含一个无限的 while 循环。在 while 循环中，我创建了一个新的 DirectoryEntry 并在其上调用 RefreshCache。很多时候，尤其是在启动时，其中一个线程会遇到以下异常

COMException -2147016643 "A decoding error has occurred."

此错误也称为 0x8007203D aka -2147016643 aka 2147950653

当在一个线程中发现此异常时，一个或多个其他线程将挂起对 RefreshCache 的调用。

在 DirectoryEntry 构造函数中，我们没有包含 AuthenticationTypes.Secure。 Secure 是一个默认标志，但因为我们设置了其他 AuthenticationTypes 标志，我们也应该手动包含 Secure。不知道为什么，但是在启用安全模式时，DirectoryServices 在多线程下表现得更好。

【讨论】：