管理与保护

配置身份与访问

查看 Markdown

本指南面向使用 Okta 或 Microsoft Entra ID 作为身份提供商(IdP)的管理员,介绍如何让工程部门之外的人员通过 Cursor 团队访问 Grok Bot,以及如何让成员从 Bot 计算机登录由 IdP 预配的应用。更完整的安全模型见Grok Bot 安全;推广步骤和管理员控制见面向团队和企业的 Grok Bot

Grok Bot 使用您的 Cursor 账户,因此 Okta 或 Entra ID 中没有单独的 Grok Bot 应用。本指南的所有操作都针对已有的 Cursor 应用。Cursor 单点登录采用 SAML 2.0,支持 Okta、Microsoft Entra、Google Workspace 和 OneLogin;本指南详细介绍其中最常需要关注设备信任策略的两种。

将进行哪些更改

您将进行两项更改,它们各有不同作用:

  • 分配 Cursor 应用,让工程部门之外的用户通过 Cursor 团队访问 Grok Bot。

  • 添加身份验证规则,让用户能够从 Bot 计算机登录由 IdP 预配的应用;该计算机运行 Linux,且不运行设备信任代理。

只有第一项更改控制 Grok Bot 登录。第二项绝不会阻止 Grok Bot 登录,也不适用于插件登录,因为插件身份验证不经过该计算机。

开始之前

用户必须是 Cursor 团队成员才能访问 Grok Bot。成员使用 Cursor 账户登录,因此现有的 Cursor SSO 同样适用。启用自动预配后,用户首次登录即加入团队;否则,请先预配用户,再让其登录 Cursor 获取席位,或通过以下位置邀请:Cursor 控制台

如果使用 SCIM,预配采用 SCIM 2.0,仅在 Enterprise 套餐提供,取消预配会自动执行:在身份提供商中移除用户,也会将其从 Cursor 移除。

分配 Cursor 应用

用户必须拥有 Cursor 账户才能登录;通过分配到已有 Cursor SSO 应用来获得账户,使用 SCIM 时还需分配到 SCIM 应用。如果 Cursor 仅分配给工程部门,其他所有人都会遇到以下错误:User is not assigned to this application(用户未分配到此应用),或邀请流程始终无法完成。不要另外创建 Grok Bot 应用;应扩大已有 Cursor 应用的分配范围。

在 Okta 中分配应用

  1. 前往Admin Console → Applications → Applications(管理控制台 → 应用 → 应用)并打开现有 Cursor 应用。

  2. 打开Assignments(分配)并选择Assign → Assign to Groups(分配 → 分配给组)。若要分配给个人,请选择Assign to People(分配给人员)

  3. 添加所有应获得 Grok Bot 的组,而不只是工程部门。

  4. 如果使用 SCIM,请将相同的组分配到 Cursor SCIM 应用并推送。用户只有被分配到 SCIM 应用后才会出现在 Cursor 中。

  5. 确认每个组也已分配到 SAML 应用。仅分配 SCIM 而未分配 SSO,仍会阻止首次登录。

如果在 Cursor 中使用组织级身份,请在目录组同步后将其映射到 Grok Bot 团队;参阅组织。应用分配和组推送应使用不同的组。

在 Microsoft Entra ID 中分配应用

  1. 前往Microsoft Entra admin center → Enterprise applications(Microsoft Entra 管理中心 → 企业应用)并打开现有 Cursor 企业应用。

  2. 打开Users and groups(用户和组)并选择Add user/group(添加用户/组)

  3. 添加所有应获得 Grok Bot 的组,而不只是工程部门。

  4. 如果使用 SCIM,请将相同的组分配到 Cursor 预配应用。开启预配,并将范围限定为已分配的用户和组。

  5. 确认分配授予的是 SSO 访问,而不是仅报告访问。

基于组的分配需要 Entra ID P1 或 P2,且不包含嵌套组。必须明确分配用户;取消分配会阻止 SSO 登录,使用 SCIM 时还会将用户从 Cursor 移除。

对于任一提供商,满足以下条件即表示分配有效:

  • 不在最初工程部门分配范围内的用户能够打开 Grok Bot 并完成 Cursor SSO,且不会出现以下错误:User is not assigned to this application(用户未分配到此应用)

  • 启用自动预配时,用户首次登录后会出现在 Cursor 团队中,无需手动邀请。

  • 关闭自动预配时,用户登录 Cursor 获取席位后,或您从控制台邀请后,会加入团队。

允许从计算机登录 IdP 应用

在托管计算机内,成员通过浏览器中的您自己的身份提供商登录应用,因此这些会话受您的会话策略约束。计算机运行 Linux,未注册到移动设备管理(MDM),也不运行 Okta FastPass 等设备信任代理。任何要求 FastPass、已注册或受管理设备、合规设备,或只有 FastPass 才能满足的防钓鱼验证因素的规则,都会在该计算机浏览器中失败。

不要为整个公司关闭 FastPass 或设备合规要求。请添加一条优先级更高、范围限定为此不受管理 Linux 会话的规则。此更改只涵盖 Bot 在计算机浏览器中打开的 IdP 预配应用;Grok Bot 登录和插件登录都不需要这项更改。

