保護 Active Directory 同盟服務的最佳做法

  • 發行項

本文件提供安全規劃和部署 Active Directory 同盟服務 (AD FS) 和 Web 應用程式 Proxy (WAP) 的最佳做法。 其中包含其他安全性設定、特定使用案例和安全性需求的建議。

本檔適用於 Windows Server 2012 R2、2016 和 2019 中的 AD FS 和 WAP。 這些建議可用於內部部署網路或雲端託管環境中，例如 Microsoft Azure。

標準部署拓撲

針對在內部部署環境中部署，我們建議使用由下列項目組成的標準部署拓撲：

  • 內部公司網路上的一或多個 AD FS 伺服器。
  • DMZ 或外部網路中的一或多個 Web 應用程式 Proxy (WAP) 伺服器。

在每個 AD FS 和 WAP 的層級，硬體或軟體負載平衡器會放在伺服器陣列前面，並處理流量路由。 防火牆會視需要放置在負載平衡器的外部 IP 位址前面。

A diagram depicting a standard A D F S topology.

注意

AD FS 需要完整的可寫入網域控制站才能運作，而不是唯讀網域控制站。 如果規劃的拓撲包含唯讀網域控制站，則唯讀網域控制站可用於驗證，但 LDAP 宣告處理將需要連線至可寫入的網域控制站。

強化您的 AD FS 伺服器

以下是強化和保護 AD FS 部署的最佳作法和建議清單：

  • 請確定只有 Active Directory 系統管理員和 AD FS 系統管理員具有 AD FS 系統的系統管理員權限。
  • 減少所有 AD FS 伺服器上的本機系統管理員群組成員資格。
  • 要求所有雲端管理員使用多重要素驗證 (MFA)。
  • 透過代理程式的最低管理功能。
  • 透過主機防火牆限制網路存取。
  • 確定 AD FS 系統管理員使用系統管理工作站來保護其認證。
  • 將 AD FS 伺服器電腦物件放在不同時裝載其他伺服器的最上層 OU 中。
  • 套用至 AD FS 伺服器的所有 GPO 都只能套用至它們，而非其他伺服器。 這會限制透過 GPO 修改的潛在權限提升。
  • 請確定已安裝的憑證受到保護，以免遭竊 (不要將這些憑證儲存在網路的共用上)，並設定行事曆提醒，以確保在過期之前更新憑證 (過期的憑證會中斷同盟驗證)。 此外，我們建議保護連結至 AD FS 的硬體安全性模組 (HSM) 中的簽署金鑰/憑證。
  • 將日誌記錄設定為最高層級，並將 AD FS (和安全性) 記錄傳送到 SIEM，以與 AD 驗證及 AzureAD (或類似身分驗證) 相關聯。
  • 刪除不必要的協定和 Windows 功能。
  • 針對 AD FS 服務帳戶使用長 (>25 個字元)、複雜密碼。 我們建議使用群組受管理的服務帳戶 (gMSA) 作為服務帳戶，因為其可藉由自動管理服務帳戶來移除管理服務帳戶密碼的需求。
  • 更新為最新的 AD FS 版本，以取得安全性和記錄改善功能 (一如既往地先進行測試)。

所需的連接埠

下圖描述必須在 AD FS 和 WAP 部署元件之間啟用的防火牆連接埠。 如果部署不包括 Microsoft Entra ID/Office 365，則可以忽略同步要求。

注意

僅當利用使用者憑證驗證時才需要連接埠 49443，這對於 Microsoft Entra ID 和 Office 365 是選用的。

A diagram showing the required ports and protocols for an A D F S deployment.

注意

連接埠 808 (Windows Server 2012R2) 或連接埠 1501 (Windows Server 2016+) 是 Net。 TCP 連接埠 AD FS 會用於本機 WCF 端點，以將設定資料傳送至服務處理程序和 PowerShell。 執行 Get-AdfsProperties 可以看到此連接埠 |選取 [NetTcpPort]。 這是本機連接埠，不需要在防火牆中開啟，但會顯示在連接埠掃描中。

同盟伺服器之間的通訊

AD FS 伺服器陣列上的同盟伺服器會透過 HTTP 連接埠 80 與伺服器陣列中的其他伺服器和 Web 應用程式 Proxy (WAP) 伺服器通訊，以進行組態同步處理。 請確定只有這些伺服器可以彼此通訊，而且沒有其他伺服器屬於深度防禦的措施。

組織可以在每部伺服器上設定防火牆規則，以達到此狀態。 規則應該只允許來自伺服器陣列和 WAP 伺服器中伺服器 IP 位址的輸入通訊。 某些網路負載平衡器 (NLB) 會使用 HTTP 連接埠 80 來探查個別同盟伺服器上的健康情況。 請確定您已設定的防火牆規則中包含 NLB 的 IP 位址。

