如果有人有类似的故事，请在下面发布详细信息！
我正在构建一个 ASP.NET 网站，它需要支持针对 LDAP 的身份验证.
I'm building an ASP.NET website which needs to support authentication against LDAP.
在 Windows 上，可以通过 Active Directory 执行 LDAP 身份验证(我不是专家，但 AD 似乎只是 ldap 的一种特殊形式).我不控制 AD 和/或 LDAP 服务器.
On windows, LDAP auth can be performed via Active Directory (I'm no expert, but AD seems to simply be a particular flavor of ldap). I don't control the AD and/or LDAP servers.
我尝试了各种身份验证方法，但我决定每次身份验证尝试使用单个 DirectoryEntry:
I've tried various methods of authentication, but I've settled on using a single DirectoryEntry per authentication attempt:
using (DirectoryEntry de = new DirectoryEntry(ldapPath, ldapUsername, password, AuthenticationTypes.ServerBind)) {
try {
// Bind to the native AdsObject to force authentication.
object obj = de.NativeObject;//not IDisposable
} catch(...
如果出现任何问题，检索 NativeObject 会导致 COMException，例如，如果身份验证失败，则异常类似于登录失败:未知用户名或密码错误"，如果 ldap服务器无法访问或超时，例如服务器无法运行".
Retrieving the NativeObject causes a COMException if anything whatsoever goes wrong, for instance if the authentication failed, the exception is something like "Logon failure: unknown user name or bad password", and if the ldap server is unreachable or times out, something like "The server is not operational."
这基本上是可行的，但是在可变天数之后，总是从早上的第一件事开始，我们得到服务器无法运行".直到 IIS 重新启动.这显然不是一个很好的长期解决方案，但据我所知，问题在于底层 DirectoryEntry 的 Com 对象 - 不容易修复.
This works, basically, but after variable number of days, always starting first thing in the morning, we get "The server is not operational." until IIS is restarted. This is obviously not a great long-term solution, but as far as I can tell the fault lies with the Com Object underlying DirectoryEntry - not something easy to fix.
这个 问题 不是 新 或 未知.有些人通过微软的支持，结果喜忧参半；基本上答案似乎归结为采用您的 ldap 路径并创建一些等效的替代方案，也许其中一个会起作用".每次你尝试，或者当然，你不会知道它是否真的有效，直到找到真正的解决方案，我们才回到每晚重新启动 Windows 服务器".
This problem isn't new or unknown. Some people have gone through microsoft's support with mixed results; basically the answers seem to come down to "take your ldap path and create a few equivalent alternatives and maybe one of those will work". Each time you try, or course, you won't know for a few days whether it actually worked, and until a real solution is found, we're back to "reboot the windows servers every night".
首先，我尝试了 ldap 路径的格式
As a start, I've tried ldap paths in the format
* "LDAP://server.uri:636"
* "LDAP://insecure.server.uri:389"
* "LDAP://server.uri:636/cn=username,ou=staff,o=myOrganisation,c=org"
始终使用具有以下模式的用户名:
Always with a username with the following pattern:
* "cn=username,ou=staff,o=myOrganisation,c=org"
所有这些方法最初都有效，但在可变天数后失败(并在 IIS 重置后开始工作).服务器在 win 2k3 上运行 IIS6.
All of these methods work initially, but fail after a variable number of days (and start working after an IIS reset). The server is running IIS6 on win 2k3.
如果其他人有这些问题，请在下面发布，也许最终我们会找到一种可以使用的模式或有足够数量的示例来说服微软解决这个问题.
If anyone else has these problems, please post below, and perhaps eventually we'll find a pattern to work with or have sufficient number of examples to convince microsoft to fix this.
虽然我无法准确定位这个问题的原因，但迁移到非集群服务器后似乎不得不停止了.
Although I can't precisely pinpoint the cause of this trouble, it seems to have to have stopped after migrating to a non-clustered server.
关于这个错误还有其他奇怪的事实:
There are other odd facts about this bug:
总而言之，这看起来很像 win2k3 中启用集群的驱动程序或内核问题，而不是与 .NET 相关的问题.
All in all, this looks very much like a driver or kernel issue in win2k3 with clustering enabled, and not a .NET related problem.
因此，如果其他人遇到类似问题，请检查是否启用了集群 - 它可能会为您节省数周的麻烦.
So, if anyone else stumbles over a similar problem, check to see if clustering is enabled - it may save you weeks of headaches.
这篇关于为什么使用 DirectoryEntry 对 LDAP 进行身份验证会间歇性地抛出 COMException (0x8007203A):“服务器无法运行"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！