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

Discussion

Discussion

Laserfiche and Organizational Units in Active Directory

Laserfiche
Updated February 25, 2020
posted on February 25, 2020

This seems to be the year of client's making massive OU changes within Active Directory. All the OU changes in different environments has lead to some critical concerns with Laserfiche's Active Directory users and groups.

A forms LDAP-Participant that is moved to another OU within AD seems to lose their account, assigned tasks, and history altogether. A brand new unlicensed account is created for them with the same username, but it is not the same account.

A group that is moved to another OU will cause directory server to lose track of the group altogether and not be able to sync with AD anymore.

The most serious is the loss of history, tasks, and drafts.

0 0
replied on February 25, 2020

Hi Chad,

To address the LFDS AD Group Sync part:

My understanding is that LFDS uses standard LDAP query syntax for group sync. E.g.

memberOf=CN=LaserficheUsers,OU=HumanResources,DC=BEACHCITY,DC=COM

Because the OU is a necessary part of the query, moving the group to another OU means you must re-add the group in the LFDS group sync rules to auto-gen a new LDAP query.

It's like running a Within Folder search where the OU is a specific folder and the AD group is a document. If you move the document from Folder 1 to Folder 2, you need to update your search to look within Folder 2.

The Forms issue you describe sounds strange, as I know Forms keeps track of individual AD users by their AD SIDs, which should not change with OU moves. Please open a support case for that one.

0 0
View 1 previous reply
replied on February 25, 2020

Am I wrong that Laserfiche uses Kerberos for Active Directory users? I thought only Forms participants use and LDAP connection and all other services use Kerberos. I was not aware there was any LDAP configuration in Directory Server.

0 0
replied on February 25, 2020 • Show version history

Kerberos is an authentication protocol. Laserfiche's native Windows Authentication methods (such as the Windows Authentication button in LFS or the checkbox in the Windows Client) use Kerberos. Kerberos does not do anything like query AD for a list of all members in Group X.

Active Directory (the service) supports LDAP (the protocol). The LDAP protocol provides both authentication and query functionality. When you type AD credentials into a username/password fields in Laserfiche, that authenticates you to AD via LDAP rather that Kerberos. See: The Difference Between Active Directory and LDAP. 

LFDS AD Group Sync queries group membership using those groups' AD Distinguished Names. This is a common property to use for uniquely identifying AD groups - indeed, Microsoft's own Get-ADGroupMember PowerShell command lists Distinguished Name as the first option for specifying the group to query. 

With that said, we heard a similar story from a different customer at Empower this year. We acknowledge that it's a pain point in the uncommon and infrequent event of major OU reshuffles. As such, the LFDS team has now made a note to investigate alternative unique group identifiers without hierarchy dependencies for Group Sync.

Auth Examples:
LFDS:

 

Windows Client:

0 0
replied on February 25, 2020 • Show version history

Ok I think I understand. It's a bit strange though, because for example, in Avante we do not configure any LDAP connections and yet our users do not HAVE to check the use windows authentication box.

They can simply enter their fully qualified username and password for the domain and authenticate. I always thought the use windows authentication box was just a way to check with the local workstation to get their currently logged in credentials.

0 0
replied on February 25, 2020

Laserfiche Server's connection to Active Directory is automatically configured for you. To simplify a bit, AD Domain Controllers broadcast themselves to servers on their own and trusted domains. LFS knows what domain each Windows User belongs to as its part of their attributes, so it knows where to send those username/password LDAP authentication request to for validation.

The Kerberos/Windows Auth protocols by contrast never sends the user credentials to LFS at all. Instead, the user says to the domain controller "I would like to access the Laserfiche Server service" and gets a cryptographically-signed Kerberos ticket from a Domain Controller that says "Laserfiche Server, I certify this is Chad Saar. Here are his attributes and group memberships. Signed, DC."

Because LFS trusts the issuing party, LFS lets you in. Check out the "Kerberos Authentication Explained" article I linked in my last post. It's short, sweet, and has a nice diagram showing the flow.

 

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

Sign in to reply to this post.

Details
Related Posts
Loading ...