Azure AD自定义SCIM应用预配需两次执行才能成功问题排查

这个问题是Azure AD SCIM客户端的默认机制与服务端实现不匹配导致的，和PingIdentity SCIM 2 SDK本身的能力无关，按以下步骤定位修复即可：

根因排查方向 #

• 最常见触发原因：Azure AD SCIM客户端默认逻辑中，首次CREATE用户请求只会下发标记为「创建时必传」的属性+核心元数据，其余映射属性会放到后续增量同步的UPDATE请求中下发。你观察到的名、姓字段未拆分、仅传displayName的现象，基本都是这部分字段没有被配置为创建阶段下发属性导致的。
• 服务端响应不符合规范：Azure AD发送CREATE请求后，会校验服务端返回的201响应体，如果响应中没有返回全量用户属性，Azure AD会判定服务端不支持对应属性，不会在本次创建流程中重试下发，只会等后续属性变更触发UPDATE时再传输。
• Schema声明缺失：如果你的SCIM服务端实现了GET /Schemas接口，但返回的User资源Schema没有声明名、姓、自定义属性等字段，Azure AD预配作业启动拉取Schema后，会默认这些字段不被支持，创建阶段不会下发。
• 初始同步配置开关问题：部分Azure AD租户默认开启初始预配优化策略，首次批量创建用户时仅传输核心属性，剩余属性会在初始同步完成后数小时到数天内通过UPDATE补全，就是你提到的CREATE和UPDATE间隔数天的现象。

修复步骤 #

1. 调整属性映射配置
   进入企业应用预配的属性映射页面，找到所有需要在创建阶段就下发的字段（包括name.givenName、name.familyName以及所有自定义映射字段），编辑单条属性映射时，勾选创建操作期间同步此属性选项，同时将这些字段的对象匹配优先级调整到高于displayName的层级，保存后重启预配作业生效。
2. 修正CREATE接口的响应逻辑
   严格遵循SCIM 2.0规范实现POST /Users接口：用户创建成功返回201状态码时，响应体必须返回完整的用户资源对象，包含所有服务端支持的属性字段，不能仅返回用户ID、displayName这类最简字段。
   如果使用PingIdentity SCIM 2 SDK开发，不要使用默认的最简资源返回实现，需要将持久化存储后的完整用户实体序列化为SCIM User资源对象后返回。可以本地构造带全量属性的创建请求，自检响应体是否覆盖所有映射字段。
3. 调整预配作业的初始同步行为
   调用Microsoft Graph接口修改对应预配作业的配置，将syncInitialSyncBehavior参数设置为fullAttributesOnCreate，关闭默认的初始同步优化逻辑，强制首次创建请求下发所有已映射的非空属性。
4. 补全Schema声明
   如果服务端实现了Schema发现接口，检查/Schemas/urn:ietf:params:scim:schemas:core:2.0:User的返回内容，确保所有需要支持的属性都在attributes列表中正确声明了数据类型、多值特性等元数据。
5. 校验源属性取值
   检查Azure AD侧待预配用户的源属性，确认首次预配触发时，名、姓等目标字段对应的源属性本身不为空，Azure AD不会在创建请求中下发取值为空的属性。

验证方法 #

调整配置后，清空预配作业的缓存状态，删除测试环境中已创建的测试用户，重新触发一次完整预配，抓取SCIM请求日志确认POST /Users请求体已包含所有预期字段，无需等待后续UPDATE请求补全。

内容的提问来源于stack exchange，提问作者Kevin Malone