How to do Entra (Azure AD) user provisioning for multiple clients as an MSP?

[VanGoghJoe1]

Hi,

We are an MSP using domain sep with multiple clients who are using Microsoft Entra (aka Azure AD) and we would like to integrate with each client's Entra tenant to auto provision their users in our instance.

The document here:
https://learn.microsoft.com/en-us/entra/identity/saas-apps/servicenow-provisioning-tutorial

shows the basic method for setting this up.

However, it requires using a SNOW account that has admin rights. Since this is to integrate with external clients, we don't want to give admin to the application, even one maintained by SNOW, if it is at all avoidable.

Is there a more restricted set of roles we can give the account that would still allow it to work? We can domain the account, but if it has full admin rights that can always be gotten around. Is there at least a way to only give rights during an initial set up phase and then the account can be given more limited rights to do the actual provisioning?

If not, can anyone suggest an alternative method, other than getting the Entra spoke and essentially creating our own custom process?

Thanks!

[Mark Manders]

You can give the account 'web access only' on the user form. And of course you can downgrade the roles to just the necessary ones after initial setup. Just like with any other account. 

[Colin15]

Thanks for your reply, this is similar to what I did.

Does this stop the user account having to renew the password conform the policy or do I have to take other steps for this? I don't want to set up this account then have to renew the password every X days or so.

[Ryan Duce]

I'll just reiterate that you should never be giving customers you host on a domain-separated instance the admin role at all - even if for a short while. Those customers can use that role to access all customers' data on the instance, even if web service access only = true

[Ryan Duce]

We have a similar problem on our managed service instance. We do not give ServiceNow admin accounts to our hosted clients under any circumstances, and admin is required in full for Azure to configure the ServiceNow IdP fully on your behalf, so we needed to provide a work instruction out to our clients to set up Azure SSO. The process we came up with is:

Client:

1. Sign into Azure portal
2. Open Azure Entra ID
3. Enterprise applications > All applications > New application
4. "Add from gallery" > ServiceNow
5. Find "Manage" from the new application and select "Single sign-on"
6. Select SAML as your method
7. Select Edit on "Basic SAML Configuration" to change the settings
8. Perform following configuration
   1. Sign on URL: https://<instance_name>.service-now.com/login_with_sso.do?glide_sso_id=<sys_id_placeholder>, where sys_id_placeholder is provided in a later step.
   2. Identifier (Entity ID): https://<instance_name>.service-now.com
   3. Reply URL: https://<instance_name>.service-now.com/navpage.do
   4. Logout URL: https://<instance_name>.service-now.com/navpage.do
9. Find the certificate and metadata URL from the "SAML Signing Certificate" section.
10. Click "Download" next to the Certificate (Base64) option and send the file to the managed service instance admin.
11. Click the "Copy" button next to the "App Federation Metadata URL" and send the URL to the managed service instance admin.
12. Find the "Set up ServiceNow" section and copy and paste all three URLs and send them to the managed service instance admin.

Managed service instance admin

1. Navigate to All > Multi-Provider SSO > Identity Providers and click New
2. Click SAML from the interceptor page.
3. Paste the identity provider metadata URL that the client provided you with and click "Import".
4. If the above doesn't work, you'll have to manually configure the IdP in ServiceNow using the information received from the client.
5. Ensure "User Provisioning" is enabled and "Update user on each login" is enabled. This is because Azure doesn't have an admin account to your ServiceNow instance so you will have to use the ServiceNow-side user provisioning to create the account. (If you want additional fields synced from the client, have them create custom claims).
6. Add a scripted field mapping to the User provisioning transform map (related link at the bottom of the IdP record). The field mapping should specify the Company of the incoming user to be the company for which this IdP is relevant.
7. Navigate back to the IdP record and copy its sys id. The client will need to paste this sys id into the URL they configured in their step 8.
8. Navigate to the client's core_company record and update the SSO Source field to sso:<IdP sys id> using the sys ID you just copied

Voila! You've set up Azure SSO without giving a managed service instance admin account to one of your clients.

Any questions, let me know.