共用方式為

對您的合作夥伴租戶強制使用多重要素驗證 (MFA)

  • 發行項

適當的角色：管理代理人員, 銷售專員, 客服專員, 計費管理員, 安全管理員

更好的安全性，持續的安全性和隱私權保護是我們的首要任務之一，我們繼續協助合作夥伴保護其客戶和租使用者。

為了協助合作夥伴保護其企業和客戶免於身分識別竊取和未經授權的存取，我們為合作夥伴租用戶啟用更多安全性防護。 這些保護措施會授權並驗證 MFA。 管理 MFA 可協助合作夥伴保護其存取客戶資源，以防止認證遭入侵。

本文提供在合作夥伴中心管理多重要素驗證 （MFA） 的詳細範例和指引。

參與雲端解決方案提供者（CSP）計劃、控制台廠商（CPV）和顧問的合作夥伴必須實施合作夥伴安全性要求，才能保持符合規範。

合作夥伴必須在其合作夥伴租戶中的所有使用者帳戶中強制執行多因素驗證，包括來賓使用者。 使用者必須完成下列區域的 MFA 驗證：

合作夥伴中心

合作夥伴中心的某些頁面受到 MFA 保護，包括：

  • 客戶 頁籤下的所有頁面（也就是 URL 以 https://partner.microsoft.com/commerce/* 開頭的所有頁面）
  • 在 [支援>客戶要求] 頁籤下的所有頁面（例如，以 URL https://partner.microsoft.com/dashboard/v2/support/customers/* 開頭的所有頁面）
  • <帳單> 索引標籤中的所有頁面

合作夥伴中心的其他頁面，例如概觀頁面和服務健康狀態檢查頁面，不需要 MFA。

下表顯示哪些使用者類型有權存取這些受 MFA 保護的頁面（且受此功能影響）。

受 MFA 保護的頁面 管理代理人 銷售代理人 技術服務代理人 安全性系統管理員 計費管理員
[客戶 標籤頁下的所有頁面] x x x
支持標籤下的所有「顧客要求」頁面 x x
帳單 頁面 x x x
安全性 工作區 x x

若要存取這些頁面，您必須先完成 MFA 驗證。

支援的 MFA 選項

  • 受Microsoft支持的合作夥伴使用Microsoft Entra多重驗證。 如需詳細資訊，請參閱 啟用 Microsoft Entra 多重要素驗證的多種方式（支援多種 MFA 方法）
  • 實作整合式 MFA 同盟驗證的合作夥伴。 這些合作夥伴使用者可存取合作夥伴中心，並使用 GDAP 管理客戶。 請參閱具有 AD FS 可用 MFA 功能的整合式 MFA 提供者：設定 AD FS 的方法。

重要

合作夥伴必須使用與 Microsoft Entra ID 的整合式 MFA 宣告相容的驗證提供者。 整合式認證聲明指出驗證時提供的實際憑證類型。 合作夥伴必須使用整合的 MFA 來管理客戶租戶與 GDAP。

合作夥伴中心與 API

下列合作夥伴中心 API 需要應用程式和使用者存取權限，以及 Microsoft Entra ID 支援的多因素驗證 (MFA)：

  • 探索 （價格/目錄/促銷）
  • 交易和管理
  • 帳單與對帳
  • 使用代理存取/AOBO 來管理客戶
  • 使用者與授權指派（僅限 DAP）
  • 使用者和授權指派（使用 GDAP）
  • 細微管理員關聯性要求和存取權指派

下列選項適用於合作夥伴：

  • 使用 Microsoft 內建驗證方法來滿足 MFA 需求。
  • 如果您使用同盟識別提供者，請確定同盟已設定為接受聯邦身份驗證。
  • 如果您想要使用 ADFS 來設定外部第二個驗證因素，請參考由第三方提供者提供的與 AD FS 相關的 MFA 服務：設定 AD FS 的驗證方法
  • 實作 MFA：遵循 安全性預設值指引，立即透過安全性預設值或條件式存取啟用 MFA。

驗證範例

若要說明驗證在合作夥伴中心的運作方式，請考慮下列範例。

