Two Issues after implementing Azure AD SSO with ServiceNow

[Yuri Yoshinami]

We have implemented Azure AD SSO with the prod instance.

Could you kindly advise us the solution for the below issues?

1. The user which have deleted in the AzureAD seems still exist in the servicenow instance.

In our case, almost all the users are created in the AzureAD and they are added to the servicenow from AD automatically. However even after we delete the userA in the AzureAD ,we still find the userA in the sys_user.list in the ServiceNow.

Is there any solution for this case?

2.When we update the value as Null in the AzureAD are not synchronizesd/updated in servicenow.

It looks like when the servicenow got the value NULL from AzureAD when provisioning, servicenow doesn't do any updates, even it is updated as NULL in AzureAD.

Could you kindly tell me any best practice for updating it as NULL in servicenow?

[Astrid Sapphir1]

Hi Yuri,

I'll respond to each component separately for clarity:

1 - Assuming AzureAD was set up to integrate with your Production instance using LDAP and transform maps, this functionality makes sense. While ServiceNow is getting updated from your Active Directory, in the cause of UserA, ServiceNow is simply not getting further updates from AD for that user. It doesn't have any way to tell that the user was deleted and that it should match that in ServiceNow. Furthermore, it is recommended that records are not deleted in ServiceNow, but rather disabled and, if required, archived.

As such, the solution to this case can take a few forms. You can set up an OnComplete script for the Active Directory transform maps, and in this script both confirm that the operation completed successfully (confirming LDAP connectivity was there, to avoid users being adversely affected by the second step) and then check, of users that were synchronized with AD, which ones were not updated this time. In that case, you can then set the user to Active=False and Locked Out=True, which means that user will no longer have access or be assignable to users (excluding user admins and admins). An alternative would be a scheduled job to check this information.

---

2 - This leads me to thing that the assumption from part 1 is true, that this is using LDAP and transform maps. Transform maps have options for updating empty values, and by default these are not set to true. To fix this matter, you'd want to navigate to the Transform map(s) responsible for updating these users and set 'Copy empty fields' to True. An alternative if you do not want to do this across the entire transform, would be to use scripting either on the field mapping or an onAfter transform script to handle for these values being NULL.

---

Hope the above helps,

Astrid

[Yuri Yoshinami]

Hi, Astrid,

Thank you for your reply.

 We connect ServiceNow with Azure by SOAP not using the LDAP, so the ServiceNow won't do any transforming. Our provisioning with AzureAD uses SOAP directly access to sys_user. In this case, could you kindly help me figure out the solution for #2?

[Yass]

Hi @Yuri Yoshinami,

Did you find a way to solve your issues?

We got the same issues.

Regards,

[Astrid Sapphir1]

Hi Yass,

I've since learnt a fair bit about this in practice, so might be able to be more helpful this time.

If you're having issues with @Yuri Yoshinami's (1) which was the deletion of users, could you please share the SOAP envelope you are sending, redacted where required? Just so this could be verified. 

The format on the Data Modification API is quite simple for this one, so it would be worth checking that it matches the sample format here: https://docs.servicenow.com/bundle/paris-application-development/page/integrate/web-services-apis/re.... If the envelope is being sent as expected, then it would also be worth confirming which role your SOAP user has, and if it is being restricted from the deleteRecord function. Lastly, checking the Scripted SOAP Services for any overriding definitions may assist you in addressing and resolving this.

----

On a separate note, I would not recommend deleting users, as that breaks any existing record associations. I always recommend setting to inactive, locking out, and possibly archiving depending on the requirements of the organisation.

----

As for (2), the SOAP API will often support clearing fields, but can be forced to do so using the &allow_empty_value=true parameter. If you are doing this and still seeing issues, please provide an example. ServiceNow documentation has more detail here: https://docs.servicenow.com/bundle/paris-application-development/page/integrate/inbound-soap/concept...

I hope this clears things up a bit. Please let me know if I can help further

Kind regards,

Astrid