管理传统上围绕 Active Directory 的服务器标识：服务器已加入域，管理员将获得通过域组添加到本地管理员的域帐户，Windows 设置是使用组策略管理的。 在云管理模型中， Microsoft Entra 成为标识和访问的基石，而 Active Directory（AD）仍可用于本地 Windows 计算机上的应用身份验证和旧协议。
服务器管理中的云原生标识通过使用 Microsoft Entra 对管理员和服务器本身进行身份验证来实现。 本地 AD 已加入域的服务器仍可由云原生 Windows（工作站）设备或这些设备上的用户访问。 通过 Microsoft Entra，可以获得统一凭据，因为 Microsoft Entra ID 可以管理虚拟机（VM）、已启用 Arc 的服务器、Office 365 等。 多重身份验证（MFA）和条件访问等功能可提高安全性。 混合环境中的服务器可以使用 Azure 的标识系统安全地访问资源。 利用这些优势，可以缩短维护服务帐户或为每个计算机授予本地管理员权限所花费的时间。 这是思维的过渡，但与完全云管理的生态系统保持一致。
让我们看看系统管理员的世界如何随着 Microsoft Entra 的好处而变化。
Microsoft Entra 集成
Microsoft Entra ID 是基于云的标识服务。 与 Active Directory 域服务（AD DS）不同，Microsoft Entra ID 不是在组织单位中构建的，并且不专注于 Kerberos 身份验证。 相反，Microsoft Entra ID 管理用户标识、应用以及对Microsoft资源（包括 Azure）以及支持Microsoft Entra ID 的其他应用程序和作系统的访问权限。
服务器本身不会像加入域那样“加入”Microsoft Entra ID。 相反，已启用 Arc 的服务器在首次连接到 Azure 时会加入受 Microsoft Entra ID 管理的 Azure 租户。 使用 Microsoft Entra ID，用户可以使用 Azure 基于角色的访问控制（Azure RBAC）将角色分配到指定范围（或添加到具有这些权限的组）。 然后，具有相应权限的用户可以使用远程桌面连接来访问 Windows Server 计算机， 或使用 SSH 访问 Linux。
“管理员帐户”是 Azure 中具有适当角色的 Microsoft Entra ID 标识（或已同步 AD 帐户）。 例如，若要管理已启用 Arc 的服务器，Microsoft Entra ID 用户可能具有 Azure 内置角色 虚拟机管理员登录 角色，或者使用适当的权限创建的自定义角色分配。 Microsoft Entra ID 允许将角色限定为一组特定的 Azure 工作负载，而不是拥有一个允许对每个服务器进行完全访问权限的管理员帐户，只授予在已启用 Arc 的服务器和本机 Azure 资源上执行必要任务所需的权限。
系统分配的托管标识
已启用 Arc 的服务器需要 系统分配的托管标识。 这是一种企业应用程序，表示 Azure 中计算机资源的标识。 服务器上运行的应用程序可以使用服务器的托管标识向 Azure 进行身份验证，而不是存储凭据。 Azure Arc Connected 计算机代理公开应用可用于请求令牌的终结点。 该应用不需要向提供令牌的非可路由 Web 服务进行身份验证，该服务不提供正确设置请求格式（包括元数据标头）的令牌，因此预期的安全边界是 VM。 本地服务器可以直接访问 Azure 服务，而无需硬编码凭据，因为 Azure 知道请求来自该服务器，并且仅根据设置的角色分配对其进行授权。
对于系统管理员，一种常见方案可能是在服务器上（安装了 Azure CLI）上运行 Azure CLI 命令，该命令会调用 Azure 存储来检索自动化脚本使用的项目。 由于服务器具有对该存储帐户的标识授权访问权限，因此请求已完成，无需服务帐户或个人访问令牌（PAT）。
基于角色的访问控制 (RBAC)
Azure 的模型鼓励精细的 RBAC。 由于不同的内置角色支持不同类型的访问，因此你可以分配权限非常有限的角色。 例如，用户可以具有一个角色，该角色仅授予在已启用 Arc 的服务器上使用 运行命令 的能力，或者允许对配置进行只读访问，而仅允许其他作。
与 Azure Arc 一起使用的常见内置角色是 Azure Connected Machine Onboarding 角色。 具有此角色的用户可以将服务器加入 Azure Arc，但不能执行大多数其他管理任务，除非授予其他角色。 同样，你可以为应用程序所有者角色提供角色，允许他们通过 Azure 自动化在其服务器上部署修补程序，而无需提供实际的 OS 登录访问权限。 这种级别的微调支持“足够”的管理原则。
实时访问
若要进一步控制对已启用 Arc 的服务器和其他 Azure 资源的提升访问权限，可以启用Microsoft Entra Privileged Identity Management （PIM）。 PIM 可用于实时（JIT）访问，因此你可以要求某人显式提升到特定角色，以便执行需要更高级别的访问的任务。 你可以要求管理员批准此访问权限，并为提升的角色设置自动过期期限。 PIM 还包括一个审核历史记录，用于查看过去 30 天内所有特权角色的所有角色分配和激活（或配置的时间较长）。
使用 PIM 有助于减少正在进行的管理员访问权限，并支持 最低特权原则。 例如，可以使用 PIM 授予某些用户将角色提升到 Azure Connected Machine 资源管理员的能力，从而允许他们在已启用 Arc 的服务器上执行更高级的管理任务。
混合标识配置
实际上，许多企业运行已启用 Arc 的服务器，这些服务器也已加入 AD 域。 这些不是相互排斥的;它们相互补充。 如果需要，可以通过 AD 登录到服务器，但在 Azure 中执行管理任务。
在单个服务器上，仍可以通过 AD 管理本地帐户，例如使用本地管理员密码解决方案（LAPS）轮换本地管理员密码。 由于 Azure Arc 不管理本地帐户，可能需要继续使用此过程。 甚至可以使用 Azure Policy 来确保启用 LAPS 并将密码存储在 Microsoft Entra 中。
可以灵活地使用 Microsoft Entra 和 Azure 的功能，同时仍维护适合你的本地标识解决方案。 随着时间的推移，你会发现需要与维护服务帐户或授予本地管理员权限的交互更少，因为你可以有管理云中的标识的选项。