通过条件访问限制 Microsoft Teams 设备的设备代码流

设备代码流允许用户登录到没有浏览器或丰富输入体验的设备。 某些Microsoft Teams设备在第一次注册、重新预配和一些重新身份验证方案中使用设备代码流。

设备代码流也是高风险身份验证流。 攻击者可以启动流,向用户发送代码,并要求用户在合法Microsoft登录页上输入该代码。 由于登录页面是真实的,因此用户很难识别此攻击。

Microsoft 建议尽可能阻止设备代码流。 如果你的组织使用需要设备代码流的 Teams 设备,请将例外范围限定为特定的 Teams 设备资源帐户,并从条件访问策略中排除设备注册服务资源。

应使用本指南的人员

如果你的组织属于以下情况,请参阅本文:

  • 使用 Teams 会议室、Teams Android 设备、共享 Teams 设备或其他需要设备代码流的 Teams 设备体验。
  • 想要使用条件访问限制设备代码流。
  • 需要使 Teams 设备注册正常工作,同时减少租户范围内的设备代码流泄露。

本文重点介绍 Teams 设备使用场景。 如果组织对其他工具(如Azure CLI或开发人员命令行工具)使用设备代码流,请在实施阻止策略之前查看本文中的其他指南。

在您开始之前

您需要:

注意

在本文中, Teams 设备资源帐户 表示分配给会议室、公共区域或共享 Teams 设备的帐户。 这并不是指用于进行设置的技术人员或管理员帐户。

从仅报告模式开始。 在启用策略之前验证预期的 Teams 设备行为。

本文采用默认阻止策略,并设置了两层例外规则:

  • 包含需要设备代码流的 Teams 设备资源帐户的持久性安全组。
  • 为设备注册服务资源设置例外,以便您的策略不会阻止通过设备代码流进行设备注册。

分阶段推出策略:

  1. 在登录日志中清点设备代码流使用情况。

  2. 创建异常组:

    • 一个永久性的 Teams 设备例外组,其中包含已分配给你的 Teams 设备的资源帐户。
    • 如果已批准非 Teams 设备代码流方案,则为持久批准的非 Teams 组。
  3. 创建一个条件访问策略,用于阻止设备代码流、排除这些组,并排除设备注册服务资源。

  4. 在“仅报告”模式下,先在选定的帐户和 Teams 设备中试行该策略。

  5. 查看仅报告的结果和登录日志。

  6. 启用策略。

  7. 部署设备时,将新的 Teams 设备资源帐户添加到异常组。

  8. 监控被阻止的登录和例外组成员资格。

Teams 设备在初始登录以及因密码更改或条件访问策略变更等情况而需要重新进行身份验证时,都需要设备代码流。 Teams 设备资源帐户的例外情况是长期有效的,没有时间限制。 使用无密码身份验证的 Teams 资源帐户是重新身份验证要求的例外:它们仅在初始预配时需要设备代码流。 将这些帐户保留在持久例外组中,以免重新预配和恢复场景受阻。

例外是帐户范围。 无法将异常的范围限定为一个资源或方案。 在异常期间,排除的帐户可以对策略范围内的任何应用或资源使用设备代码流。 将例外成员资格仅限于真正的 Teams 设备资源帐户,且这些帐户应受到监控并经所有者批准。

被排除的用户

条件访问策略是一个功能强大的工具。 建议从策略中排除以下帐户:

  • 紧急访问或破窗帐户,用于防止因策略错误配置导致的锁定。 在所有管理员被锁定的可能性不大的情况下,紧急访问管理帐户可用于登录和恢复访问权限。
  • 服务帐户 和 服务主体(如 Microsoft Entra Connect Sync 帐户)。 服务帐户是未绑定到任何特定用户的非交互帐户。 它们通常由后端服务用来允许以编程方式访问应用程序,但它们也用于登录系统以实现管理目的。 服务主体进行的调用不受适用于用户的条件访问策略的阻止。 对工作负荷标识使用条件访问来定义面向服务主体的策略。
    • 如果你的组织在脚本或代码中使用这些帐户,请将这些帐户替换为 托管标识。

创建条件访问策略

创建一个策略,默认阻止设备代码流。

  1. 至少以条件访问管理员的身份登录到Microsoft Entra 管理中心。
  2. 浏览到 Entra ID>条件访问>策略。
  3. 选择“新策略”。
  4. 为策略指定名称。 为策略的名称创建有意义的标准。
  5. 在分配下,选择用户或工作负载标识。
    1. 在 “包括”下,选择策略范围内所需的用户(建议所有用户 )。
    2. 在“排除”下:
      • 选择 用户和组,然后选择组织的紧急访问(破窗)账户以及已批准的设备代码流例外组。 定期审核此排除列表。
  6. 在 目标资源>资源(以前称为云应用)下:
    1. 在 “包括”下,选择 “所有资源”(之前称为“所有云应用”),除非贵组织已针对该场景验证了更窄的资源范围。
    2. 在“ 排除”下,选择“ 选择资源 ”,然后选择 “选择特定资源 ”并添加 设备注册服务。 此排除项是必需的,因此策略不会阻止通过设备代码流进行设备注册。 有关详细信息,请参阅 在设备注册服务资源上强制实施身份验证流策略。
  7. 在“条件”“身份验证流”下>,将“配置”设置为“是”。
    1. 选择“设备代码流”。
    2. 选择“ 完成”。
  8. 在“访问控制”“授予”下,选择“阻止访问”。
    • 选择 选择。
  9. 确认设置,然后将“启用策略”设置为“只限报告”。
  10. 选择“ 创建 ”以启用策略。

