将 Azure 订阅转移到其他 Microsoft Entra 目录

组织可能具有多个 Azure 订阅。 每个订阅都与特定 Microsoft Entra 目录关联。 为了简化管理,你可能希望将订阅转移到其他 Microsoft Entra 目录。 将订阅转移到其他 Microsoft Entra 目录时,某些资源不会转移到目标目录。 例如,Azure 基于角色的访问控制 (Azure RBAC) 中的所有角色分配和自定义角色将从源目录中永久删除,不会转移到目标目录。

本文介绍将订阅转移到其他 Microsoft Entra 目录并在转移后重新创建一些资源时可以遵循的基本步骤。

如果要改为阻止将订阅转移到组织中的其他目录,可以配置订阅策略。 有关详细信息,请参阅管理 Azure 订阅策略

注意

对于 Azure 云解决方案提供商 (CSP) 订阅,不支持更改订阅的 Microsoft Entra 目录。

概述

将 Azure 订阅转移到其他 Microsoft Entra 目录是一个复杂的过程,必须仔细计划和执行。 许多 Azure 服务都需要安全主体(标识)才能正常运行,或者才能管理其他 Azure 资源。 本文将尽力涵盖很大程度上依赖于安全主体的大多数 Azure 服务,但这些服务并不全面。

重要

在某些情况下,转移订阅的过程可能需要停机才能完成。 需要认真规划以评估转移是否需要停机。

下图显示了将订阅转移到其他目录时必须遵循的基本步骤。

  1. 准备转移

  2. 将 Azure 订阅转移到另一目录

  3. 在目标目录中重新创建资源,例如角色分配、自定义角色和托管标识

    Transfer subscription diagram

决定是否将订阅转移到其他目录

以下是你可能想要转移订阅的一些原因:

  • 由于公司合并或收购,你希望在主 Microsoft Entra 目录中管理获得的订阅。
  • 组织中的某个人员创建了一个订阅,你希望将管理合并到特定的 Microsoft Entra 目录。
  • 你的应用程序依赖于特定的订阅 ID 或 URL,并且无法轻松修改应用程序配置或代码。
  • 部分业务已拆分为一个独立的公司,你需要将一些资源转移到其他 Microsoft Entra 目录中。
  • 出于安全隔离目的,你希望在不同的 Microsoft Entra 目录中管理某些资源。

备用方法

转移订阅的过程需要停机才能完成。 可以根据情况考虑以下替代方法:

  • 重新创建资源并将数据复制到目标目录和订阅中。
  • 采用多目录体系结构,并将订阅保留在源目录中。 使用 Azure Lighthouse 委托资源,以便目标目录中的用户可以访问源目录中的订阅。 更多信息,请参阅 Azure Lighthouse 企业方案

了解转移订阅的影响

许多 Azure 资源都依赖于订阅或目录。 下表列出了转移订阅的已知影响,具体取决于你的情况。 通过执行本文中的步骤,你可以重新创建转移订阅之前存在的某些资源。

重要

本部分列出了依赖于订阅的已知 Azure 服务或资源。 由于 Azure 中的资源类型在不断发展变化,可能还有其他没有列出的依赖项会对你的环境造成中断性变更。