以下登录方式可在计算机浏览器中使用:

  • 密码加上可在远程浏览器中使用的第二因素,例如 Okta Verify 推送或身份验证器应用。

  • 存储在计算机密码管理器中的通行密钥;密码管理器通过以下方式安装:团队设置脚本。Team Setup 仅适用于 Enterprise。

仍可要求 Grok Bot 登录本身必须使用受管理设备。Grok Bot 使用 Cursor SSO,因此身份提供商中感知设备状态的登录策略同样适用。该策略限制的是成员设备上的登录,而不是托管计算机上的登录。

在 Okta 中添加规则

在 Okta Identity Engine 中,该计算机匹配的设备平台为Other Desktop(其他桌面设备);没有 Linux 复选框。对 Bot 在计算机浏览器中打开的每个 IdP 预配应用重复以下步骤。

  1. 前往Admin Console → Security → Authentication Policies(管理控制台 → 安全 → 身份验证策略)并打开应用关联的策略。查找策略时,先打开Applications(应用),再打开对应应用,然后打开Sign On(登录)

  2. 在 FastPass、受管理设备和兜底拒绝规则之前添加规则。为其命名以便以后查找,例如Grok Bot 计算机(Linux)

  3. 在 IF 条件中,将规则范围限定为一个组。如果不希望规则覆盖整个公司,可使用已分配 Cursor 的组。

  4. Device platform(设备平台)设为Other Desktop(其他桌面设备),并将Device state(设备状态)设为Any(任意)。不要要求Registered(已注册)Managed(受管理),也不要要求依赖 FastPass 的设备保障策略。

  5. 在 THEN 条件中,将访问设为Allowed after successful authentication(身份验证成功后允许),并采用Password + Another factor(密码 + 另一验证因素)。不要要求防钓鱼或硬件保护验证因素。

  6. 保存规则,并确认其位于拒绝不受管理设备的兜底规则之前。

如果多个应用共享同一条受管理设备上的 FastPass 策略,请将 Linux 规则添加到共享策略并按组限定范围,或为这些应用分别设置策略。在 Classic Engine 上,允许Other Desktop(其他桌面设备),且不要求Device Trust = Trusted(设备信任 = 受信任)

在 Microsoft Entra ID 中添加策略

Entra ID 没有 FastPass。会阻止计算机浏览器的授予条件包括合规设备、混合加入设备、只有平台通行密钥或受管理通行密钥才能满足的防钓鱼身份验证强度,以及已批准的客户端应用或应用保护策略。

  1. 前往Microsoft Entra admin center → Protection → Conditional Access → Policies(Microsoft Entra 管理中心 → 保护 → 条件访问 → 策略)

  2. 找出对 Bot 所需 IdP 应用施加这些授予条件的所有策略。

  3. 保持这些策略开启。为 Linux 上的 Grok Bot 用户添加优先级更高的策略,或将其从阻止访问的策略中排除。

  4. 在新策略中,将用户设为已分配 Cursor 的组,并将目标设为他们必须在计算机上打开的 IdP 应用。只有接受相应范围时,才选择All resources(所有资源)

  5. Device platforms(设备平台)中,包含Linux并排除WindowsmacOS

  6. 将授予条件设为Require multifactor authentication(要求多重身份验证)这一项。

  7. 先以仅报告模式启动策略,再将其启用。

  8. 在现有合规设备策略中,排除该组或排除 Linux。

要在没有受管理设备的情况下防范钓鱼,请使用同步通行密钥能够满足的身份验证强度,并在强制执行前测试从计算机登录。

对于任一提供商,如果用户能够从 Bot 计算机登录 IdP 预配应用,且没有 FastPass 或设备合规错误,插件登录仍与之前相同,笔记本电脑登录也不受影响,即表示更改有效。

无论采用哪种方式,撤销权始终在您手中:在身份提供商中撤销用户会终止其计算机内的应用会话,组织管理员也可以随时终止成员的计算机

限制

  • Okta FastPass 不在 Linux 上运行,因此 Bot 计算机无法满足 FastPass 或受管理设备规则。

  • 计算机默认未注册到 MDM。

  • Entra ID 中基于组的分配需要 P1 或 P2,且不包含嵌套组。

常见问题

是否需要在 Okta 或 Entra ID 中单独创建 Grok Bot 应用?

不需要。Grok Bot 使用 Cursor 账户登录,因此现有 Cursor 应用控制访问。应扩大该应用的分配范围,而不是创建新应用。

设备信任更改会影响插件登录吗?

不会。插件身份验证不经过该计算机,因此计算机浏览器的身份验证规则不适用于插件。

这些更改会削弱员工笔记本电脑上的登录安全性吗?

不会。将新规则或策略范围限定为 Linux 平台和已分配 Cursor 的组,笔记本电脑登录仍保留现有要求。

如果取消用户的 Cursor 应用分配,他们会失去访问权限吗?

会,他们将无法再通过 SSO 登录。使用 SCIM 时,取消分配还会自动将其从 Cursor 移除;不使用 SCIM 时,请在控制台中将其从团队移除。


最后更新:2026 年 9 月 16 日