Roles required for User provisioning from Azure AD

[Magesh Babu1]

Hi Team

I have a requirement to integrate Azure AD with ServiceNow for SSO and Automatic User provisioning, as per the Microsoft article, the integration ID should have admin role, this is not safe to provide admin role, could you please let me know how this can be done without admin role to create/update user record from Azure AD

When I just tried with soap roles with ACL added to sys_user table, Azure throws error: Insufficient privilege to create user record

Error code

ServiceNowInsufficientRights

Error message

com.glide.processors.soap.SOAPProcessingException: Insufficient rights for creating new records

Reference article 

https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/servicenow-provisioning-tutorial

With Regards 

Magesh

[Yousaf]

Hi Magesh,

I appologize I should have explained my intent to share that link. Actually I did understand. sent you that link to show you that maybe in this query even nowSupport will not be able to help either.
But still I think you should contact nowSupport (hiwave) and discuss. 

[Appli]

Hi, you can try to search across the product documentation, in multiple pages related to Azure Ad integration this is mentioned a a requirement.

Example: here ("ServiceNow Role required: sam_integrator or admin").

Hope it helps

[Magesh Babu1]

Hi

The reference link is for SAM integration, so sam_integrator is used

[Kim Sullivan]

I've successfully provisioned users with just giving my Azure provisioning account the soap roles, rest_service and snc_internal.  Make sure you have ACLs on sys_user to allow one of those roles to write to all the fields.  I am still getting the SOAP error on provisioning Groups -- still working to figure it out.

[Ed41]

I don't know if you ever found an answer to this but I did some reverse-engineering and managed to craft a role that grants only the access the account needs.  It has always bothered me that companies will tell you to grant such high level access into ServiceNow for their apps/plugins/integrations.  Either they have no idea how ServiceNow operates, or they don't want to be bothered to assist their users with the more complex ACL configurations that might be required to get around it.  Either way it's just pure laziness on their part to not even provide you with the documentation you would need to get started.

NOTE: this is NOT an OOB configuration and may have implications elsewhere in ServiceNow if you aren't careful.  Each instance is different especially in terms of security, so I can only provide some general guidelines.  You may find it useful to turn on SOAP debugging by creating the system property "glide.processor.debug.SOAPProcessor" and setting it to "true" so that the inbound SOAP calls are captured in the system logs.  I do NOT recommend leaving this property on permanently, and it should not be turned on in production environments unless absolutely necessary.

1. You need to know that Azure Account Provisioning uses SOAP and not REST.  You will need to grant the appropriate SOAP roles to the service account for the provisioning to even connect, otherwise Azure will complain about not having access.  You can toy with giving it less than full SOAP access, but I just granted it the SOAP role and called it a day.
2. If like us you give service accounts the snc_external role to help lock down the account you will have more work to do than if it has the snc_internal role.  Many "core" permissions are granted to snc_internal that will need to be duplicated for your new role.  If these roles are not in your instance then you can disregard this entirely as they are added by specific modules being activated that you might not be using.
3. You must create READ ACLs for any fields you are filling in on the user record that are reference fields.  For example, if you are populating the "department" field, the account must have read access to the cmn_department table.  Azure will fail to write any value if it can't look it up.  you do NOT need to grant it "write" access to these reference tables.
4. You may need READ ACLs for the sys_user_grmember table.  When syncing users calls are made against this table even if you aren't putting them in groups.  I don't know if denying access would cause any problems as I didn't test it, but from what I have seen AAP gets mad very easily over the smallest discrepancy so it's conceivable that at the very least your Azure logs would show errors if you don't grant the access.
5. You will need to ensure that at a minimum you have read, create, and write roles for the sys_user table that apply to your custom role.  This is where things may get tricky, especially if you use the snc_external role.  Before adding ACls for this, check to verify whether or not they are needed (many provide access to snc_internal).  the sys_user table OOB has ACLs for the following that "may" need tweaks.
   1. Table level read, write, and create
   2. Several field level read and write (both * and explicitly defined field ACLs)
6. OOB the ACLs governing "create" on the sys_user fields are not on the sys_user table.  Instead, it falls back to the *.* create ACL.  If you are using the snc_external role, you will need an explicit sys_user.* create ACL that masks the *.* ACL.  Make sure that the conditions defined in the *.* ACL are mirrored/duplicated in your work for the sys_user table or you may inadvertently break other components writing to the sys_user table.
7. We specifically do not allow AAP to delete records, but if you wanted to you may need to create new DELETE ACLs to accomodate that.  These should be limited to sys_user, sys_user_group (if needed), and potentially sys_user_grmember (not sure if cascade deletes would be impacted by the service account not having delete access).
8. I haven't tried syncing groups from Azure yet, but the process will likely look very similar.  You will likely need to grant read, write and create access to sys_user_grmember, sys_user_group, and then read access to any reference fields you are populating within the sys_user_group table.  SOAP debugging will be your friend with figuring this out.

It may take you several tries to get the ACLs correct, but once you do you will find no errors on the Azure end and the records will populate/update in ServiceNow as expected.