範例 1：合作夥伴已實作Microsoft Entra 多重要素驗證

  1. Alejandra 為一家名為 Contoso 的 CSP 工作。 Contoso 已經為其合作夥伴租用戶中的所有用戶實施了 Microsoft Entra 的多重驗證 (MFA)。

  2. Alejandra 會啟動新的瀏覽器會話，並移至合作夥伴中心概觀頁面（不受 MFA 保護）。 合作夥伴中心會將 Alejandra 重新導向至 Microsoft Entra ID 登入。

  3. 由於 Contoso 現有的 Microsoft Entra 多重要素驗證設定，Alejandra 需要完成 MFA 驗證。 成功登入和 MFA 驗證後，Alejandra 會重新導向回合作夥伴中心概觀頁面。

  4. Alejandra 會嘗試存取合作夥伴中心其中一個受 MFA 保護的頁面。 由於 Alejandra 在稍早登入期間已完成 MFA 驗證，因此 Alejandra 可以存取受 MFA 保護的頁面，而不需要再次通過 MFA 驗證。

範例 2：合作夥伴已使用身分識別同盟實作非Microsoft MFA

  1. Prashob 在一家名為 Wingtip 的 CSP 工作。 Wingtip 已使用非Microsoft MFA，為 Wingtip 合作夥伴租使用者下的所有用戶實作 MFA，該 MFA 會透過身分識別同盟與 Microsoft Entra ID 整合。

  2. Prashob 會啟動新的瀏覽器會話，並移至合作夥伴中心概觀頁面（未受 MFA 保護）。 合作夥伴中心會將 Prashob 重新導向至 Microsoft Entra 識別碼以登入。

  3. 因為 Wingtip 有設定身分識別同盟，Microsoft Entra ID 會將 Prashob 重新導向至同盟識別提供者，以完成登入和 MFA 驗證。 成功登入和 MFA 驗證後，Prashob 會重新導向回 Microsoft Entra ID，然後重新導向至合作夥伴中心概觀頁面。

  4. Prashob 會嘗試存取合作夥伴中心的其中一個受 MFA 保護的頁面。 由於 Prashob 已在稍早登入期間完成 MFA 驗證，因此他不需要再次通過 MFA 驗證即可存取受 MFA 保護的頁面。

  5. Prashob 接著移至服務管理頁面，在 Contoso 的 Microsoft Entra 識別符中新增使用者。 由於 Prashob 已使用與 Entra 相容的驗證提供者和強化身份驗證，因此他們可以存取客戶租戶，沒有任何問題。

此範例中對 Prashob 的建議是使用 Microsoft Entra 多因素驗證解決方案或 Entra 相容的驗證提供者，以便他們能夠成功管理客戶的租戶。

範例 3：合作夥伴尚未實作 MFA

  1. 名為 Fabrikam 的 CSP 合作夥伴尚未實作 MFA。 Microsoft建議他們實作 Microsoft Entra ID 支援的 MFA 解決方案。

  2. 約翰為 Fabrikam 工作。 Fabrikam 尚未為 Fabrikam 合作夥伴租戶中的任何用戶實施 MFA。

  3. John 會啟動新的瀏覽器會話，並移至合作夥伴中心概觀頁面（不受 MFA 保護）。 合作夥伴中心會將John重新導向至 Microsoft Entra 識別碼以登入。

  4. 成功登入之後，John 會重新導向回合作夥伴中心概觀頁面，因為他尚未完成 MFA 驗證。

  5. John 嘗試存取合作夥伴中心內受 MFA 保護的其中一個頁面。 由於 John 尚未完成 MFA 驗證，合作夥伴中心會將 John 重新導向至 Microsoft Entra 識別碼，以完成 MFA 驗證。 因為這是 John 第一次需要完成 MFA，因此也要求 John 進行 MFA 註冊。 成功註冊 MFA 和 MFA 驗證後，John 可以存取受 MFA 保護的頁面。

  6. 在另一天，在 Fabrikam 為任何用戶實作 MFA 之前，John 會啟動新的瀏覽器會話，並移至合作夥伴中心概觀頁面（不受 MFA 保護）。 合作夥伴中心會將John重新導向至 Microsoft Entra 識別碼，以在沒有 MFA 提示的情況下登入。

  7. John 嘗試存取合作夥伴中心內受 MFA 保護的其中一個頁面。 由於 John 尚未完成 MFA 驗證，合作夥伴中心會將 John 重新導向至 Microsoft Entra 識別碼，以完成 MFA 驗證。 因為 John 已註冊 MFA，這次他只被要求完成 MFA 驗證。

