正在實行最低權限管理型號

發行項
02/21/2024
適用於:

✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

下列摘錄來自 Administrator 帳戶安全性規劃指南，最初於 1999 年 4 月 1 日發佈：

「大部分與安全性相關的訓練課程和文件會討論最低權限原則的實作，但組織很少遵循此原則。原則很簡單，而且正確套用它的影響可大幅提升您的安全性並降低風險。原則會指出所有使用者都應該使用具有完成目前工作所需絕對最低權限的使用者帳戶登入，而不需要更多權限。這樣做可抵禦惡意程式碼，以及其他攻擊。此原則適用於電腦和這些電腦的使用者。「此原則非常有效的一個原因是它迫使你進行一些內部研究。例如，您必須判斷電腦或使用者真正需要的存取權限，然後實作這些權限。對許多組織而言，這項工作一開始看起來可能相當繁瑣；不過，對於成功保護您的網路環境而言是一個重要步驟。「您應該以最低權限的概念授與所有網域系統管理員使用者其網域權限。例如，如果系統管理員以特殊權限帳戶登入，且意外執行病毒程式，則病毒具有本機電腦和整個網域的系統管理存取權。如果系統管理員改為使用非特殊權限 (非系統管理) 帳戶登入，則病毒的損害範圍只會是本機電腦，因為它以本機電腦使用者身分執行。「在另一個範例中，您授與網域層級系統管理員權限的帳戶不得在另一個樹系中擁有較高的權限，即使樹系之間有信任關係也一樣。如果攻擊者設法入侵一個受管理的樹系，此策略有助於防止損害擴大。組織應定期稽核其網路，以防止未經授權的權限提升。」

下列摘錄來自 Microsoft Windows 安全性資源套件，首次發行於 2005 年：

「一律考慮安全性，也就是授與執行工作所需的最低權限。如果有太多權限的應用程式應該遭到入侵，攻擊者便可能能夠將攻擊擴大到超出應用程式在可能最低權限以內的範圍。例如，檢查網路系統管理員不知情地開啟啟動病毒的電子郵件附件的後果。如果系統管理員使用網域 Administrator 帳戶登入，則病毒會在網域中的所有電腦上具有系統管理員權限，因此不會限制對網路上幾乎所有資料的存取。如果系統管理員使用本機 Administrator 帳戶登入，則病毒會在本機電腦上具有系統管理員權限，因此將能夠存取電腦上的任何資料，並在電腦上安裝惡意軟體，例如鍵盤側錄軟體。如果系統管理員使用一般使用者帳戶登入，則病毒將只能存取系統管理員的資料，且無法安裝惡意軟體。在此範例中，藉由使用讀取電子郵件所需的最低權限，入侵的潛在範圍會大幅縮小。」

權限問題

上述摘錄中所述的原則沒有變更，但在評估 Active Directory 安裝時，我們總是發現已授與權限的帳戶數量遠遠超出執行日常工作所需的權限。環境的大小會影響過度特殊權限帳戶的原始數目，但中型目錄在最高權限群組中可能有數十個帳戶，而大型安裝可能會有數百或甚至數千個帳戶。除了少數例外狀況，無論攻擊者技能和工具的複雜程度為何，攻擊者通常會依循抵抗最少的途徑。只有在較簡單的機制失敗或遭到防禦程式阻擋時，它們才會增加其工具和方法的複雜性。

不幸的是，許多環境中抗最少的途徑經證明是過度使用具有廣泛和深層權限的帳戶。廣泛的權限是可讓帳戶跨環境中大型跨區段執行特定活動的權限；例如，技術支援中心人員可能會獲授與權限，可讓他們在許多使用者帳戶上重設密碼。

深層權限是適用於一小部分人的強大權限，例如在伺服器上授與工程師 Administrator 權限，以便執行修復。廣泛權限和深層權限都不一定很危險，但是當網域中的許多帳戶永久獲得廣泛和深層權限時，如果只有其中一個帳戶遭到入侵，它就可以用來根據攻擊者的目的將環境重新設定，甚至破壞基礎結構的大型區段。

傳遞雜湊攻擊是一種無處不在的認證竊取攻擊類型，因為執行這些攻擊的工具可免費取得且易於使用，且許多環境都容易受到攻擊。不過，傳遞雜湊攻擊並不是真正的問題。問題的癥結有兩個層面：

攻擊者通常很容易在單一電腦上取得深層權限，然後將該權限廣泛地傳播至其他電腦。
在計算環境中，通常會有太多具有高層級權限的永久帳戶。

即使消除了傳遞雜湊攻擊，攻擊者仍只會使用不同的戰略，而非不同的策略。與其植入包含認證竊取工具的惡意程式碼，不如植入鍵盤側錄的惡意程式碼，或利用任意數目的其他方法來擷取環境中功能強大的認證。無論戰略如何，目標都保持不變：具有廣泛和深入權限的帳戶。

過度權限的授與不僅存在於受危害環境中的 Active Directory 中。當組織養成了授與超出所需權限的習慣時，通常會在整個基礎結構中發現這種情況，如下列幾節所討論。

在 Active Directory 中

在 Active Directory 中，通常會發現 EA、DA 和 BA 群組包含過多的帳戶數目。最常見的情況是，組織的 EA 群組包含最少的成員、DA 群組通常包含 EA 群組中使用者數目的數倍，而 Administrator 群組通常包含比其他群組合併後總數更多的成員。這通常是因為認為 Administrator 比起 DA 或 EA「權限較低」。雖然授與給每個群組的權限不同，但其應該有效地被視為同樣強大的群組，因為其中一個成員可以讓自己成為其他兩個群組的成員。