Microsoft Entra Connect 和同盟伺服器/WAP

下表描述 Microsoft Entra Connect 伺服器與聯合/WAP 伺服器之間通訊所需的連接埠和協定。

通訊協定 連接埠 描述
HTTP 80 (TCP/UDP) 用來下載 CRL (憑證撤銷清單) 以驗證 SSL 憑證。
HTTPS 443 (TCP/UDP) 用來與 Microsoft Entra ID 同步處理。
WinRM 5985 WinRM 接聽程式。

WAP 與同盟伺服器

下表描述同盟伺服器與 WAP 伺服器之間通訊所需的連接埠和通訊協定。

通訊協定 連接埠 描述
HTTPS 443 (TCP/UDP) 用於驗證。

WAP 和使用者

下表描述使用者與 WAP 伺服器之間通訊所需的連接埠和通訊協定。

通訊協定 連接埠 描述
HTTPS 443 (TCP/UDP) 用於裝置驗證。
TCP 49443 (TCP) 用於憑證驗證。

如需混合式部署所需的連接埠和通訊協定的相關資訊，請參閱混合式參考連接埠。

有關 Microsoft Entra ID 和 Office 365 部署所需的連接埠和通計協定的資訊，請參閱文件 Office 365 URL 和 IP 位址範圍。

端點已啟用

安裝 AD FS 和 WAP 時，同盟服務和 Proxy 上會啟用一組預設的 AD FS 端點。 這些預設值是根據最常見的必要和已使用案例來選擇，因此不需要變更這些預設值。

為 Microsoft Entra ID/Office 365 啟用的最小終點 Proxy 集 (選用)

僅為 Microsoft Entra ID 和 Office 365 案例部署 AD FS 和 WAP 的組織可以進一步限制在 Proxy 上啟用的 AD FS 終點的數量，以實現更小的攻擊面。 以下是在下列案例中必須在 Proxy 上啟用的端點清單：

端點 目標
/adfs/ls/ 瀏覽器型份驗證流程和目前版本的 Microsoft Office 使用此終點進行 Microsoft Entra ID 和 Office 365 驗證
/adfs/services/trust/2005/usernamemixed 用於 Exchange Online 與 Office 2013 2015 年 5 月更新之前的 Office 用戶端。 後面的用戶端會使用被動 \adfs\ls 端點。
/adfs/services/trust/13/usernamemixed 用於 Exchange Online 與 Office 2013 2015 年 5 月更新之前的 Office 用戶端。 後面的用戶端會使用被動 \adfs\ls 端點。
/adfs/oauth2/ 用於已設定為直接向 AD FS 進行驗證的任何新式應用程式 (內部部署或在雲端中) (即不通過 Microsoft Entra ID)
/adfs/services/trust/mex 用於 Exchange Online 與 Office 2013 2015 年 5 月更新之前的 Office 用戶端。 後面的用戶端會使用被動 \adfs\ls 端點。
/federationmetadata/2007-06/federationmetadata.xml 對任何被動流程的要求，並由 Office 365/Microsoft Entra ID 用於檢查 AD FS 憑證。

您可以使用下列 PowerShell Cmdlet 在 Proxy 上停用 AD FS 端點：

Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false

驗證延伸保護

驗證的延伸保護是一項功能，可降低中間人 (MITM) 攻擊的風險，且預設會使用 AD FS 來啟用。 您可以使用下列 PowerShell Cmdlet 來驗證設定：

Get-ADFSProperties

屬性是 ExtendedProtectionTokenCheck。 預設設定為 [允許]，如此一來，即可達成安全性優點，而不需要考慮與不支援此功能的瀏覽器相容性。

保護同盟服務的壅塞控制

同盟服務 Proxy (WAP 的一部分) 提供壅塞控制，以保護 AD FS 服務免於大量要求湧入。 如果 Web 應用程式 Proxy 與同盟伺服器之間的延遲偵測到同盟伺服器超載，則 Web 應用程式 Proxy 將拒絕外部用戶端驗證要求。 此功能預設會設定為建議的延遲閾值層級。 若要確認設定，您可以執行下列動作：

  1. 在 Web 應用程式 Proxy 電腦上，啟動提升權限的命令視窗。
  2. 瀏覽至位於 %WINDIR%\adfs\config 的 AD FS 目錄。
  3. 將壅塞控制設定從其預設值變更為 <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />。
  4. 儲存並關閉檔案。
  5. 依序執行 net stop adfssrv 和 net start adfssrv 來重新啟動 AD FS 服務。