範例 4：合作夥伴已實作與 Microsoft Entra 不相容的非Microsoft MFA

  1. Trent 就職於一家名為 Wingtip 的 CSP。 Wingtip 已在其合作夥伴租戶的所有用戶中，使用具有條件式存取功能的雲端環境，實作非-Microsoft MFA。

  2. Trent 會啟動新的瀏覽器會話，並移至合作夥伴中心概觀頁面（不受 MFA 保護）。 合作夥伴中心會將 Trent 重新導向至 Microsoft Entra ID 以登入。

  3. 由於 Wingtip 使用與 Microsoft Entra ID 不相容且沒有強身份驗證的非Microsoft MFA 整合，因此 Trent 將會遭到封鎖，無法存取合作夥伴中心內所有受 MFA 保護的頁面和 API。

由於 Trent 正在存取受 MFA 保護的頁面，因此他必須向 MFA 顯示強身份驗證，才能存取受 MFA 保護的頁面。

合作夥伴必須使用與 Microsoft Entra 識別相容並支援認證方法宣告的驗證提供者（在存取令牌宣告參考中為 「amr 宣告」- Microsoft 身分識別平台），以反映在驗證過程中提供的實際認證類型。

強烈建議 CSP 合作夥伴實作與 Microsoft Entra 識別符相容的 MFA，以立即提高租使用者的安全性基準。

合作夥伴中心 API

合作夥伴中心 API 同時支援僅限應用程式驗證和應用程式和使用者 （App+User） 驗證。

使用 App+使用者驗證時，合作夥伴中心需要 MFA 驗證。 更具體來說，當合作夥伴應用程式將 API 要求傳送至合作夥伴中心時，它必須在要求的授權標頭中包含存取令牌。

注意

安全應用程式模型架構是一種具有彈性的架構，允許在呼叫合作夥伴中心 API 時，透過 Microsoft Azure MFA 架構驗證 CSP 合作夥伴和 CPV。 在服務自動化中使用 MFA 時，您必須實作此架構。

當合作夥伴中心收到以 App+User 驗證取得存取權杖的 API 要求時，合作夥伴中心 API 會檢查驗證方法參考（AMR）宣告中是否存在 MFA 值。 您可以使用 JWT 解碼器來驗證存取令牌是否包含預期的身份驗證方法參考 (AMR) 值：

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

  • 如果該值存在，合作夥伴中心即會判定 MFA 驗證已完成，並處理 API 要求。

  • 如果值不存在，合作夥伴中心 API 會以下列回應拒絕要求：

    HTTP/1.1 401 Unauthorized - MFA required
Transfer-Encoding: chunked
Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
WWW-Authenticate: Bearer error="invalid_token"
Date: Thu, 14 Feb 2019 21:54:58 GMT

呼叫合作夥伴中心 API 時，只有在不需要於客戶租戶中指定 GDAP 角色的作業中，才支援僅限應用程式的存取權杖。

若要深入瞭解最佳做法，請參閱 API 驗證和授權 – 概觀。

合作夥伴委派的管理

合作夥伴租戶應使用細粒度委派系統管理員許可權（GDAP），透過 Microsoft Online Services 入口網站（portal.azure.com 或 admin.microsoft.com）、命令列介面（CLI）和 API（使用 App + 使用者驗證）來管理客戶資源。 如需詳細資訊，請參閱 支援的 MFA 選項。

使用服務入口網站

CSP 合作夥伴可以透過服務管理介面從合作夥伴中心入口網站管理他們的客戶。 合作夥伴可以流覽至客戶，然後選取 [服務管理] 以管理客戶的特定服務。 合作夥伴必須遵循 GDAP 角色指引，以取得正確的最低許可權 GDAP 角色來管理其客戶。

使用合作夥伴委派系統管理員許可權（Admin-On-Behalf-Of）存取 Microsoft Online Services 入口網站來管理客戶資源時，許多這些入口網站都需要合作夥伴帳戶以互動方式進行驗證，並將客戶的 Microsoft Entra 租戶設為驗證內容。 需要合作夥伴帳號才能登入客戶租戶。

