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

Question

Question

Possible Bug: LFDS AD Synchronization

Directory Server Version 10
Updated May 28
asked on April 11, 2019 • Show version history

Hello,

We just encountered an issue with AD synchronization that seems very likely to be bug (we are currently running 10.3.0.110).

We discovered that our AD synchronization has been failing for several days now and the error reported on the server was a unique key violation.

Because LFDS uses sAMAccountName for the unique identifier, this what I believe happened.

  1. One of our users was disabled and removed from the system and their account had not yet been removed from LFDS (automated cleanup options would help here)
  2. The user returned and was issued a new account with the same username (i.e., same sAMAccountName) but with a new SID (I think this is what caused the problem)
  3. Instead of overwriting the user entry because the unique value matched, LFDS saw this as a different account and the entire synchronization failed because it tried to enter a duplicate value into a unique column of the database.

 

From my point of view, if sAMAccountName is the unique name attribute, then it should treat anything with that unique identifier as an update to the existing entry, even if it has a new SID, otherwise it should use SID as the unique identifier.

In our environment is pretty common for employees to come back after leaving the organization, so without automated cleanup options for LFDS, it is inevitable that a new SID will be associated with a previously registered sAMAccountName.

 

Because LFDS does not report these kinds of errors, it went undetected for several days until we realized a user whose name changed was now showing the correct username in Forms.

The error we've been getting is below.

Is this by any chance fixed in a newer update?

1 0

Answer

SELECTED ANSWER
replied on April 12, 2019 • Show version history

Deleting users from LFDS that have been deleted from AD is available as a setting in LFDS, under the general (added in 10.3):

If you turn that setting on, the users you delete in AD that are part of AD sync should be deleted from LFDS. As such, when users return (or a new employee joins with the same name), they will be added as a new user with a clean slate. Does that address your primary concern?

If you want to retain settings (security, attributes, etc.) across the LF suite when the users return, I would recommend disabling these users in AD instead of deleting them since you said this is a frequent occurrence.

A little more info on the Unique Name Id:

The Unique Name Id is about how we identify the users logging in, and thus must be unique like any other username, but it is not the ID we use on the backend: we use the Windows SID across the LF suite since the Windows SID stays the same when a user's name changes, formats change, domain names are modified, etc.

As a final note, your error message screenshot is generated from the LFDS synchronization failure --- I was able to reproduce it when attempting AD sync in LFDS. That said, it does seem to me that a separate error noting that AD sync failed would be helpful.

0 0
View 1 previous reply
replied on April 12, 2019

Just to clarify, I know the error was generated was generated by the synchronization failure. I think the issue was that we didn't get any indication from LFDS that something was wrong so we did not know to check.

 

I didn't know the Remove Users option was added; that one slipped by me and will make a big difference. Thank you for pointing that one out!

 

We do disable users for at least a month before we actually delete the account, but we have a unique environment in which a certain type of user will retire, and may come back to fill in on an "as-needed" basis weeks, months, or even years later.

0 0
replied on April 12, 2019

We have an item on our backlog for improving visibility of AD sync failure, though I don't have an ETA on when it will release.

For now, we have a dialog where you can see the current status:

You can find it near the top of the Identity Providers page:

It seems like you'd prefer something that draws attention to itself, but I thought this might be helpful for now.

1 0
replied on April 12, 2019

Thanks. That is how I determined there was a synchronization issue before getting the specific error from the event logs, but a notification would certainly be helpful as it is hard to know to check the status until we can narrow down the issue.

In our case, a user had a name change and Forms was still showing her old username. It look awhile to track that back to the AD sync issue, so some kind of email notification would definitely come in very handy in situations like that.

1 0
replied on April 12, 2019

I've linked to this post in the feature request, so we will know to update here if there are any changes to the status smiley

 

Thanks for all the detail in your responses! It's always helpful.

0 0

Replies

replied on June 7, 2023

A nice feature to have under the active directory synchronization would be "Remove users disabled from Active Directory". 

 

We have several clients that have hundreds of disabled accounts. They would like to keep them but do not need to see them in LFDS. 

 

Is there any talk of having a feature like this?

 

Thanks,

1 0
replied on December 20, 2024

We are currently experiencing this problem. We have 'Remove users deleted from Active Directory' enabled, and it has been enabled since before these users were created, yet they remain in LFDS in a disabled state seemingly forever. We have 'Ignore Active Directory tombstones' disabled.

 

Looking at this link:

https://doc.laserfiche.com/laserfiche.documentation/11/administration/en-us/Subsystems/LFDS/Content/HandlingDeletedUsersInADGS.htm

 

It says: Note: An Active Directory administrator must give Laserfiche Directory Server permission to access the Active Directory tombstone lifetime attribute for user deletion to be delayed in Laserfiche Directory Server.

 

If our service account does not have permissions to the tombstone lifetime, could that be causing LFDS to fail to remove the user's account? Would enabling the 'Ignore Active Directory tombstones' setting clear out these users?

1 0
replied on May 28

Same issue here for years.  No response yet??

0 0
replied on April 12, 2019

We have also seen AD sync fail if a Named Users account is removed from AD, but they still exist in LFDS.  Instead of the Sync failing when a user is not found in AD, it should just remove the license (if a license is assigned) from that account and move on to the next.

0 0
replied on April 12, 2019

That's interesting. I've never actually seen it fail because a user no longer exists. We have a lot of user accounts in LFDS that are no longer in AD, but this is the first time I've seen a sync error directly caused by a specific account.

0 0
replied on April 12, 2019

Your recommend is actually the current intended behavior: if the user is removed from AD, the user in LFDS should have their license removed. I checked in a few versions and this is the behavior I see.

If you are seeing AD sync fail in this scenario, you may want to open a support case. 

The way the remove should happen is this:

  1. LFDS compiles all the AD sync rules based on current AD group membership. Since the user doesn't exist in AD anymore, they obviously aren't members of the AD group anymore and thus are not set to receive a license.
  2. LFDS checks that licenses can be assigned given the current available number of licenses and the total number of users that should receive them
    1. If all license assignments should succeed, LFDS proceeds
    2. If the number of licenses is insufficient, LFDS stops and logs an error
  3. Any users that don't have "Exempt from AD sync rules" set and are not eligible for a license under the current rules should have their license removed --- and the deleted user should fall into this category
0 0
replied on October 18, 2024

Our organization is seeing issues with failures due to the duplicate keys. Seems to be when a user is disabled in AD and their LFDS account is deactivated/license removed, but then the user is reactivated in Active Directory. The sync following that action seems to fail every now and then. 

Recommending alerting when the sync fails. 

Recommending option to delete user in LFDS when account is deactivated in AD.

0 0
replied on October 18, 2024

As noted in the selected answer, the option to delete a user in LFDS when the account is deactivated in AD has already been released, and should be available in all versions of LFDS from 10.3+

You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...