如需此功能的指引，請參閱在 Windows Server 2012 R2 上設定 AD FS 的外部網路存取。

Proxy 的標準 HTTP 要求檢查

Proxy 也會針對所有流量執行下列標準檢查：

  • FS-P 本身會透過短期憑證向 AD FS 進行驗證。 在可疑遭入侵 DMZ 伺服器的案例中，AD FS 可以「撤銷 Proxy 信任」，使其不再信任來自可能遭入侵 Proxy 的任何連入要求。 撤銷 Proxy 信任會撤銷每個 Proxy 本身的憑證，使其無法針對 AD FS 伺服器的任何用途成功進行驗證。
  • FS-P 會終止所有連線，並在內部網路上建立 AD FS 服務的新 HTTP 連線。 這會提供外部裝置與 AD FS 服務之間的工作階段層級緩衝區。 外部裝置永遠不會直接連線至 AD FS 服務。
  • FS-P 會執行 HTTP 要求驗證，以特別篩除 AD FS 服務不需要的 HTTP 標頭。

確定所有 AD FS 和 WAP 伺服器都會收到最新的更新。 AD FS 基礎結構最重要的安全性建議是確保您有辦法讓 AD FS 和 WAP 伺服器隨時掌握所有安全性更新，以及此頁面上針對 AD FS 指定為重要的選用更新。

Microsoft Entra 客戶監視及保留其基礎結構的建議方式，是透過 Microsoft Entra Connect Health for AD FS、Microsoft Entra ID P1 或 P2 的功能。 Microsoft Entra Connect Health 包括監視器和警報，如果 AD FS 或 WAP 機器缺少專門針對 AD FS 和 WAP 的重要更新之一，則會觸發這些監視器和警報。

若要了解有關 AD FS 運作狀況監視的詳細資訊，請參閱 Microsoft Entra Connect Health 代理安裝。

使用 Microsoft Entra ID 保護和監視 AD FS 信任的最佳做法

