Identity duplication after domain migration

[diego.azevedo]

We are in the middle of an AD domain migration project. Accounts from source domain were sync’d to the target domain, including SID History.
 
We noticed ASG is creating a duplicate identity in the database when users login to the app using the account in the target domain. This means a new profile is created, and all information associated with the previous profile is not carried across (credentials, private connections, etc.).
 
I was just wondering if there is any workaround available that would enforce the app to look at other attributes to determine that the account in the target domain is, in fact, the same account as in the source domain.
 
Some attributes that are not changed between source/target domains are:
 
samaccountname
Mail
SID History (target account has the SID of the source account)

I am aware of the export/import functionality, but was trying to avoid that if possible.

[DevOma]

You can try to edit the database directly - if it is a clone of your AD it should work - else every user needs to change the login method to username/pwd and after migration to the new AD change back to Windows-Account (and using the new AD)

Please backup your database before editing content of any table - then try to update the domain name in table "Users" and "SecurityGroupUsers" - ensure that your new AD-Accounts are deleted before editing. Afterwards the "assignment" to the internal UserId should be mapped correctly and if your AD-Account is really a clone the password decryption should work - try it with one account...

[diego.azevedo]

You can try to edit the database directly - if it is a clone of your AD it should work - else every user needs to change the login method to username/pwd and after migration to the new AD change back to Windows-Account (and using the new AD)

Please backup your database before editing content of any table - then try to update the domain name in table "Users" and "SecurityGroupUsers" - ensure that your new AD-Accounts are deleted before editing. Afterwards the "assignment" to the internal UserId should be mapped correctly and if your AD-Account is really a clone the password decryption should work - try it with one account...

Hi Oliver,

Just tried the above but it didn't work on its own. We also  had to update the SID of the previous record to match the SID of new record.

While users are the same in both domains, the SID is unique to an object and can't be replicated. The SID of the source account gets added to an attribute called SIDHistory in the target account.

Account pwd and other attributes like samaccountname, email, department, phone, etc., are all the same.


Thanks for your help

[DevOma]

Ok - that's why the only possibility is to switch from old domain (if still available) to the Login type (Environment => Login type) "Internal user" - then login to your new domain, login with username/password to ASGRD and switch the Login type back to Windows Account - now with the new domain account! That's it - all your data should be migrated to the new user!

If you change SID from your user in the database you will be able to see the users data - but all personal passwords are not readable - of course every user can "reset" all passwords - the not readable passwords are marked by an special icon - hope that helps