在成員伺服器上

當我們擷取許多環境中成員伺服器上本機 Administrator 群組的成員資格時，我們發現成員資格範圍從少數本機和網域帳戶，一直到數十個巢狀群組，這些群組在展開時會顯示數百個甚至數千個帳戶，並在伺服器上具有本機 Administrator 權限。在許多情況下，具有大型成員資格的網域群組會巢狀化於成員伺服器的本機 Administrator 群組中，而未考慮任何可以修改網域中這些群組成員資格的使用者，都可以取得群組已巢狀化於本機 Administrator 群組中之所有系統的系統管理控制權。

在工作站上

雖然工作站在其本機 Administrator 群組中通常比成員伺服器的成員少得多，但在許多環境中，使用者會被授與其個人電腦上的本機 Administrator 群組成員資格。當發生這種情況時，即使已啟用 UAC，這些使用者也會對其工作站的完整性造成較高的風險。

重要

您應該仔細考慮使用者是否在其工作站上需要系統管理權限，如果他們需要，更好的方法是在屬於 Administrator 群組成員的電腦上建立個別的本機帳戶。當使用者需要提高權限時，他們可以出示該本機帳戶的認證以提升權限，但由於帳戶是本機帳戶，因此無法用來入侵其他電腦或存取網域資源。不過，如同任何本機帳戶，本機特殊權限帳戶的認證應該是唯一的；如果您在多個工作站上建立具有相同認證的本機帳戶，則會將電腦暴露於傳遞雜湊攻擊。

在應用程式中

在目標為組織智慧財產權的攻擊中，已獲授與應用程式內強大權限的帳戶可能會遭到鎖定，以實現資料外洩為目標。雖然具有敏感性資料存取權的帳戶可能未獲授與網域或作業系統中較高的權限，但是可以操作應用程式設定，或存取應用程式所提供資訊的帳戶可能會造成風險。

在資料存放庫中

如同其他目標的情況，攻擊者會以文件和其他檔案的形式尋求智慧財產權的存取權，而其目標可能是控制檔案存放區存取權的帳戶、直接存取檔案的帳戶，甚至是可存取檔案的群組或角色。例如，如果使用檔案伺服器來儲存合約文件，並使用 Active Directory 群組授與文件的存取權，則可以修改群組成員資格的攻擊者便能夠將遭入侵的帳戶新增至群組並存取合約文件。在 SharePoint 等應用程式提供文件存取權的情況下，攻擊者可以如先前所述以應用程式為目標。

降低權限

環境愈大且愈複雜時，管理及保護便愈困難。在小型組織中，檢閱和降低權限可能是一個相對簡單的命題，但組織中每個額外的伺服器、工作站、使用者帳戶和應用程式都會新增另一個必須保護的物件。由於難以或甚至不可能正確保護組織 IT 基礎結構的每個層面，因此您應該先將精力放在權限造成最大風險的帳戶上，這通常是 Active Directory 中內建的特殊權限帳戶和群組，以及工作站和成員伺服器上的特殊權限本機帳戶。

保護工作站和成員伺服器上的本機 Administrator 帳戶

儘管如先前所述本文件著重於保護 Active Directory，但對目錄的大多數攻擊都是從針對個別主機的攻擊開始。無法提供保護成員系統上本機群組的完整指導方針，但下列建議可用來協助您保護工作站和成員伺服器上的本機 Administrator 帳戶。

保護本機 Administrator 帳戶

在目前處於主流支援的所有 Windows 版本上，預設會停用本機 Administrator 帳戶，讓帳戶無法用於傳遞雜湊和其他認證竊取攻擊。不過，在包含舊版作業系統或已啟用本機 Administrator 帳戶的網域中，這些帳戶可以如先前所述，在成員伺服器和工作站之間傳播入侵。基於這個原因，針對已加入網域系統上的所有本機 Administrator 帳戶建議使用下列控制項。

如需實作這些控制項的詳細指示，請參閱附錄 H：保護本機 Administrator 帳戶和群組。不過，在實作這些設定之前，請確定環境中目前未使用本機 Administrator 帳戶在電腦上執行服務，或執行不應該使用這些帳戶的其他活動。在生產環境中實作這些設定之前，請先徹底測試這些設定。

本機 Administrator 帳戶的控制項

內建的 Administrator 帳戶絕不應當作成員伺服器上的服務帳戶使用，也不應該用來登入本機電腦 (除非在安全模式中，即使帳戶已停用也允許使用)。實作此處所述的設定的目的是要防止每部電腦的本機 Administrator 帳戶可供使用，除非先反轉保護控制項。藉由實作這些控制項並監視 Administrator 帳戶的變更，您可以大幅降低以本機 Administrator 帳戶為目標的攻擊成功可能性。

設定 GPO 以限制已加入網域系統上的 Administrator 帳戶

在每一個網域中建立並連結至工作站和成員伺服器 OU 的一或多個 GPO 中，將 Administrator 帳戶新增至 [電腦設定\原則\Windows 設定\安全性設定\本機原則\使用者權限指派] 中的下列使用者權限：

拒絕從網路存取這台電腦
拒絕以批次工作登入
拒絕以服務方式登入
拒絕透過遠端桌面服務登入

