Active Directory 的預設密碼複雜度原則在 Windows Server 2016 與 2019 上要求密碼至少 7 個字元,在 Windows Server 2022 及之後版本則要求至少 8 個字元,並規定密碼必須從五大類字元中至少包含三類:大寫字母、小寫字母、數字、非英數符號,以及 Windows 歸類為字母性質的任何 Unicode 字元。這個五分類規則就是著名的「3 選 5」組成檢查,每當網域控制站處理密碼變更時就會觸發。若您候選的字串未通過任何一項條件,控制站會拒絕這次變更,並顯示一個明確指出未滿足哪項要求的錯誤訊息。由於該錯誤僅在提交那一刻才會顯示,大多數使用者都希望能事先評估候選字串。先讀取網域的實際原則,再用透明的計量工具在本機檢視候選字串,就能在進入密碼變更對話框之前,事先知道該值是否會通過。

how to check password complexity requirements in active directory
how to check password complexity requirements in active directory

Active Directory 的預設密碼複雜度原則

全新 Active Directory 網域所隨附的原則是由預設網域原則 (Default Domain Policy) 所設定,並由每一部網域控制站強制執行。相關設定位於 電腦設定 > 原則 > Windows 設定 > 安全性設定 > 帳戶原則 > 密碼原則。其中有兩項設定會直接影響複雜度:密碼長度下限 與 密碼必須符合複雜度需求。

最小長度是嚴格的下限;任何短於該長度的密碼會在進入複雜度檢查之前就被拒絕。預設值在不同的 Windows Server 版本之間有過調整。在 Windows Server 2016 與 2019 上,預設為 7 個字元。在 Windows Server 2022 及更新版本上,預設為 8 個字元。許多組織會進一步提高下限,常見為 12 或 14,以符合現行的 NIST SP 800-63B 記憶型密碼 (memorized secrets) 指引。

複雜度旗標會啟用「3 選 5」組成規則。當此旗標為啟用時,控制站會對所提出的密碼中每個字元進行分類,並計算五大類中實際出現了幾類。候選密碼必須命中至少三個不同的分類,否則會被拒絕。該五大分類如下:

  • 大寫字母 - 英文字母 A-Z,以及 Windows 所辨識的任何其他 Unicode 大寫字母。
  • 小寫字母 - 英文字母 a-z,以及任何其他 Unicode 小寫字母。
  • 數字 - 0 到 9。
  • 非英數符號 - 例如 !、@、#、$、% 等字元,以及各種標點符號與數學運算子。
  • Unicode 字元 - 任何被 Windows 歸類為字母性質、但不屬於前三類的字元,包括帶重音的拉丁字母、西里爾字母、希臘字母等。

「3 選 5」規則是一種組成規則,而組成規則正是 OWASP 身分驗證速查表 所標記為弱點的設計:使用者為了應付強制性的組成要求,會做出可預測的替換,例如將第一個字母大寫並在尾端加上一個數字。長度與封鎖清單篩選對帳號的保護效果其實比組成規則更佳,但只要該旗標為啟用,組成規則仍然是 Active Directory 強制執行的規則。

讀取您實際的網域原則

上述預設值描述的是一個剛建置好的網域,並不一定就是您目前實際使用的原則。在測試候選字串之前,請先讀取真正的原則,以了解您要瞄準的確切下限。以下三種方法皆無需安裝任何新軟體。

從成員工作站,使用 net accounts:

  1. 開啟命令提示字元。
  2. 輸入 net accounts 並按下 Enter。
  3. 讀取 Minimum password length (密碼長度下限)、Length of password history maintained (保留的密碼歷程長度)、Maximum password age (days) (密碼最長有效期,以天為單位),以及 Minimum password age (days) (密碼最短有效期,以天為單位) 等行。

這會顯示套用至本機電腦的有效原則。若有針對特定使用者的精細密碼原則 (fine-grained password policy) 覆寫了它,net accounts 並不會反映該覆寫;您必須使用下列另外兩種方法之一。

使用 gpresult 取得原則來源:

  1. 開啟命令提示字元。
  2. 輸入 gpresult /r | findstr "Default Domain Policy",以確認該原則物件已套用。
  3. 執行 gpresult /h gp.html,產生一份可在瀏覽器中開啟的 HTML 報告,然後展開 電腦設定 > Windows 設定 > 安全性設定 > 帳戶原則。

使用 PowerShell,直接對網域進行查詢:

  1. 開啟已載入 Active Directory 模組的 PowerShell。
  2. 執行 Get-ADDefaultDomainPasswordPolicy,讀取整個網域的預設原則。
  3. 若要查詢特定使用者,請執行 Get-ADUserResultantPasswordPolicy -Identity samAccountName,以查看任何精細密碼原則的覆寫。
原則設定 預設值 控制項目
Minimum password length (密碼長度下限) 7 (Server 2016/2019),8 (Server 2022+) 字元數的嚴格下限
Password must meet complexity requirements (密碼必須符合複雜度需求) Enabled (已啟用) 強制採用 5 類字元中的 3 類
Maximum password age (密碼最長有效期) 42 天 密碼保持有效的時間長度
Minimum password age (密碼最短有效期) 1 天 兩次變更之間的最短間隔時間
Password history (密碼歷程) 記住 24 組密碼 防止重複使用的計數
Account lockout threshold (帳戶鎖定閾值) 0 (預設為停用) 鎖定前的失敗嘗試次數

依據上述規則預先檢查候選字串