确认设置后,使用策略影响模式或仅报告模式,将“启用策略”开关从 “仅报告” 切换到 “打开”。

管理 Teams 设备资源账户异常

部署设备时,将 Teams 设备资源帐户添加到永久性异常组。 仅当设备停用或不再使用资源帐户时,才删除帐户。

  1. 标识分配给设备的 Teams 设备资源帐户。
  2. 将资源账户添加到永久性 Teams 设备例外组。
  3. 记录所有者、设备以及变更或工单 ID,以供审计。
  4. 使用设备代码流注册或重新预配 Teams 设备。
  5. 确认设备完成预配并按预期登录。

将 Teams 设备退役:

  1. 从异常组中删除资源帐户。
  2. 禁用或删除资源帐户。
  3. 记录退役情况。

在强制实施之前进行验证

启用策略之前,请使用仅限报告的结果和登录日志进行确认:

  • 预期的 Teams 设备注册成功。
  • 当已为资源账户设置例外时,注册不会被设备代码流策略阻止。
  • 设备注册服务从策略中排除。
  • Teams 设备在注册后仍可保持登录状态,包括密码更改或条件访问策略发生更改等需要重新进行身份验证的情形。
  • 批准的非 Teams 设备代码流方案由显式异常组表示。
  • 未知或不合理的设备代码流使用被阻止。
  • 紧急访问帐户仍被排除。

在推出前列出活动设备代码流使用情况时,请使用 身份验证协议 = 设备代码流 。 当您需要了解后续登录或令牌刷新是否仍与先前的设备代码流会话相关联时,请使用 原始传输方式 = 设备代码流。

情景 要使用的字段 为什么
在推出之前清点当前设备代码流使用情况 身份验证协议 = 设备代码流 查找在该事件中使用了设备代码流的登录。
查看仅报告影响 这两个字段 显示直接设备代码流的使用情况,以及之后仍会被判定为源自设备代码流的会话。
审核 Teams 设备资源账户对设备代码流的持续使用情况 身份验证协议 = 设备代码流 预期为异常组中的帐户显示初始登录和重新身份验证事件的设备代码流。
排查 Teams 设备上的意外阻止问题 原始传输方法 = 设备代码流 当前的登录事件可能不会将“设备代码流”显示为身份验证协议,但条件访问仍可将该会话判定为源自设备代码流。
审核已批准的非 Teams 例外情况 这两个字段 显示新的设备代码流使用情况以及由设备代码生成的会话中的持续活动。

使用设备代码流启动的会话可以在以后的令牌刷新时保持协议跟踪,即使当前登录事件不将设备代码流显示为身份验证协议也是如此。 有关详细信息,请参阅 协议跟踪。

故障排除

Teams 设备被意外阻止使用

如果资源帐户位于异常组中,并且设备注册服务已从策略中排除,则条件访问策略不应阻止 Teams 设备。

如果 Teams 设备被意外阻止:

  1. 确认资源帐户位于永久性异常组中。
  2. 确认设备注册服务已从策略中的 目标资源 中排除。
  3. 查看登录日志。 如果 原始传输方法 显示设备代码流,则即使当前 身份验证协议 值不是设备代码流,会话也可能是从早期身份验证中跟踪的。

如果这些检查后设备仍被阻止,请打开支持票证进行调查。

个人版 Teams 设备需要使用设备代码流身份验证

个人 Teams 设备使用场景的范围更难界定,因为该用户帐户还可能能够在非 Teams 场景中使用设备代码流。 避免排除范围过大的用户。 如果需要基于用户的异常,请记录风险、监视使用情况并定期查看异常。

如果您在 Teams 设备之外使用设备代码流

某些组织将设备代码流用于其他方案,例如Azure CLI、开发人员工具、管理工具或旧版命令行体验。 将这些方案作为已配置策略的一部分考虑,以避免产生影响。

在整个租户范围内强制执行设备代码流阻止之前:

  1. 查看按 身份验证协议 = 设备代码流 筛选的登录日志,以及 原始传输方法 = 设备代码流 的登录记录。
  2. 确定每个依赖项的用户、应用或资源、位置、设备上下文和业务所有者。
  3. 尽可能将相关使用场景迁移到更安全的身份验证方法。 对于用户,应优先采用基于浏览器或代理的登录方式。 对于自动化场景,建议优先使用托管标识或工作负载标识联合。
  4. 仅为已批准的设备代码流依赖项创建异常组。
  5. 将任何剩余的非 Teams 例外情况视为有据可查的风险接受,并明确责任人和审查周期。

不要将广泛的用户群体添加到异常组。 广泛的用户异常可以允许设备代码流超出预期工具或方案。

强制实施后维护策略

在策略生效后,继续监控设备代码流的使用情况,并及时更新例外项。

务必 不要
定期审查例外成员资格。 将永久性设备代码流异常视为永久性默认值,而无需持续评审。
监控 原始传输方式 为设备代码流的登录活动。 调查协议跟踪的会话时,仅依赖于 身份验证协议 。
当提供更安全的身份验证方法时,将非 Teams 依赖项从设备代码流移开。 将非 Teams 帐户添加到 Teams 设备异常组。
针对特权用户、紧急访问账户、陌生应用或异常位置的异常设备代码流使用发出警报。 假定已获批的例外情况无需定期复审也仍然安全。