You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Active Directory User migration procedure to keep Forms tasks assigned to same Windows SID

Forms Directory Server
Updated November 4, 2020
posted on October 20, 2020 • Show version history

We have a client that is migrating all of their users from multiple forests to a new forest. When this migration is complete and they have new accounts under the new forest, they will no longer be able to finish the active Forms processes they had assigned to their previous account nor will they be able to see the data from the historical process they completed in the past with their old account. I've seen a lot of posts with procedures regarding migrating from LF Users to LFDS users, but is there a way to migrate from one AD Account to another to maintain their relationship to their historical data.

 

*Note: Their Windows SID is not going to change.

 

We were told by LF that if the windows SID doesn't change we should be fine and any process step assigned to them would still be accessible by the new account because the SID stays the same. However, we tested one and the SID in Forms IS changing. So the user was severed from their current tasks.

 

This customer has upwards of 800+ users to migrate so manually updating SIDs or reassigning tasks is not efficient.

 

Is there anything that can be done to prepare for this migration and automate the cutover?

0 0
replied on October 21, 2020

What's the value of the "user_type" in cf_users table for the user that you have tested the SID in Forms is changing? Does the value for the sid column start with "S-1-5"?

0 0
View 2 previous replies
replied on October 21, 2020

Yes. S-1-5-21-etc.

The user exists in the table twice. 

0 0
replied on October 21, 2020

Sorry. User Type is 6.

0 0
replied on October 22, 2020 • Show version history

Please open a support case and export the content in the cf_users table so that we can have further investigation. 

0 0
replied on October 22, 2020

Case 213111: I have updated some details we have discovered in the case.

0 0
replied on October 28, 2020

Does LF use sidHistory in any of its logic to account for this type of a scenario? The behaviors we are seeing within LF seem to indicate that it DOES take into account the sidHistory, but the behavior isn't consistent with our expectations. 

With no action Forms allow the user to login with the new account as both are active in AD. However, the old account shows up as 'invalid'. There is mysteriously a new account created for this user under the new username but it is a group type account. The user can still login with their old account (even though it shows invalid), but any task newly assigned to the old account suspends.

I updated the case on 10/23 with these questions.

Case 213111

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...