关于团队成员身份使用 IdP 组进行管理
凭借 Enterprise Managed Users,则可以将 GitHub 中的团队与 IdP 中的组连接起来,通过 IdP 管理企业内的团队和组织成员身份。 可以查看已从企业设置同步到 IdP 组的团队列表。 有关详细信息,请参阅“使用标识提供者组管理团队成员身份”。
GitHub 还每天运行一次对帐作业,该作业根据以前通过 SCIM 从 IdP 发送的信息,将团队成员身份与存储的 GitHubIdP 组成员身份同步。 如果此作业发现用户是企业中 IdP 组的成员,但不是映射团队或其组织的成员,则作业将尝试将该用户添加到组织和团队。
如果 GitHub 无法将团队成员身份与 IdP 上的组同步,可以查看错误消息并解决问题。
查看团队与 IdP 组同步时发生的错误
-
导航到您的企业。 例如,从 GitHub.com 上的 公司 页面。
-
在企业列表中,单击你想要查看的企业。
-
若要查看 IdP 组列表,请在左侧边栏中单击“ Identity provider”****。
-
在“标识提供者”**** 下方,单击“组”****。
-
如果组的同步遇到问题,将会看到以下消息:“某些组未能同步到团队。 请检查你是否具有许可证。”
-
在 IdP 组列表中,单击要查看的组。
-
要查看组遇到的同步错误,在该组名称下方单点“团队”。
如果团队无法将成员身份与 IdP 上某个组同步,将会在团队名称和成员身份计数下方看到对于问题的描述。
错误:“由于许可证不足而不同步”
GitHub在企业层面存储Enterprise Managed Users的 IdP 组成员身份数据。 此数据通过来自标识提供者 (IdP) 的 Group SCIM API 调用进行填充和更新。
对于映射到团队的 IdP 组, GitHub 运行 每日对帐作业 ,将团队成员身份与存储的企业级 IdP 组数据同步。 每当组 SCIM API 调用更新组成员身份,或者管理员将团队链接或取消链接到 GitHub 上存储的组时,该同步过程也会运行。
如果企业没有足够的许可证可用, GitHub 可能无法完成此同步。 发生这种情况时,你将看到消息:
“由于许可证不足而不同步”
因此,受影响的团队或组织可能缺少成员。

若要调查此问题,请查看企业可用的许可证总数,以及有关哪些用户正在使用许可证和原因的详细信息。 有关详细信息,请参阅 在组织中使用许可证的人员 和 查看GitHub企业计划的使用情况。
解决问题
若要允许同步成功完成,请使用以下方法之一提供其他企业许可证:
-
释放现有许可证
- 确定哪些用户正在使用许可证,以及他们是否仍需要访问权限。
- 根据需要从组织或 IdP 组中删除用户,具体取决于管理组织和团队成员身份的方式(请参阅 查看企业中的人员):
- 如果通过 IdP 组管理组织的成员身份,请从相关组中删除用户。
- 监视这些企业审核日志事件以跟踪更新组成员身份或托管用户帐户的 SCIM API 调用(请参阅 企业的审核日志事件:
external_group.scim_api_failure/external_group.scim_api_successexternal_identity.scim_api_failure/external_identity.scim_api_success
-
购买其他许可证
- 如果所有当前用户都需要访问权限,请为企业购买更多许可证。 有关详细信息,请参阅“管理组织或企业的用户许可证”。
错误:“不同步”
如果团队成员身份与 IdP 上的某个组由于许可证以外的其他问题同步失败,则会看到“不同步”的消息。

GitHub 将尝试在下一次同步期间自动解决此问题,这至少每天发生一次。 通过取消 IdP 组中受影响团队的链接,然后再将其关联到同一个组,也许能够解决此问题。 有关详细信息,请参阅“使用标识提供者组管理团队成员身份”。
如果问题仍然存在,请联系 GitHub Enterprise 支持,并提供有关你遇到问题的组织、团队和 IdP 组的详细信息。
SCIM API 的不完整事件
如果您在企业审计日志中看到某个 external_identity.scim_api_incomplete 或 external_group.scim_api_incomplete 事件,则表示来自您的身份提供商的 SCIM 请求已被 GitHub 收到,但未成功完成。 未向您的身份提供商发送任何响应,因此它可能会将此操作报告为失败或已超时。
解决问题
从受影响的用户或组的标识提供者中重新触发预配。 SCIM 操作是幂等的,因此重新预配不会创建重复项。
- Entra ID: 在 Microsoft Entra 管理中心中,转到 企业应用程序 > 你的 SCIM 应用 > 预配,然后对受影响的用户或组使用 按需预配,或者使用 重新启动预配 执行完全同步。有关详细信息,请参阅 Microsoft 文档中的 Microsoft Entra ID 中的按需预配。
- Okta: 在 推送组中重新推送受影响的组,或将应用重新分配给受影响的用户。 有关详细信息,请参阅 Okta 文档中的 推送组 。
- 其他标识提供者: 请参阅标识提供者的文档,了解如何为特定用户或组重新触发 SCIM 预配。
检查是否已应用更改
如果已配置审核日志流式处理,则可以在流式传输日志中搜索事件request_id中具有相同scim_api_incomplete值的其他事件。 有关详细信息,请参阅“流式处理企业审核日志”。
单个组 SCIM API 调用可以在处理过程中触发以下任何事件:
| 审计日志事件 | Description |
|---|---|
external_group.provision | 已创建组 |
external_group.delete | 群组已删除 |
external_group.update | 组元数据已更新 |
external_group.update_ | 显示名称已更改 |
external_group.add_ | 添加了特定成员 |
external_group.remove_ | 已删除特定成员 |
若要确定在中断之前应用了哪些成员更改, add_member 并且 remove_member 事件最有用。 它们标识受影响的特定成员。 如果发现成员事件数少于预期请求,则不会处理剩余成员。
注意
企业审计日志 UI 和 REST API 目前尚不支持按 request_id 进行筛选。 此步骤要求将审计日志流式传输到 SIEM 或日志平台。
常见原因
不完整事件的常见原因
- 处理时间超过连接超时时间,通常是由于组规模过大。
- 标识提供者与 GitHub 之间发生网络中断。
- GitHub 的基础架构上出现了临时性问题。
- 网络环境(例如公司代理、防火墙或 CASB 解决方案)会干扰连接。
- 身份提供商的 SCIM 客户端超时设置过于严格。
如果此事件在同一组或用户中再次发生,请联系 GitHub Enterprise 支持,并提供受影响事件中的 request_id 值。
大型群组超时
针对成员数量庞大的组发出的单个 SCIM PUT 或 PATCH 请求可能会超出请求超时时间。 发生这种情况时,标识提供者可能会报告操作失败,你可能会在企业审核日志中看到一个 external_group.scim_api_incomplete 事件。
SCIM 预配速率限制规定每组每小时最多 1,000 个用户,但单个用于更改大型组成员关系的 PUT 或 PATCH 请求,也可能在所有成员都处理完之前就因请求超时而无法完成。 有关详细信息,请参阅“使用 REST API 通过 SCIM 预配用户和组”。
避免超时
- 将大型组分解为较小的组。 如果标识提供者支持它,请考虑将经常超时的组拆分为多个较小的组。 这减少了每个 SCIM 请求的处理时间。
- 使用增量更新。 如果可能,请使用
PATCH请求添加或删除单个成员,而不是PUT替换整个成员列表的请求。 - 监控不完整事件。 设置审计日志流传输,并针对
scim_api_incomplete事件设置警报,以便及时重新触发预配。