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

Discussion

Discussion

Laserfiche after domain swap (w/ SID carry over)

Laserfiche
Updated May 20, 2024
posted on November 11, 2022

Has anyone ever done a swap to a new domain for a company running Laserfiche where the SIDs were transferred to the new domain controller and found that Admin Console handled it perfectly, by updating everyone's username to the existing account with all of it's settings, yet Forms created new accounts for everyone, leaving the old account inaccessible under the old username?

I know there is no support for doing this, but I found it odd that one system handled it without issue and the other did not, even on the Kerberos side of forms (Named Users)

LDAP also failed to match up even when using the Retain SIDs beforehand

Yet in Admin console, it kept everything, attributes, rights, group membership.

1 0
replied on May 20, 2024

To add to this discussion, I am involved with a domain migration where the customer had Directory Server and saw some interesting differences on the DS side as well.

Where the Administration Console automatically updated all accounts with the new FQDN and no changes were needed here as usual, DS server did not. All the accounts still showed the old domain name in the FQDN. The licenses status still synced properly so that the user accounts had a full license, but they could not login until we manually added the new DC in DS as an identity provider, added the users new domain account to DS and moved the full licenses status over to it.

They did not use DS for Authentication, just for licensing.

It is odd that LFS handles domain migrations so well, but forms and DS do not. I understand each service is different code, but if these services can not work together it effects the system as a whole.

1 0
replied on November 11, 2022

Different code, different database structures for users. You could try reaching out to Support on the off chance there's  a SQL script to handle bulk username updates in Forms. They likely can't help you otherwise, but it's worth asking if there's a one-off script (or other fix) for this scenario.

1 0
replied on November 11, 2022

Ok, we tried for a long time to get an official options or database scripts without success but we have one IT company who was savvy about moving the SIDs and they went for it, yet the Forms users still lost their Drafts, History, Task Assignments, etc.

I just found it odd that one system handled it so perfectly and the other ignored it completely. It is like it half worked perfectly when it is all synced to the same controller. Forms is even synced with Admin console for Named Users but it wanted to create new accounts when it saw the updated usernames in Admin console.

Also since LDAP now has a retain SIDs feature I thought that would have to work, but you can clearly see the account shows No for a license and when you switch it to Yes and login, everything is gone.

0 0
replied on November 11, 2022 • Show version history

Forms has User Names, User IDs and User SIDs. It sounds like you might have ended up with a new set of User Names/IDs potentially linked to the same SIDs.

You might find this Answers post for a somewhat related user migration scenario useful as "inspiration":

https://answers.laserfiche.com/questions/200490/Forms-Considerations-with-SAML-Identity-Conversion

Matthew Tingey’s SQL queries changed the data linked from an old user id to a new user id. It essentially rebuilds the entire user as a new one, copies some of their original attributes to the new user id profile, and then re-assigns everything associated with the old user id to the new one.

Also for inspiration, I've attached a text file with a SQL script that creates a stored procedure for updating user SIDs and nothing else. It was designed for the "migrate from AD users to SAML users scenario". Mostly, it will tell you all of the (many) places that SIDs are stored in the Forms database.

It takes need the old (AD User) SID and new (LFDS SAML) User SID as inputs.

There should be no new_user_id in the database because in this scenario we expect the “user id” to not change while updating the SID for same user from AD to SAML.

For example:

  • Before:
    • User_id: 3
    • User_SID: S-12345 (AD User SID)
  • After update:
    • User_id: 3
    • User_SID: S-678910 (LFDS SAML User SID)

 

It should go without saying to test any of this on a copy of their Forms database first, such database modifications are not officially supported, perform at your own risk, etc. etc.

FormsMigrationUtility-MigrateFormsUserSP.sql.txt (3.03 KB)
Download
1 0
replied on November 12, 2022

Oh wow, that sounds a bit risky since these tables change with version 11. It is A solution we can bring to them though, lots of requests for this feature over the years and some just push forward with it anyways.

For this client, it is like a bomb hit their forms system, there are tasks just all over the place assigned to their old dup account and in the Monitor/Task view it does not show the fully qualified name so you can not even see which ones are assigned to the new account and which are assigned to the old account as you try to correct everything.

Deleting the old account is impossible because of this:

"The DELETE statement conflicted with the REFERENCE constraint "FK_task_shown_columns_user_id". The conflict occurred in database "Laserfiche_Forms", table "dbo.task_shown_columns", column 'user_id'."

 

I like to have as many options as we can give them though, so I think, if tested beforehand, this script might be a future option. Or if they decide to scrap all this Monday morning, and re-try later we might try it.

It would be nice if there was a straight forward way, when replacing a domain, to make sure any attached services  are not impacted in such a way. The domain controller is just there to manage authentication, shouldn't break a billion things to replace it.

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

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...