本節提供許多 Microsoft Entra 密碼保護常見問題的解答。
一般問題
使用者可以使用哪些指引來瞭解如何選取安全密碼？
下列連結是目前 Microsoft 中有關本主題的指引：
非公用雲端是否支援內部部署 Microsoft Entra 密碼保護？
Azure 全域和 Azure Government 雲端都支援內部部署 Microsoft Entra 密碼保護。
Microsoft Entra 系統管理中心允許在不支援的雲端中修改內部部署特定「Windows Server Active Directory 的密碼保護」設定;這類變更會持續發生，但永遠不會生效。 不支援在不支援的雲端中註冊內部部署 Proxy 代理程式或樹系，而且任何這類註冊嘗試一律會失敗。
如何讓內部部署使用者的子集受益於 Microsoft Entra 密碼保護？
不支援。 部署並啟用之後，Microsoft Entra Password Protection 同樣適用於所有使用者。
密碼變更和密碼設定 (或重設) 之間有何差異？
密碼變更是指使用者在證明自己知道舊密碼之後選擇新的密碼。 例如，若在使用者登入 Windows 時，系統提示使用者選擇新密碼，就會進行密碼變更。
當系統管理員將帳戶的密碼取代為新密碼 (例如，使用 Active Directory 使用者和電腦管理工具) 時，則屬於密碼設定 (有時稱為密碼重設)。 此作業需要高階許可權（通常是 Domain Admin），而執行作業的人員通常不知道舊的密碼。 技術支援中心案例通常會執行密碼集，例如協助忘記密碼的使用者。 當您第一次使用密碼建立全新的用戶帳戶時，您也會看到密碼設定事件。
無論執行的是密碼變更還是密碼設定，密碼驗證原則的行為都相同。 Microsoft Entra 密碼保護 DC 代理程式服務會記錄不同的事件，以通知您密碼變更或設定作業是否已完成。 請參閱 Microsoft Entra 密碼保護的監視和記錄。
Microsoft Entra 密碼保護是否會在安裝後驗證現有的密碼？
否 - Microsoft Entra 密碼保護只能在密碼變更或設定作業期間，對純文字密碼強制執行密碼原則。 一旦 Active Directory 接受密碼，就只會保存該密碼的驗證通訊協定特定哈希。 永遠不會保存純文本密碼，因此Microsoft Entra Password Protection 無法驗證現有的密碼。
初始部署 Microsoft Entra 密碼保護之後，所有使用者和帳戶最終將開始使用 Microsoft Entra 密碼保護驗證的密碼，因為其現有密碼應會在一段時間後到期。 如有需要，您可以透過單次手動到期使用者帳戶密碼來加速此程式。
除非手動到期，否則以「密碼永不過期」設定的帳戶不會強制變更其密碼。
嘗試使用 Active Directory 使用者和電腦管理嵌入式管理單元來設定弱式密碼時，為何會記錄重複的密碼拒絕事件？
Active Directory 使用者和電腦 管理嵌入式管理單元會先嘗試使用 Kerberos 通訊協議來設定新的密碼。 失敗時，嵌入式管理單元會嘗試使用舊版 （SAM RPC） 通訊協議來設定密碼。 使用的特定通訊協定並不重要。 如果Microsoft Entra Password Protection 將新密碼視為弱式密碼，此嵌入式管理單元行為會產生兩組要記錄的密碼重設拒絕事件。
為何使用空白的使用者名稱來記錄 Microsoft Entra 密碼保護密碼驗證事件？
Active Directory 支援測試密碼以確認是否符合網域目前的密碼複雜性需求的功能，例如使用 NetValidatePasswordPolicy api。 以這種方式驗證密碼時，測試也會包含密碼篩選 dll 型產品的驗證，例如 Microsoft Entra Password Protection，但傳遞給指定密碼篩選 dll 的用戶名稱是空的。 在此案例中，Microsoft Entra Password Protection 仍會使用目前作用中的密碼原則來驗證密碼，併發出事件記錄檔訊息以擷取結果。 不過，事件記錄檔訊息會有空的用戶名稱欄位。
我的混合式使用者嘗試在 Microsoft Entra ID 中變更密碼，但收到回應「此密碼已多次受使用。 請選擇較難猜出的密碼。」請選擇較難猜中的密碼。」在此情況下，為什麼沒看到內部嘗試驗證？
當混合式使用者在 Microsoft Entra ID 中變更密碼時，無論是透過 Microsoft Entra SSPR、MyAccount 或其他 Microsoft Entra 密碼變更機制，將會根據雲端上的全域和自訂禁用密碼清單來評估其密碼。 當密碼透過密碼回寫到達 Active Directory 時，它已在 Microsoft Entra 標識碼中驗證。
關於混合式使用者在 Microsoft Entra ID 中起始的密碼重設和變更未通過驗證，請查看 Microsoft Entra 稽核記錄。 請參閱針對 Microsoft Entra ID 中的自助式密碼重設進行疑難排解。
是否支援同時安裝 Microsoft Entra 密碼保護與其他密碼篩選產品？
是。 核心 Windows 功能之一就是支援多個已註冊的密碼篩選 dll，因此並不限於 Microsoft Entra 密碼保護。 所有註冊的密碼篩選 dll 必須先同意才能接受密碼。
如果不使用 Azure，我要如何在 Active Directory 環境中部署和設定 Microsoft Entra 密碼保護？
不支援。 Microsoft Entra 密碼保護是一項 Azure 功能，可延伸至內部部署 Active Directory 環境。
如何修改 Active Directory 層級上的原則內容？
不支援。 原則只能使用 Microsoft Entra 系統管理中心來管理。 另請參閱上一個問題。
為什麼 SYSVOL 複寫需要 DFSR？
FRS (DFSR 之前的技術) 有許多已知問題，而且在更新版本的 Windows Server Active Directory 中完全不支援。 Microsoft Entra Password Protection 零測試是在 FRS 設定的網域上完成。
如需詳細資訊，請參閱下列文章：
將 sysvol 複寫移轉至 DFSR 的案例 \(英文\)
FRS 終章將至 \(英文\)
如果您的網域尚未使用 DFSR，您必須先將其移轉為使用 DFSR，再安裝 Microsoft Entra Password Protection。 如需詳細資訊，請前往下面連結：
警告
Microsoft Entra Password Protection DC Agent 軟體目前安裝在仍在使用 FRS 進行 sysvol 複寫的網域中的域控制器上，但軟體在此環境中無法正常運作。 負面副作用包括個別檔案無法復寫，而 sysvol 還原程式似乎成功，但以無訊息方式無法復寫所有檔案。 您應盡快遷移網域以使用 DFSR，以獲得 DFSR 既有的優勢，同時消除部署 Microsoft Entra 密碼保護的障礙。 在仍在使用 FRS 的網域中執行時，系統會自動停用未來的軟體版本。
此功能在網域 SYSVOL 共用上需要多少磁碟空間？
精確的空間使用量會因為一些因素而有所不同，例如 Microsoft 全域禁用清單和每個租用戶自訂清單中禁用的權杖數量和長度，以及加密的額外負荷。 這些清單的內容很可能在未來繼續增加。 考慮到這一點，合理的預期是此功能需要網域 sysvol 共用上至少 5 MB 的空間。
為什麼需要重新開機才能安裝或升級 DC 代理程式軟體？
此需求是核心 Windows 行為所造成。
是否有任何方法可將 DC 代理程式設定為使用特定 Proxy 伺服器？
否。 由於 Proxy 伺服器是無狀態的，因此使用哪一個特定 Proxy 伺服器並不重要。
Microsoft Entra 密碼保護 Proxy 服務是否可以與其他服務 (例如 Microsoft Entra Connect) 一起部署？
是。 Microsoft Entra 密碼保護 Proxy 服務與 Microsoft Entra Connect 之間永遠不會產生直接衝突。
不幸的是，Microsoft Entra Password Protection Proxy 軟體會安裝與 Microsoft Entra 應用程式 Proxy 軟體所安裝版本不相容的 Microsoft Entra Connect 代理程式更新程式服務版本。 此一不相容可能會導致代理程式更新程式服務無法與 Azure 連線以進行軟體更新。 不建議在同一部計算機上安裝 Microsoft Entra Password Protection Proxy 和 Microsoft Entra 應用程式 Proxy。
DC 代理程式和 Proxy 要以何種順序進行安裝及註冊？
支援不分先後順序安裝 Proxy 代理程式、安裝 DC 代理程式、註冊樹系及註冊 Proxy。
是否應該顧慮到部署此功能時，對網域控制站造成的效能衝擊？
在狀況良好的現有 Active Directory 部署中，Microsoft Entra 密碼保護 DC 代理程式服務應不會大幅影響網域控制站效能。
對於大部分的 Active Directory 部署，密碼變更作業是任何指定域控制器上整體工作負載的一小部分。 例如，假設 Active Directory 網域有 10,000 個用戶帳戶，且 MaxPasswordAge 原則設定為 30 天。 平均而言，此網域每天會看到 10000/30=~333 個密碼變更作業，即使是單一域控制器的作業數目也很小。 考慮到可能最糟糕的情況：假設單一 DC 上的這 ~333 個密碼變更作業需要在一小時左右完成。 例如，許多員工都在星期一早上進行工作時，就可能會發生此情況。 即使在這種情況下，我們仍然查看 ~333/60 分鐘 = 每分鐘 6 個密碼變更，這再次不是重大負載。
不過，如果您的目前域控制器已在效能限制層級執行（例如，在 CPU、磁碟空間、磁碟 I/O 等方面已達到最大值），建議您在部署這項功能之前新增更多域控制器或擴充可用的磁碟空間。 請參閱上述關於 sysvol 磁碟空間使用量的上一個問題。
我只想在網域中的幾個 DC 上測試 Microsoft Entra 密碼保護。 有可能強制使用這些特定 DC 來進行使用者密碼變更作業嗎？
否。 使用者變更其密碼時，Windows 用戶端 OS 會控制要使用哪一個網域控制站。 網域控制站的選取會取決於 Active Directory 站台和子網路指派，以及環境特有網路設定等因素。 Microsoft Entra Password Protection 不會控制這些因素，而且不會影響選取哪個域控制器來變更用戶的密碼。
可部分達成此目標的方法之一是，在指定 Active Directory 站台中的所有網域控制站上部署 Microsoft Entra 密碼保護。 此方法為指派給該網站的 Windows 用戶端，以及登入這些客戶端的使用者，以及變更其密碼的使用者，提供合理的涵蓋範圍。
如果我只在主要網域控制站 (PDC) 上安裝 Microsoft Entra 密碼保護 DC 代理程式服務，網域中的所有其他網域控制站也可受到保護嗎？
否。 當非 PDC 網域控制站上的使用者密碼變更時，純文字密碼永遠不會傳送到 PDC (這是常見的錯誤觀念)。 當指定 DC 接受新密碼後，此 DC 會使用該密碼來建立該密碼的各種驗證通訊協定特有雜湊，然後在目錄中保存這些雜湊。 不會保存純文字密碼。 已更新的雜湊接著會複寫到 PDC。 在某些情況下，使用者密碼可能會直接在 PDC 上變更，這也是取決於各種因素，例如網路拓樸和 Active Directory 站台的設計。 (請參閱上一個問題。)
總之，在 PDC 上部署 Microsoft Entra 密碼保護 DC 代理程式服務時，就必須達到此功能在網域間的 100% 安全性涵蓋範圍。 在 PDC 上部署此功能，但不會為網域中任何其他 DC 提供Microsoft Entra Password Protection 安全性優點。
為何即使在內部部署 Active Directory 環境中安裝代理程式後，自訂智慧鎖定仍無法運作？
只有 Microsoft Entra ID 才支援自訂智慧鎖定。 在 Microsoft Entra 系統管理中心中對自訂智慧鎖定設定的變更並不會影響內部部署 Active Directory 環境，即使已安裝代理程式亦然。
System Center Operations Manager 管理組件可用於 Microsoft Entra 密碼保護嗎？
否。
即使我已將原則設定為「稽核模式」，為何 Microsoft Entra ID 仍會拒絕弱式密碼？
只有內部部署 Active Directory 環境才支援稽核模式。 Microsoft Entra ID 在評估密碼時，一律會隱含地處於「強制」模式。
當 Microsoft Entra 密碼保護拒絕密碼時，我的使用者會看到傳統的 Windows 錯誤訊息。 是否可以自訂此錯誤訊息，讓使用者知道究竟發生什麼事？
否。 網域控制站拒絕密碼時，使用者所看到的錯誤訊息是由用戶端機器所控制，而不是由網域控制站控制。 無論拒絕密碼的是預設的 Active Directory 密碼原則，還是以密碼篩選器為基礎的解決方案 (例如 Microsoft Entra 密碼保護)，都會發生此行為。
密碼測試程序
您可以對不同的密碼進行一些基本測試，以驗證軟體是否適當運作，並進一步了解密碼評估演算法。 本節將概述這類測試的方法，其設計目的是要產生可重複的結果。
為何需要執行這類步驟？ 有數個因素使得難以在 內部部署的 Active Directory 環境中執行受控制、可重複測試的密碼：
- 密碼原則在 Azure 中設定並保存，且內部部署 DC 代理程式使用輪詢機制定期同步處理原則的複本。 此輪詢週期中既有的延遲可能會產生混淆。 例如，如果您在 Azure 中設定了原則，但忘了將其同步處理至 DC 代理程式，您的測試就可能不會產生預期的結果。 輪詢間隔目前硬式編碼為每小時一次，但在兩次原則變更之間等候一小時，並不適合用於互動式測試案例。
- 將新的密碼原則同步至域控制器之後，複寫至其他域控制器時，就會發生更多延遲。 如果您針對尚未收到最新原則版本的域控制器測試密碼變更，這些延遲可能會導致非預期的結果。
- 透過使用者介面測試密碼變更，會使您難以信賴您的結果。 例如，將無效密碼輸入到使用者介面很容易，特別是因為大部分的密碼使用者介面都會隱藏使用者輸入（例如，Windows Ctrl-Alt-Delete -> 變更密碼 UI）。
- 測試已加入網域客戶端的密碼變更時，無法嚴格控制使用哪一個域控制器。 Windows 用戶端作業系統會根據多項因素來選取網域控制站，例如 Active Directory 站台和子網路指派，以及環境特定的網路設定等。
為了避免這些問題，下列步驟是以登入域控制器時密碼重設的命令行測試為基礎。
警告
請只在測試環境中使用這些程式。 當DC代理程式服務停止時，會接受所有傳入的密碼變更和重設，而不需要驗證。 這也有助於避免登入域控制器的風險增加。
下列步驟假設您已在至少一個域控制器上安裝 DC 代理程式、已安裝至少一個 Proxy，並已註冊 Proxy 和樹系。
使用 Domain Admin 認證或其他具有足夠許可權來建立測試用戶帳戶並重設密碼的域控制器登入域控制器。 請確定域控制器已安裝 DC 代理程式軟體，且已重新啟動。
開啟事件檢視器，並瀏覽至 DC 代理程式管理事件記錄檔。
開啟提升權限的命令提示字元視窗。
建立測試帳戶以進行密碼測試
建立使用者帳戶的方法有很多種，但這裡提供命令列選項，可讓您在重複的測試週期中輕鬆作業：
net.exe user <testuseraccountname> /add <password>為方便進行下列討論，假設我們已建立名為 "ContosoUser" 的測試帳戶，例如：
net.exe user ContosoUser /add <password>以至少驗證系統管理員的身分登入 Microsoft Entra 系統管理中心。
瀏覽至 [保護] > [驗證方法] > [密碼保護]。
根據您要執行的測試，視需要修改 Microsoft Entra 密碼保護原則。 例如，您可以決定要設定強制還是稽核模式，或決定要在自訂禁用密碼清單中修改禁用字詞清單。
藉由停止並重新啟動 DC 代理程式服務，將新的原則同步處理。
此步驟可用多種方式來完成。 其中一種方式是使用 [服務管理] 管理主控台，方法是以滑鼠右鍵按一下 Microsoft Entra 密碼保護 DC 代理程式服務，然後選擇 [重新啟動]。 此外也可從命令提示字元視窗執行其他方式，如下所示：
net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgent檢查事件檢視器，確認是否已下載新的原則。
每當 DC 代理程式服務在停止後再次啟動時，您都應該會看到接連發出的兩個 30006 事件。 第一個 30006 事件會反映 sysvol 共用中的磁碟上快取的原則。 第二個 30006 事件 (如果有的話) 應會有更新的租用戶原則日期，若有此日期，則會反映從 Azure 下載的原則。 租用戶原則日期值目前會編碼以顯示從 Azure 下載原則的約略時間戳記。
如果第二個 30006 事件未出現，您應該先針對問題進行疑難解答，然後再繼續。
30006 事件會類似於下列範例：
The service is now enforcing the following Azure password policy. Enabled: 1 AuditOnly: 0 Global policy date: 2018-05-15T00:00:00.000000000Z Tenant policy date: 2018-06-10T20:15:24.432457600Z Enforce tenant policy: 1例如，在 [強制執行] 和 [稽核] 模式之間變更會導致 AuditOnly 旗標遭到修改（以 AuditOnly=0 列出的原則處於強制模式）。 自定義禁用密碼清單的變更不會直接反映在上述 30006 事件中，也不會因為安全性原因而記錄到其他地方。 在此變更之後，從 Azure 成功下載原則也會包含修改過的自定義禁用密碼清單。
嘗試在測試使用者帳戶上重設新密碼，以執行測試。
您可以從命令提示字元視窗執行此步驟，如下所示：
net.exe user ContosoUser <password>執行此命令後，您可以在事件檢視器中查看命令的結果，以取得更多相關資訊。 密碼驗證結果事件記載於 DC 代理程式管理員事件記錄主題中;除了來自 net.exe 命令的互動式輸出之外，您還會使用這類事件來驗證測試的結果。
我們來看看這個範例：嘗試設定 Microsoft 全域清單禁用的密碼 (請注意，清單並未列載出來，但在此我們可以對已知的禁用字詞進行測試)。 此範例假設您已將原則設定為強制模式，且未將任何字詞新增至自訂禁用密碼清單。
net.exe user ContosoUser PassWord The password doesn't meet the password policy requirements. Check the minimum password length, password complexity, and password history requirements. More help is available by typing NET HELPMSG 2245.根據文件，由於我們的測試是密碼重設作業，您應該會看到 ContosoUser 使用者的 10017 和 30005 事件。
10017 事件應該如下列範例所示：
The reset password for the specified user was rejected because it didn't comply with the current Azure password policy. For more information, please see the correlated event log message. UserName: ContosoUser FullName:30005 事件應該如下列範例所示：
The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. UserName: ContosoUser FullName:很有趣吧 - 我們來看看另一個範例！ 現在，我們會嘗試在原則處於稽核模式時，設定自定義禁用清單所禁止的密碼。 此範例假設您已完成下列步驟：將原則設定為處於稽核模式、將 「lachrymose」 一詞新增至自定義禁用密碼清單，並依照先前所述迴圈 DC 代理程式服務，將產生的新原則同步處理至域控制器。
接著，設定禁用密碼的變異：
net.exe user ContosoUser LaChRymoSE!1 The command completed successfully.切記這次會成功，因為原則處於稽核模式。 您應該會看到 ContosoUser 使用者的 10025 和 30007 事件。
10025 事件應該如下列範例所示：
The reset password for the specified user would normally have been rejected because it didn't comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details. UserName: ContosoUser FullName:30007 事件應該如下列範例所示：
The reset password for the specified user would normally be rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. UserName: ContosoUser FullName:繼續測試您選擇的各種密碼，並使用先前步驟中所述的程序來檢查事件檢視器中的結果。 如果您需要變更 Microsoft Entra 系統管理中心中的原則，別忘了將新原則同步處理至 DC 代理程式，如先前所述。
我們已討論過可讓您對 Microsoft Entra 密碼保護的密碼驗證行為進行受控測試的程序。 直接在域控制器上從命令行重設用戶密碼，似乎是執行這類測試的奇怪方法，但如先前所述，其設計目的是產生可重複的結果。 當您測試各種密碼時，請記住 密碼評估演算法 ，因為它可能有助於說明您未預期的結果。
警告
完成所有測試時，別忘了刪除為了測試目的而建立的任何用戶帳戶！
其他內容
下列連結不屬於核心Microsoft Entra Password Protection 檔，但可能是功能的其他實用來源。
電子郵件網路釣魚防護指南 – 第 15 節：實作 Microsoft Entra 密碼保護服務 (也適用於內部部署環境！)
可用的 Microsoft 頂級\統一支援訓練
如果您想要深入瞭解 Microsoft Entra Password Protection 以及如何部署它，您可以使用Microsoft主動式服務。 此服務適用於具有頂級或統一支援合約的客戶。 服務稱為 Microsoft Entra ID：密碼保護。 如需詳細資訊，請連絡客戶成功專案經理。