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

Question

Question

Why do all AD groups need to be included when using Linked Identity Providers?

asked on February 9, 2023

Our organization has been working on implementing Okta authentication with Directory Server. We have been successful, and it is working, but we would like to now take the next step by using the Linked Identity Providers feature since we already have a few thousand users in the system. What is currently holding us back is our concern with this note in the documentation:

Why are all AD groups required? Our organization has thousands of AD groups, and a user could be a member of hundreds of groups. Is there a reason we are not able to only include the Laserfiche AD groups?

0 0

Answer

SELECTED ANSWER
replied on February 9, 2023 Show version history

Hi Blake,

Strictly speaking, they do not. However, customers should not deviate from the guidance unless they fully understand the potential downsides and risks of sending a partial group list and are confident they have the controls in place to mitigate those.

At a technical level, only the AD groups sent in the IdP SAML response are written into the Groups attribute of the user's LFDS STS token. Laserfiche applications only look at a user's STS token's Groups values to evaluate membership for access rights/features/privileges/etc.

We provide the guidance to send all AD groups in the SAML response because it is rare that the people configuring SAML and Linked Identity Providers (who might understand that nuance) are the same ones setting Laserfiche security rights a year later.

We hope to avoid scenarios where someone might set important security rights on an AD group (because they know users log in with their AD creds) that isn't getting passed in the SAML response even though users are members in AD. This is beyond most SPs and customers' ability to diagnose themselves, requires advanced technical knowledge of both SAML and LFDS to even troubleshoot, and would regularly generate complicated support cases.

In your scenario of a centrally-managed enterprise Laserfiche deployment for a very large organization, you can proceed with sending a filtered group list in the IdP SAML token. You'll want to ensure the following:

  1. The AD group filter criteria for the SAML IdP is clearly documented and kept up to date
  2. A comprehensive list of Laserfiche-related AD groups is clearly documented and kept up to date
  3. Any policies or procedures your org has for setting security rights in Laserfiche on AD groups involve first checking the above documentation to validate the group is getting sent. This includes making AD groups members of LFDS Laserfiche groups.

Don't forget that you need the SAML IdP to send the AD groups in SID format.

Cheers,
Sam

3 0
replied on April 28, 2023

Why is group mapping required when configuring Linked Identity Providers?

0 0
replied on April 28, 2023

Can you provide additional context on that question?

The detailed description above seems to make the implication of not passing and mapping the group claim clear.

Your original post mentions "the Laserfiche AD groups", so presumably some of those exist. Laserfiche Directory Server needs to know which SAML attribute it should use to determine the groups it writes into the STS token. If the group claim isn't mapped, LFDS is going to produce a STS token for a Windows user that lists zero AD group membership, regardless of the AD groups they're actually in.

0 0
replied on April 28, 2023

We currently are not using AD groups for assigning licenses or for security within Laserfiche. We are currently manually adding AD accounts in LFDS and assigning them to LFDS groups. If that is the case, is group mapping required for configuring Linked Identity Providers?

The original question was based off of what was in the Help Files and the wording it uses.

0 0
replied on April 28, 2023

What are they for then?

If you're not sending any groups whatsoever (even non-AD ones), you don't "need" a group claim mapping. However, LFDS may still enforce having a group claim mapping exist because in 99.x% of cases people want to send group values. If you legitimately don't have any, you can try putting in a dummy string for the group claim mapping like "Placeholder-To-Pass-Config-Validation". This will pass the config validation check but may still result in runtime errors when LFDS attempts to parse a SAML token and doesn't find a claim it expects.

I'd recommend having Okta include a groups claim with no values, and configuring the mapping for that claim. LFDS will parse the SAML token, successfully find the group claim section, and then skip any actual mapping because there are no group values to map.

Then, if you ever decide later on to pass groups via Okta, you can easily do that without needing to change the SAML integration config on either side.

3 0
replied on May 5, 2023

First off, thank you Samuel for giving such detailed responses. I greatly appreciate it. Our AD groups are currently not synched to Okta, so passing the SIDs or LDAP Names was not an option. I have instead added a fake Claim name to satisfy the LFDS requirement for having one for Groups on the Claims tab. I was then able to setup the Linked Identity Provider successfully for one of our AD domains and successfully logged in! I still need to configure the other 9 domains, but we are making progress. Instead of worrying about using SCIM, we will work on creating AD groups and just using AD Sync until our AD groups are synched in the future.

1 0

Replies

replied on May 21, 2024 Show version history

@████████  in a post above, you note:

Don't forget that you need the SAML IdP to send the AD groups in SID format.

 

So then the LDAP Name will not work for groups?  My customers SAML provider does not contain/track/store the AD SID for users or groups.  We need a way to link SAML users to AD users with their group memberships using user UPN and group LDAP Names.

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

Sign in to reply to this post.