Changing a users account to use new domain

[danec]

Currently we use Google Single Sign On as the means for users to access Hornbill. As a company we are going to be changing our primary domain which from testing seems to break people's access to Hornbill. We have two different approaches:

1) If we do not make any amendments to Hornbill, we find that it creates a new account when they log in with the new domain. 

2) We change the email and login ID parameters to the new email. It identifies the account however it then raises an error. I believe this is to do with the user ID not matching. 

What is the best approach as ideally we do not want to re-create accounts as this would mean all requests will need to be reassigned and permissions on each account need readjusting. 

 

Would be great to see what solution are available to us.

[Steve Giller]

11 minutes ago, danec said:

It identifies the account however it then raises an error.

It would probably be helpful if we could see the error.

[SamS]

@danec,

I would advise you to turn off AutoProvisioning (to disable the creation of the new accounts) and set up a Second SSO profile.

Your customers will then need to select the correct "identity provider" before logging in - but hopefully you will have communicated to them which of the two to select - or, indeed, the simple instruction: "if "ABC" identity provide doesn't work for you, please try "XYZ" and know that we have already migrated your account."

[Giuseppe Iannacone]

@Steve Giller and @SamS we have the same issue for our employees, we have different legal entity, and if i move to another legal entity the email domain will change and the user will be created with the new email domain. This is due to the mapping of our sync job from AD.
The only way I was thinking might work for us, might have the user in hornibill being associated to the SID in AD which is the unique reference in AD, but then the user login instead has to be setup against the upn.
Changing it now is challenging as this will impact our integration of course so at the end I've decided to keep all as it is. When we started our instance, no one took in consideration this and change it now is not possible as far as I know, summarizing  I believe the solution might be having the User ID mapped to a unique value on the side of sync (in our case the AD the SID as an alphanumeric string) and instead the logon ID, Employee ID and the Handle mapped against the upn(that usually matches the email address ) for a transparent user experience
 

[danec]

So with the change of domain and updating the email, Logon ID and Employee ID we receive this error:

Authorization failure: Failed to auto-provision user. Operation[admin::userCreate] User already exists with account status: active

I believe changing a new a second SSO profile will have the similar outcome as it seems to be reliant on user ID matching. Is this not the case?

[Steve Giller]

As @SamS has correctly identified, the error is because the Auto-Provisioning is attempting to create a new User, however as the User ID is already taken this cannot be completed.

Using a second SSO Profile will match against the User's Logon ID (which can be changed, unlike the User ID) and will recognise the User and try to log them in with the provided credentials rather that auto-provisioning a new one.

[SamS]

@Giuseppe Iannacone,

I would play around with using the "Action" of "Update" (instead of "Both") and figure out how and when you move across. Please note that one does NOT NEED to use the User ID to match users on - in our LDAP/Azure/DB User import utilities.

 

[Giuseppe Iannacone]

@SamS so you are suggesting to have 2 import jobs, one for create and one for update, instead of a single action with "Both"

[SamS]

@Giuseppe Iannacone, depending on your specific requirements, two or more import jobs are totally possible. The import utilities don't need to be on the same machine, nor point at the same data source.

We have customers where there are various sources of truth - eg one for (mobile) phone numbers, one for physical location (eg room 12) - with matching fields email address or UPN or such.

IF you want to know what would work for yourselves, you can always arrange a consultancy session.

[danec]

I have turned off auto provisioning for now which has allowed me access in with only changing the login ID. 

In terms of the second SSO profile, what needs to be done differently for that not to try and create a new account also. Is there a way to set priority for one SSO over another?

[SamS]

@danec,

Just ensure AutoProvisioning is disabled to prevent the creation of accounts.
There is no way to set up priorities of SSOs, so the customer will have to select the one (s)he thinks is the relevant one, and, if unsuccessful, try the other instead.