Entra ID Bug — Integer Values in Custom SCIM Attributes

Entra ID Bug — Integer Values in Custom SCIM Attributes

Resolved. Microsoft shipped the fix in March 2026. New-user provisioning with Integer-typed custom attributes now works as expected; this writeup is left up for anyone digging through error messages from the affected period.

A bug I hit with Entra ID's SCIM provisioning — Integer-typed values don't work for custom attributes when creating new users. Updates to existing users go through fine. Only the creation path is broken.

For context, I set up a custom attribute called LinuxUID to store POSIX user IDs as part of our OCI Identity Domains integration. The PAM module on each Linux host reads these UIDs to map authenticated users to local accounts. The SCIM attribute mapping looks like this:

urn:ietf:params:scim:schemas:oracle:idcs:extension:posix:User:uidNumber

Attribute mapping

Updates to existing users worked fine. Provisioning new users kept failing with this error:

Mapping Integer value to remote attribute is expecting Integer, but is being passed as
'[ string, dateTime, binary, reference ]'

Error detail

Integer is missing from the allowed-type array. The attribute expects an Integer, but the provisioning engine on the create path only knows how to pass string, dateTime, binary, and reference.

The asymmetry is in two different code paths: the patch request factory (used for updates) handles Integer custom attributes correctly. The create request factory does not. So an admin who provisions everyone with the same attribute set will see existing users sync cleanly while new users error out — which is exactly the kind of split-brain behavior that wastes hours before you realize the create and patch flows aren't sharing code.

I opened a support case with Microsoft and got this RCA back:

Solution is to update EntryCore2GroupFactory to handle Integer type custom attributes similar to how it's handled in EntryResourcePatchRequestFactory. The deployment will start within 2 weeks.

That fix has since rolled out (see the banner at the top). If you ran into this during the affected window and worked around it by setting the attribute via a post-creation patch, you can drop the workaround.