订阅跨租户迁移致Managed Service Identity故障的解决与预防咨询

我之前处理过好几起类似的跨租户订阅迁移导致MSI失效的案例，完全不用重新部署Web Apps就能搞定，而且提前做好准备还能把后续的权限配置工作量降到最低，我给你详细拆解下：

为什么迁移后MSI会失效？ #

其实本质原因很简单：系统分配的MSI是和原租户绑定的Azure AD服务主体，当订阅从原租户迁移到新租户后，这个服务主体属于原租户，新租户的Azure AD根本不认可它，自然就失效了。用户分配的MSI同理，它本身就是原租户里的资源，跨租户迁移后订阅根本访问不到原租户的用户分配MSI。

不用重新部署，重置MSI就能恢复功能 #

不管是系统分配还是用户分配的MSI，都有对应的解决办法，而且都不用碰Web App的部署包：

针对系统分配的MSI #

方法1：Azure Portal操作

• 打开目标Web App，左侧导航栏找到「身份」选项卡
• 切换到「系统分配」标签，先点击「禁用」，保存设置
• 等待1-2分钟（给Azure AD同步的时间），再点击「启用」，保存
• 这时候Azure会自动在新租户里生成一个全新的服务主体，MSI功能就恢复了，一般等3-5分钟配置生效后就能正常使用

方法2：Azure CLI批量处理（适合多Web App场景）

先禁用MSI：

az webapp identity remove --name <你的Web App名称> --resource-group <资源组名称>

再重新启用：

az webapp identity assign --name <你的Web App名称> --resource-group <资源组名称>

可以把这些命令写成脚本，循环处理订阅里的所有Web App，效率更高。

针对用户分配的MSI #

这种情况没法直接重置，需要在新租户里重新操作：

• 在新租户的目标资源组里创建一个新的用户分配MSI
• 回到Web App的「身份」选项卡，切换到「用户分配」标签，删除原来的用户分配MSI，添加刚创建的新MSI
• 保存配置后，等待几分钟生效

关键注意点：权限需要重新配置 #

不管是系统分配还是用户分配的MSI，重置/重建后都是全新的服务主体，原来的角色权限（比如访问存储账户、Key Vault的权限）不会自动迁移，所以需要：

1. 迁移前，导出所有MSI的现有权限记录，比如用Azure CLI命令：

az role assignment list --assignee <原MSI的主体ID> --output json > msi-permissions.json

2. 迁移并重置MSI后，拿到新的主体ID，用脚本批量重新分配角色权限

迁移前的预防措施，减少后续工作量 #

虽然迁移后MSI失效是必然的，但提前做好准备能省很多事：

• 提前盘点所有Web App的MSI类型（系统/用户分配），记录对应的权限配置
• 准备好批量重置MSI和重新分配权限的脚本，迁移完成后直接运行
• 如果是用户分配的MSI，提前在新租户里创建好同名的MSI，迁移后直接关联即可

这样处理下来，完全不用重新部署Web App，就能恢复MSI功能，也能避免后续迁移其他订阅时手忙脚乱。

内容的提问来源于stack exchange，提问作者Filip Krane Adamsen