Microsoft Entra 傳遞驗證:常見問題集

本文說明 Microsoft Entra 傳遞驗證的常見問題。 繼續檢查更新的內容。

我應該選擇哪一種方法來登入 Microsoft Entra ID、傳遞驗證、密碼哈希同步處理,以及 Active Directory 同盟服務 (AD FS) ?

請檢閱 本指南 ,以比較各種 Microsoft Entra 登入方法,以及如何為您的組織選擇正確的登入方法。

傳遞驗證是否為免費功能?

傳遞驗證是免費功能。 您不需要任何付費版本的 Microsoft Entra ID 才能使用它。

條件式存取是否可與傳遞驗證搭配使用?

是。 所有 條件式存取 功能,包括 Microsoft Entra 多重要素驗證,都可以使用傳遞驗證。

傳遞驗證是否支援「替代識別碼」作為用戶名稱,而不是 「userPrincipalName」 ?

是,傳遞驗證 (PTA) 和密碼哈希同步處理 (PHS) 都支援使用非 UPN 值登入,例如替代電子郵件。 如需替代登入標識碼的詳細資訊

密碼哈希同步處理是否作為傳遞驗證的後援?

否。 傳遞驗證 不會 自動故障轉移至密碼哈希同步處理。 若要避免使用者登入失敗,您應該設定傳遞驗證以提供 高可用性

當我從密碼哈希同步處理切換到傳遞驗證時,會發生什麼事?

當您使用 Microsoft Entra 連線 將登入方法從密碼哈希同步處理切換為傳遞驗證時,傳遞驗證會成為受控網域中使用者的主要登入方法。 先前由密碼哈希同步處理同步處理的所有用戶密碼哈希仍會儲存在 Microsoft Entra ID 上。

我可以在與傳遞驗證代理程式相同的伺服器上安裝 Microsoft Entra 專用網連接器嗎?

是。 重新命名的傳遞驗證代理程式版本 1.5.193.0 版或更新版本支援此設定。

您需要哪些版本的 Microsoft Entra 連線 和傳遞驗證代理程式?

若要讓這項功能運作,您需要 Microsoft Entra 連線 和 1.5.193.0 或更新版本 1.1.193.0 版或更新版本,才能讓傳遞驗證代理程式使用。 在具有 Windows Server 2012 R2 或更新版本的伺服器上安裝所有軟體。

為什麼我的連接器仍然使用舊版,而不是自動升級至最新版本?

這可能是因為更新程式服務無法正常運作,或如果沒有服務可以安裝的新更新, 如果更新程式正在執行,而且事件記錄檔中沒有記錄任何錯誤,更新程序服務就會狀況良好(應用程式和服務記錄檔 - Microsoft ->> AzureAD 連線-Agent -> Updater -> 管理員)。

只有主要版本會發行以進行自動升級。 建議您只在需要時才手動更新代理程式。 例如,您無法等候主要版本,因為您必須修正已知問題,或是想要使用新功能。 如需新版本的詳細資訊,請參閱版本發行類型(下載、自動升級)、Bug 修正和新功能, 請參閱 Microsoft Entra 傳遞驗證代理程式:版本發行歷程記錄

