共用方式為

Azure Stack Hub 的識別提供者概觀

  • 發行項

Azure Stack Hub 要求以 Active Directory 所支援的 Microsoft Entra ID 或 Active Directory Federation Services (AD FS) 作為識別提供者。 提供者的選擇是您第一次部署 Azure Stack Hub 時所做的一次性決定。 本文中的概念和授權詳細數據可協助您在識別提供者之間選擇。

選擇 Microsoft Entra ID 或 AD FS 會由您用來部署 Azure Stack Hub 的模式所決定：

  • 當您在連線模式下部署時，可以使用 Microsoft Entra ID 或 AD FS。
  • 當您在沒有網際網路連線的中斷連線模式下部署時，僅支援 AD FS。

如需您相依於 Azure Stack Hub 環境之選項的詳細資訊，請參閱下列文章：

重要

Azure AD Graph 即將淘汰，將於 2023 年 6 月 30 日淘汰。 如需詳細資訊，請參閱本節。

識別提供者的一般概念

下一節將討論身分識別提供者及其在 Azure Stack Hub 中的使用方式的常見概念。

識別提供者的術語

目錄租用戶和組織

目錄是保存使用者、應用程式、群組和服務主體相關信息的容器。

目錄租使用者是一個 組織，例如Microsoft或您自己的公司。

  • Microsoft Entra ID 支援多個租用戶並可支援多個組織 (各自位於自己的目錄中)。 如果您使用 Microsoft Entra ID 並有多個租使用者，則可以將應用程式與使用者從一個租使用者存取權授與該相同目錄的其他租使用者。
  • AD FS 僅支援單一租用戶，因此僅支援單一組織。

使用者和群組

使用者帳戶 (身分識別) 是標準帳戶，可使用使用者識別碼和密碼驗證個人。 群組可以包含使用者或其他群組。

您建立及管理使用者和群組的方式取決於使用的身分識別解決方案。

在 Azure Stack Hub 中，使用者帳戶：

  • 會以 username@domain 格式建立。 雖然 AD FS 會將使用者帳戶對應至 Active Directory 實例，但 AD FS 不支援使用 \<domain>\<alias> 格式。
  • 可以設定為使用多重要素驗證。
  • 受限於它們首先註冊的目錄，也就是其組織目錄。
  • 可以從內部部署目錄匯入。 如需詳細資訊，請參閱 整合內部部署目錄與 Microsoft Entra ID。

當您登入組織的使用者入口網站時，您會使用 https://portal.local.azurestack.external URL。 從不同於用來註冊 Azure Stack Hub 的網域登入 Azure Stack Hub 入口網站後，必須將用來註冊 Azure Stack Hub 的網域名稱附加至入口網站 url。 例如，如果 Azure Stack Hub 已註冊 fabrikam.onmicrosoft.com，而登入的用戶帳戶為 ，則用來登入使用者入口網站的 URL 會是 admin@contoso.com： https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

來賓使用者

來賓使用者是其他目錄租用戶中的使用者帳戶，這些使用者已獲得您目錄中資源的存取權。 若要支援來賓使用者，您必須使用 Microsoft Entra ID 並啟用多租用戶支援。 若已啟用支援，您可以邀請來賓使用者存取您目錄租用戶中的資源，進而能夠與外部組織共同作業。

若要邀請來賓用戶，雲端操作員和使用者可以使用 Microsoft Entra B2B 共同作業。 受邀的使用者可取得您目錄中文件、資源及應用程式的存取權，而您會保有對自己的資源和資源的控制權。

身為來賓使用者，您可以登入其他組織的目錄租用戶。 若要這麼做，您必須將該組織的目錄名稱附加至入口網站 URL。 例如，如果您屬於 Contoso 組織，而且想要登入 Fabrikam 目錄，您可以使用 https://portal.local.azurestack.external/fabrikam.onmicrosoft.com.

應用程式

您可以向 Microsoft Entra ID 或 AD FS 註冊應用程式，然後將應用程式提供給您組織中的使用者。

應用程式包括：

  • Web 應用程式：範例包括 Azure 入口網站和 Azure Resource Manager。 它們支援 Web API 呼叫。
  • 原生用戶端：範例包括 Azure PowerShell、Visual Studio 和 Azure CLI。

應用程式可支援兩種租用戶：

  • 單一租用戶：僅支援應用程式註冊所在相同目錄中的使用者和服務。

    注意

    因為 AD FS 僅支援單一目錄，所以您在 AD FS 拓撲中建立的應用程式會設計為單一租用戶應用程式。

  • 多租用戶：支援由以下目錄中的使用者和服務使用：應用程式註冊所在的目錄，以及其他租用戶目錄。 使用多租用戶應用程式，另一個租用戶目錄 (另一個 Microsoft Entra 租用戶) 的使用者可以登入您的應用程式。

    如需多租用戶的詳細資訊，請參閱 啟用多租使用者。

    如需開發多租使用者應用程式的詳細資訊，請參閱 多租用戶應用程式。