一旦您知道網域所強制執行的下限,即可在開啟密碼變更對話框之前先評估候選字串。本機審查工具是無需傳送候選字串就能快速完成此作業的最佳方式。Password Strength Checker (密碼強度檢查工具) 完全在瀏覽器中執行,以 Unicode 碼點 (code point) 而非 UTF-16 單位來計算,會回報描述性的字元分類數,標記出簡單的重複片段與四字元單調序列,並套用與現行 NIST 指引相符的已公布長度級距。

  1. 開啟 Password Strength Checker,輸入或貼上所提出的密碼。除非您按下 Show (顯示),否則輸入內容會保持在本機且隱藏;資料不會離開瀏覽器。
  2. 讀取以碼點計算的長度與字元分類摘要。針對 Active Directory 的候選密碼,請確認您至少使用了三個分類 - 大寫、小寫、數字、符號或 Unicode 字母 - 且長度達到或超過您網域的下限。
  3. 檢查模式旗標。簡單的重複片段或升冪/降冪的四字元序列會將評分上限壓在 Fair (尚可),無論長度為何,這是一個有用的訊號,表示該候選密碼即使通過組成規則,仍過於可預測。
  4. 讀取每一項建議。請優先以增加長度、再增加獨特性的方式調整候選密碼,而不是用像 Password1! 這樣的替換方式來硬湊組成規則。
  5. 當本機計量工具顯示滿意後,透過正常的 Active Directory 變更對話框提交密碼,並確認控制站接受該密碼。請搭配密碼管理工具中的唯一一筆紀錄一起使用,以免因重複使用而削弱強度。

這個流程能在您浪費一次密碼變更嘗試並觸發歷程計數器累加之前,先抓出最常見的拒絕原因 - 太短、僅使用兩個字元分類,或可一眼看穿的模式。

計量工具如何計算長度

Unicode 碼點是一個單一的純量值,不論其在儲存時佔用多少位元組或 UTF-16 單位。計量工具以碼點計算,Active Directory 本身的分類步驟也是如此,這讓兩者的審查結果保持一致。

公式: 以碼點計算的長度 = 字串中的 Unicode 純量值數量

範例字串: cat-Dog-2026-🌅

逐一計算每個純量:c-a-t (3) + 短橫 (4) + D-o-g (7) + 短橫 (8) + 2-0-2-6 (12) + 短橫 (13) + 日出表情符號 (14)。結果為 14 個碼點。日出表情符號僅貢獻一個碼點,即使在傳輸時佔用兩個 UTF-16 單位。因此候選字串會回報為 14 個字元,已超過預設的 8 字元下限。字元分類摘要顯示小寫字母、大寫字母、數字、符號,以及一個非 ASCII 字元 - 為計量工具所回報的六類中的五類 - 故此值在這些條件上也滿足 Active Directory 的「3 選 5」複雜度規則。

為何本機計量工具無法取代網域強制執行

本機審查能提供早期訊號,但網域控制站永遠是唯一真相來源。以下三項檢查僅會在伺服器端進行:

  • 密碼歷程。 控制站會將您的新值與最近 24 組雜湊 (或您原則所規定的數量) 進行比對;本機計量工具看不到那些雜湊。
  • 個別使用者的精細原則。 系統管理帳號或具特殊權限的群組可能有更高的長度下限與更嚴格的鎖定原則,Get-ADDefaultDomainPasswordPolicy 並不會顯示這些;只有 Get-ADUserResultantPasswordPolicy 才會顯示。
  • 混合身分識別的 Azure AD 覆寫。 當使用者被同步至 Microsoft 365 時,雲端預設原則為 8 個字元並採用相同的複雜度規則,但如禁用密碼偵測等額外控制項是在雲端執行,無法從本機瀏覽器工具進行檢查。

基於上述原因,計量工具最恰當的定位是「預先檢查」而非「保證」。請將其 Strong (強) 等級視為該候選密碼大致不錯的證據,然後再到伺服器端確認是否被接受。

超越組合規則：真正保護帳號的是什麼

組合規則很容易滿足，也很容易規避。真正能大幅降低帳號被盜風險的保護措施則不同。

  • 長度。 根據 NIST SP 800-63B，當密碼是唯一的認證因素時，短於 15 個字元的密碼是弱的。只要服務允許，應力求達到 15 至 20 個字元以上。
  • 唯一性。 在多個系統間重複使用同一組密碼，會讓任何單一外洩事件演變成多系統的連帶受駭。請使用本機密碼產生器為每個帳號產生全新的密碼，並儲存在密碼管理工具中。
  • 黑名單篩檢。 將候選密碼的完整內容與該帳號提供者的已知外洩密碼清單進行比對。這正是能攔截像 Password1! 這類密碼的關鍵——即使它滿足了 3 選 5 的規則。
  • 多因素認證。 第二重認證因素，特別是能抗釣魚的 passkey 或硬體權杖，可以徹底抵消被猜中或竊取的密碼所帶來的風險。
  • 被動式更換。 應在密碼遭到重複使用、外洩或疑似遭到破解時予以更換，而不是按照固定週期輪換。

結合這五項控制措施才是真正的防線。Active Directory 所執行的組合規則檢查只是分層防禦中的一環，而非阻擋攻擊者的那一層。

如果您正在權衡各種選擇，如何在 Google 密碼管理工具中產生密碼對此有詳細說明。

如果您正在權衡各種選擇，Base58 解碼速查表：字母表、十六進位與規則對此有詳細說明。