如果有需要 MFA 的原則，Microsoft Entra ID 驗證會要求使用者完成 MFA 驗證。 可能的使用者體驗有兩種，這取決於合作夥伴帳戶是受控識別還是同盟身分識別：

  • 如果合作夥伴帳戶是 受控 識別，Microsoft Entra ID 會直接提示使用者完成 MFA 驗證。 如果合作夥伴帳戶先前尚未在 Microsoft Entra ID 註冊多重因素驗證 (MFA)，系統會要求使用者先完成 MFA 註冊。

  • 如果合作夥伴帳戶是 同盟 身分識別，則體驗取決於合作夥伴系統管理員在 Microsoft Entra 標識符中設定同盟的方式。 在 Microsoft Entra 識別符中設定同盟時，合作夥伴系統管理員可以向 Microsoft Entra 識別符指示同盟的身分供應者是否支援 MFA。

    • 如果是，Microsoft Entra ID 會將使用者重新導向至同盟識別提供者，以完成 MFA 驗證。
    • 如果沒有，Microsoft Entra ID 會直接提示使用者完成 MFA 驗證。 如果合作夥伴帳戶先前尚未向 Microsoft Entra ID 註冊 MFA，系統會要求使用者先完成 MFA 註冊。

整體體驗就像終端客戶租戶為其系統管理員實作多因素驗證 (MFA) 的情境一樣。 例如，客戶租使用者已啟用 Microsoft Entra 安全性預設值，這需要具有系統管理許可權的所有帳戶使用 MFA 驗證來登入客戶租使用者，包括系統管理員代理程式和技術服務人員。

基於測試目的，合作夥伴可以在客戶租戶中啟用 Microsoft Entra 安全性預設值，然後嘗試使用合作夥伴細微委派系統管理許可權 (GDAP) 以存取客戶租戶。

注意

並非所有 Microsoft 在線服務入口網站都需要合作夥伴帳戶在使用 GDAP 存取客戶資源時，登入客戶租戶。 而是，有些只需要合作夥伴帳戶登入合作夥伴租戶。 Exchange 系統管理中心是其中一例。 經過一段時間，我們預期這些入口網站會要求合作夥伴帳戶在使用 GDAP 時登入客戶租使用者。

MFA 註冊體驗

在 MFA 驗證期間，如果合作夥伴帳戶之前尚未註冊 MFA，Microsoft Entra ID 會提示使用者先完成 MFA 註冊。

檢閱Microsoft Authenticator 方法的詳細資訊：

Screenshot of the first step in MFA registration.MFA 註冊中第一個步驟的螢幕快照。

用戶選取 [下一步] 之後，系統會要求他們從驗證方法清單中選擇。

Screenshot of the second step in MFA registration.MFA 註冊中第二個步驟的螢幕快照。

成功註冊之後，用戶必須使用所選的驗證方法完成 MFA 驗證。

常見問題

若要瞭解您的要求是否有效，請檢閱其他合作夥伴回報的常見問題清單。

問題 1：合作夥伴需要更多時間來為其合作夥伴代理人員實作 MFA

合作夥伴尚未開始，或仍在為其需要使用「合作夥伴委派管理權限」以存取 Microsoft Online Services 入口網站管理客戶資源的夥伴代理人實施 MFA。 合作夥伴需要更多時間來完成 MFA 實作。 這是技術例外狀況的合理原因嗎？

回答：否。 合作夥伴必須規劃為其用戶實作 MFA，以避免中斷。

注意

即使合作夥伴尚未為其合作夥伴代理實作 MFA，如果合作夥伴代理在登入客戶租用戶期間被提示時，能夠完成 MFA 註冊和 MFA 驗證，那麼他們仍然可以使用合作夥伴委派系統管理許可權來存取 Microsoft 在線服務入口網站。 完成 MFA 註冊並不會自動為使用者啟用 MFA。

問題 2：合作夥伴尚未實作 MFA，因為它們不需要存取來管理客戶