服务或资源 受影响 可恢复 你是否受到影响? 可执行的操作
角色分配 “是” “是” 列出角色分配 将永久删除所有角色分配。 必须将用户、组和服务主体映射到目标目录中的相应对象。 必须重新创建角色分配。
自定义角色 “是” “是” 列出自定义角色 将永久删除所有自定义角色。 必须重新创建自定义角色和任何角色分配。
系统分配的托管标识 “是” “是” 列出托管标识 必须禁用并重新启用托管标识。 必须重新创建角色分配。
用户分配的托管标识 “是” “是” 列出托管标识 必须删除、重新创建托管标识并将其附加到相应的资源。 必须重新创建角色分配。
Azure Key Vault “是” 列出 Key Vault 访问策略 必须更新与密钥保管库关联的租户 ID。 必须删除并添加新的访问策略。
启用了 Microsoft Entra 身份验证集成的 Azure SQL 数据库 检查采用 Microsoft Entra 身份验证的 Azure SQL 数据库 不能将启用了 Microsoft Entra 身份验证的 Azure SQL 数据库传输到不同的目录中。 有关详细信息,请参阅使用 Microsoft Entra 身份验证
启用了 Microsoft Entra 身份验证集成的 Azure Database for MySQL 不能将启用了 Microsoft Entra 身份验证的 Azure Database for MySQL(单一服务器和灵活服务器)传输到不同的目录中。
Azure 存储和 Azure Data Lake Storage Gen2 必须重新创建任何 ACL。
Azure Data Lake Storage Gen1 必须重新创建任何 ACL。
Azure 文件 必须重新创建任何 ACL。
Azure 文件同步 存储同步服务和/或存储帐户可移动到不同的目录中。 有关详细信息,请查看 Azure 文件存储常见问题解答 (FAQ)
Azure 托管磁盘 如果使用磁盘加密集通过客户管理的密钥对托管磁盘进行加密,则必须先禁用再重新启用与磁盘加密集关联的系统分配标识。 你必须重新创建角色分配,即,向密钥保管库中的磁盘加密集再次授予所需权限。
Azure Kubernetes 服务 不能将 AKS 群集及其关联资源传输到不同的目录中。 有关详细信息,请查看 Azure Kubernetes 服务 (AKS) 的常见问题解答
Azure Policy 所有 Azure Policy 对象,包括自定义定义、分配、豁免和符合性数据。 必须导出、导入和重新分配定义。 然后,创建新的策略分配以及任何必需的策略豁免
Microsoft Entra 域服务 不能将 Microsoft Entra 域服务托管域传输到不同的目录中。 有关详细信息,请查看 Microsoft Entra 域服务的常见问题解答 (FAQ)
应用注册 “是”
Microsoft Dev Box 不能将 Dev Box 及其关联资源传输到不同的目录中。 在订阅移动到另一个租户后,你将无法对 Dev Box 执行任何操作
Azure 部署环境 不能将环境及其关联资源传输到不同的目录中。 在订阅移动到另一个租户后,你将无法对环境执行任何操作
Azure 服务总线 必须删除、重新创建托管标识并将其附加到相应的资源。 必须重新创建角色分配。
Azure Synapse Analytics 工作区 必须更新与 Synapse Analytics 工作区关联的租户 ID。 如果工作区与 Git 存储库相关联,则必须更新工作区的 Git 配置。 有关详细信息,请参阅将订阅转移到其他 Microsoft Entra 目录(租户)后恢复 Synapse Analytics 工作区

警告

如果对依赖于要传输的密钥保管库的资源(例如存储帐户或 SQL 数据库)使用静态加密,则可能会导致无法恢复的情况。 如果遇到这种情况,应采取步骤使用其他密钥保管库或暂时禁用客户管理的密钥,以避免这种不可恢复的情况。

若要获取在转移订阅时受到影响的一些 Azure 资源的列表,还可以在 Azure Resource Graph 中运行查询。 有关示例查询,请参阅列出转移 Azure 订阅时受影响的资源

先决条件

若要完成这些步骤,需要:

  • Azure CLI
  • 要在源目录中转移的订阅的帐户管理员
  • 进行目录更改的用户在源目录和目标目录中的用户帐户

步骤 1:准备转移

登录源目录

  1. 以管理员身份登录 Azure。

  2. 使用 az account list 命令获取订阅列表。

    az account list --output table
    
  3. 使用 az account set 设置要转移的活动订阅。

    az account set --subscription "Marketing"
    

安装 Azure Resource Graph 扩展

借助 Azure Resource Graph 的 Azure CLI 扩展 resource-graph,你可以使用 az graph 命令来查询由 Azure 资源管理器管理的资源。 后续步骤中需要使用此命令。

  1. 使用 az extension list 查看是否安装了 resource-graph 扩展。

    az extension list
    
  2. 如果使用的是预览版或旧版 resource-graph 扩展,请使用 az extension update 更新扩展。

    az extension update --name resource-graph
    
  3. 如果未安装 resource-graph 扩展,请使用 az extension add 安装扩展。

    az extension add --name resource-graph
    

