AzureAD 组配置到 ServiceNow - 由于存储了 SYSID，无法更改 ServiceNow 中的组详细信息
AzureAD Group Provisioning to ServiceNow - Cannot change group details in ServiceNow due SYSID being stored
我正在尝试了解 AzureAD 配置和 ServiceNow。组配置是 OOTB 并设置为映射到组名称字段，它确实如此。但是，AzureAD 正在存储来自初始匹配的组 (SYSID) 的 ServiceNow ID，然后将其用作以后配置同步的一部分。
我的objective是确定：
- 根据最近的问题，我怀疑最近对 AzureAD 配置进行了更改，以在创建或匹配记录后存储目标 ID (ServiceNow sysid)。我说得对吗？
- 如果以上 1 为真，那么它存储在哪里，我可以使用 GraphAPI 或配置屏幕访问它
- 我在 ServiceNow 中有多少控制权来使 AzureAD 配置匹配我创建和重新配置的组
为了强制进行测试，我在 ServiceNow 中进行了一些组更改，以测试 AzureAD 配置的工作方式并导致配置失败，我想了解。
- 向我的企业应用程序添加了组“测试配置组”
- Azure 配置 运行 并在 ServiceNow“测试配置组”中创建了一个组 - (ID=31f1f3792f630110fc1e52172799b6fa)
- 在 ServiceNow 中，我将 AzureAD 配置创建的组重命名为“测试配置组已重命名”
(ID=31f1f3792f630110fc1e52172799b6fa)
- 在 ServiceNow 中，我创建了一个名为“Test Provisioning Group”的新组 - (ID=8bd8394e2f2b0110fc1e52172799b6e2)
- Azure 配置运行 和失败
故障分析
- 在“第 1 部分。从 Azure Active Directory 导入 sys_user_group”的配置日志中，以旧组 ID 的 ID 值开头
- 在“3.在 Azure Active Directory 和 ServiceNow 之间匹配 sys_user_group”我看到
- EntryImportByJoiningProperty 按名称查找新组
- EntryImport 通过 ID 找到旧的重命名组 - 它甚至列出了组的新名称“从 ServiceNow 检索 'Test Provisioning Group Renamed'”
抱歉，没有足够的积分来 post 图片所以这里是 table 结果
EntryImportByJoiningProperty
Result
Success
Description
A target entry in ServiceNow has been matched with the source entry by matching attribute name: Test Provisioning Group
Active
1
Name
Test Provisioning Group
Sys_id
8bd8394e2f2b0110fc1e52172799b6e2
条目导入
Result
Success
Description
Retrieved 'Test Provisioning Group Renamed' from ServiceNow
Active
1
Description
Testing AzureAD provisioning issues
Name
Test
Provisioning Group Renamed
Sys_id
31f1f3792f630110fc1e52172799b6fa
每当第一次创建或定位对象（用户、组..）时，目标系统 ID 值（ServiceNow SOAP sys_id API）将在内部存储到配置中服务。该值无法手动清除。您的选择是要么完全删除原始组，以便下次 AAD 配置尝试通过 sys_id 定位第一个组时失败并恢复为通过友好名称再次搜索，或者通过 MS Graph [=20= 重新启动配置] 的 resetScope 为 Full，这将清除系统之间 ID 值的配置内部映射。
您无法访问 source/target 系统之间链接的这些数据，它仅对配置服务可见。一般来说，我建议不要执行您所描述的操作 - 这不是 AAD 预配的预期方案。这就提出了一个问题 - 为什么要重命名 ServiceNow 中的组并尝试将其替换为另一个最终会处于相同状态的组？
MS Graph 重启 API 文档：https://docs.microsoft.com/en-us/graph/api/synchronization-synchronizationjob-restart?view=graph-rest-beta&tabs=http
我正在尝试了解 AzureAD 配置和 ServiceNow。组配置是 OOTB 并设置为映射到组名称字段，它确实如此。但是，AzureAD 正在存储来自初始匹配的组 (SYSID) 的 ServiceNow ID，然后将其用作以后配置同步的一部分。
我的objective是确定：
- 根据最近的问题，我怀疑最近对 AzureAD 配置进行了更改，以在创建或匹配记录后存储目标 ID (ServiceNow sysid)。我说得对吗？
- 如果以上 1 为真，那么它存储在哪里，我可以使用 GraphAPI 或配置屏幕访问它
- 我在 ServiceNow 中有多少控制权来使 AzureAD 配置匹配我创建和重新配置的组
为了强制进行测试，我在 ServiceNow 中进行了一些组更改，以测试 AzureAD 配置的工作方式并导致配置失败，我想了解。
- 向我的企业应用程序添加了组“测试配置组”
- Azure 配置 运行 并在 ServiceNow“测试配置组”中创建了一个组 - (ID=31f1f3792f630110fc1e52172799b6fa)
- 在 ServiceNow 中，我将 AzureAD 配置创建的组重命名为“测试配置组已重命名” (ID=31f1f3792f630110fc1e52172799b6fa)
- 在 ServiceNow 中，我创建了一个名为“Test Provisioning Group”的新组 - (ID=8bd8394e2f2b0110fc1e52172799b6e2)
- Azure 配置运行 和失败
故障分析
- 在“第 1 部分。从 Azure Active Directory 导入 sys_user_group”的配置日志中，以旧组 ID 的 ID 值开头
- 在“3.在 Azure Active Directory 和 ServiceNow 之间匹配 sys_user_group”我看到
- EntryImportByJoiningProperty 按名称查找新组
- EntryImport 通过 ID 找到旧的重命名组 - 它甚至列出了组的新名称“从 ServiceNow 检索 'Test Provisioning Group Renamed'”
抱歉，没有足够的积分来 post 图片所以这里是 table 结果
EntryImportByJoiningProperty
| Result | Success |
| Description | A target entry in ServiceNow has been matched with the source entry by matching attribute name: Test Provisioning Group |
| Active | 1 |
| Name | Test Provisioning Group |
| Sys_id | 8bd8394e2f2b0110fc1e52172799b6e2 |
条目导入
| Result | Success |
| Description | Retrieved 'Test Provisioning Group Renamed' from ServiceNow |
| Active | 1 |
| Description | Testing AzureAD provisioning issues |
| Name | |
| Test | Provisioning Group Renamed |
| Sys_id | 31f1f3792f630110fc1e52172799b6fa |
每当第一次创建或定位对象（用户、组..）时，目标系统 ID 值（ServiceNow SOAP sys_id API）将在内部存储到配置中服务。该值无法手动清除。您的选择是要么完全删除原始组，以便下次 AAD 配置尝试通过 sys_id 定位第一个组时失败并恢复为通过友好名称再次搜索，或者通过 MS Graph [=20= 重新启动配置] 的 resetScope 为 Full，这将清除系统之间 ID 值的配置内部映射。
您无法访问 source/target 系统之间链接的这些数据，它仅对配置服务可见。一般来说，我建议不要执行您所描述的操作 - 这不是 AAD 预配的预期方案。这就提出了一个问题 - 为什么要重命名 ServiceNow 中的组并尝试将其替换为另一个最终会处于相同状态的组？
MS Graph 重启 API 文档：https://docs.microsoft.com/en-us/graph/api/synchronization-synchronizationjob-restart?view=graph-rest-beta&tabs=http