當您將 Administrator 帳戶新增至這些使用者權限時，請指定您透過標記帳戶的方式新增本機 Administrator 帳戶或網域的 Administrator 帳戶。例如，若要將 NWTRADERS 網域的 Administrator 帳戶新增至這些拒絕權限，您需要將帳戶輸入為 NWTRADERS\Administrator，或瀏覽至 NWTRADERS 網域的 Administrator 帳戶。若要確保您限制本機 Administrator 帳戶，請在群組原則物件編輯器中的這些使用者權限設定中輸入 Administrator。

注意

即使本機 Administrator 帳戶已重新命名，原則仍會套用。

這些設定可確保電腦 Administrator 帳戶無法用來連線至其他電腦，即使該電腦意外或惡意啟用也一樣。您無法完全停用使用本機 Administrator 帳戶的本機登入，也不應該嘗試這麼做，因為電腦的本機 Administrator 帳戶是設計成用於災害復原案例。

如果成員伺服器或工作站脫離網域，而沒有其他本機帳戶獲授與系統管理權限，則電腦可以開機進入安全模式，且可以啟用 Administrator 帳戶，然後可以使用帳戶來影響電腦上的修復。修復完成時，應該再次停用 Administrator 帳戶。

保護 Active Directory 中具特殊權限的本機帳戶和群組

定律六：電腦只有在系統管理員值得信任時才安全。 - 安全性十大定律 (2.0 版)

此處提供的資訊旨在提供一般指導方針，以保護 Active Directory 中具有最高權限的內建帳戶和群組。如需詳細逐步指示，另請參閱附錄 D：保護 Active Directory 中的內建 Administrator 帳戶、附錄 E：保護 Active Directory 中的 Enterprise Admins 群組、附錄 F：保護 Active Directory 中的 Domain Admins 群組，以及附錄 G：保護 Active Directory 中的 Administrator 群組。

在實作任何設定之前，您也應該徹底測試所有設定，以判斷它們是否適合您的環境。並非所有組織都能夠實作這些設定。

保護 Active Directory 中的內建 Administrator 帳戶

在 Active Directory 的每個網域中，系統會在建立網域時建立 Administrator 帳戶。此帳戶預設為網域中 Domain Admins 和 Administrator 群組的成員，而且，如果網域是樹系根網域，則帳戶也是 Enterprise Admins 群組的成員。網域中本機 Administrator 帳戶的使用應該只保留給初始建置活動，也可能是災害復原案例。若要確保可以在未使用任何其他帳戶的情況下使用內建 Administrator 帳戶來進行修復，您不應該變更樹系內任何網域中 Administrator 帳戶的預設成員資格。相反地，您應該遵循指導方針來協助保護樹系中每個網域中的 Administrator 帳戶。如需實作這些控制項的詳細指示，請參閱附錄 D：保護 Active Directory中的內建 Administrator 帳戶。

內建 Administrator 帳戶的控制項

實作此處所述的設定的目的是要防止每個網域的本機 Administrator 帳戶 (非群組) 可供使用，除非反轉幾個控制項。藉由實作這些控制項並監視 Administrator 帳戶的變更，您可以大幅降低利用網域 Administrator 帳戶成功攻擊的可能性。針對樹系中每個網域中的 Administrator 帳戶，您應該設定下列設定。

啟用帳戶上的「這是機密帳戶，無法委派」旗標

根據預設，Active Directory 中的所有帳戶都可以委派。委派可讓電腦或服務向其他電腦出示已向電腦或服務驗證的帳戶憑證，以代表帳戶取得服務。當您啟用網域型帳戶上的 [帳戶具敏感性，因此無法委派] 屬性時，帳戶的認證無法出示給網路上的其他電腦或服務，這會限制利用委派的攻擊在其他系統上使用帳戶的認證。

啟用帳戶上的「互動式登入必須使用智慧卡」旗標

當您啟用帳戶上的 [互動式登入必須使用智慧卡] 屬性時，Windows 會將帳戶的密碼重設為 120 個字元的隨機值。藉由在內建的 Administrator 帳戶上設定此旗標，您可確保帳戶的密碼不僅夠長而複雜，且任何使用者皆無法得知。在啟用此屬性之前，技術上不需要為帳戶建立智慧卡，但可能的話，在設定帳戶限制之前，應該為每個 Administrator 帳戶建立智慧卡，且智慧卡應該儲存在安全的位置。

雖然設定 [互動式登入必須使用智慧卡] 旗標會重設帳戶的密碼，但不會防止具有重設帳戶密碼權限的使用者將帳戶設定為已知值，以及使用帳戶的名稱和新密碼來存取網路上的資源。因此，您應該在帳戶上實作下列其他控制項。

設定 GPO 以限制已加入網域系統上的網域 Administrator 帳戶

雖然停用網域中的 Administrator 帳戶可有效地讓帳戶無法使用，但當帳戶意外或惡意啟用時，您應該在帳戶上實作其他限制。雖然這些控制項最終可由 Administrator 帳戶反轉，但目標是建立控制來減緩攻擊者的進度，並限制帳戶可能遭受的損害。

在每個網域中建立並連結至工作站和成員伺服器 OU 的一或多個 GPO 中，將每個網域的 Administrator 帳戶新增至 [電腦設定\原則\Windows 設定\安全性設定\本機原則\使用者權限指派] 中的下列使用者權限：

拒絕從網路存取這台電腦
拒絕以批次工作登入
拒絕以服務方式登入
拒絕透過遠端桌面服務登入

