Azure AD SSO provisioning duplicates group assignments / mappings in sys_user_grmember
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2017 04:06 PM
I am configuring the Azure AD plugin for user provisioning and SSO. In the future state, every domain in our ServiceNow instance (we are domain separated) may or may not use SSO, each with its own Identity provider. In my PoC, I am using Azure AD. We are on Helsinki.
Azure AD SSO Plugin: Microsoft Azure Marketplace
Tutorial: Tutorial: Azure Active Directory integration with ServiceNow | Microsoft Docs
My provisioning user is in a "customer" domain in ServiceNow and has two roles: user_admin and SOAP (not full admin role). Everything is working well except for Group syncing:
Working:
- Azure AD users get synced to ServiceNow based on my scoping criteria, get assigned the right domain in SN, etc (good)
- Azure AD Groups that meet my scoping criteria get created in ServiceNow, including a couple of extra attributes we have in the sys_user_group table (Company and Type). (good)
- Azure AD Group members get added to the appropriate groups in ServiceNow (good)
- Users and Groups become inactive if I delete or deactivate them in AD (good)
Problems with Group syncing:
- Every time I add a new user to a group in Azure AD (a group that is also synced to SN), when it syncs the group member to SN it creates duplicate records of the existing users in the group. (it is not creating new SN users, it is creating duplicate user-group mappings in sys_user_grmember table). If I have 5 members in a group, then I add a user, I get 11 members (2 of each of the first 5, plus the new one). The next time I sync with a new group user, I'll get those 11 plus 7 more (6 are dupes, 1 is new). The same thing happens when I manually restart provisioning in Azure AD Classic portal > Application > Configure tab > Restart provisioning button. It duplicates the existing user mappings in the group. Expected behavior: I should only see NEWLY added users get added to the group, and no duplicates.
- When I remove a member from the AD group, nothing happens in the ServiceNow group. The user is not removed. Expected behavior: User should be removed from the ServiceNow group
I tried giving my SN provisioning user (user configured for Azure AD provisioning) full admin role, and that hasn't helped.
Any ideas on how to troubleshoot / solve these two problems?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2017 09:30 AM
Hi Chris,
Thank You so much for documenting the information that was helpful. I would like to know if this has been resolved for you. If so can you please provide me the solution that SNOW has provided or the fix you applied.
My company does not want to use LDAP so they want to continue with the SAML and SSO import for the users and groups
Your response will be really appreciated.
Thanks
Afra
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2017 01:11 PM
Hi Chris,
I am facing the same issue, it is adding the same user to the same group over and over again. Could you please let me know if this issue is resolved for you?
Regards,
Sankar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-20-2017 02:53 PM
I have not been able to resolve this issue yet. Still having issues with group member provisioning. I'm still seeing duplicate records get created in the sys_user_grmember table by SOAP calls sent by the Azure ServiceNow app. As a workaround, I implemented a business rule that prevents duplications, but its not a great solution. I also cannot get group member deletion to work in my environment (all of this works fine in a "Vanilla" developer instance by the way).
My latest hypothesis is something got configured somewhere in my instance that is causing my ServiceNow instance to respond incorrectly to Azure. I think Azure checks for group membership first (getmembers SOAP call) before doing insertions or deletions, but somehow my instance is giving a response that doesn't get interpreted correctly. Azure thinks the user doesn't exist in the group, so it will send a new insert when it shouldn't. Or, it doesn't think the member exists in a group so it won't send a delete. I have been trying to do some testing with the SoapUI tool to see if I can compare the response of my ServiceNow instance vs. a vanilla developer instance configured similarly - nothing pops out to me yet. (This kind of troubleshooting is not really my forte).
If anyone has ideas on how to troubleshoot my instance, it would be greatly appreciated.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-25-2018 06:23 AM
Hi Chris,
My suggestion would be to enable SOAP debugging (ServiceNow KB: Inbound Web Service Troubleshooting (KB0546297) ) and see exactly what the requests from Azure AD look like. You can then use a tool to send the same SOAP messages to your instance, using the same credentials you set up for Azure AD (if you cannot find a good tool, then you can always send from another ServiceNow instance, or even the same instance). This will allow you to see what response you are getting back (as well as what Azure AD is getting back).
The fact that you gave the provisioning user admin rights would rule out an ACL issue (or so it would seem). You mentioned that you are domain-separated; that could be contributing to the problem. It is possible that the provisioning user is not able to read either the user or the group record due to domain separation from the sys_user_grmember table. What domain is your provisioning user in? You may want to put that user in global.
I'm assuming the instance in which this is working (the "vanilla" instance) is not domain-separated? If that is the difference, then I would focus on that for your troubleshooting. We run two domain-separated instances and there is no end to the surprises it gives us!
Hope that helps.
Thank you,
Nick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-25-2018 06:53 AM
Fixed... Azure discovered some bugs in their tenant. Apparently nothing to do with ServiceNow. Only took 7 months to find and fix it!
Chris Hanson
Mobile: 303-502-6242<tel:303-502-6242> | Work: 720-258-0322<tel:720-258-0322>
Email: chanson@hitachiconsulting.com<mailto:chanson@hitachiconsulting.com>