DirectoryServices.AccountManagement“舊”密碼在密碼更改后仍然有效

Question

在Active Directory中重置用戶密碼后，如果用戶嘗試使用舊密碼登錄，則以下代碼驗證為True：

Dim up As UserPrincipal = GetAdUser(objContext, arg_strBA, arg_strUsername)

If up IsNot Nothing Then

    Dim valid As Boolean = up.Context.ValidateCredentials(
    up.UserPrincipalName, arg_strPassword, ContextOptions.Negotiate)


    If (valid) Then strReturn = up.SamAccountName

End If

我們正在使用以下代碼重置密碼：

Dim objUser As New DirectoryEntry(arg_strLDAPPath)

If Not objUser Is Nothing Then
    objUser.AuthenticationType = AuthenticationTypes.Secure


    objUser.Invoke("SetPassword", arg_strNewPW)
    objUser.CommitChanges()
end if

密碼重置工作正常，用戶可以使用新密碼登錄，但舊密碼仍不能驗證。

當上述ValidateCredentials適用於舊密碼時，我們將憑據分配給Web服務調用，然后失敗並顯示“401：Unauthorized”錯誤。

有人見過這樣的事嗎？

Answer 1

這個問題與Code無關，但是聽到的罪魁禍首是Active目錄......

請參考http://support.microsoft.com/kb/906305獲取解決方案......

Answer 2

這項工作 - 請參閱下面的解決方案 - 如果您覺得這有用，請告訴我，因為我們的商店對這是否是一個好的解決方案存在分歧。

以下是Active Directory允許舊密碼在更改后工作的解決方案。 我非常希望得到關於接受此解決方案的反饋，因為它在登錄身份驗證期間使用ChangePassword。 這是一個奇怪的事情，但它的工作原理。 目前我們的商店沒有使用此解決方案，所以如果有人可以告訴我他們是否正在使用它，將不勝感激。

謝謝Ch

返回的Active Directory和舊密碼有效（15分鍾到+ - 小時）。 調用SetPassword或ChangePassword時會發生這種情況。

歷史：

我發現這被稱為AD的“功能”，並且是設計在AD中的設計，因此當用戶更改密碼時，有一種寬限期允許使用這些密碼的所有資源轉移到新密碼。

支持AD知道最新密碼概念的AD的一個示例是更改PC上的登錄密碼 - 在這種情況下，計算機將不允許舊密碼登錄。 雖然我沒有這方面的答案（除了微軟必須讓它工作），我認為這並不像PC所涉及的那樣簡單，它也有密碼。

顯示AD​​中密碼更改如何持續一段時間的一個示例可能是：

使用從Windows 7 PC到Windows Server 2008 R2的遠程桌面。 從Windows安全框登錄然后出現，單擊確定框，單擊確定，然后您已登錄。現在將您用於遠程用戶的密碼更改為框（與您的Kirkman用戶不同??），注銷和登錄再次使用舊密碼（在15分鍾到一小時的時間范圍內+ - ）。 舊密碼將通過Windows安全框和OK框。 單擊“確定”后，它將失敗。 如果從遠程桌面重新開始並嘗試輸入錯誤密碼，則會在Windows安全框中停止顯示“登錄嘗試失敗”消息。 時間限制到期后，您將無法使用舊密碼通過Windows安全框。 （確保每次不切換用戶的遠程桌面，這將按預期運行，這也表明涉及PC的某種方式）。 至少它不是用戶登錄 - 但這確實表明（某些級別似乎是AD）允許舊密碼在某種程度上進行身份驗證。

研究：我發現了很多關於這個問題的引用，並且只有一個可能的解決方案，到目前為止我還無法確定我們是否可以實現它（這是嚴格通過Kerberos而不是NTLM調用的引用，這並不像它可能會出現在文件和我的研究中）。 我找到了很多關於如何在.NET中與AD交互的鏈接，但沒有實際的AD手冊。

解決方案解決方案 - 如果您需要SOlution解決方案，請閱讀此部分！ 現在：我發現（在測試期間偶然）對AD的ChangePassword調用將不允許傳遞給它的OldPassword成功將密碼更改為新密碼。 我認為，這項有效的測試實際上並不知道，因為我沒有找到任何使用它的參考。 我實際上還沒有找到解決這個問題的方法。 一天早上凌晨3點，我意識到我可以利用ChangePassword的這種方法來解決這個問題 - 至少我們可以立即使用解決方法，直到我們能夠確定更好的方法。

首先，我檢查一切是否有效，AD返回密碼有效。 然后使用oldpassword和newpassword作為用戶提供的密碼（兩者都相同）調用ChangePassword（username，oldpassword，newpassword）。 我知道其中一個（可能是三個，但密碼策略違規阻止它成功）結果將會發生。 OldPassword是好的，我們失敗，因為密碼策略不符合（歷史記錄，新密碼不能是最后N個密碼之一）或我們失敗，因為舊密碼不正確（兩者都作為異常錯誤返回消息中的文本）。 我們檢查最后一個條件，如果oldpassword無效，我們不允許用戶登錄。

未來：也許第二組眼睛會有所幫助。
我認為解決方案是模擬或Kerberos。 我沒有成功地找到足夠的解決方案。 很明顯，AD可以區分舊密碼，因為ChangePassword會這樣做。 我們正在做的是安全的核心所以不是所有東西都是開放的（就像在AD中查看密碼歷史的能力，我還沒有找到訪問它的方法）。

Answer 3

我在這里得到答案

從鏈接......

“然而，重要的是ContextOption 不能確保僅使用Kerberos。事實證明，在某些情況下（如果您指定AD而不是本地，並且您有足夠的最新服務器），代碼選擇無論如何都要進行協商。從這個意義上說，指定Sealing可能意味着它將使用Kerberos，但不一定是唯一的。真正重要的標志是在這之下埋下了幾層。在封面下，這個方法最終建立了一個LdapConnection，設置連接的網絡憑據，設置AuthType（重要的實際標志！），最后調用Bind（）方法.LdapConnection.Bind（）方法使用指定的憑據建立與其中一個AD服務器的經過身份驗證的連接。問題是當PrincipalContext.ValidateCredentials設置此調用時（在您的場景中），它總是設置AuthType = Negotiate。在這種情況下，Kerberos確實會被使用，並最終成為fa iling，但系統回歸到NTLM。“

Answer 4

您是否考慮到AD需要在整個網絡中傳播類似的更改，最多花費15分鍾的時間？

渣

Answer 5

我假設您在客戶端計算機上執行ValidateCredentials。 如果是這種情況，那么它將緩存舊的（成功）密碼。 這樣做是為了使用戶能夠在Active Directory脫機或無法訪問時登錄。 傳播變化需要一些時間。

如果您想解決此問題，則應在身份驗證時使用服務於Web服務的服務器而不是本地客戶端計算機進行身份驗證。