將 AD FS 與 Microsoft Entra ID 聯合時，必須密切監視聯合組態 (在 AD FS 和 Microsoft Entra ID 之間設定的信任關係），並擷取任何異常或可疑活動。 若要這樣做，建議您設定警示，以在對同盟設定進行任何變更時收到通知。 若要了解如何設定警示，請參閱監視同盟設定的變更。

其他安全性設定

您可以設定下列其他功能以提供更多保護。

帳戶的外部網路「軟」鎖定保護

使用 Windows Server 2012 R2 中的外部網路鎖定功能，AD FS 系統管理員可以設定允許的最大失敗驗證要求數目 (ExtranetLockoutThreshold) 和 observation window 時段 (ExtranetObservationWindow)。 達到驗證要求的最大數目 (ExtranetLockoutThreshold) 時，AD FS 會針對設定的時段 (ExtranetObservationWindow) 停止嘗試對 AD FS 驗證提供的帳號憑證。 此動作會保護此帳戶免於 AD 帳戶鎖定，換句話說，它會保護此帳戶，使其不至於無法存取依賴 AD FS 進行使用者驗證的公司資源。 這些設定適用於 AD FS 服務可以驗證的所有網域。

您可以使用下列 Windows PowerShell 命令來設定 AD FS 外部網路鎖定 (範例)：

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

如需參考，請參閱設定 AD FS 外部網路鎖定以深入了解這項功能。

從外部網路停用 Proxy 上的 WS-Trust Windows 端點

WS-Trust Windows 端點 (/adfs/services/trust/2005/windowstransport 和 /adfs/services/trust/13/windowstransport) 僅代表使用 HTTPS 上 WIA 繫結的內部網路面向端點。 將其公開至外部網路可能會允許對這些端點的要求略過鎖定保護。 這些端點應該在 Proxy 上停用 (也就是從外部網路停用)，以使用下列 PowerShell 命令來保護 AD 帳戶鎖定。 停用 Proxy 上的這些端點並不會影響已知的終端使用者。

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false

注意

如果您的 AD FS 伺服器陣列在 Windows 內部資料庫 (WID) 上執行，而且具有次要 AD FS 伺服器，則在停用主伺服器上的端點之後，請先等候 SYNC 在次要節點上發生，再重新啟動其上的 AD FS 服務。 使用次要節點上的 PowerShell 命令 Get-AdfsSyncProperties 來追蹤最後一個 SYNC 處理程序。

區分內部網路和外部網路存取的存取原則

AD FS 能夠區分源自本機、公司網路的要求存取原則，以及透過 Proxy 從網際網路傳入的要求。 這項差異可以為每個應用程式或全域完成。 對於高商務價值應用程式或包含敏感資訊的應用程式，請考慮要求進行多重要素驗證。 可以透過 AD FS 管理管理單元設定多重要素驗證。

需要多重要素驗證 (MFA)

AD FS 可以設定為需要強式驗證 (例如多重要素驗證)，特別是對於透過 Proxy 傳入的請求、單一應用程式以及對 Microsoft Entra ID/Office 365 和內部部署資源的條件式存取。 MFA 支援的方法包括 Microsoft Azure MF 和協力廠商提供者。 系統會提示使用者提供其他資訊 (例如包含一次性代碼的 SMS 文字)，而 AD FS 會與提供者特定的外掛程式搭配使用，以允許存取。

支援的外部 MFA 提供者包括設定 AD FS 的其他驗證方法頁面中所列的提供者。

啟用保護以防止在與 Microsoft Entra ID 同盟時傳遞雲端 Microsoft Entra 多重要素驗證

啟用保護以防止在與 Microsoft Entra ID 聯合並使用 Microsoft Entra 多重要素驗證聯合使用者的多重要素驗證時繞過雲端 Microsoft Entra 多重要素驗證。

在 Microsoft Entra 租用戶中啟用聯合網域保護，可確保在聯合使用者存取由需要 MFA 的條件式存取原則控制的應用程式時，始終執行 Microsoft Entra 多重要素驗證。 這包括執行 Microsoft Entra 多重要素驗證，即使聯合身分識別提供者已指示 (透過聯合權杖聲明) 已執行內部部署 MFA。 每次強制實施 Microsoft Entra 多重要素驗證，確保遭到入侵的內部部署帳戶無法透過模仿身分識別提供者已執行的多重要素驗證來繞過 Microsoft Entra 多重要素驗證，除非使用第三方 MFA 提供程式為聯合使用者執行 MFA，否則強烈建議這樣做。

您可以使用新的安全性設定 federatedIdpMfaBehavior 來啟用保護，此設定會公開為內部同盟 MS Graph API 或 MS Graph PowerShell Cmdlet 的 一部分。 該 federatedIdpMfaBehavior 設定確定當聯盟使用者存取由需要 MFA 的條件式存取原則控制的應用程式時，Microsoft Entra ID 是否接受聯合身分識別提供者執行的 MFA。

系統管理員可以選擇下列其中一個值：

屬性 說明
acceptIfMfaDoneByFederatedIdp Microsoft Entra ID 接受由身分識別提供者執行的 MFA。 如果沒有，請執行 Microsoft Entra 多重要素驗證。
enforceMfaByFederatedIdp Microsoft Entra ID 接受由身分識別提供者執行的 MFA。 若否，其會將要求重新導向至識別提供者以執行 MFA。
rejectMfaByFederatedIdp Microsoft Entra ID 一律會執行 Microsoft Entra 多重要素驗證，並在身分識別提供者執行時拒絕 MFA。

您可以使用下列命令，將 federatedIdpMfaBehavior 設定 rejectMfaByFederatedIdp 來啟用保護。

MS GRAPH API

 PATCH /domains/{domainsId}/federationConfiguration/{internalDomainFederationId} 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

}

範例：

PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-f373ee4cbc5a 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"

範例：

Update-MgDomainFederationConfiguration -DomainId <domainsId> -InternalDomainFederationId <internalDomainFederationId> federatedIdpMfaBehavior "rejectMfaByFederatedIdp"

範例：

Update-MgDomainFederationConfiguration -DomainId “contoso.com” -InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a” federatedIdpMfaBehavior "rejectMfaByFederatedIdp"

硬體安全性模組 (HSM)

在其預設組態中，AD FS 用來簽署權杖的金鑰絕不會離開內部網路上的同盟伺服器。 這些金鑰永遠不會出現在 DMZ 或 Proxy 電腦上。 您可以選擇性地提供更多保護，建議您在連結至 AD FS 的硬體安全性模組 (HSM) 中保護這些金鑰。 Microsoft 不會產生 HSM 產品，但市場上有數個支援 AD FS 的產品。 若要實作這項建議，請遵循廠商指引來建立 X509 憑證以進行簽署和加密，然後使用 AD FS 安裝 PowerShell Commandlet 以指定自訂憑證，如下所示：

Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>

其中：

  • CertificateThumbprint 是您的 SSL 憑證
  • SigningCertificateThumbprint 是您的簽署憑證 (使用 HSM 保護的金鑰)
  • DecryptionCertificateThumbprint 是您的加密憑證 (使用 HSM 保護的金鑰)