Compartilhar via

Microsoft Entra Kerberos 简介

Microsoft Entra Kerberos 是一种云原生身份验证协议，它通过启用对云和本地资源的安全访问来桥接混合标识方案。 它将传统的 Kerberos 功能扩展到Microsoft Entra生态系统中，使组织能够现代化其标识基础结构，而不会牺牲与旧系统的兼容性。 它还为使用新式凭据（如 Windows Hello for Business 或 FIDO2 安全密钥）进行身份验证的用户启用本地资源无缝单一登录（SSO）。

Microsoft Entra Kerberos 于 2021 年引入，以帮助弥合旧式本地身份验证协议与新式云标识之间的差距。 在实践中，Microsoft Entra Kerberos 将Microsoft Entra ID转换为基于云的密钥分发中心（KDC），以便进行 Kerberos 身份验证。 此功能允许Microsoft Entra ID向用户颁发 Kerberos 票证，从而将传统的 Kerberos 身份验证扩展到 on-premises Active Directory 之外。

在混合环境中，本地 Active Directory Domain Services（AD DS）中存在的帐户会与 Microsoft Entra ID 同步。在这种情况下，Microsoft Entra Kerberos 起着关键作用。 它使这些混合用户能够使用 Kerberos 向云和本地资源进行身份验证，而无需直接看到域控制器。 例如，如果通过 Microsoft Entra ID 加入的 Windows 客户端通过互联网访问文件共享或应用程序，Microsoft Entra ID 可以代表本地 Active Directory 环境颁发所需的 Kerberos 票证。

有关 Windows 中 Kerberos 的详细信息，请参阅《Windows Server 中的 Kerberos 身份验证概述》。

Microsoft Entra Kerberos 支持混合身份和仅云身份，只要服务支持。

混合身份

混合标识是指存在于本地 AD DS 和 Microsoft Entra ID 中的用户标识。 这些标识通过 Microsoft Entra Connect 等工具进行同步，因此用户可以使用一组凭据访问基于云的和本地资源。

此设置可跨环境实现无缝身份验证和 SSO 体验。 它非常适合想要在维护旧基础结构的同时过渡到云的组织。

仅限云身份 （预览版）

仅限云标识是指仅存在于Microsoft Entra ID（以前为 Azure AD）中的用户帐户，并且on-premises Active Directory中没有相应的帐户。

主要功能和优势

无缝混合身份验证：Microsoft Entra Kerberos 允许用户的帐户驻留在本地 AD DS 中，并同步到 Microsoft Entra ID，从而能够跨云和本地资源进行身份验证。 它减少了对域控制器的直接连接需求（并且在某些情况下，完全消除了这种需求）。

例如，当 Microsoft Entra ID 联接的 Windows 客户端通过 internet 访问文件共享或应用程序时，Microsoft Entra ID 可以作为与资源关联的 KDC 颁发必要的 Kerberos 票证。

仅限云的标识支持（预览版）：仅限云标识现在可以将 Kerberos 身份验证用于Azure Files等工作负载，而无需本地 AD DS。 这由 Entra Kerberos 启用，后者充当基于云的 KDC。

具有新式凭据支持的安全性：用户可以使用无密码方法（如 Windows Hello for Business 或 FIDO2 安全密钥）登录，但仍可以访问具有 Kerberos 保护的本地资源。 此功能使多重身份验证（MFA）和无密码身份验证能够降低与密码盗窃和网络钓鱼攻击相关的风险。

安全票证交换：Microsoft Entra Kerberos 使用票据授予票据（TGT）交换模型增强安全性。

可缩放的组成员身份：Microsoft Entra Kerberos 解决了大型或动态组成员身份的传统 Kerberos 限制，以提高可靠性和用户体验。 在涉及大量用户的方案中，通过站点内所有域控制器（DC）的自动负载分布来优化性能。 对于Azure Virtual Desktop环境中的部署，我们建议确保有足够的 DC 可用，并在地理上靠近环境，以保持响应能力。

Microsoft Entra Kerberos 的工作原理

在混合场景中，Microsoft Entra Kerberos 允许 Microsoft Entra ID 租户作为专用 Kerberos 领域，与现有本地 Active Directory 领域一起运行。 当用户登录到已加入 Microsoft Entra ID 或混合加入的 Windows 设备时，设备会使用 Microsoft Entra ID 进行身份验证，并接收 Primary Refresh Token（PRT）。