注意

當您將本機 Administrator 帳戶新增至此設定時，必須指定您要設定本機 Administrator 帳戶還是網域 Administrator 帳戶。例如，若要將 NWTRADERS 網域的本機 Administrator 帳戶新增至這些拒絕權限，您必須將帳戶輸入為 NWTRADERS\Administrator，或瀏覽至 NWTRADERS 網域的本機 Administrator 帳戶。如果您在群組原則物件編輯器內的這些使用者權限設定中輸入 Administrator，則將會限制每部套用 GPO 之電腦上的本機 Administrator 帳戶。

建議使用與網域型 Administrator 帳戶相同的方式，來限制成員伺服器和工作站上的本機 Administrator 帳戶。因此，您一般應該會將樹系內每個網域的 Administrator 帳戶以及本機電腦的 Administrator 帳戶新增至這些使用者權限設定。

設定 GPO 以限制網域控制站上的 Administrator 帳戶

在樹系的每個網域中，應該修改預設網域控制站原則或連結至網域控制站 OU 的原則，以將每個網域的 Administrator 帳戶新增至 [電腦設定\原則\Windows 設定\安全性設定\本機原則\使用者權限指派] 中的下列使用者權限：

拒絕從網路存取這台電腦
拒絕以批次工作登入
拒絕以服務方式登入
拒絕透過遠端桌面服務登入

注意

這些設定將確保無法使用本機 Administrator 帳戶來連線至網域控制站，不過若啟用此帳戶，則可以在本機登入至網域控制站。因為此帳戶只應該啟用及用於災害復原案例，所以預期至少可以使用一個網域控制站的實體存取，或者可以使用具有遠端存取網域控制站權限的其他帳戶。

設定內建 Administrator 帳戶的稽核

當您保護每個網域的 Administrator 帳戶並停用帳戶時，應該設定稽核來監視帳戶的變更。如果帳戶已啟用、重設其密碼，或對帳戶進行任何其他修改，則除了組織中的事件回應小組之外，應該還會將警示傳送給負責 AD 系統管理的使用者或小組。

保護 Administrator、Domain Admins 和 Enterprise Admins 群組

保護 Enterprise Admins 群組

位於樹系根網域內的 Enterprise Admins 群組每一天都不應該包含任何使用者，但網域的本機 Administrator 帳戶例外，前提是其受到保護，如先前以及附錄 D：保護 Active Directory 中的內建系統管理員帳戶中所述。

需要 EA 存取權時，帳戶需要 EA 權限的使用者應該暫時放入 Enterprise Admins 群組中。雖然使用者使用的是高度特殊權限帳戶，但應該稽核其活動，最好是與執行變更的使用者一起執行，而另一位使用者觀察變更，以將意外誤用或設定錯誤的可能性降到最低。當活動完成時，應該從 EA 群組中移除帳戶。這可以透過手動程序和記載的程序、協力廠商特殊權限身分識別/存取管理 (PIM/PAM) 軟體或兩者的組合來達成。如需建立帳戶以用來控制 Active Directory 中特殊權限群組成員資格的指導方針，請參閱常成為認證竊取目標的帳戶，而附錄 I：為 Active Directory 中的受保護帳戶和群組建立管理帳戶中提供詳細的指示。

根據預設，Enterprise Admins 是樹系中每個網域內建 Administrator 群組的成員。從每個網域中的 Administrator 群組移除 Enterprise Admins 群組是不適當的修改，因為在發生樹系災害復原案例時，可能需要 EA 權限。如果 Enterprise Admins 群組已從樹系中的 Administrator 群組中移除，則應該將其新增至每個網域中的 Administrator 群組，且應實作下列其他控制項：

如先前所述，Enterprise Admins 群組不應每天包含任何使用者，但樹系根網域 Administrator 帳戶在可能的例外狀況下應受到保護，如附錄 D︰保護 Active Directory 中的內建 Administrator 帳戶中所述。
在連結至包含每個網域成員伺服器和工作站之 OU 的 GPO 中，EA 群組應該新增至下列使用者權限：
- 拒絕從網路存取這台電腦
- 拒絕以批次工作登入
- 拒絕以服務方式登入
- 拒絕本機登入
- 拒絕透過遠端桌面服務登入。

這可防止 EA 群組的成員登入成員伺服器和工作站。如果跳躍伺服器用來管理網域控制站和 Active Directory，請確定跳躍伺服器位於未連結受限 GPO 的 OU 中。

如果對 EA 群組的屬性或成員資格進行任何修改，應該設定稽核以傳送警示。這些警示至少應傳送給負責 Active Directory 管理和事件回應的使用者或小組。您也應該定義暫時擴展 EA 群組的程序和流程，包括執行群組合法母體擴展時的通知程序。

保護 Domain Admins 群組

如同 Enterprise Admins 群組的情況，Domain Admins 群組中的成員資格只有在組建或災害復原案例中才需要。 DA 群組中不應該有日常使用者帳戶，該網域的本機 Administrator 帳戶除外 (如已依照附錄 D︰保護 Active Directory 中的內建 Administrator 帳戶所述而受到保護)。

