在某些情況下，當用戶被鎖定時LDAP綁定到ActiveDirectory會成功

Question

我在測試錯誤密碼提供足夠多的時間來觸發鎖定時測試.net LDAP客戶端的行爲。

我看到這種奇怪的行爲：看起來，如果進程成功連接在任何時間，然後它能夠​​重新連接，即使有意識地觸發鎖定後。

這裏是我的綁定方法的簡寫：

private DirectoryEntry Bind(string userId, string password) 
{ 
    var entry = new DirectoryEntry(BasePath, userId, password); 
    // If the password is bad, the attempt to access entry.NativeObject throws an exception. 
    var obj = entry.NativeObject; // causes the bind to occur 
    return entry; 
} 

我的測試過程如下：

private void TestLockout() 
{ 
    // attempt with bad pw enough times to trigger a lockout. 
    for (int i=0; i < 5; i++) 
    { 
     try 
     { 
      // i.ToString() is a purposefully bad pw 
      Bind("testuser", i.ToString()); 
     } 
     catch 
     { 
     } 
    } 
    // Now make sure that an attempt with a good pw fails due to lockout 
    var bindSuccess = true; 
    try 
    { 
     Bind("testuser", "correctpassword"); 
    } 
    catch 
    { 
     bindSuccess = false; 
    } 
    // the output should be "false" 
    Console.WriteLine("Bind result is " + bindSuccess.ToString(); 
} 

這工作正常原樣。但是，如果在測試之前使用密碼良好的方式調用Bind（），則會得到不同的結果。

督察，這樣的：

Bind("testuser", "correctpassword"); // succeeds 
TestLockout(); // does not give the correct result 

會出現以下情況。

a）TestLockout產生不正確的輸出，因爲最終的綁定成功，它不應該。
b）然而，由於後續的檢查，我知道用戶被鎖定。

因此，看起來某些組件正在跟蹤當前進程是否成功連接。我需要有一種方法來清除這種情況。此驗證代碼將在長時間運行的服務進程中執行，並且在用戶被鎖定時驗證用戶身份是不可接受的。

Answer 1

這與DirectoryEntry正在使用ADSI的事實有關。 ADSI具有基於BasePath，Username和Password構建的內部LDAP連接池。

如果您在帳戶被鎖定之前嘗試使用正確的密碼進行綁定，則使用該正確的密碼成功建立LDAP連接並在連接池中進行高速緩存。然後，您將帳戶鎖定，並嘗試使用相同的BasePath,Username和Password綁定到Active Directory。 DirectoryEntry此時不會建立新的LDAP連接，而是重用前一個。您可以通過查看網絡跟蹤來證明。

要解決這個問題，你可以在你不需要的時候處置你的DirectoryEntry。處置好您的DirectoryEntry後，ADSI應該足夠聰明，可以關閉不再需要的LDAP連接。在你的示例代碼中，它看起來像你再也不需要它了。所以，這應該解決這個問題。

private void Bind(string userId, string password) 
{ 
    using (var entry = new DirectoryEntry(BasePath, userId, password)) 
    { 
     // If the password is bad, the attempt to access entry.NativeObject throws an exception. 
     var obj = entry.NativeObject; // causes the bind to occur 
    } 
}