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

Question

Question

identifying attribute in LFDS Proxied Providers dab

Directory Server Version 10 How To
Updated January 20, 2023
asked on April 9, 2020

Hello,

 

I am working to get SAML configured and we have made lots of progress but we are unsure which attribute we are supposed to reference in this portion of the configuration. I reviewed the documentation, but could not find an answer to this.

 

https://www.laserfiche.com/support/webhelp/Laserfiche/10/en-US/administration/#../Subsystems/LFDS/Content/ProxiedProviders.htm%3FTocPath%3DDirectory%2520Server%7CConfiguring%2520Licensing%2520Site%2520Settings%7CIdentity%2520Providers%2520%7CSAML%2520Identity%2520Provider%7C_____2

 

 

1 0

Replies

replied on April 9, 2020

I went through this configuration as well.  My notes are in AzureAD and AD accounts. Hope this helps, because most likely, you will have to go to Azure and add the Attribute(s).

3 0
replied on April 9, 2020 • Show version history

That section is only required if you are trying to have AD users that are already registered in LFDS start authenticating through this SAML provider instead of using Windows Authentication. Is that what your goal is here?

If so, can you share what part of the instructions you are stuck on?

 

The relevant section:

Add the Identity Provider, Identifying Attribute, and Attribute Format. Once finished, click Save. See the image below for an example.

  1. Identity Provider: Choose an AD or LDAP identity provider.
  2. Identifying Attribute: Make sure that the incoming SAML token contains the identifying attribute specified.

    Note: All Active Directory (AD) or LDAP groups must be included on the SAML token or their membership will be ignored.

    Note: Active Directory (AD) providers only support AD SIDs as a plain text string or Base-64 encoded.

  3. Attribute Format: Select an attribute format from the drop-down menu.

    Note: The SAML provider determines the Identifying Attribute and the Attribute Format. You can find this by looking at the SAML provider's configuration or intercepting the SAML Response generated for a SAML log-in to find the attribute name and format. The SAMLResponse is Base64 encoded. To learn more, navigate to Intercepting the SAML Response.

 

To paraphrase, the SAML token needs to include the SID for the AD user (or DN for LDAP), and the identifying attribute with that SID is something the SAML administrator should already know (because the SAML administrator must configure it), but you can also look at the token to verify on the linked page, Intercepting the SAML Response.

 

I've also attached a powerpoint presentation from my identity management class at Empower, which talks about SAML starting on slide 31. (larger pictures, animations, etc. have been removed to make it fit as an attachment)

IT Admin 304 Advanced Topics in Identity Management_trimmed.pptx (1.63 MB)
Download
1 0
View 9 previous replies
replied on April 9, 2020

From Drew's post, I believe his question is what should be used in the Identity Attribute?

0 0
replied on April 9, 2020 • Show version history

Yes, which is what those steps are intended to answer, so I'm trying to understand what part isn't coming across well. The Identity Attribute should be the name of the attribute where the SID will be found on the incoming SAML token. 

Is the confusion how to find the name of the attribute within the SAML token? The name should be used exactly as it appears in the SAML token and the element is called 'Name' (not 'Friendly Name').

If that's the issue, take a look at the attached PowerPoint (or Bert's linked post and see if either helps. if so, I can make a request to expand the help files with whatever you find helpful from the PowerPoint.

0 0
replied on April 9, 2020

I think what you said in your first paragraph is what we were looking for, "The Identity Attribute should be the name of the attribute where the SID will be found on the incoming SAML token." The documentation does not specify that information. Thank you!

replied on April 9, 2020

Update: I have filed a documentation update request to include the following information, based on Bert's post and the confusion here.

  • A note that the SAML provider may require additional configuration to provide the AD SID
  • More clearly state that the "Identifying Attribute" refers to the name of the attribute as found on the SAML token
  • An excerpt of a SAML token
0 0
replied on April 14, 2020

Brianna, the confusion was answered by your post where you said, "To paraphrase, the SAML token needs to include the SID for the AD user (or DN for LDAP)". It was not clear as to what value was expected. We now know for AD it is expecting the SID.

1 0
replied on April 15, 2020

Hello Brianna,

 

Thank You for the responses to this thread. Unfortunately we are still having issues with the configuration. I am gathering the information on the current issue and will post that soon.

 