當您註冊應用程式時，會建立兩個物件：

  • 應用程式物件：應用程式在所有租用戶中的全域代表。 此關聯性是與軟體應用程式的一對一關聯性，且只存在於首先註冊應用程式的目錄中。

  • 服務主體物件：在首先註冊應用程式的目錄中針對應用程式所建立的認證。 服務主體也會建立於使用該應用程式的每個其他租用戶的目錄中。 此關聯性可以是與軟體應用程式的一對多關聯性。

若要深入瞭解應用程式和服務主體物件，請參閱 Entra ID Microsoft 中的應用程式和服務主體物件。

服務主體

服務主體是應用程式或服務的一組「認證」，可授與 Azure Stack Hub 中資源的存取權。 使用服務主體可區隔應用程式權限與應用程式使用者的權限。

服務主體會建立於使用應用程式的每個租用戶中。 服務主體會建立身分識別，以供登入及存取受到該租用戶保護的資源 (例如使用者)。

  • 單一租用戶應用程式只有一個服務主體，位於首次建立的目錄中。 此服務主體會建立並同意在應用程式註冊期間使用。
  • 如果是多租用戶 Web 應用程式或 API，則會在使用者同意使用應用程式的每個租用戶中建立一個服務主體。

服務主體的認證可以是金鑰 (透過 Azure 入口網站產生) 或憑證。 憑證的使用很適合自動化，因為一般認為憑證比金鑰更安全。

注意

當您使用 AD FS 搭配 Azure Stack Hub 時，只有系統管理員可以建立服務主體。 使用 AD FS 時，服務主體需要憑證並透過特殊權限的端點 (PEP) 來建立。 如需詳細資訊，請參閱 使用應用程式身分識別來存取資源。

若要瞭解 Azure Stack Hub 的服務主體，請參閱 建立服務主體。

服務

在 Azure Stack Hub 中與識別提供者互動的服務，識別提供者會將其註冊為應用程式。 如同應用程式，註冊可讓服務向身分識別系統進行驗證。

所有 Azure 服務都會使用 OpenID Connect 通訊協定和 JSON Web 令牌 來建立其身分識別。 由於Microsoft Entra ID 和 AD FS 一致地使用通訊協定，因此您可以使用 Microsoft 驗證連結庫 （MSAL） 來取得安全性令牌，以驗證內部部署或 Azure（在連線的案例中）。 透過 MSAL，您也可以使用 Azure PowerShell 和 Azure CLI 等工具進行跨雲端和內部部署資源管理。

身分識別和身分識別系統

Azure Stack Hub 的身分識別包括使用者帳戶、群組和服務主體。

當您安裝 Azure Stack Hub 時，有數個內建應用程式和服務會在目錄租用戶中自動向您的識別提供者註冊。 有些註冊的服務可用於管理。 其他服務則可供使用者使用。 預設註冊會提供核心服務身分識別，這類身分識別可彼此互動，以及與您稍後新增的身分識別互動。

如果您設定採用多租用戶的 Microsoft Entra ID，則有些應用程式會傳播到新的目錄。

驗證與授權

由應用程式和用戶驗證

Azure Stack Hub 層之間的身分識別

對應用程式和使用者而言，Azure Stack Hub 的架構可以用四個層級來說明。 各層級之間的互動可以使用不同類型的驗證。

層 各層之間的驗證
工具與用戶端，例如系統管理員入口網站 若要存取或修改 Azure Stack Hub 中的資源，工具和用戶端會使用 JSON Web 令牌 來呼叫 Azure Resource Manager。
Azure Resource Manager 會驗證 JSON Web 令牌，並查看 所發行令牌中的宣告 ，以估計使用者或服務主體在 Azure Stack Hub 中擁有的授權層級。
Azure Resource Manager 與其核心服務 Azure Resource Manager 會與資源提供者通訊，以傳輸使用者的通訊。
傳輸會透過 Azure Resource Manager 範本使用直接命令式呼叫或宣告式呼叫。
資源提供者 傳遞至資源提供者的呼叫會以憑證型驗證進行保護。
Azure Resource Manager 和資源提供者而後會持續透過 API 通訊。 對於從 Azure Resource Manager 接收的每個呼叫，資源提供者會使用該憑證來驗證呼叫。
基礎結構和商務邏輯 資源提供者會使用其所選的驗證模式來與商務邏輯和基礎結構通訊。 Azure Stack Hub 隨附的預設資源提供者會使用 Windows 驗證來保護此通訊。

驗證所需的資訊

向 Azure Resource Manager 進行驗證

若要向識別提供者進行驗證並收到 JSON Web 權杖，您必須具有下列資訊:

  1. 識別系統 (授權單位) 的 URL:可以連線到您識別提供者的 URL。 例如： https://login.windows.net 。
  2. Azure Resource Manager 的應用程式識別碼 URI:已向識別提供者註冊之 Azure Resource Manager 的唯一識別碼。 此識別碼也是每個 Azure Stack Hub 安裝中的唯一識別碼。
  3. 認證：您用來向識別提供者驗證的認證。
  4. Azure Resource Manager 的 URL:URL 是 Azure Resource Manager 服務的位置。 例如，https://management.azure.com 或 https://management.local.azurestack.external。