需要 DA 存取權時，需要此存取層級的帳戶應該暫時放在有問題網域的 DA 群組中。雖然使用者使用的是高度特殊權限帳戶，但應該稽核活動，最好是與執行變更的使用者一起執行，而另一位使用者觀察變更，以將意外誤用或設定錯誤的可能性降到最低。當活動完成時，應該從 Domain Admins 群組中移除帳戶。這可以透過手動程序和記載的程序、透過協力廠商特殊權限身分識別/存取管理 (PIM/PAM) 軟體或兩者的組合來達成。如需建立帳戶以用來控制 Active Directory 中特殊權限群組成員資格的指導方針，請參閱附錄 I：為 Active Directory 中的受保護帳戶和群組建立管理帳戶。

根據預設，Domain Admins 是其各自網域中所有成員伺服器和工作站上本機 Administrator 群組的成員。此預設巢狀化不應該修改，因為它會影響支援性和災害復原選項。如果已從成員伺服器上的本機 Administrator 群組中移除 Domain Admins 群組，該群組應該透過連結 GPO 中的限制群組設定，新增至網域中每個成員伺服器和工作站上的 Administrator 群組。附錄 F︰保護 Active Directory 中的 Domain Admins 群組中詳細描述的下列一般控制項也應該實作。

針對樹系中每個網域中的 Domain Admins 群組：

請從 DA 群組中移除所有成員，該網域內建的 Administrator 帳戶除外 (前提是已依照附錄 D︰保護 Active Directory 中的內建 Administrator 帳戶所述而受到保護)。
在連結至包含每個網域成員伺服器和工作站之 OU 的 GPO 中，DA 群組應該新增至下列使用者權限：
- 拒絕從網路存取這台電腦
- 拒絕以批次工作登入
- 拒絕以服務方式登入
- 拒絕本機登入
- 拒絕透過遠端桌面服務登入
這可防止 DA 群組的成員登入成員伺服器和工作站。如果跳躍伺服器用來管理網域控制站和 Active Directory，請確定跳躍伺服器位於未連結受限 GPO 的 OU 中。
如果對 DA 群組的屬性或成員資格進行任何修改，應該設定稽核以傳送警示。這些警示至少應傳送給負責 AD DS 管理和事件回應的使用者或小組。您也應該定義暫時擴展 DA 群組的程序和流程，包括執行群組合法母體擴展時的通知程序。

保護 Active Directory 中的 Administrators 群組

如同 EA 和 DA 群組的情況，只有在建置或災害復原案例中才需要 Administrator (BA) 群組中的成員資格。 Administrator 群組中不應該有日常使用者帳戶，該網域的本機 Administrator 帳戶除外 (如已依照附錄 D︰保護 Active Directory 中的內建 Administrator 帳戶所述而受到保護)。

需要 Administrator 存取權時，需要此存取層級的帳戶應該暫時放在有問題網域的 Administrator 群組中。雖然使用者使用的是高度特殊權限帳戶，但應該稽核活動，最好是與執行變更的使用者一起執行，而另一位使用者觀察變更，以將意外誤用或設定錯誤的可能性降到最低。當活動完成時，應該立即從 Administrator 群組中移除帳戶。這可以透過手動程序和記載的程序、透過協力廠商特殊權限身分識別/存取管理 (PIM/PAM) 軟體或兩者的組合來達成。

根據預設，Administrator 是各自網域中大部分 AD DS 物件的擁有者。組建和災害復原案例中可能需要此群組中的成員資格，這些案例需要擁有權或取得物件擁有權的能力。此外，DA 和 EA 會依照在 Administrator 群組中的預設成員資格，繼承一些權限。不應修改 Active Directory 中具特殊權限群組的預設群組巢狀，且每個網域的 Administrator 群組都應該受到保護，如附錄 G：保護 Active Directory 中的 Administrator 群組，以及下列一般指示中所述。

請從 Administrator 群組中移除所有成員，該網域的本機 Administrator 帳戶除外 (如已依照附錄 D︰保護 Active Directory 中的內建 Administrator 帳戶所述而受到保護)。
網域的 Administrator 群組成員絕對不需要登入成員伺服器或工作站。在每個網域中連結至工作站和成員伺服器 OU 的一或多個 GPO 中，Administrator 群組應該新增至下列使用者權限：
- 拒絕從網路存取這部電腦
- 拒絕以批次工作登入，
- 拒絕以服務方式登入
- 這可防止 Administrator 群組的成員用來登入或連線至成員伺服器或工作站 (除非先違反多個控制項)，否則系統可能會快取其認證，因而遭到入侵。特殊權限帳戶絕不應用來登入較低權限的系統，而強制執行這些控制項可抵禦一些攻擊。
在樹系中每個網域的網域控制站 OU 上，Administrator 群組應獲授與下列使用者權限 (如果其還沒有這些權限)，這可讓 Administrator 群組的成員執行整個樹系範圍災害復原案例所需的功能：
- 從網路存取這台電腦
- 允許本機登入
- 允許透過遠端桌面服務登入
如果對 Administrator 群組的屬性或成員資格進行任何修改，則應該設定稽核以傳送警示。這些警示至少應傳送給負責 AD DS 管理的小組成員。警示也應該傳送給安全性小組的成員，且應該定義修改 Administrator 群組成員資格的程序。具體來說，這些程序應該包含安全性小組在 Administrator 群組即將修改時收到通知的程序，以便他們能預期會發出警示，且不會引發警示。此外，當 Administrator 群組使用完成且已從群組中移除所使用的帳戶時，通知安全性小組的程序應該實作。

注意