保存所有角色分配

  1. 使用 az role assignment list 列出所有角色分配(包括继承的角色分配)。

    为了更轻松地查看列表,可以将输出导出为 JSON、TSV 或表。 有关详细信息,请参阅使用 Azure RBAC 和 Azure CLI 列出角色分配

    az role assignment list --all --include-inherited --output json > roleassignments.json
    az role assignment list --all --include-inherited --output tsv > roleassignments.tsv
    az role assignment list --all --include-inherited --output table > roleassignments.txt
    
  2. 保存角色分配的列表。

    转移订阅时,所有角色分配都将永久删除,因此保存副本非常重要。

  3. 查看角色分配的列表。 可能存在目标目录中不需要的角色分配。

保存自定义角色

  1. 使用 az role definition list 列出自定义角色。 有关详细信息,请参阅使用 Azure CLI 创建或更新 Azure 自定义角色

    az role definition list --custom-role-only true --output json --query '[].{roleName:roleName, roleType:roleType}'
    
  2. 将目标目录中需要的每个自定义角色另存为单独的 JSON 文件。

    az role definition list --name <custom_role_name> > customrolename.json
    
  3. 创建自定义角色文件的副本。

  4. 将每个副本修改为使用以下格式。

    稍后将使用这些文件在目标目录中重新创建自定义角色。

    {
      "Name": "",
      "Description": "",
      "Actions": [],
      "NotActions": [],
      "DataActions": [],
      "NotDataActions": [],
      "AssignableScopes": []
    }
    

确定用户、组和服务主体映射

  1. 根据你的角色分配列表,确定你将在目标目录中映射到的用户、组和服务主体。

    可以通过查看每个角色分配中的 principalType 属性来确定主体类型。

  2. 如果需要,可以在目标目录中,创建所需的任何用户、组或服务主体。

列出托管标识的角色分配

将订阅转移到另一个目录时,不会更新托管标识。 因此,任何现有系统分配的或用户分配的托管标识将被破坏。 转移完成后,可以重新启用任何系统分配的托管标识。 对于用户分配的托管标识,必须重新创建并将它们附加到目标目录中。

  1. 查看支持托管标识的 Azure 服务列表以了解可能用到托管标识的位置。

  2. 使用 az ad sp list 列出系统分配的和用户分配的托管标识。

    az ad sp list --all --filter "servicePrincipalType eq 'ManagedIdentity'"
    
  3. 在托管标识列表中,确定哪些是系统分配的托管标识,哪些是用户分配的托管标识。 可以使用以下条件来确定类型。

    条件 托管标识类型
    alternativeNames 属性包括 isExplicit=False 系统分配
    alternativeNames 属性不包括 isExplicit 系统分配
    alternativeNames 属性包括 isExplicit=True 用户分配

    还可以使用 az identity list 命令仅列出用户分配的托管标识。 有关详细信息,请参阅使用 Azure CLI 创建、列出或删除用户分配的托管标识

    az identity list
    
  4. 获取托管标识的 objectId 值列表。

  5. 搜索角色分配列表,以查看是否有托管标识的任何角色分配。

列出密钥保管库

创建密钥保管库时,它会自动绑定到创建它的订阅的默认 Microsoft Entra 租户 ID。 所有访问策略条目也都绑定到此租户 ID。 有关详细信息,请参阅将 Azure Key Vault 移动到另一个订阅

警告

如果对依赖于要传输的密钥保管库的资源(例如存储帐户或 SQL 数据库)使用静态加密,则可能会导致无法恢复的情况。 如果遇到这种情况,应采取步骤使用其他密钥保管库或暂时禁用客户管理的密钥,以避免这种不可恢复的情况。

列出采用 Microsoft Entra 身份验证的 Azure SQL 数据库

列出 ACL

  1. 如果使用的是 Azure Data Lake Storage Gen1,请使用 Azure 门户或 PowerShell 列出适用于任何文件的 ACL。

  2. 如果使用的是 Azure Data Lake Storage Gen2,请使用 Azure 门户或 PowerShell 列出适用于任何文件的 ACL。

  3. 如果使用的是 Azure 文件,请列出应用于任何文件的 ACL。

列出其他已知资源

  1. 使用 az account show 获取订阅 ID(在 bash 中)。

    subscriptionId=$(az account show --output tsv --query id)
    
  2. 使用 az graph 扩展列出具有已知 Microsoft Entra 目录依赖项的其他 Azure 资源(在 bash 中)。

    az graph query -q 'resources 
        | where type != "microsoft.azureactivedirectory/b2cdirectories" 
        | where  identity <> "" or properties.tenantId <> "" or properties.encryptionSettingsCollection.enabled == true 
        | project name, type, kind, identity, tenantId, properties.tenantId' --subscriptions $subscriptionId --output yaml
    

