本節提供許多 Microsoft Entra 密碼保護常見問題的解答。
一般問題
使用者可以使用哪些指引來瞭解如何選取安全密碼？
下列連結是目前 Microsoft 中有關本主題的指引：
非公用雲端是否支援內部部署 Microsoft Entra 密碼保護？
Azure 全域和 Azure Government 雲端都支援內部部署 Microsoft Entra 密碼保護。
Microsoft Entra 系統管理中心允許修改內部部署特定的「Windows Server Active Directory 的密碼保護」設定，即使在不支援的雲端中亦然；這類變更將會保存，但永遠不會生效。 在不支援的雲端中不支援註冊內部部署 Proxy 代理程式或樹系，且任何這類的註冊嘗試一律會失敗。
如何讓內部部署使用者的子集受益於 Microsoft Entra 密碼保護？
不支援。 部署並啟用之後，Microsoft Entra 密碼保護會一視同仁，所有使用者都會受惠於相同的安全性優點。
密碼變更和密碼設定 (或重設) 之間有何差異？
密碼變更是指使用者在證明自己知道舊密碼之後選擇新的密碼。 例如，若在使用者登入 Windows 時，系統提示使用者選擇新密碼，就會進行密碼變更。
當系統管理員將帳戶的密碼取代為新密碼 (例如，使用 Active Directory 使用者和電腦管理工具) 時，則屬於密碼設定 (有時稱為密碼重設)。 此作業需要高層級的權限 (通常是網域管理員)，而執行此作業的人員通常不知道舊密碼。 技術支援人員常會執行密碼設定，例如，協助忘記密碼的使用者。 在第一次使用密碼建立全新的使用者帳戶時，您也會看到密碼設定事件。
無論執行的是密碼變更還是密碼設定，密碼驗證原則的行為都相同。 Microsoft Entra 密碼保護 DC 代理程式服務會記錄不同的事件，以通知您密碼變更或設定作業是否已完成。 請參閱 Microsoft Entra 密碼保護的監視和記錄。
Microsoft Entra 密碼保護是否會在安裝後驗證現有的密碼？
否 - Microsoft Entra 密碼保護只能在密碼變更或設定作業期間，對純文字密碼強制執行密碼原則。 一旦 Active Directory 接受密碼，就只會保存該密碼的驗證通訊協定特定雜湊。 純文字密碼一律不會保存，因此 Microsoft Entra 密碼保護無法驗證現有的密碼。
初始部署 Microsoft Entra 密碼保護之後，所有使用者和帳戶最終將開始使用 Microsoft Entra 密碼保護驗證的密碼，因為其現有密碼應會在一段時間後到期。 如有需要，可透過一次性的使用者帳戶密碼手動到期，讓此程序加速執行。
除非執行手動到期，否則一律不會強制設定了「密碼永久有效」的帳戶變更其密碼。
嘗試使用 Active Directory 使用者和電腦管理嵌入式管理單元來設定弱式密碼時，為何會記錄重複的密碼拒絕事件？
Active Directory 使用者和電腦管理嵌入式管理單元會先嘗試使用 Kerberos 通訊協定設定新密碼。 如果失敗，嵌入式管理單元會使用舊版 (SAM RPC) 通訊協定再次嘗試設定密碼 (具體使用何種通訊協定並不重要)。 如果 Microsoft Entra 密碼保護將新密碼視為弱式密碼，此嵌入式管理單元的行為將導致系統記錄兩組密碼重設拒絕事件。
為何使用空白的使用者名稱來記錄 Microsoft Entra 密碼保護密碼驗證事件？
Active Directory 支援測試密碼以確認是否符合網域目前的密碼複雜性需求的功能，例如使用 NetValidatePasswordPolicy api。 以此方式驗證密碼時，測試也會包含以密碼篩選器 dll 為基礎的產品 (例如 Microsoft Entra 密碼保護) 執行的驗證，但傳遞給指定密碼篩選 dll 的使用者名稱將會是空的。 在此案例中，Microsoft Entra 密碼保護仍會使用目前作用中的密碼原則來驗證密碼，且會發出事件記錄檔訊息來取得結果，但事件記錄檔訊息的使用者名稱欄位將是空白的。
我的混合式使用者嘗試在 Microsoft Entra ID 中變更密碼，但收到回應「此密碼已多次受使用。 請選擇較難猜出的密碼。」請選擇較難猜中的密碼。」在此情況下，為什麼沒看到內部嘗試驗證？
當混合式使用者在 Microsoft Entra ID 中變更密碼時，無論是透過 Microsoft Entra SSPR、MyAccount 或其他 Microsoft Entra 密碼變更機制，將會根據雲端上的全域和自訂禁用密碼清單來評估其密碼。 當密碼透過密碼回寫而到達 Active Directory 時，表示已在 Microsoft Entra ID 中驗證過。
關於混合式使用者在 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 中完全不支援。 在 FRS 設定的網域上，完全不會執行任何 Microsoft Entra 密碼保護測試。
如需詳細資訊，請參閱下列文章：
將 sysvol 複寫移轉至 DFSR 的案例 \(英文\)
FRS 終章將至 \(英文\)
如果您的網域尚未使用 DFSR，您必須先將其遷移以使用 DFSR，再安裝 Microsoft Entra 密碼保護。 如需詳細資訊，請前往下面連結：
警告
Microsoft Entra 密碼保護 DC 代理程式軟體目前會安裝在仍使用 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 密碼保護 Proxy 軟體所安裝的 Microsoft Entra Connect 代理程式更新程式服務的版本，與 Microsoft Entra 應用程式 Proxy 軟體所安裝的服務版本並不相容。 此一不相容可能會導致代理程式更新程式服務無法與 Azure 連線以進行軟體更新。 建議您不要在同一部機器上安裝 Microsoft Entra 密碼保護 Proxy 和 Microsoft Entra 應用程式 Proxy。
DC 代理程式和 Proxy 要以何種順序進行安裝及註冊？
支援不分先後順序安裝 Proxy 代理程式、安裝 DC 代理程式、註冊樹系及註冊 Proxy。
是否應該顧慮到部署此功能時，對網域控制站造成的效能衝擊？
在狀況良好的現有 Active Directory 部署中，Microsoft Entra 密碼保護 DC 代理程式服務應不會大幅影響網域控制站效能。
對大部分的 Active Directory 部署而言，任何指定網域控制站上的密碼變更作業都是整體工作負載的一小部分。 例如，假設某個 Active Directory 網域有 10000 個使用者帳戶，而 MaxPasswordAge 原則設為 30 天。 平均而言，此網域每天會看到 10000/30=~333 個密碼變更作業，甚至對單一網域控制站而言，這都是很小的作業量。 考慮到可能最糟糕的情況：假設單一 DC 上的這 ~333 個密碼變更作業需要在一小時左右完成。 例如，許多員工都在星期一早上進行工作時，就可能會發生此情況。 即使在該情況下，我們仍然可看到每分鐘有 ~333/60 分鐘 = 6 個密碼變更作業，這依然不是龐大的負載。
不過，如果您目前的網域控制站已在效能受限的層級上執行 (例如 CPU、磁碟空間和磁碟 I/O 等已達到極限)，建議您先新增其他網域控制站或擴展可用磁碟空間，然後再部署這項功能。 另請參閱上面有關 Sysvol 磁碟空間使用量的問題。
我只想在網域中的幾個 DC 上測試 Microsoft Entra 密碼保護。 有可能強制使用這些特定 DC 來進行使用者密碼變更作業嗎？
否。 使用者變更其密碼時，Windows 用戶端 OS 會控制要使用哪一個網域控制站。 網域控制站的選取會取決於 Active Directory 站台和子網路指派，以及環境特有網路設定等因素。 Microsoft Entra 密碼保護不會控制這些因素，也無法影響要選取哪個網域控制站來變更使用者密碼。
可部分達成此目標的方法之一是，在指定 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 密碼保護安全性的優勢。
為何即使在內部部署 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 和樹系。
使用網域管理員認證 (或其他有足夠權限可建立測試使用者帳戶和重設密碼的認證)，登入已安裝 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 does not 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 did not comply with the current Azure password policy. Please see the correlated event log message for more details. 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 did not 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 have been 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 密碼保護文件，但可能是適用於此功能的其他資訊來源。
電子郵件網路釣魚防護指南 – 第 15 節：實作 Microsoft Entra 密碼保護服務 (也適用於內部部署環境！)
可用的 Microsoft 頂級\統一支援訓練
如果您想要深入瞭解 Microsoft Entra 密碼保護，並將其部署在您的環境中，可利用提供給頂級或統一支援合約客戶的 Microsoft 主動式服務。 服務稱為 Microsoft Entra ID：密碼保護。 如需詳細資訊，請連絡客戶成功專案經理。