通過 RADIUS 進行身份驗證：MSCHAPv2 錯誤 691
我正在通過 RADIUS 將身份驗證設置為 Acme Packet Net-Net 3820 (SBC)。事情的會計方面工作得很好，沒有任何問題。事物的身份驗證方面是另一回事。我可以從數據包擷取中看到，訪問請求消息實際上正在到達 RADIUS 伺服器，此時 RADIUS 伺服器開始與域控制器通信。然後我看到通信鏈返回到 RADIUS，最後返回到 SBC。問題是我得到的響應始終是原因程式碼為 16 的訪問拒絕消息（由於使用者憑據不匹配，身份驗證失敗。提供的使用者名與現有使用者帳戶不匹配或密碼不正確）。通過查看安全事件日誌可以確認這一點，我可以在其中看到事件 4625 和 6273。
事件編號：6273
Network Policy Server denied access to a user. Contact the Network Policy Server administrator for more information. User: Security ID: NULL SID Account Name: real_username Account Domain: real_domain Fully Qualified Account Name: real_domain\real_username Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: - Calling Station Identifier: - NAS: NAS IPv4 Address: 10.0.0.10 NAS IPv6 Address: - NAS Identifier: radius1.real_domain NAS Port-Type: - NAS Port: 101451540 RADIUS Client: Client Friendly Name: sbc1mgmt Client IP Address: 10.0.0.10 Authentication Details: Connection Request Policy Name: SBC Authentication Network Policy Name: - Authentication Provider: Windows Authentication Server: RADIUS1.real_domain Authentication Type: MS-CHAPv2 EAP Type: - Account Session Identifier: - Logging Results: Accounting information was written to the SQL data store and the local log file. Reason Code: 16 Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.事件編號：4625
An account failed to log on. Subject: Security ID: SYSTEM Account Name: RADIUS1$ Account Domain: REAL_DOMAIN Logon ID: 0x3E7 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: real_username Account Domain: REAL_DOMAIN Failure Information: Failure Reason: Unknown user name or bad password. Status: 0xC000006D Sub Status: 0xC000006A Process Information: Caller Process ID: 0x2cc Caller Process Name: C:\Windows\System32\svchost.exe Network Information: Workstation Name: Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: IAS Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network). The Process Information fields indicate which account and process on the system requested the logon. The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The authentication information fields provide detailed information about this specific logon request. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.因此，乍一看，問題似乎只是使用者名無效或密碼不匹配的情況。這在數據包擷取中得到了進一步證實，我可以看到 MSCHAPv2 響應的錯誤程式碼為 691（訪問被拒絕，因為使用者名或密碼或兩者在域上無效）。問題是我知道我正在使用一個有效的使用者名，並且我嘗試了許多使用者名，包括我為故障排除而創建的新使用者名。我不知道我重置了多少次密碼以確保它不是不匹配的密碼。我什至確保使用相當短且僅包含字母的密碼，以確保沒有終端編碼問題（我們通過 SSH 客戶端連接到 SBC）。我也對 SBC 和 RADIUS 伺服器之間通信期間使用的共享密鑰做了同樣的事情。我嘗試在登錄時為使用者名加上域名前綴（儘管我認為這沒有必要）。我也嘗試過使用使用者的完整 UPN 登錄。我嘗試了幾個 RADIUS 測試客戶端（NTRadPing、RadiusTest 等），但它們要麼不支持 MSCHAPv2，要麼只支持 EAP-MSCHAPv2。我什至使用 PHP 的 PECL RADIUS 模組創建了自己的客戶端。儘管如此，MSCHAPv2 身份驗證似乎總是失敗，錯誤程式碼為 691。當我盡一切可能確保不是這種情況時，有沒有人知道為什麼我總是得到無效的使用者名或錯誤的密碼響應？我嘗試了幾個 RADIUS 測試客戶端（NTRadPing、RadiusTest 等），但它們要麼不支持 MSCHAPv2，要麼只支持 EAP-MSCHAPv2。我什至使用 PHP 的 PECL RADIUS 模組創建了自己的客戶端。儘管如此，MSCHAPv2 身份驗證似乎總是失敗，錯誤程式碼為 691。當我盡一切可能確保不是這種情況時，有沒有人知道為什麼我總是得到無效的使用者名或錯誤的密碼響應？我嘗試了幾個 RADIUS 測試客戶端（NTRadPing、RadiusTest 等），但它們要麼不支持 MSCHAPv2，要麼只支持 EAP-MSCHAPv2。我什至使用 PHP 的 PECL RADIUS 模組創建了自己的客戶端。儘管如此，MSCHAPv2 身份驗證似乎總是失敗，錯誤程式碼為 691。當我盡一切可能確保不是這種情況時，有沒有人知道為什麼我總是得到無效的使用者名或錯誤的密碼響應？
以下是我們的 RADIUS 配置的規格：
- 視窗伺服器 2012 R2
- 用於記帳的 SQL Server 2012 後端數據庫。
- 該伺服器已在域上獲得授權，並且是“RAS 和 IAS 伺服器”組的成員。該組確實有權訪問我們正在測試的帳戶。
- 我們正在測試的帳戶確實在其“撥入”屬性選項卡下選中了“通過 NPS 網路策略控制訪問”選項。
- RADIUS 客戶端配置為僅匹配 IP 地址，您可以從上面的事件中看到它正在應用客戶端友好名稱。
- 連接請求策略：如上所示，正在應用“SBC 身份驗證”策略。唯一的條件是成功匹配友好名稱的正則表達式。
- 網路策略：如上述事件所示，沒有一個被應用。出於故障排除的目的，我為處理訂單創建了一個設置為“1”的網路策略，其唯一條件是目前設置為任何時間、任何一天的日期和時間限制。
- 身份驗證方法設置為僅 MSCHAPv2 或 MSCHAPv2（使用者可以在密碼過期後更改密碼）。我嘗試將其添加到網路策略中，並且我還嘗試將其添加到連接請求策略並將其設置為覆蓋網路策略的身份驗證方法。
- 我們的域中確實有其他 RADIUS 伺服器，它們使用 PEAP 來驗證無線客戶端，它們都工作正常。但是，我們需要它才能僅與 MSCHAPv2（無 EAP）一起使用。
- 所有其他配置均設置為預設值。
唯一需要考慮的其他事項是，在上述事件中，您可以看到安全 ID 為“NULL SID”。現在我知道這在登錄失敗中很常見，但鑑於此問題說明使用者名無效或密碼錯誤，在這種情況下可能很重要。此外，該伺服器已使用 Active Directory 中的相同電腦帳戶重建。我不知道在重建之前它是否會起作用。本質上，我們建構了此伺服器，並且僅在我們決定將 SQL 角色分離到另一台伺服器上時才將伺服器授權到域並添加 SQL。我們只是重建了機器，而不是解除安裝 SQL。但是，在重新安裝 Windows 之前，我確實對電腦帳戶進行了重置。我不
總而言之，這是一個相當基本的設置，希望我已經提供了足夠的資訊讓人們了解可能發生的事情。抱歉，如果我對此的理解似乎有點基本，畢竟，當談到 RADIUS 伺服器時，我想你可以說我是這裡的新人。
編輯1：
為了進一步解決此問題，我嘗試啟動其他伺服器進行測試。這是我執行的其他測試。
多個域
我現在已經在 3 個不同的獨立域中嘗試過這個。我們的測試和生產域以及我的私有主域，除了對 Exchange 和 ConfigMgr 所做的修改外，幾乎沒有自定義方式。都具有上述相同的結果。
VPN服務
使用 Windows Server 2012 R2，我們建立了一個單獨的伺服器來執行標準 VPN 設置。目的是看看我們是否可以對 VPN 使用 RADIUS 身份驗證，如果可行，我們就會知道問題出在 SBC 上。但是，在我們甚至可以將其配置為使用 RADIUS 之前，我們只是嘗試確保它與本地 VPN 伺服器上的標準 Windows 身份驗證一起工作。有趣的是，它也失敗了，記錄了與 RADIUS 伺服器相同的事件。客戶端電腦是 Windows 8.1 工作站。我再次指出，我們有專門用於我們的無線環境的工作 RADIUS 伺服器。這些 RADIUS 伺服器與我遇到問題的伺服器之間的唯一區別是工作無線伺服器使用的是 PEAP 而不是 MSCHAPv2。
自由半徑
現在我不是 Linux 專家，但我相信我已經啟動並執行了它。登錄到控制台時，我可以使用 ntlm_auth 對使用者進行身份驗證。但是，當 radiusd 服務嘗試使用 ntlm_auth 執行基本相同的操作時，它會失敗並返回與 Windows 伺服器相同的消息 (E=691)。我有在調試模式下執行的 radiusd 服務，所以我可以看到更多正在發生的事情。如果需要，我可以發布我得到的調試資訊。然而，我特別感興趣的行如下：
(1) ERROR: mschap : Program returned code (1) and output 'Logon failure (0xc000006d)' (1) mschap : External script failed. (1) ERROR: mschap : External script says: Logon Failure (0xc000006d) (1) ERROR: mschap : MS-CHAP2-Response is incorrect這裡要注意的是，雖然我們基本上仍然收到“錯誤密碼”消息，但實際狀態碼 (0xc000006d) 與我在 Windows 伺服器上得到的 (0xc000006a) 略有不同。從本文件中，您可以看到這些程式碼的含義：NTSTATUS values。這個 FreeRADIUS 伺服器的好處是，當它處於調試模式時，我可以看到所有的質詢響應。因此，如果我可以了解如何計算 MSCHAPv2 響應，我可以比較它，看看這是否只是一個錯誤計算的質詢響應。更新只是注意到 6a 程式碼只是 6d 程式碼的子狀態程式碼。所以與 Windows 伺服器沒有什麼不同，我仍然想知道挑戰響應是否存在計算錯誤。
目前，我正在開發一個 RADIUS 伺服器的 Windows Server 2008 R2 實例，看看是否有幫助。但是，如果該服務在 W2K8 R2 和 W2K12 R2 之間出現問題而直到現在沒有人注意到，我會感到驚訝。如果這不起作用，我可能不得不向 Microsoft 開一個案例。**更新：**與 W2K8 R2 的結果相同。
更新 2
我向微軟開了一個案子，他們為此工作了幾個星期。第一周，我花時間試圖讓他們了解這與無線無關，並且我們嘗試連接的設備不支持使用任何形式的 EAP 對 RADIUS 伺服器進行身份驗證。一旦他們最終了解到我們只是嘗試將身份驗證方法設置為僅 MSCHAPv2，他最初的反應就是“你不能那樣做”。他說，無論您總是需要在頂部框中設置某種形式的 EAP 或 PEAP（即使對於該身份驗證方法視窗中的 PAP 和其他“不太安全的方法”）。這對我來說似乎不太可能，所以我要求提供一些文件說明這一點，然後他改變了主題並且從未提供任何文件。很明顯，當他們告訴我問題似乎出在使用者名和密碼上時，我對微軟一事無成。因此，當我的首映票的主題行中有 E691 錯誤程式碼時，他們花了 2 週時間才得出這個結論，這意味著使用者名和密碼不匹配，儘管我用很長的一段解釋說我已盡一切可能確保它不是錯誤的使用者名和密碼。
不幸的是，我的項目負責人不想再為此浪費首映支持時間，所以我們已經結案了。我們可能只處理 SBC 本地共享登錄並設置其他方式來強制執行問責制（我們中只有 4 人可以訪問）。
我要指出的是，在我被告知放棄該項目之前，我確實讓 FreeRADIUS 伺服器僅使用 MSCHAPv2 工作，但只能使用 FreeRADIUS 伺服器的本地帳戶來執行此操作。那是儲存在某個地方的 FreeRADIUS 配置文件中的純文字密碼。所以顯然不是一個解決方案，但它至少表明 SBC 正在通過 MSCHAPv2 正確地與 RADIUS 伺服器通信。這一點以及我上面提到的其他事情讓我相信問題出在 RADIUS 伺服器和域控制器之間。雖然 NTLM 身份驗證在本地登錄到伺服器時在 Windows RADIUS 和 FreeRADIUS 伺服器上都可以正常工作（可以通過測試帳戶登錄到 Windows RADIUS，並且可以在僅使用使用者名和密碼的 ntlm_auth 命令時在 FreeRADIUS 伺服器上獲得成功的身份驗證） ,
所以我會在這裡結束這個執行緒，但我會密切關注這一點，如果有人發帖，它會通知我。如果有人發布解決方案或有評論，我會回复。
解決方案
你不知道嗎，在我們放棄這種使用 RADIUS 伺服器來控制對 SBC 的訪問的方法大約一個月後，我們找到了一個可能的解決方案。當然，此時我們正忙於其他項目，無法回去嘗試這個解決方案，所以我不能說 100% 是否能解決問題，但一旦我解釋，你可能會同意這就是答案。
我的一位同事在 Microsoft 會議上進行了各種討論，當時他意識到 MSCHAPv2 依賴於 NTLM 來生成密碼挑戰和響應。現在，當在 Windows RAS 服務中使用普通的舊 MSCHAP 和 MSCHAPv2（即不是 EAP-MSCHAPv2 或 PEAP）時，預設情況下將使用 NTLMv1。
正如你們中的許多人已經開始了解的那樣，我們和許多管理員一樣，已經在我們的 DC 上禁用了 NTLMv1，因此 DC 將只接受 NTLMv2 請求。這解釋了為什麼我繼續遇到的失敗是“密碼錯誤”錯誤。發送到 DC 的密碼採用 NTLMv1 格式並且被忽略。
一旦我們意識到這一點，我就能夠做更多的研究，我發現了以下文章：
http://support.microsoft.com/kb/2811487
本文描述了我遇到的相同行為，包括我提到的 E=691 錯誤程式碼。本文還提供了一種解決方法，以強制 RAS 服務在建構 MSCHAPv2 響應時使用 NTMLv2。有趣的是，在您確切知道問題所在之後，找到這些文章是多麼容易。
同樣，我還沒有驗證這是問題所在，因為我沒有時間重建我已經退役的 RADIUS 伺服器，但如果有機會，我確實計劃在某個時候嘗試一下。我只是想發布這個可能的解決方案，以防其他人偶然發現這個問題。如果有人可以在我之前確認這一點，請告訴我。
編輯 - 確認
我們被要求在這些 SBC 中扮演更重要的角色，因此我們回到了這個項目並再次啟動了 Windows RADIUS 伺服器。這次我們應用了上面連結中描述的系統資料庫項。在對 RADIUS 伺服器和 SBC 之間的通信進行數據包捕穫後，我實際上現在可以看到“訪問接受”消息在 SBC 處被觸發。所以我現在可以至少在我們的場景中確認我們遇到的問題如上所述。
TL; 博士
在 DC 上禁用 NTLMv1。設置系統資料庫項以強制 RADIUS 伺服器使用 NTLMv2 解決了該問題。