What is the correct way to move users assigned to an LFDS Identity Provider to a new LFDS Identity Provider?
We don't technically support this scenario as there has been no testing dedicated toward it. What I do know is that you must preserve the users' AD SIDs when migrating them from the old domain to the new one, in order to preserve properties in Forms and Server. You might be able to follow a process like this (ensuring that you have the necessary backups and a rollback plan):
Perform the AD user migration according to Microsoft documentation so that the users are moved to the new domain with their existing SIDs preserved
Add the new IdP and users in LFDS
Start Forms and LFS back up
Edit: a migration from one domain to another cannot preserve SIDs, please see this post.
Hi Drew,
Can you elaborate on what it is you'd like to accomplish? What is the relationship between the new and old IdPs?
Hello Chris,
Client is moving to a new domain. The current domain is still active. there is currently a trust between the two domains. Ultimately we want to get rid of the old identity provider and point it to the new domain. I am concerned that I will lose the users in the old domain when I do this. I was hoping there would be a way to migrate these users without starting fresh.
Thanks,
We don't technically support this scenario as there has been no testing dedicated toward it. What I do know is that you must preserve the users' AD SIDs when migrating them from the old domain to the new one, in order to preserve properties in Forms and Server. You might be able to follow a process like this (ensuring that you have the necessary backups and a rollback plan):
Perform the AD user migration according to Microsoft documentation so that the users are moved to the new domain with their existing SIDs preserved
Add the new IdP and users in LFDS
Start Forms and LFS back up
Edit: a migration from one domain to another cannot preserve SIDs, please see this post.
@████████, do you have a link to the Microsoft documentation referenced to in #3?
The reason I ask is because I have read several posts that say you cannot retain SIDs when migrating to a new domain because the first part of the SID is domain specific. You can keep a history of the SID in a different value, but not do a SID for SID migration.
An account cannot maintain its SID when it is moved between domains because the first portion of the SID is domain-specific. You can use the sIDHistory attribute to keep a list of old SIDs assigned to a user account inside the new user account object.
admt - Does the active directory migration tool keep the same user SIDs? - Server Fault
I may have answered my own question. It looks like when you migrate from one domain to another the SID cannot be migrated SID to SID, but the SID from the old domain can be put into an attribute named sIDHisotry which is a property of a security principal (users and groups, most commonly) that maintains the former value of an object's SID.
"A typical migration scenario involves setting up a trust relationship between source and destination domains, and moving groups, users, and servers gradually over time, in the sequence as indicated. If no SID history is maintained during migration, migrated users will lose access to resources that are still maintained in the source domain, because the new SID of the migrated user account will not be matched to any access control entries on the resources in the source domain."
Hi Blake,
I was mistaken before, you are correct in thinking AD users cannot be migrated from one domain to another while maintaining the same SID. In this case, user data will need to be manually migrated to the new users for both Forms and the repository.
For Forms, Xiuhong shared some information here that shows how to migrate data to a new user. Since LFDS does not store the SID of its users as a string in the database, a program can be written like so to find the SID string.
For LFS, the process is more complex and will require writing and utilizing a SQL query that updates all the tables. An example would be something like:
IF NOT EXISTS( SELECT 1 FROM trusted_allow WHERE sid = @newAdSID ) BEGIN INSERT INTO trusted_allow (sid) VALUES (@newAdSID); END; Update account_security SET sid = @newAdSID WHERE sid = @oldAdSID; Update annaccess SET sid = @newAdSID WHERE sid = @oldAdSID; Update audit_reason_choices SET sid = @newAdSID WHERE sid = @oldAdSID; Update bizproc_entity_trustee SET sid = @newAdSID WHERE sid = @oldAdSID; Update certificate_store SET sid = @newAdSID WHERE sid = @oldAdSID; Update defaultacl SET sid = @newAdSID WHERE sid = @oldAdSID; Update entryacl SET sid = @newAdSID WHERE sid = @oldAdSID; Update propacl SET sid = @newAdSID WHERE sid = @oldAdSID; Update psetacl SET sid = @newAdSID WHERE sid = @oldAdSID; Update tagacl SET sid = @newAdSID WHERE sid = @oldAdSID; Update trustee_attr SET sid = @newAdSID WHERE sid = @oldAdSID; Update trustee_tag SET sid = @newAdSID WHERE sid = @oldAdSID; Update vhist_annaccess SET sid = @newAdSID WHERE sid = @oldAdSID; Update volacl SET sid = @newAdSID WHERE sid = @oldAdSID; Update watermarks SET sid = @newAdSID WHERE sid = @oldAdSID; Update vhist_ann SET ann_creator = @newAdSID WHERE ann_creator = @oldAdSID; Update ann SET ann_creator = @newAdSID WHERE ann_creator = @oldAdSID; Update annhist SET creator = @newAdSID WHERE creator = @oldAdSID; Update toc SET creator = @newAdSID WHERE creator = @oldAdSID; Update doc SET deleter = @newAdSID WHERE deleter = @oldAdSID; Update recycle_bin SET deleter = @newAdSID WHERE deleter = @oldAdSID; Update recycle_elec SET deleter = @newAdSID WHERE deleter = @oldAdSID; Update frozen SET freezer = @newAdSID WHERE freezer = @oldAdSID; Update plock SET owner = @newAdSID WHERE owner = @oldAdSID; Update toc SET reviewer = @newAdSID WHERE reviewer = @oldAdSID; Update document_signatures SET signed_by = @newAdSID WHERE signed_by = @oldAdSID; Update stamp SET stamp_owner = @newAdSID WHERE stamp_owner = @oldAdSID; Update toc SET toc_modifier = @newAdSID WHERE toc_modifier = @oldAdSID; Update toc SET toc_owner = @newAdSID WHERE toc_owner = @oldAdSID; Update deleted_ver SET who = @newAdSID WHERE who = @oldAdSID; Update user_area SET uarea_owner = @newAdSID WHERE uarea_owner = @oldAdSID; Update vhist_toc SET who = @newAdSID WHERE who = @oldAdSID; Update activity_log SET who = @newAdSID WHERE who = @oldAdSID; Update active_doc SET who = @newAdSID WHERE who = @oldAdSID; Update trustee SET sid = @newAdSID WHERE sid = @oldAdSID; Update account_cache SET account_sid = @newAdSID WHERE account_sid = @oldAdSID; Update ldap_allow SET sid = @newAdSID WHERE sid = @oldAdSID; Update ldap_deny SET sid = @newAdSID WHERE sid = @oldAdSID; Update password_history SET sid = @newAdSID WHERE sid = @oldAdSID; Update sess_sid SET sid = @newAdSID WHERE sid = @oldAdSID; Update trusted_deny SET sid = @newAdSID WHERE sid = @oldAdSID; Update trusted_group SET sid = @newAdSID WHERE sid = @oldAdSID; Update trusted_login SET sid = @newAdSID WHERE sid = @oldAdSID; Update user_login SET sid = @newAdSID WHERE sid = @oldAdSID; IF EXISTS(SELECT* FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME= 'wopi_at') BEGIN UPDATE wopi_at SET sid = @newAdSID where sid = @oldAdSID END; IF EXISTS(SELECT* FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME= 'wopi_user_info') BEGIN UPDATE wopi_user_info SET sid = @newAdSID where sid = @oldAdSID END;
Note that this is not comprehensive and this migration from one domain to another is not an officially supported situation.