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

Question

Question

AzureAD and AD accounts

asked on February 27, 2020

We have a customer that has their local AD linked to AzureAD (updating the password of one updates both)  and are logging into their Office365 products with AzureAD when out of the office.  They would like to set up Laserfiche so that when the users are in the office, they log in using AD authentication and when out of the office, they use AzureAD authentication.  As we tested, it looks like in LFDS, the AzureAD (SAML) accounts are separate from the AD accounts and if a user logs in using AzureAD, they are not linked to any AD groups to pick up security.

Is there any way to configure this so that they would not have to recreate all the security and user accounts to utilize SAML authentication?

0 0

Answer

SELECTED ANSWER
replied on February 27, 2020

Hi Bert,

This sounds like a job for LFDS 10.4.3's Proxied Providers feature. Under your SAML IdP's tab in Settings > Identity Providers, you will see the Proxied Providers tab. There you can choose your AD IdP of interest, type in the chosen identifying attribute value that will be received via the SAML response, and specify the format of that identifying attribute.

From there, whenever an AD user logs into LFDS via AD authentication or SAML authentication, they will be signed in to the AD account in LFDS (no SAML accounts in LFDS will be needed for AD users).

3 0

Replies

replied on February 27, 2020

That is exactly what they want.  But we need to know what to enter for the Identifying Atribute and the Atribute Format.  How do we find out what these should be for their environment?

0 0
replied on February 27, 2020

This is determined by the SAML provider. You can either find this out by looking at the SAML provider's configuration or by intercepting the SAMLResponse generated for a SAML login to find the attribute name and format (the SAMLResponse is base64 encoded).

For example, if you looked at a user's SAMLResponse and saw this:

<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/sid">

    <AttributeValue>S-1-1-11-1111111111-11111111-111111111-11111</AttributeValue>

You would then use "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/sid" as the identifying attribute and "AD SID" as the attribute format.

4 0
replied on February 28, 2020

This was not very intuitive and have very little in the way of understandable documentation, but between Chrome and FireFox, we were able to locate the SAMLResponse and see the Attributes.  We found that the SID was not included, so we had to go to the Azure app and add the claim mapping.

Once the users SID was included in the attributes, we tried to add the Proxied Provider Settings, only to get an error that the Claim Group mapping had to be completed.  Again, the Group(s) were not included in the attributes, so we had to go back to our Azure app and add them (making sure to switch it to Security Identifier).  We then added the Group mapping along with any other attributes that we had, and then we could finally add the Proxied Provider Settings.  Once this was completed, we removed the SAML account that we were testing with (it still had its AD account in place) and logged in with SAML but using the AD account.

Thank you Chase for your help, but this needs to be much better documented and explained.  The current help file may as well be in a foreign language because it did not provide any help at all.

3 0
replied on March 2, 2020

Sorry about that Bert, we're working on the documentation currently and hope to have much clearer instructions soon.

0 0
replied on January 24

@████████, when including the Groups in the claim, did you have to include all groups or does it still work if you only include specific groups?

Also, what role does the Group Claim play in the Linked Identity Providers?

0 0
replied on January 25

@████████ in Linked Identity Provider in Laserfiche Directory Server, it notes:

It appears that for some reason, the "Linking" of SALM accounts to AD accounts requires all groups to complete the link.

1 0
replied on January 25 Show version history

Thank you, Bert. I must have missed that Note when I was reviewing everything.

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

Sign in to reply to this post.