除了 PRT，Microsoft Entra ID 还会为域 KERBEROS.MICROSOFTONLINE.COM 颁发云 TGT，后者用于对云资源进行身份验证。 会发布一个单独的部分 TGT 以便访问本地资源，具体细节请参见本文档后面的描述。 在此模型中，Microsoft Entra ID充当 KDC，以促进无缝身份验证。

仅限云身份标识场景（预览版）

对 Entra Kerberos 的仅限云标识支持需要已启用 Entra Kerberos 的Microsoft Entra ID租户，并且Windows 10/11 设备已加入Microsoft Entra。

支持 Microsoft Entra ID 与 Entra Kerberos 结合使用，实现仅限云标识的身份验证，使加入 Entra 的会话主机无需依赖传统的 Active Directory 基础结构即可对云资源（如 Azure 文件共享）进行身份验证和访问。 此功能对于采用仅限云的策略的组织至关重要，因为它消除了域控制器的需求，同时保留企业级安全性、访问控制和加密。

目前支持的工作负荷包括Azure Files、Azure Virtual Desktop和通过Windows身份验证访问Azure SQL托管实例。

身份验证流

1.用户身份验证

用户登录到已加入 Microsoft Entra 或混合联接的 Windows 设备。

本地安全机构（LSA）使用云身份验证提供程序（CloudAP）通过 OAuth 进行身份验证以Microsoft Entra ID。

2. 令牌颁发

身份验证成功后，Microsoft Entra ID颁发包含用户和设备信息的 PRT。 除了 PRT，Microsoft Entra ID 还为领域KERBEROS.MICROSOFTONLINE.COM颁发云 TGT。

Microsoft Entra ID还颁发了一个 OnPremTgt（部分 TGT），其中包含用户的安全标识符（SID），但没有群组声明。 此部分 TGT 不足以直接访问本地资源。

云票据授予 (TGT)

Microsoft Entra ID 作为云资源的 KDC，在合适的情况下向客户端发放云 TGT。 客户端将 Microsoft Entra ID 租户识别为云资源的单独 Kerberos 域，TGT 存储在客户端的 Kerberos 票据缓存中。 云 TGT 在本地缓存，可以使用 PowerShell 命令“klist cloud_debug”进行验证。

Microsoft Entra ID 颁发的云 TGT：

  • 适用于领域 KERBEROS.MICROSOFTONLINE.COM。
  • 允许访问与 Microsoft Entra Kerberos 集成的基于云的资源，例如Azure Files、Azure SQL和其他服务。
  • 包含特定于云服务的授权数据，并直接用于请求云资源的 Kerberos 服务票证。
  • 当用户使用支持的凭据（例如，Windows Hello for Business或 FIDO2）登录到Windows设备时，始终发出。
  • 不依赖于本地域控制器。

注释

云 TGT 不是本地 TGT 的替代项。 这是另一个允许访问云资源的票证。 访问本地资源仍需要本地 TGT。

本地部署访问的 OnPremTgt 发布

这些先决条件适用：

  • 用户必须通过 Microsoft Entra Connect 从 on-premises Active Directory 同步到Microsoft Entra ID。
  • Kerberos 服务器对象必须存在于on-premises Active Directory中，并同步到Microsoft Entra ID。 此对象允许 Microsoft Entra ID 颁发本地域控制器可以使用的 OnPremTgt。
  • 设备必须运行Windows 10（2004 或更高版本）或Windows 11。
  • 设备应注册到 Microsoft Entra 或混合加入。
  • 建议Windows Hello for Business或 FIDO2 身份验证方法以获得最佳集成。
  • 必须为本地部署的域控制器进行修补以支持 Kerberos 云信任。
  • 确保客户端设备与域控制器之间有畅通的通信路径，以便进行票据交换。

如果用户在运行 Windows 10（版本 2004 或更高）或 Windows 11 的设备上使用无密码方法（例如 FIDO2 或 Windows Hello for Business）登录，Microsoft Entra ID 会为用户的本地 Active Directory 域颁发一个 OnPremTgt。 此 OnPremTgt 包含用户的 SID，但不包含授权数据。

