When provisioning a new user on demand in Azure AD, not all attributes reach the target application

Geoffrey van Wyk 21

The new user does get created in the target application, but some of the attributes are not set in the target application. This happens even as the details of the "Perform action" step shows the missing attributes and even if those attributes are not null.

When provisioning on demand is retried for the same user, in other words, the user is updated in the target application, the missing attributes are set as well.

An example attribute which does not get sent during creation is companyName (Azure AD attribute) mapped to company (custom SCIM attribute).

I have confirmed that those attributes are not sent by Azure Active Directory to the custom application by logging to file the request body before any other code touches the request.

Anshul Kumar (MINDTREE LIMITED) 6 Reputation points

2021-10-08T05:10:36.31+00:00

Hi, if the posted answer resolves your question, please mark it as the answer by clicking the check mark. Doing so helps others find answers to their questions.

1 answer

Danny Zollner 9,531 Reputation points Microsoft Employee

2021-07-19T21:49:22.77+00:00

Can you provide the exact target attribute that is being targeted? Is it just "company"? If so, that attribute is not a part of the SCIM Core Schema. Attributes that are not a part of the SCIM Core Schema as defined in RFC 7643 must have a fully SCIM compliant URI as outlined in section 10.2.1 - https://datatracker.ietf.org/doc/html/rfc7643#section-10.2.1.

Try renaming that attribute in your service and in the AAD provisioning schema for your target system to be something like urn:ietf:params:scim:schemas:extension:MyAppName:2.0:User:company and our service should handle it correctly.
Please sign in to rate this answer.

1 person found this answer helpful.
Geoffrey van Wyk 21 Reputation points

2021-07-20T11:45:14.4+00:00

Hi @Anonymous

The exact target attribute is urn:ietf:params:scim:schemas:core:2.0:User:company. The attribute does get sent when the user is updated though.

Department is another attribute not part of the core schema that does get sent when the user is created and gets updated as well.

At first, I used organization and department from urn:ietf:params:scim:schemas:extension:enterprise:2.0:User, but then AD gave an error that my application's response did not comply with the SCIM client's schema. I could not see the what caused the error when comparing a response that worked and one that raised the error.

Danny Zollner 9,531 Reputation points Microsoft Employee

2021-07-20T16:05:38.007+00:00

Company is not a part of the core schema. Appending urn:ietf:params:scim:schemas:core:2.0:User: to an attribute name is not sufficient here. If you look at the core schema docs (https://datatracker.ietf.org/doc/html/rfc7643) and control-F for "company" you will find zero hits.

Department is a part of the enterprise schema extension that is detailed in the same spec (7643), and therefore using urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department is valid. You cannot replace department in that string with company, however, as company is not an attribute defined in the enterprise extension in 7643.

My previous advice still stands - try renaming that attribute in your service and in the AAD provisioning schema for your target system to be something like urn:ietf:params:scim:schemas:extension:MyAppName:2.0:User:company and our service should handle it correctly.

Geoffrey van Wyk 21 Reputation points

2021-07-21T08:52:18.977+00:00

Thank you, @Anonymous . I will try that.

Ivo Klerkx 0 Reputation points

2023-02-22T13:47:10.55+00:00

Hi, I seem to have an equal problem.

For me it's just one attribute not working though: "objectId". The rest seems fine but "objectId" isn't send in the initial creation, only in the update.

Danny Zollner 9,531 Reputation points Microsoft Employee

2023-02-22T17:52:20.7666667+00:00

ObjectID is an attribute in Azure AD, but not in the SCIM spec. The problem and resolution outlined above is the same. Please reread the answer above.
Sign in to comment