當您在 GPO 中對 Administrator 群組實作限制時，除了網域的 Administrator 群組之外，Windows 也會將設定套用至電腦本機 Administrator 群組的成員。因此，在 Administrator 群組上實作限制時需小心謹慎。雖然最好盡可能禁止 Administrator 群組成員的網路、批次和服務登入，但請勿限制本機登入或是透過遠端桌面服務的登入。禁止這些登入類型可能會封鎖本機 Administrator 群組成員對於電腦的合法管理。下列螢幕擷取畫面會顯示組態設定，這些設定除了會禁止濫用內建本機或網域 Administrator 群組之外，還會禁止濫用內建本機和網域 Administrator 帳戶。請注意，[拒絕透過遠端桌面服務登入] 的使用者權限不包含 Administrator 群組，因為在此設定中將其包含在內也會封鎖本機電腦 Administrator 群組成員帳戶的這類登入。如果電腦上的服務設定為在本節所述的任何特殊權限群組內容中執行，實作這些設定可能會導致服務和應用程式失敗。因此，如同本節中的所有建議，您應該徹底測試環境中適用性的設定。

最低許可權管理員模型

Active Directory 的角色型存取控制 (RBAC)

一般來說，角色型存取控制 (RBAC) 是一種機制，可分組使用者，並根據商務規則提供資源的存取權。在 Active Directory 的情況下，實作 AD DS 的 RBAC 是建立角色的程序，其權限會委派給該角色，以允許角色的成員執行日常系統管理工作，而不需要授與他們過多的權限。您可以透過原生工具和介面來設計及實作 Active Directory 的 RBAC，方法是利用您可能已經擁有的軟體、購買協力廠商產品，或這些方法的任何組合。本節不提供實作 Active Directory 的 RBAC 逐步指示，而是討論您在選擇在 AD DS 安裝中實作 RBAC 的方法時應考慮的因素。

Active Directory 的 RBAC 原生方法

在最簡單的 RBAC 實作中，您可以將角色實作為 AD DS 群組，並將權限委派給群組，讓他們可以在角色的指定範圍內執行日常管理。

在某些情況下，Active Directory 中的現有安全性群組可用來授與適用於職能的權限。例如，如果 IT 組織中的特定員工負責 DNS 區域與記錄的管理和維護，委派這些責任可以像為每個 DNS 系統管理員建立帳戶，並將其新增至 Active Directory 中的 DNS Admins 群組一樣簡單。 DNS Administrator 群組與更高權限的群組不同，在 Active Directory 中僅有少數強大的權限，雖然此群組的成員已獲委派權限，可讓他們管理 DNS，但仍會遭到入侵，而濫用可能會導致權限提高。

在其他情況下，您可能需要建立安全性群組，並將權限委派給 Active Directory 物件、檔案系統物件和登錄物件，以允許群組成員執行指定的系統管理工作。例如，如果您的技術支援中心操作員負責重設忘記的密碼、協助使用者解決連線問題，以及針對應用程式設定進行疑難排解，則您可能需要將 Active Directory 中使用者物件的委派設定與權限結合，讓技術支援中心使用者從遠端連線至使用者的電腦，以檢視或修改使用者的組態設定。針對您定義的每個角色，您應該識別：

角色成員的哪些工作會每天執行，而哪些工作較不常執行。
在哪些系統和哪些應用程式中應授與角色成員的權限。
哪些使用者應獲授與角色的成員資格。
如何執行角色成員資格的管理。

在許多環境中，手動建立角色型存取控制來管理 Active Directory 環境可能很難實作和維護。如果您已明確定義 IT 基礎結構管理的角色和責任，則可以利用其他工具來協助您建立可管理的原生 RBAC 部署。例如，如果 Forefront Identity Manager (FIM) 在您的環境中使用，您可以使用 FIM 將系統管理角色的建立和母體擴展自動化，以簡化進行中的系統管理。如果您使用 Microsoft Endpoint Configuration Manager 和 System Center Operations Manager (SCOM)，則可以使用應用程式特定角色來委派管理和監視功能，同時在網域中跨系統強制執行一致的設定和稽核。如果您已實作公開金鑰基礎結構 (PKI)，則可以為負責管理環境的 IT 人員發行並要求智慧卡。使用 FIM 認證管理 (FIM CM)，您甚至可以結合系統管理人員的角色和認證。

在其他情況下，組織可能最好考慮部署提供「現成」功能的協力廠商 RBAC 軟體。許多廠商提供適用於 Active Directory、Windows 以及非 Windows 目錄和作業系統之 RBAC 的商用現貨 (COTS) 解決方案。在原生解決方案和協力廠商產品之間選擇時，您應該考慮下列因素：

預算：藉由投資使用您可能擁有的軟體和工具開發 RBAC，您可以降低部署解決方案所涉及的軟體成本。不過，除非您的員工有建立和部署原生 RBAC 解決方案的經驗，否則您可能需要取得諮詢資源來開發您的解決方案。您應該仔細權衡自訂開發解決方案的預期成本，以及部署「現成」解決方案的成本，特別是在您預算有限的情況。
IT 環境的組成：如果您的環境主要是由 Windows 系統所組成，或如果您已經利用 Active Directory 來管理非 Windows 系統和帳戶，則自訂原生解決方案可能會為您的需求提供最佳解決方案。如果您的基礎結構包含許多未執行 Windows 且不受 Active Directory 管理的系統，您可能需要考慮與 Active Directory 環境分開管理非 Windows 系統的選項。
解決方案中的權限模型：如果產品仰賴於將其服務帳戶放置在 Active Directory 中具有高度特殊權限的群組，且並不提供不需將過度權限授與 RBAC 軟體的的選項，則您並沒有真正降低 Active Directory 攻擊面，而只會變更目錄中最高特殊權限群組的組成。除非應用程式廠商可以為服務帳戶提供控制項，以將帳戶遭到入侵和惡意使用的機率降到最低，否則您可能會想要考慮其他選項。

