Multi-SSO - Move users from one Identity Provider to another

[Carl Fransen1]

Hi Team,

Currently we have a single Identity Provider (we'll call it IDP-A for now) which is configured under the 'Multi-Provider SSO>Identity Providers' module.  This is a SAML connection and is pointing to our Azure Domain.  This has been setup for authentication and provisioning and has been working well since we went live.  

Recently we have been acquired by another company and are in the process of moving all our staff to our new Azure domain with our new company.  In UAT I have created a second Identity Provider (lets call this IDP-B) and with a small amount of configuration (I'll write an article once I've finished the document) I have both now working.  Both Azure domains have different domain suffixes - IDP-A is '@idp-a.co' and IDP-B is '@idp-b.com'.  We are using the default 'user_name' field as the unique identifier.

However I now need to move all my users created and managed by IDP-A to be managed by IDP-B.  We also need to ensure we keep all the user history (so all previous tickets/updates etc...) in particular the historical HR cases.

If we provision all the users in the new domain using IDP-B we will essentially end up with duplicate users - one from IDP-A and another from IDP-B as the 'user_name' values aren't the same.

My first idea was to rename the 'user_name' field to the new domain, but the system won't allow me to do this (I get invalid update).  I can't ind any other material on-line either to assist with this.

Can anyone help with this, has anyone done this before?  

Thanks 

Carl Fransen

[Carl Fransen1 · Accepted solution]

Hi All,

After much trial and error, logging a HI ticket and testing I have found the solution and have now confirmed how to move/migrate users from IDP-A to IDP-B in ServiceNow. 

 Essentially the steps to take for an individual user is:

1. In IDP-A de-provision the user in Azure
2. 1. This sets the user to ‘locked out’ and sets ‘active’ to False
3. Rename the user_name field (in ServiceNow) to the new IDP-B value
4. 1. Example is ‘carl.fransen@idp-a.co’ to ‘carl.fransen@idp-b.com’
5. Provision the user in IDP-B azure
6. 1. This needs to match the new name of ‘carl.fransen@idp-b.com’.
7. User is automatically linked to new IDP/username combination
8. 1. All details come through and are updated as needed
9. Authentication and Provisioning work fine:
10. 1. However, the first time the user will need a special link to connect to the correct IDP
    2. After this the browser keeps the cookie and will use the same IDP for subsequent connecitons
11. The SSO field isn’t used
12. 1. This only comes into play if we would like to use the ‘use external login’ from the login screen, which is clunky.  It does work but requires the user_name to be entered a number of times

The special URL link needs the sys_id of the IDP - in this example it needs to have IDP-B:

https://<instancename>.service-now.com/login_with_sso.do?glide_sso_id=<sys_id of IDP-B>

Originally we had one IDP setup, as the default, as everyone was automatically re-directed.  While migrating we have two Identity Providers (ISP’s) set up in ServiceNow.  Once we have completed migration to IDP-B we can set it as the default and remove IDP-A.

So it took a while to figure this all out – but essentially the initial Azure provisioning of the user doesn’t use the ServiceNow transform map (which made things confusing), it does this via the IDP, so we only need to change the ‘user_name’ value (and not the email and all ther details manually).  Only for later updates, such as manager, email, phone etc.. does it use the transform map. 

For the actual migration – We’ll need to perform the following steps to do this ‘en-masse’

1. Extract users from AD/Azure that will be migrated (IDP-A)
2. Create search filter for all users in ServiceNow and AD/Azure
3. Un-provision users in IDP-A Azure
4. 1. This will take a while to sync across
5. Extract users from ServiceNow, with sys_id
6. Import/update users into ServiceNow with new UPN
7. Provision users in IDP-B Azure
8. 1. This will also take a while to sync across
9. Provide new link to migrated users to access ServiceNow
10. 1. Recommend – we updated all intranet links to the full link to ensure ALL users can connect regardless.  This meant that all advertised links we the full one, include sso, to simplify things for all users.

Hope this helps someone out there.  If anyone finds anything else useful I'd love to hear from you and discuss further.

Cheers

Carl.

[jules2]

HI were trying to do something similar using the multi sso plugin on Kingston.

We have an instance that is set up with ADFS domain A.com This is the default so always get redirected to ADFS of A.Com

users get redirection to a.com page. 

However we now need to implement 3 separate Domains for ADFS and one on Okta that are on different domains and different identity providers.

B.Com 

C.Com

and D.com (using Okta.)

The issue i have is the docs say this 

/login_with_sso.do?glide_sso_id=<sys_id of the sso configuration>

i would expect if you configure this sso source field on the company or the user record it will redirect you to the correct identity provider instead of avoiding the default redirect to a.com. Ours appears to ignore these issues and always redirects to a.com

Where do you configure the 

/login_with_sso.do?glide_sso_id=<sys_id of the sso configuration>

Could you use this in a login script on the multi sso to day if from company B, C,D always use this login IDP and redirect them to the adf page for that domain?

I have not been able to find any detailed information about login scripts and best practice. 

If you use the cms external login for 1st time users can you get the redirection to work form here as the users will have the Multisso source configured and if so how?