Microsoft Entra ID 签发的 OnPremTgt：

  • 通过充当Microsoft Entra ID和Active Directory之间的桥梁来访问本地资源。
  • 包含有限的数据（例如，用户的 SID）和没有组声明。 它本身不足以访问本地资源。
  • 仅当环境配置为支持它时才发出。 例如，您在 Active Directory 中设置了混合标识和 Microsoft Entra Kerberos 服务器对象。
  • 必须与本地 Active Directory 域控制器进行交换，以获取包含用户 SID、完整 PAC（所有组成员资格）、会话密钥以及其他访问控制数据的完整 TGT。 然后，使用完整的 TGT 访问服务器消息块（SMB）共享或 SQL 服务器等资源。

该 dsregcmd /status 命令将显示两个 TGT 的结果。 有关 使用 dsregcmd 命令对设备进行故障排除的详细信息。

  • OnPremTgt：如果登录用户的设备上存在用于访问本地资源的云 Kerberos 票证，请将状态设置为“是”。
  • CloudTgt：如果云 Kerberos 票证用于访问已登录用户的设备上存在云资源，则将状态设置为“是”。

Microsoft Entra Kerberos TGT 和 Active Directory 访问控制

拥有用户的本地部署 Active Directory 域的 Microsoft Entra Kerberos TGT 并不能自动授予对完整 Active Directory TGT 的访问权限。

Microsoft Entra Kerberos 使用 Read-Only 域控制器 （RODC） 对象的允许列表和阻止列表来控制哪些用户可以从Microsoft Entra ID接收部分 TGT，以便进行本地资源访问。 此机制对于限制暴露和强制实施安全边界至关重要。 此机制在混合环境中尤其重要，在这些环境中，Microsoft Entra ID颁发的部分TGT必须与本地Active Directory域控制器一起兑换，以获取完整的TGT。

若要完成交换，用户必须列在 RODC 对象的允许列表中，而不是在阻止列表中。

Active Directory中用户帐户属性的屏幕截图。

在交换过程中，Microsoft Entra Kerberos TGT 的部分内容被转换为完整的 Active Directory TGT。 Microsoft Entra ID评估列表以确定访问资格。 如果用户在允许列表中，Microsoft Entra ID 颁发完整的 TGT。 如果用户位于阻止列表中，Microsoft Entra ID拒绝请求，身份验证失败。

最佳做法是将默认配置设置为 “拒绝”。 仅向有权使用 Microsoft Entra Kerberos 的组授予显式Allow权限。

重要

仅本地 Active Directory 识别部分 TGT。 具有部分 TGT 的访问权并不能提供对 Active Directory 外部资源的访问权限。

领域映射

领域映射是一种机制，允许Windows客户端确定用户访问资源时要联系的 Kerberos 领域。 当组织在同一环境中同时使用on-premises Active Directory和Microsoft Entra ID时，此机制尤其重要。

Windows 使用服务的命名空间（例如，*.file.core.chinacloudapi.cn）来决定是否联系 Active Directory 或 Microsoft Entra ID 以获取 Kerberos 票证。 由于云和本地服务可能共享相同的命名空间，因此Windows无法自动区分它们。

若要解决此问题，管理员通过以下方法配置主机名到 Kerberos 领域的映射：

  • 组策略： 计算机配置>管理模板>系统>Kerberos>定义主机名到 Kerberos 领域映射
  • Intune 策略配置服务提供程序 （CSP）： Kerberos/HostToRealm

contoso.com 的示例映射为 .file.core.chinacloudapi.cnKERBEROS.MICROSOFTONLINE.COM。 此映射指示 Windows 对特定的 Azure Files 实例使用 Microsoft Entra Kerberos，同时将其他实例默认为本地 Active Directory。

Microsoft Entra Kerberos 中的Azure租户信息

Microsoft Entra ID 充当云资源的密钥分发中心 (KDC)。 它维护租户特定的配置，指导如何颁发和验证 Kerberos 票证：

  • Cloud TGT：Microsoft Entra ID 为 KERBEROS.MICROSOFTONLINE.COM 领域发出此 TGT。 它存储在客户端的 Kerberos 票证缓存中，用于云资源访问。
  • KDC 代理：此协议通过 Internet 安全地将 Kerberos 流量路由到Microsoft Entra ID。 此路由使客户端无需直接连接到域控制器即可获取票证。
  • Azure租户识别：Kerberos 堆栈使用领域映射和租户 ID 来验证云 TGT 并颁发服务票证。

3. 服务票证请求和颁发