若要手動升級連接器:

  • 下載最新版本的代理程式。 (您可以在 Microsoft Entra 系統管理中心的 Microsoft Entra 連線 傳遞驗證下找到它。 您也可以在 Microsoft Entra 傳遞驗證:版本發行歷程記錄中找到連結。
  • 安裝程式會重新啟動 Microsoft Entra 連線 驗證代理程式服務。 在某些情況下,如果安裝程式無法取代所有檔案,則需要伺服器重新啟動。 因此,建議您在開始升級之前關閉所有應用程式,事件檢視器。
  • 執行安裝程式。 升級程式很快,不需要提供任何認證,而且不會重新註冊代理程式。

如果使用者的密碼已過期,且他們嘗試使用傳遞驗證登入,會發生什麼情況?

如果您已針對特定使用者設定 密碼回 寫,而且如果使用者使用傳遞驗證登入,他們可以變更或重設其密碼。 密碼會如預期般寫回 內部部署的 Active Directory。

如果您尚未針對特定使用者設定密碼回寫,或使用者未獲指派有效的 Microsoft Entra ID 授權,則使用者無法在雲端更新其密碼。 即使密碼已過期,他們也無法更新其密碼。 相反地,使用者會看到此訊息:「您的組織不允許在此網站上更新密碼。 根據您的組織建議的方法更新它,或詢問您的系統管理員是否需要協助。」用戶或系統管理員必須在 內部部署的 Active Directory 中重設其密碼。

用戶以認證登入 Microsoft Entra 識別碼(使用者名稱、密碼)。 同時,用戶的密碼到期,但使用者仍然可以存取 Microsoft Entra 資源。 為何發生此狀況?

密碼到期不會觸發驗證令牌或 Cookie 的撤銷。 在令牌或 Cookie 有效之前,使用者才能使用這些令牌。 無論驗證類型為何(PTA、PHS 和同盟案例)都適用。

如需詳細資訊,請參閱下列檔:

Microsoft 身分識別平台 存取令牌 - Microsoft 身分識別平台 |Microsoft Docs

傳遞驗證如何保護您免受暴力密碼破解攻擊?

閱讀智慧鎖定的相關信息。

傳遞驗證代理程式如何透過埠 80 和 443 進行通訊?

  • 驗證代理程式會針對所有功能作業透過埠 443 提出 HTTPS 要求。

  • 驗證代理程式會透過埠 80 提出 HTTP 要求,以下載 TLS/SSL 證書吊銷清單(CRL)。

    注意

    最近的更新可減少功能所需的埠數目。 如果您有舊版的 Microsoft Entra 連線 或驗證代理程式,請保留這些埠開啟:5671、8080、9090、9091、9350、9352 和 10100-10120。

傳遞驗證代理程式是否可以透過輸出 Web Proxy 伺服器進行通訊?

是。 如果您的內部部署環境中已啟用 Web Proxy 自動探索(WPAD),驗證代理程式會自動嘗試尋找並使用網路上的 Web Proxy 伺服器。 如需使用輸出 Proxy 伺服器的詳細資訊,請參閱 使用現有的內部部署 Proxy 伺服器

如果您的環境中沒有 WPAD,您可以新增 Proxy 資訊(如下所示),以允許傳遞驗證代理程式與 Microsoft Entra ID 通訊:

  • 在伺服器上安裝傳遞驗證代理程式之前,請先在 Internet Explorer 中設定 Proxy 資訊。 這可讓您完成驗證代理程式的安裝,但仍會在 管理員 入口網站上顯示為作用中。
  • 在伺服器上,流覽至 「C:\Program Files\Microsoft Azure AD 連線 Authentication Agent」。
  • 編輯 「AzureAD 連線 AuthenticationAgentService」 組態檔,並新增下列幾行 (取代 “http://contosoproxy.com:8080"使用您的實際 Proxy 位址):
   <system.net>
      <defaultProxy enabled="true" useDefaultCredentials="true">
         <proxy
            usesystemdefault="true"
            proxyaddress="http://contosoproxy.com:8080"
            bypassonlocal="true"
         />
     </defaultProxy>
   </system.net>

我可以在同一部伺服器上安裝兩個或多個傳遞驗證代理程式嗎?

否,您只能在單一伺服器上安裝一個傳遞驗證代理程式。 如果您想要設定高可用性的傳遞驗證, 請遵循這裡的指示。

我是否需要手動更新傳遞驗證代理程式所使用的憑證?

每個傳遞驗證代理程式和 Microsoft Entra ID 之間的通訊都會使用憑證式驗證來保護。 這些 憑證會由 Microsoft Entra ID 每隔幾個月自動更新一次。 不需要手動更新這些憑證。 您可以視需要清除較舊的過期憑證。

如何移除「傳遞驗證代理程式」?

只要傳遞驗證代理程式正在執行,它就會保持作用中,並持續處理使用者登入要求。 如果您想要卸載驗證代理程式,請移至 控制台 - 程式 ->> 程式和功能,並卸載 Microsoft Entra 連線 驗證代理程式和Microsoft Entra 連線 代理程式更新程式

如果您在 Microsoft Entra 系統管理中心檢查 [傳遞驗證] 刀鋒視窗,至少是混合式身分識別 管理員 istrator。 完成上述步驟之後,您會看到驗證代理程序顯示為 非作用中。 這是預期的。 10 天後,「驗證代理程式」就會自動從清單中卸除。

我已經使用 AD FS 來登入 Microsoft Entra ID。 要如何改為使用傳遞驗證?

如果您要從 AD FS(或其他同盟技術)移轉至傳遞驗證,強烈建議您遵循我們的 快速入門指南

是否可以在多樹系 Active Directory 環境中使用傳遞驗證?

是。 如果您的 Active Directory 樹系之間有樹系信任(雙向),且名稱後綴路由已正確設定,則支援多樹系環境。

傳遞驗證是否可在多個驗證代理程式之間提供負載平衡?

否,安裝多個傳遞驗證代理程式可確保只有 高可用性。 它不提供驗證代理程式之間的決定性負載平衡。 任何驗證代理程式(隨機)都可以處理特定的使用者登入要求。

我需要安裝幾個傳遞驗證代理程式?

安裝多個傳遞驗證代理程式可確保 高可用性。 但是,它不提供驗證代理程式之間的決定性負載平衡。

請考慮您預期在您的租使用者上看到之登入要求的尖峰和平均負載。 作為基準檢驗,單一驗證代理程式可以在標準 4 核心 CPU、16 GB RAM 伺服器上處理每秒 300 到 400 個驗證。

若要估計網路流量,請使用下列大小調整指引:

  • 每個要求都有一個承載大小 (0.5K + 1K * num_of_agents) 位元組:也就是從 Microsoft Entra ID 到驗證代理程序的數據。 在這裡,“num_of_agents”表示在租用戶上註冊的驗證代理程式數目。
  • 每個回應都有 1K 個字節的承載大小;也就是說,從驗證代理程式到 Microsoft Entra ID 的數據。

對大多數客戶而言,總共有兩個或三個驗證代理程式足以達到高可用性和容量。 不過,在生產環境中,我們建議您在租使用者上至少執行 3 個驗證代理程式。 您應該安裝靠近域控制器的驗證代理程式,以改善登入延遲。

注意

每個租使用者有 40 個驗證代理程式的系統限制。

為什麼我需要僅限雲端的全域 管理員 istrator 帳戶來啟用傳遞驗證?

建議您使用僅限雲端的全域 管理員 istrator 帳戶來啟用或停用傳遞驗證。 瞭解如何新增僅限雲端的全域 管理員 istrator 帳戶。 如此一來,可確保不會鎖定您的租使用者。

如何停用傳遞驗證?

重新執行 Microsoft Entra 連線 精靈,並將使用者登入方法從傳遞驗證變更為另一種方法。 這項變更會停用租使用者上的傳遞驗證,並從伺服器卸載驗證代理程式。 您必須從其他伺服器手動卸載驗證代理程式。

當我卸載傳遞驗證代理程式時,會發生什麼事?

如果您從伺服器卸載傳遞驗證代理程式,它會導致伺服器停止接受登入要求。 為了避免中斷租用戶上的使用者登入功能,務必要有另一個驗證代理程式正在執行,才能解除安裝傳遞驗證代理程式。

我有一個舊版租使用者,原本是使用AD FS進行設定。 我們最近移轉至 PTA,但現在看不到同步處理至 Microsoft Entra 識別碼的 UPN 變更。 為何我們的 UPN 變更無法同步?

在下列情況下,如果下列情況,您的內部部署 UPN 變更可能不會同步處理:

  • 您的 Microsoft Entra 租使用者是在 2015 年 6 月 15 日之前建立的。
  • 您一開始是使用AD FS進行驗證的 Microsoft Entra 租使用者同盟。
  • 您已切換為使用 PTA 做為驗證的受管理使用者。

這是因為租使用者在 2015 年 6 月 15 日之前建立的預設行為是封鎖 UPN 變更。 如果您需要取消封鎖 UPN 變更,您需要執行下列 PowerShell Cmdlet。 使用 Get-MgDirectoryOnPremiseSynchronization Cmdlet 取得標識符。

$params = @{ "SynchronizeUpnForManagedUsersEnabled" = "True" }
Update-MgDirectoryOnPremiseSynchronization -OnPremisesDirectorySynchronizationId $SynchronizationId -BodyParameter $params

2015 年 6 月 15 日之後建立的租用戶,其預設行為便是同步 UPN 變更。

如何? 從 Microsoft Entra 登入記錄和 PTA 伺服器擷取 PTA 代理程式識別碼,以驗證哪個 PTA 伺服器用於登入事件?

若要驗證特定登入事件所使用的本地伺服器或驗證代理程式:

  1. Microsoft Entra 系統管理中心,移至登入事件。

  2. 選取 [ 驗證詳細數據]。 在 [ 驗證方法詳細 數據] 數據行中,代理程式標識碼詳細數據會以「傳遞驗證」格式顯示;PTA AgentId:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX“。

  3. 若要取得安裝在本機伺服器上的代理程式識別碼詳細數據,請登入您的本地伺服器並執行下列 Cmdlet:

    Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Azure AD Connect Agents\Azure AD Connect Authentication Agent' | Select *Instance*

    傳回的 GUID 值是安裝在該特定伺服器上的驗證代理程式的代理程式識別碼。 如果您的環境中有多個代理程式,您可以在每個代理程式伺服器上執行此 Cmdlet,並擷取代理程式識別碼詳細數據。

  4. 將您從本地伺服器和 Microsoft Entra 登入記錄取得的代理程式識別碼相互關聯,以驗證哪個代理程式或伺服器已認可簽署要求。

下一步