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

Question

Question

LFDS Certificate Requirements

Directory Server
Updated December 10, 2019
asked on December 6, 2019 • Show version history

We have a client that is implementing LFDS and will be using SSO with Forms and the Web Client.

We had a conversation with them about Certificates, internal CA vs 3rd Party vs self-signed. The question came up that since their AD domain is something to the effect of domain.local, could they just add internal DNS entries so that company.org resolves internally, could they not just get a wild card cert for company.org and have that work with LFDS?

The reason I ask is because we had a recent support case open and were told that the certificate had to have the FQDN of the LFDS server, but I cannot find any requirements for the LFDS cert.

0 0

Replies

replied on December 9, 2019

We have found that the browsers are very sensitive to the server name as defined in the certificate, so I don't think the wildcard + DNS idea will work.  That said, the certificate could be self-signed, since you are only working internally.  FQDN is correct, in the form, server.domain.com.

0 0
View 1 previous reply
replied on December 9, 2019

Bill, thank you for your reply. We are trying to avoid a self-signed cert so the client doesn't have to push it out using group policy since they will be using SSO.

0 0
replied on December 9, 2019

Hi Blake,

First, I am assuming you're asking about the certificate requirements for the LFDSSTS IIS site, not the backend certificate-based "alternate binding" between LFDS and LFDSSTS.

The customer should do the following:

  1. Issue a SAN certificate from their AD Certificate Authority (CA) for the desired hostname (e.g. lfsso.company.org). SAN certificates are more secure than wildcard certificates and no more difficult to create. Correctly generated wildcard certs do work though.
  2. Install the certificate in the LFDS server's local machine certificate store (Personal or WebHosting). This step may happen automatically depending on the certificate provisioning process.
  3. Bind the certificate to HTTPS/443 in IIS.
  4. Create an internal DNS CNAME record for lfsso.company.org pointing at the LFDS server FQDN (e.g. lfsso.domain.local).

 

Important Note: The Laserfiche web applications you want to use LFDS SSO with must have a similar setup with *.company.org DNS names. If their hostnames have separate domains, you may get an infinite auth redirect issue do to mismatched cookie locations. In short, LFDSSTS will place its token in the company.org cookie jar while the other web apps check for it in the domain.local cookie jar. They won't find it there and will redirect back to LFDSSTS, which see that it has issued an auth token and sends the user back to the web app, repeating the cycle.

2 0
replied on December 10, 2019

Thank you for that Samuel. I am guessing your Important Note is referring to internal LF web applications using LFDS SSO and not in a DMZ since the DMZ would use the alternate binding, correct?

0 0
replied on December 10, 2019 • Show version history

Hey Blake,

Yes and no. The alternate binding is only for authentication between the LFDSSTS web application and the LFDS service. It's a way for the two components to perform a sort of auth handshake when AD-based methods are not available. If there is a DMZ AD domain which has a two-way trust with the internal domain, you don't need the alternate binding at all as the native AD-based auth will still work.

The alternate binding has no effect whatsoever on what goes on in a user's browser, aside from Windows Auth being unavailable.

I would generalize the note as "Users accessing Laserfiche web applications must authenticate to an LFDSSTS instance accessible at the same domain as those web applications."

Where 'domain' means the domain portion of a URL, not AD domain. Obviously does not apply to Forms Portal and WebLink Public Portal DMZ scenarios where users do not authenticate.

E.g.:

forms.company.org -> lfdssts.company.org

forms.companydmz.com -> lfdssts.companydmz.com

 

Hope that helps clarify.

Cheers,

Sam

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

Sign in to reply to this post.

Details
Related Posts
Loading ...