对于客户端对本地资源的访问（混合方案）：

  1. Microsoft Entra ID 发放部分 TGT。
  2. 客户端联系本地 Active Directory 域控制器以交换部分 TGT 以获取完整的 TGT。
  3. 完整的 TGT 用于访问本地资源，例如 SMB 共享或 SQL 服务器。

客户端使用云 TGT 请求云资源的服务票证。 无需与on-premises Active Directory交互。 对于客户端对云资源的访问：

  1. 当用户访问某项服务（例如 Azure 文件）时，客户端使用 TGT 从 Microsoft Entra ID 请求服务票证。
  2. 客户端将票证授予服务请求（TGS-REQ）发送到Microsoft Entra ID。
  3. Kerberos 标识服务（例如 cifs/mystuff.file.core.chinacloudapi.cn），并将域映射到 KERBEROS.MICROSOFTONLINE.COM。 KDC 代理协议允许通过 Internet 进行 Kerberos 通信。
  4. Microsoft Entra ID验证云 TGT 和用户的标识。 它还会查找在 Microsoft Entra ID 中注册的 Azure 文件资源中请求的服务主体名称 (SPN)。
  5. Microsoft Entra ID生成服务票证，并使用服务主体的密钥对其进行加密。 在票证授予服务回复（TGS-REP）中，Microsoft Entra ID 将票证返回给客户端。
  6. Kerberos 堆栈处理 TGS-REP，提取票证，并生成应用程序请求（AP-REQ）。
  7. AP-REQ 被提供给 SMB，然后由 SMB 包含在对 Azure Files 的请求中。
  8. Azure Files解密票证并授予访问权限。 FSLogix现在可以从Azure Files读取用户配置文件并加载Azure Virtual Desktop会话。

对于客户端对云资源的访问：

  1. 只有云标识的用户访问云资源（例如Azure Files共享）。
  2. SMB 客户端请求资源 SPN 的 Kerberos 服务票证（例如 cifs/<storageaccount>.file.core.chinacloudapi.cn）。
  3. Entra Kerberos 基于 Cloud TGT 颁发服务票证。 票证包括用户的 Entra ID 标识和组声明信息。
  4. Azure Files对 Kerberos 票证进行 Entra ID 验证。 使用 Azure RBAC 角色（例如存储文件数据 SMB 共享参与者）来实施授权控制。
  5. 如果满足 RBAC 权限，用户将获取对资源的访问权限。 不涉及本地 AD 或 NTFS ACL - 授权完全基于云。

传统 Kerberos 的主要区别：

  • 没有本地 KDC 或Active Directory DS。
  • 无 NTFS ACL 强制;使用 Azure RBAC。
  • 由云中的 Entra Kerberos 颁发的 Kerberos 票证。

概要

功能 / 特点 云 TGT 本地 TGT
发行人 Microsoft Entra ID 内部部署Active Directory（通过Exchange）
领域 KERBEROS.MICROSOFTONLINE.COM 本地Active Directory域
授权数据 特定于云计算 完整的 Active Directory 组成员身份
需要交换 否 是（部分 TGT 转换为完整 TGT）
用例 Azure Files、Azure SQL SMB 共享、旧版应用
验证工具 （macOS） tgt_cloud tgt_ad
验证工具（Windows） klist cloud_debug klist get krbtgt

Scenarios

使用 Microsoft Entra Kerberos 来进行 Windows 身份验证与 Azure SQL 托管实例的访问

Microsoft Entra ID的Kerberos身份验证可使Windows的身份验证对Azure SQL Managed Instance的用户访问。 托管实例的Windows authentication使客户能够将现有服务迁移到云中，同时保持无缝的用户体验。 此功能为基础结构现代化提供了基础。

有关详细信息，请参阅 Azure SQL 托管实例上 Microsoft Entra 主体的 Windows 身份验证是什么？。

使用 SSO 通过 FIDO2 密钥登录到本地资源

Microsoft Entra Kerberos 用户可以使用新式凭据（如 FIDO2 安全密钥）登录到Windows，然后访问基于传统Active Directory的资源。

在平台单点登录中激活 Kerberos 单点登录，以连接本地 Active Directory 和 Microsoft Entra ID Kerberos 资源。

除了平台 SSO PRT，Microsoft Entra 还颁发用于本地和云端的 Kerberos TGT。 然后，这些 TGT 通过平台 SSO 中的 TGT 映射共享给 macOS 的本地 Kerberos 堆栈。

