sys_user table sys_id synchronization with Azure User object id

[L Q]

We are trying to have our Azure portal drive all the users, groups and group memberships on ServiceNow via the Azure ServiceNow enterprise application.

For simplicity, we want to synchronize objectid on Azure users with sys_id on ServiceNow users (so that any applications talking to either Azure or ServiceNow can uniquely identify the same user when using the same user record key).

What we found is that the Azure ServiceNow enterprise application allows the mapping on the portal interface (in Provisioning/Attribute Mapping section, objectId -> sys_id), the ServiceNow instance who creates new users would ignore that mapping and assign its own sys_id (so they will be different).

If we map objectId to other fields that support random values (such as street, etc), it works correctly. It just does not work with the sys_id field.

To be clear, we are talking about having the two sides in sync when CREATING new user records. There's no attempt to CHANGE the existing sys_id values on ServiceNow side.

Could someone shed some light on this behavior of ServiceNow? Is there something special we have to do on the ServiceNow instance side to make that happen? - Thank you in advance.

[Kristin J]

Adding to this 🙂  We do not have any active spokes for Azure through the IntegrationHub but are using the steps provided by Microsoft that allow for the basic synchronization of accounts and groups.

As Liming said, it appears that we can map the Azure object ID to the sys_id, according to the setup in Azure (Provisioning/Attribute Mapping), when a new user record sys_id is generated in ServiceNow from Azure, the sys_id does not match the Azure ObjectID despite having mapped it.

For anyone who's done this integration before, is this expected behaviour on the SN side? Has anyone tried or succeeded with a matching ObjectID/sys_id?

Thanks again!

Kristin

[Allen Andreas]

Hi,

While I can sort of get what you're trying to do, I'm unsure if this is the correct approach. Normally, if there are integrations with other systems that you're trying to maintain between users, people create a custom field called like: unique key or third-party key or something along those lines. That would house this universal identifier, so to speak, so that if/when this user is engaged with these other systems, within your integrations, you can "speak"/reference this unique key.

A ServiceNow sys_id is unique to ServiceNow and consist of specific pieces that are used to create it and make it unique. This is most likely why you're facing issues. You can technically script/code and force your own sys_id, actually, but it's not recommended and long-term/downstream it may not be appropriate to mess with that (if you ever depart with Azure, for example, or various other scenarios like this, could cause problems -- where net new users have a different formatted sys_id, etc.).

I'd highly recommend using a simply custom string field on the sys_user table that would house this universal key.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[L Q]

Thanks for the comment Allen.

Microsoft Azure is our identity platform of choice. We want our ServiceNow platform to use Azure for all user and group identities, with unified keys.

The "ServiceNow Enterprise Application" on Azure (published by ServiceNow) allows the Microsoft user object id to be mapped to user sys_id on our ServiceNow instance, we expect it to be a valid mapping config and to work as intended.

We just need some clarity on what we might have done wrong.

I get your point about stashing the Azure object id in a custom field (it worked when we mapped it to sys_user.street too).

I understand the sys_id field is special, but it is offered as a mapping target in "ServiceNow Enterprise Application" on Azure for provisioning, any special considerations needed to make it work as intended? or we misunderstood the whole thing?

[Allen Andreas]

Hi,

I think you may be confused with what the app "allows" and your expectations.

From my understanding and what I see, the application in Azure is simply querying and pulling in ALL the fields from the sys_user table. So you are merely seeing all the fields available. This isn't a free pass that everything is going to work, but that they're queried and listed.

The sys_id, as mentioned previously, is a unique field within ServiceNow and is generated upon creation of the user record. So most likely, there are system processes at play that may be overwriting what you're trying to map it to.

What I'd recommend, since I don't believe there's anything else you can do through the app itself, is to perhaps map the object ID to another field, then create a business rule on the sys_user table, to take that value from the other user field and set it as the new sys_id. Please refer to the method setNewGuidValue() as documented here, for example: https://developer.servicenow.com/dev.do#!/reference/api/rome/server/no-namespace/c_GlideRecordScoped...

So you will need to overwrite that sys_id with a custom value that you prefer. Then, you can clear the value from it's temporary home on the user record and you'll be good to go from there.

As I mentioned before, I do advise against this. It's not really making sense why you need the sys_id to be the same as the object ID. SN having a custom sys_id created for the record does not change Azure being your "identity platform of choice". The users are still authenticating with Azure even if SN has it's own sys_id field. I feel some of this may be from your misunderstanding with the authentication process, but either way, if you're persistent about using your own value for the sys_id, I've given the steps above 🙂

Please mark reply as Helpful/Correct, if applicable. Thanks!