Privileged Identity Management

特殊權限身分識別管理 (PIM)，有時稱為特殊權限帳戶管理 (PAM) 或特殊權限認證管理 (PCM)，這是一種設計、建構和實作在基礎結構中管理特殊權限帳戶的方法。一般而言，PIM 會提供一些機制，讓帳戶獲授與執行建置或中斷修正函式所需的暫時權限，而不是將權限永久連結至帳戶。無論 PIM 功能透過手動建立還是透過部署協力廠商軟體來實作，可能可以使用下列一或多個功能：

認證「保存庫」，其中特殊權限帳戶的密碼會「取出」並指派初始密碼，然後在活動完成時「存回」，此時帳戶上會再次重設密碼。
使用特殊權限認證的時間限制
一次性使用認證
工作流程產生的權限授與，以監視和報告執行的活動，以及在活動完成或分配時間已過期時自動移除權限
使用應用程式開發介面 (API) 取代硬式編碼認證，例如指令碼中的使用者名稱和密碼，以視需要從保存庫擷取認證
自動管理服務帳戶認證

建立非特殊權限帳戶以管理特殊權限帳戶

管理特殊權限帳戶的其中一個挑戰是，根據預設，可以管理特殊權限和受保護帳戶與群組的帳戶是特殊權限和受保護的帳戶。如果您為 Active Directory 安裝實作適當的 RBAC 和 PIM 解決方案，則這些解決方案可能包含的方法，可讓您有效地將目錄中最高特殊權限群組的成員資格取消擴展，並在需要時只暫時擴展群組。

不過，如果您實作原生 RBAC 和 PIM，則應該考慮建立沒有權限，且唯一功能是視需要在 Active Directory 中擴展和取消擴展特殊權限群組的帳戶。附錄 I：為 Active Directory 中的受保護帳戶和群組建立管理帳戶提供逐步指示，讓您可用來針對此用途建立帳戶。

實作強固的驗證控制項

定律六：確實有人試圖猜測你的密碼。 - 安全性管理 10 大定律

傳遞雜湊和其他認證竊取攻擊不是 Windows 作業系統特有的，也不是新的攻擊。第一個傳遞雜湊攻擊是在 1997 年建立的。不過，從歷史上來看，這些攻擊需要自訂工具、成功屬於亂槍打鳥，且需要攻擊者擁有相對較高程度的技能。引進以原生方式擷取認證的免費易用工具，導致近年來認證竊取攻擊的數量和成功次數呈指數方式增加。不過，認證竊取攻擊絕不是鎖定和入侵認證的唯一機制。

雖然您應該實作控制項來協助抵禦認證竊取攻擊，但您也應該識別環境中最有可能成為攻擊者目標的帳戶，並針對這些帳戶實作強固的驗證控制項。如果您的最高特殊權限帳戶使用單一要素驗證，例如使用者名稱和密碼 (兩者都是「您知道的事項」，也就是一個驗證因素)，這些帳戶會受到弱式保護。攻擊者只需要知道與帳戶相關聯的使用者名稱和密碼知識，且不需要傳遞雜湊攻擊，攻擊者就可以向任何接受單一因素認證的系統驗證為使用者。

雖然實作多重要素驗證並不會保護您免受傳遞雜湊攻擊，但實作多重要素驗證並結合受保護的系統可以做到。如需有關實作受保護系統的詳細資訊，請參閱實作安全系統管理主機，下列各節將討論驗證選項。

一般驗證控制項

如果您尚未實作智慧卡等多重要素驗證，請考慮這麼做。智慧卡會在公開-私密金鑰組中實作私密金鑰的硬體強制執行保護，防止使用者的私密金鑰遭到存取或使用，除非該使用者提供正確的 PIN、密碼或生物識別元給智慧卡。即使鍵盤側錄攻擊在遭到入侵的電腦上攔截使用者的 PIN 或密碼，攻擊者也必須實際擁有智慧卡才能重複使用這個 PIN 或密碼。

如果因為使用者抗拒而難以實作長且複雜的密碼，智慧卡提供一種機制，讓使用者可以實作相當簡單的 PIN 或密碼，而且認證不容易遭受暴力密碼破解或彩虹資料表等攻擊。智慧卡 PIN 不會儲存在 Active Directory 或本機 SAM 資料庫中，不過認證雜湊仍然可能儲存在電腦上的 LSASS 受保護記憶體，智慧卡在其中用於驗證。

VIP 帳戶的其他控制項

實作智慧卡或其他憑證型驗證機制的另一個優點，是利用驗證機制保證來保護 VIP 使用者可存取的敏感性資料。驗證機制保證可在功能等級設定為 Windows Server 2012 或 Windows Server 2008 R2 的網域中使用。啟用時，驗證機制保證會在使用者認證使用憑證型登入方法進行驗證時，將系統管理員指定的全域群組成員資格新增至使用者的 Kerberos 權杖。