合作夥伴在其合作夥伴租使用者中有一些使用者不需要存取 Microsoft Online Services 入口網站，以使用合作夥伴委派的系統管理許可權來管理客戶資源。 合作夥伴正進行為這些使用者實作 MFA 的程序，而需要更多時間才能完成。 這是技術例外狀況的合理原因嗎？

回答：否。 由於這些用戶帳戶不會使用合作夥伴委派的系統管理許可權來管理客戶資源，因此不需要他們登入客戶租使用者。 它們在登入客戶租用戶時需要進行 MFA 驗證，但不會受到 Microsoft Entra ID 的影響。 所有使用者都必須有 MFA 存取合作夥伴中心或客戶工作負載，才能管理客戶資源。

問題 3：合作夥伴尚未針對使用者帳戶實作 MFA

合作夥伴在其合作夥伴租用戶中有一些使用者帳戶，裝置將其當做服務帳戶使用。 這些低許可權帳戶不需要存取合作夥伴中心，也不需要Microsoft Online Services 入口網站，就能使用合作夥伴委派的系統管理許可權來管理客戶資源。 這是技術例外狀況的有效原因嗎？

回答：否。 由於這些用戶帳戶不會使用合作夥伴委派的系統管理許可權來管理客戶資源，因此不需要登入客戶租使用者。 它們在登入客戶租用戶時，不會受到 Microsoft Entra ID 要求進行 MFA 驗證的影響。 如果 API 或入口網站需要應用程式+使用者驗證，則每個使用者都必須使用 MFA 進行驗證。

問題 4：合作夥伴無法使用 Microsoft Authenticator 應用程式實作 MFA

合作夥伴有「乾淨的桌面」原則，不允許員工將個人行動裝置帶到其工作區。 若無法存取其個人行動裝置，員工就無法安裝 Microsoft Authenticator 應用程式，這是Microsoft Entra 安全性預設值唯一支援的 MFA 驗證。 這是技術例外狀況的合理原因嗎？

回答：否。 合作夥伴應該考慮下列替代方案，讓員工在存取合作夥伴中心時仍可完成 MFA 驗證：

  • 合作夥伴也可以註冊 Microsoft Entra ID P1 或 P2，或使用與 Microsoft Entra ID 相容的非Microsoft MFA 解決方案，以提供更多驗證方法。 若要深入瞭解，請參閱 支援的驗證方法。

問題 5：合作夥伴因使用舊版驗證通訊協定而無法實作 MFA

合作夥伴有一些合作夥伴代理人仍在使用與 MFA 不相容的舊版驗證通訊協定。 例如，有些使用者仍在使用以舊版驗證通訊協定為基礎的 Outlook 2010。 為這些合作夥伴代理人啟用 MFA，將會中斷舊版驗證通訊協定的使用。 這是技術例外狀況的合理原因嗎？

回答：否。 由於潛在的安全性影響，因此鼓勵合作夥伴遠離使用舊版驗證通訊協定，因為這些通訊協定無法受到 MFA 驗證的保護，而且更容易受到認證入侵的影響。 建議您取代任何舊版驗證，並使用安全性預設值或條件式存取。 若要準備逐步淘汰舊版驗證，請仔細檢閱使用舊版驗證的登入活頁簿，以及如何封鎖舊版驗證的指引。

若要瞭解支援 Outlook 舊版驗證的最新方案，請閱讀基本身份驗證和 Exchange Online 相關文章，並遵循 Exchange 小組部落格以取得即將發布的更新資訊。

問題 6：合作夥伴已實作Microsoft Entra 標識符無法辨識的非Microsoft MFA

合作夥伴已使用非Microsoft MFA 解決方案，為其用戶實作 MFA。 不過，合作夥伴無法正確設定非 Microsoft MFA 解決方案，以向 Microsoft Entra ID 中繼傳遞在使用者驗證期間已完成的 MFA 驗證。 這是技術例外狀況的合理原因嗎？

答：否，合作夥伴必須使用與 Microsoft Entra ID 兼容的身份驗證提供者，該提供者支持認證方法宣告 ("AMR")，以反映驗證期間提供的實際認證類型。Microsoft 身份識別平台訪問權杖宣告參考。

強烈建議您實作與 Microsoft Entra ID 相容的 MFA，以立即提高租使用者的安全性基準。

相關內容