當主體 (用戶端、應用程式或使用者) 提出驗證要求以存取資源時，該要求必須包含:

  • 主體的認證。
  • 主體想要存取之資源的應用程式識別碼 URI。

認證會由識別提供者驗證。 識別提供者也會驗證應用程式識別碼 URI 是否用於已註冊的應用程式，以及主體是否擁有正確權限以取得該資源的權杖。 如果要求有效，就會授與 JSON Web 權杖。

此權杖必須接著傳遞到 Azure Resource Manager 的要求標頭中。 Azure Resource Manager 會執行下列作業 (沒有特定順序):

  • 驗證 簽發者 (iss) 宣告，以確認權杖來自正確的識別提供者。
  • 驗證 對象 (aud) 宣告，以確認權杖已簽發給 Azure Resource Manager。
  • 驗證 JSON Web 權杖是否使用透過 OpenID 設定的憑證來簽署，而且為 Azure Resource Manager 所知。
  • 檢閱 簽發時間 (iat) 和 到期時間(exp) 宣告，以確認權杖為作用中並可接受。

完成所有驗證時，Azure Resource Manager 會使用 物件識別碼 (oid) 和 群組 宣告來產生主體可存取的資源清單。

令牌交換通訊協議的圖表

使用角色型 存取控制

Azure Stack Hub 中的角色型 存取控制 （RBAC） 與 azure Microsoft 中的實作一致。 您可以將適當的 RBAC 角色指派給使用者、群組和應用程式，以管理資源的存取權。 如需如何搭配 Azure Stack Hub 使用 RBAC 的詳細資訊，請參閱下列文章：

使用 Azure PowerShell 進行驗證

如需使用 Azure PowerShell 向 Azure Stack Hub 進行驗證的詳細數據，請參閱 設定 Azure Stack Hub 使用者的 PowerShell 環境。

使用 Azure CLI 進行驗證

如需使用 Azure PowerShell 向 Azure Stack Hub 進行驗證的詳細資訊，請參閱 安裝和設定 Azure CLI 以搭配 Azure Stack Hub 使用。

Azure 原則

Azure 原則有助於強制執行組織標準及大規模評估合規性。 透過其合規性儀錶板，其提供匯總檢視來評估環境的整體狀態，並能夠向下切入至每個資源、每個原則的數據粒度。 也可透過對現有資源進行大規模補救，以及自動對新資源進行補救來協助您的資源達到合規性。

Azure 原則的常見使用案例包括針對資源一致性、法規合規性、安全性、成本和管理來進行治理。 這些常見使用案例的原則定義已內建於您的 Azure 環境，以協助您開始使用。

注意

Azure Stack Hub 目前不支援 Azure 原則。

Azure AD Graph

Microsoft Azure 已於 2020 年 6 月 30 日宣佈淘汰 Azure AD Graph，以及其 2023 年 6 月 30 日的淘汰日期。 Microsoft已透過電子郵件 通知客戶有關這項變更。 如需詳細資訊，請參閱 Azure AD Graph 淘汰和 Powershell 模組淘汰 部落格。

下一節說明此取代如何影響 Azure Stack Hub。

Azure Stack Hub 小組正在與 Azure Graph 小組密切合作，以確保系統在必要時能繼續在 2023 年 6 月 30 日之後繼續運作，以確保順暢的轉換。 最重要的動作是確保您符合 Azure Stack Hub 服務原則。 客戶會在 Azure Stack Hub 的系統管理員入口網站中收到警示，而且需要更新主目錄和所有上線的客體目錄。

大部分移轉本身將由整合式系統更新體驗完成：客戶需要手動步驟，才能將新許可權授與這些應用程式，這需要在與 Azure Stack Hub 環境搭配使用的每個Microsoft Entra 目錄中，都需要應用程式管理員許可權。 使用這些變更的更新套件完成安裝之後，系統管理入口網站中會引發警示，指示您使用多租使用者UI或PowerShell腳本完成此步驟。 這是您在上線其他目錄或資源提供者時所執行的相同作業;如需詳細資訊，請參閱 在 Azure Stack Hub 中設定多租使用者。

如果您使用AD FS作為 Azure Stack Hub 的身分識別系統，這些圖形變更將不會影響您的系統。 不過，最新版的工具，例如 Azure CLI、Azure PowerShell 等，需要新的 Graph API，而且它們將無法運作。 請確定您只使用您指定的 Azure Stack Hub 組建明確支持的這些工具版本。

除了系統管理入口網站中的警示之外，我們還會透過更新版本資訊來傳達變更，並傳達哪些更新套件需要更新主目錄和所有上線的客體目錄。

下一步