有关详细信息，请参阅 如何在 Platform SSO 中启用对本地 Active Directory 和 Microsoft Entra ID Kerberos 资源的 Kerberos SSO。

使用FSLogix为Azure Virtual Desktop存储配置文件容器

若要托管虚拟桌面的用户配置文件，可以将配置文件存储在通过 Microsoft Entra Kerberos 访问的Azure文件共享中。 Microsoft Entra Kerberos 使Microsoft Entra ID能够发出必要的 Kerberos 票证，以便通过行业标准 SMB 协议访问文件共享。

有关详细信息，请参阅在混合方案中使用Microsoft Entra ID在Azure Files上存储FSLogix配置文件容器。

在 Azure Files 上启用 Microsoft Entra Kerberos 身份验证

Microsoft Entra Kerberos 身份验证使混合标识和仅限云的标识能够使用 Kerberos 身份验证访问Azure文件共享。 此方案使用Microsoft Entra ID颁发必要的 Kerberos 票证，以通过 SMB 协议访问文件共享。

有关详细信息，请参阅 在 Azure Files0 上为混合标识启用 Microsoft Entra Kerberos 身份验证。

安全注意事项

  • Microsoft Entra Kerberos 不会将部分 TGT 颁发给未同步到 Microsoft Entra ID 的标识。
  • Microsoft Entra Kerberos 通过 KDC 代理使用安全的 TGT 交换模型。 此模型可最大程度地减少对域控制器的暴露，并减少攻击面。
  • 管理员可以配置组解晰策略以限制 Kerberos 票据中包含的组。 这些控件对于管理票证大小和减少对不必要的组数据的暴露至关重要。
  • 我们建议你保持云和本地环境之间的明确分离。 我们不建议将敏感帐户（如 krbtgt_AzureAD）同步为on-premises Active Directory，因为特权升级风险。
  • 使用 RODC 对象的允许列表和阻止列表来控制哪些用户可以从Microsoft Entra ID接收部分 TGT 以访问本地资源。

限制和其他注意事项

支持仅限云的用户标识（预览版）

仅托管在 Microsoft Entra ID 中的云用户帐户支持用于工作负载的 Kerberos 身份验证，例如 Azure Files、Azure Virtual Desktop、Windows 身份验证对 Azure SQL 托管实例的访问。

操作系统和设备限制

Microsoft Entra Kerberos 支持已加入 Microsoft Entra 或采用混合加入的 Windows 10（2004 或更高版本）和 Windows 11 设备。 某些功能依赖于特定的Windows版本和修补程序。

ACL 配置的网络连接要求

用户可以通过 Internet 访问Azure文件共享，而无需直接连接到域控制器。 但是，为混合标识配置Windows访问控制列表（ACL）或文件级权限需要对本地域控制器进行不受限制的网络访问。

无跨租户或来宾用户支持

来自其他 Microsoft Entra 租户的企业对企业 (B2B) 来宾用户目前无法通过 Microsoft Entra Kerberos 进行身份验证。

密码过期

存储帐户的服务主体密码每六个月过期一次，需要轮换才能维护访问权限。

组成员身份限制

Kerberos 票证的大小约束限制可以包含的组 SID 数。 每个票证的默认上限为 1,010 个组。 如果超过该上限，则仅包含前 1,010 个。 排除其余部分可能会导致大型组织中的用户访问失败。

Azure Files身份验证的 MFA 不兼容

Microsoft Entra Azure文件共享的 Kerberos 身份验证不支持 MFA。 强制实施多重身份验证的 Microsoft Entra 条件访问策略必须排除存储账户应用程序，否则用户会遇到身份验证失败的问题。

从需要 MFA 的条件访问策略中排除Azure Files。 可以通过将策略范围限定为排除存储帐户或访问Azure Files的特定应用程序来完成此任务。

属性同步要求

对本地 Active Directory 用户的关键属性的正确同步对于 Microsoft Entra Kerberos 至关重要。 这些属性包括onPremisesDomainName和 onPremisesUserPrincipalNameonPremisesSamAccountName。

每个 Azure Storage 帐户的单一 Active Directory 方法

对于基于标识的身份验证Azure Files，每个存储帐户一次只能启用一个Active Directory方法。 这些方法包括 Microsoft Entra Kerberos、本地 AD DS 和 Microsoft Entra 域服务。 在方法之间切换需要先禁用当前方法。