這可讓資源管理員根據使用者是否使用憑證型登入方法登入，以及所使用的憑證類型，來控制對資源的存取，例如檔案、資料夾和印表機。例如，當使用者使用智慧卡登入時，可以將使用者對於網路上資源的存取權指定為與使用者不使用智慧卡時的存取權不同 (也就是當使用者輸入使用者名稱和密碼登入時)。如需驗證機制保證的詳細資訊，請參閱 Windows Server 2008 R2 中 AD DS 的驗證機制保證逐步指南。

設定特殊權限帳戶驗證

在所有系統管理帳戶的 Active Directory 中，啟用 [需要智慧卡進行互動式登入] 屬性，並針對帳戶 (例如 cn、name、sAMAccountName、userPrincipalName 和 userAccountControl) 系統管理使用者物件稽核 [帳戶] 索引標籤上任何屬性的變更 (至少)。

雖然在帳戶上設定 [需要智慧卡進行互動式登入] 會將帳戶的密碼重設為 120 個字元的隨機值，且需要智慧卡進行互動式登入，但屬性仍然可以由具有權限的使用者覆寫，允許他們在帳戶上變更密碼，然後可以使用帳戶來建立只有使用者名稱和密碼的非互動式登入。

在其他情況下，視 Active Directory 中的帳戶設定和 Active Directory 憑證服務 (AD CS) 中的憑證設定或協力廠商 PKI 而定，系統管理或 VIP 帳戶的使用者主體名稱 (UPN) 屬性可能會成為對特定攻擊類型的目標，如這裡所述。

UPN 劫持憑證詐騙

雖然對公開金鑰基礎結構 (PKIS) 的攻擊深入討論超出本文件範圍，但自 2008 年以來，對公用和私人 PKIS 的攻擊呈指數方式增加。公開 PKI 的入侵已廣為人知，但對組織內部 PKI 的攻擊可能更多。此類攻擊會利用 Active Directory 和憑證，讓攻擊者以難以偵測的方式詐騙其他帳戶的認證。

當出示憑證以向已加入網域的系統進行驗證時，憑證中主體或主體別名 (SAN) 屬性的內容會用來將憑證對應至 Active Directory 中的使用者物件。根據憑證的類型及其建構方式，憑證中的主體屬性通常包含使用者的一般名稱 (CN)，如下列螢幕擷取畫面所示。

此螢幕快照顯示憑證中的 Subject 屬性通常包含使用者的一般名稱。

根據預設，Active Directory 會串連帳戶的名字 +「」+ 姓氏，以建構使用者的 CN。不過，Active Directory 中使用者物件的 CN 元件並非必要或保證是唯一的，而且將使用者帳戶移至目錄中的不同位置會變更帳戶的辨別名稱 (DN)，這是目錄中物件的完整路徑，如上一個螢幕擷取畫面的底部窗格所示。

由於憑證主體名稱不保證是靜態或唯一的，因此主體別名的內容通常用來在 Active Directory 中尋找使用者物件。從企業憑證授權單位 (Active Directory 整合式 CA) 發行給使用者之憑證的 SAN 屬性，通常包含使用者的 UPN 或電子郵件地址。由於 UPN 保證在 AD DS 樹系中是唯一的，因此 UPN 尋找使用者物件通常是作為驗證的一部分來執行，可能使用或不使用與驗證程序相關的憑證。

攻擊者可以利用驗證憑證中 SAN 屬性中的 UPN 來取得詐騙憑證。如果攻擊者入侵了能夠在使用者物件上讀取和寫入 UPN 的帳戶，表示攻擊已實作，如下所示：

使用者物件 (例如 VIP 使用者) 上的 UPN 屬性會暫時變更為不同的值。 SAM 帳戶名稱屬性和 CN 目前也可能會變更，雖然這通常並非必然，原因如稍早所述。

當目標帳戶上的 UPN 屬性已變更時，已過時、啟用的使用者帳戶或剛建立使用者帳戶的 UPN 屬性會變更為原本指派給目標帳戶的值。已過時、啟用的使用者帳戶是長時間未登入但尚未停用的帳戶。基於下列原因而「就近隱藏」的攻擊者會以這些帳戶為目標：

因為帳戶已啟用，但最近尚未使用，因此使用帳戶不太可能如同啟用已停用使用者帳戶的方式觸發警示。
使用現有的帳戶不需要建立系統管理人員可能會注意到的新使用者帳戶。
仍然啟用的過時使用者帳戶通常是各種安全性群組的成員，並獲授與網路上資源的存取權，簡化了對現有使用者擴展的存取和「混入」。

現在已設定目標 UPN 的使用者帳戶，用來從 Active Directory 憑證服務要求一或多個憑證。

針對攻擊者帳戶取得憑證時，「新」帳戶和目標帳戶上的 UPN 會返回其原始值。

攻擊者現在可以出示一或多個憑證來進行資源與應用程式的驗證，就好像使用者是暫時修改帳戶的 VIP 使用者一樣。儘管完整討論攻擊者能以憑證和 PKI 為目標的所有方式不在本文件範圍內，但已提供此攻擊機制來說明為何您應該監視 AD DS 中特殊權限和 VIP 帳戶的變更，特別是針對帳戶的 [帳戶] 索引標籤上任何屬性的變更 (例如，cn、name、sAMAccountName、userPrincipalName 和 userAccountControl)。除了監視帳戶之外，您應該限制誰可以將帳戶盡可能修改為一組小型系統管理使用者。同樣地，系統管理使用者的帳戶應該受到保護，並監視未經授權的變更。

共用方式為