Regards,

0 0
replied on April 16, 2020 • Show version history

Edit: We discovered that some proxied authentication for the default IDP can fail, but currently believe it is limited to new functionality not yet released.- some directories will fail when privileged credentials are not specified and the application is running as network service.

If you have verified using the troubleshooting tools that the incoming SAML token (1) has the corresponding attribute name  and (2) the value of the attribute aligns with the users AD SID (either base62 encoded or plan string), you could try either adding credentials to your main IdP or creating a dummy AD IdP to see whether that resolves the issue. I will update this thread once we have narrowed down the potential issue/additional configuration requirements.

2 0
replied on April 21, 2020

Hello Brianna,

 

I met with the client and their SSO provider today and we have read through this and confirmed all the steps. When a user tries to login they are still receiving the message that they do not have a license to access Forms. Attribute is ADSID and attribute format is AD SID. when we ran a trace we found the values are passing but we thing the SID value may not be matching.

 

- They are using ADSID binary field. Previously they were using a string value, receiving a character error. That is not the case now.

 

- They are passing the object SID of the individual AD account. Is there a way to cross check this to see if there is a discrepancy?

 

0 0
replied on April 21, 2020 • Show version history

I just wanted to post our findings from this morning. We are the client MCCI is helping on this issue.

"The first attempt during our web conf today was simply Bianary Field in PortalGaurd attached as a text file.

The second config from Portalguard was the same text other then the AD SID attribute was set as “Binary Field (As SID)”.

<AttributeValue>S-1-5-21-1820287346-570170541-2003004241-11468</AttributeValue>

I confirmed that this value matches the account that was used in AD."

 

SAMLTextOutput.txt (16.9 KB)
Download
1 0
replied on April 21, 2020

In your SAMLTextOutput.txt file, you have 2 ADSID attributes.  The first one lists multiple SIDs and the second is not in a SID format (may be encrypted or something).  You need a Single SID attribute with a single SID value.

1 0
replied on April 21, 2020 • Show version history

To add to what Bert said, the first ADSID attribute appears to be the same list of SIDs as your group list under the group attribute.

The second, single-valued attribute may be a Base 64 encoded SID, which LFDS does support. If you can remove the first attribute with all the group SIDs, you can try using the AD SID Base 64 option in LFDS to decode it.

Note that using a standard Base 64 decode option doesn't work for AD SIDs; you need to use the C# library for security handling to decode, so manually decoding is challenging.

If you are on the latest version of LFDS, the "claimstest" page is exposed by default and can show you what LFDS thinks your SID is in plaintext after you log in

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

Thank you both for your replies.  The text provided was merely an example of what we have tried.  I should have clarified that.  We've tried single SID values in multiple formats and are still unable to get this working.  What we feel our issue is at this point is that we don't understand which SID Laserfiche is actually asking for.  AD has multiple SIDs we can use, but every one one we have tried hasn't done the trick. We have tried supplying multiple and single SIDs in the string and we typically always get the same error.  Any further insight here would be appreciated.

0 0
replied on April 22, 2020

LFDS is looking for the AD SID for the individual user that is trying to authenticate. Note that the user must already exist in the selected AD provider for this to work.

The format must be either plain text (will start with S-1-5- then have a long string of numbers after) or base 64 encoded (I believe the second attribute you showed was base 64 encoded). The format sent over must match the format selected in the LFDS UI you originally posted.

I am confused by the statement " AD has multiple SIDs we can use": a user in Active Directory, by definition, only has one SID. The long list of other SIDs shown in that token appear to be groups that the user belongs to, not the user's SID.

To see what SID LFDS has stored for the user, you can export the user list from within LFDS. The resulting CSV file will include the user's SID as plain text.

If you want to see the base 64 encoded string, we store that in the LFDS SQL database.

What Bert was noting is that, even if one of the values provided was correct,  multiple ADSID attributes on a SAML token means it will not work. It must be a unique attribute on the token, so you cannot send over multiple different formats/options to try them all out at once.

If this information does not help you resolve the issue, I recommend opening a support case through your reseller for troubleshooting specific to your setup.

1 0
replied on January 20, 2023

Hi Drew,

 

Do you happen to have information on configuring PortalGuard SAML with LFDS?

 

Thanks.

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

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...