Kerberos 加密设置

使用 Microsoft Entra Kerberos 的 Kerberos 票证加密仅使用 AES-256。 可以根据要求单独配置 SMB 通道加密。

Microsoft Entra Kerberos 入门

  1. 若要对混合标识进行身份验证，必须先设置 Microsoft Entra Connect，以便将本地 AD DS 用户同步到Microsoft Entra ID。 有关详细信息，请参阅 Microsoft Entra Connect 安装指南。

  2. 将Azure Files或其他服务配置为使用 Microsoft Entra Kerberos 身份验证。 有关指南，请参阅 启用 Microsoft Entra Kerberos 身份验证。

  3. 确保 Windows 客户端是最新的，并已配置为使用 Microsoft Entra Kerberos。

  4. 根据需要监视和轮换服务主体密码。

  5. 使用 Microsoft Entra ID 报告和监视工具跟踪身份验证事件。

Entra Kerberos 中的组 SID 限制（预览版）

Kerberos 票证最多可包含 1,010 个组的安全标识符（SID）。 这是Windows规范限制。 随着 Entra Kerberos 现在支持仅限云的身份（以及混合身份），票证必须同时包含本地组 SID 和云组 SID。 大型企业通常有数百或数千个组的用户，包括嵌套成员和动态成员关系。 如果组合组 SID 超过 1,010，则无法颁发 Kerberos 票证，身份验证失败。 对于 SMB 访问方案（如 Azure Files），由于 NTFS ACL 检查依赖于凭证中的完整组成员身份，这特别成问题。

作为短期解决方案，使用 Entra Kerberos 进行仅限云标识的应用可以在其应用程序清单中添加一个标签。 当 Kerberos 服务看到此标记时，它知道请求涉及仅限云的标识。 登录和 PRT 颁发成功；但是，当用户在请求 Kerberos 保护的资源时，如果超过了 1010 个组 SID 的限制，可能会在服务票证颁发阶段出现故障。

典型的最终用户错误

Windows SMB / Azure Files - 映射/装载尝试可能会失败并出现通用 SMB 错误（例如系统错误 86 或 1327 可能出现在其他策略冲突（如 MFA）中）。 - 对于小规模组的用户，访问可能会成功，但由于用户的组 SID 超过 1010 个限制，同一租户中用户数众多的组的访问可能会间歇性失败。

登录与资源访问 - 登录和 PRT 颁发成功;服务票证时间（用户访问 Kerberos 保护的资源时）发生故障。

Entra 登录日志条目 - 错误140011 - Entra 登录日志中的 KerberosUsersGroupNumberExceeded 指示 Kerberos 票证颁发过程失败，因为用户的有效组成员身份超出了 Kerberos 票证中允许的最大安全标识符数（SID）。 管理员应减少受影响用户的组成员身份（尤其是嵌套/动态组）。

如何在应用程序清单文件中更新 Tags 属性

选项 1：更新 Entra 管理门户中的标记

  1. 登录到Microsoft Entra管理中心或云应用程序管理员角色。
  2. 导航到：
    • Entra ID → 应用程序注册→ 选择您的应用程序。
  3. 在“管理”下，单击“Manifest”。
    • 在 JSON 编辑器中，找到标记属性并添加“kdc_enable_cloud_group_sids”。
  4. 单击“保存”以应用更改。

Option 2：使用 Microsoft Graph API更新标记（权限：Application.ReadWrite.All）

请求主体

PATCH https://microsoftgraph.chinacloudapi.cn/v1.0/applications/{applicationObjectId}
Content-Type: application/json
{
   "tags": [
           "kdc_enable_cloud_group_sids"
    ]
}

选项 3：使用 PowerShell cmdlet 更新标记

  1. 使用管理员特权启动 PowerShell。

  2. 安装和导入Microsoft Graph PowerShell SDK。

    Install-Module Microsoft.Graph -Scope CurrentUser
Import-Module Microsoft.Graph.Authentication
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

  3. 连接到租户并全部接受。

    Connect-MgGraph -Environment China -ClientId 'YOUR_CLIENT_ID' -TenantId 'YOUR_TENANT_ID' -Scopes "Application.ReadWrite.All"

  4. 列出给定用户的 CertificateUserIds 属性。

    Update-MgApplication -ApplicationId "<AppObjectId>" -Tags @("kdc_enable_cloud_group_sids")

相关内容

  • Last updated on