步骤 2:转移订阅

在此步骤中,你需要将订阅从源目录转移到目标目录。 具体步骤取决于是否还要转移计费所有权。

警告

转移订阅时,源目录中的所有角色分配都将永久删除且无法还原。 订阅转移后无法取消。 执行此步骤之前,请确保已完成前面的步骤。

  1. 确定是否还要将计费所有权转移到另一个帐户。

  2. 将订阅转移到另一目录。

  3. 完成订阅转移后,请返回到本文,了解如何在目标目录中重新创建资源。

步骤 3:重新创建资源

登录目标目录

  1. 在目标目录中,以接受转移请求的用户身份登录。

    只有新帐户中接受了转移请求的用户才有权管理这些资源。

  2. 使用 az account list 命令获取订阅列表。

    az account list --output table
    
  3. 使用 az account set 设置要使用的活动订阅。

    az account set --subscription "Contoso"
    

创建自定义角色

分配角色

更新系统分配的托管标识

  1. 禁用并重新启用系统分配的托管标识。

    Azure 服务 详细信息
    虚拟机 使用 Azure CLI 在 Azure VM 上配置 Azure 资源托管标识
    虚拟机规模集 使用 Azure CLI 在虚拟机规模集上配置 Azure 资源托管标识
    其他服务 支持 Azure 资源托管标识的服务
  2. 使用 az role assignment create 为系统分配的托管身份分配角色。 有关详细信息,请参阅使用 Azure CLI 为托管标识分配对资源的访问权限

    az role assignment create --assignee <objectid> --role '<role_name_or_id>' --scope "/subscriptions/<subscriptionId>/resourceGroups/<resource_group>"
    

更新用户分配的托管标识

  1. 删除、重新创建并附加用户分配的托管标识。

    Azure 服务 详细信息
    虚拟机 使用 Azure CLI 在 Azure VM 上配置 Azure 资源托管标识
    虚拟机规模集 使用 Azure CLI 在虚拟机规模集上配置 Azure 资源托管标识
    其他服务 支持 Azure 资源托管标识的服务
    使用 Azure CLI 创建、列出或删除用户分配的托管标识
  2. 使用 az role assignment create 为用户分配的托管身份分配角色。 有关详细信息,请参阅使用 Azure CLI 为托管标识分配对资源的访问权限

    az role assignment create --assignee <objectid> --role '<role_name_or_id>' --scope "/subscriptions/<subscriptionId>/resourceGroups/<resource_group>"
    

更新密钥保管库

本部分介绍更新密钥保管库的基本步骤。 有关详细信息,请参阅将 Azure Key Vault 移动到另一个订阅

  1. 将与订阅中的所有现有密钥保管库关联的租户 ID 更新到目标目录。

  2. 删除所有现有的访问策略条目。

  3. 添加与目标目录相关联的新访问策略条目。

更新 ACL

  1. 如果使用的是 Azure Data Lake Storage Gen1,请分配相应的 ACL。

  2. 如果使用的是 Azure Data Lake Storage Gen2,请分配相应的 ACL。 有关详细信息,请参阅 Azure Data Lake Storage Gen2 中的访问控制

  3. 如果使用的是 Azure 文件存储,请分配相应的 ACL。

查看其他安全方法

即使在转移过程中删除了角色分配,原始所有者帐户中的用户仍可以通过其他安全方法访问订阅,这些方法包括:

  • 存储空间等服务的访问密钥。
  • 用于向用户授予订阅资源管理员访问权限的管理证书
  • Azure 虚拟机等服务的远程访问凭据。

如果你打算删除源目录中用户的访问权限,以使他们在目标目录中没有访问权限,则应考虑轮换所有凭据。 转移之后,用户在凭据更新之前将继续具有访问权限。

  1. 轮换存储帐户访问密钥。 有关详细信息,请参阅管理存储帐户访问密钥

  2. 如果将访问密钥用于其他服务(例如 Azure SQL 数据库或 Azure 服务总线消息传送),请轮换访问密钥。

  3. 对于使用机密的资源,请打开资源设置并更新机密。

  4. 对于使用证书的资源,请更新证书。

后续步骤