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

Question

Question

NTLM & Kerberos Login Breaks if CNAME of Laserfiche Server is Used in Web Access

WebLink Version 10
Updated July 23, 2021
asked on March 7, 2019 • Show version history

Hello,

I have a problem that occurs when setting up the repository connection. The Web Client server is part of an F5 load balancer, so is given an alias on the DNS server.  The LF Repository server also has an alias.

For the sake of this post:

  • The Web's host names are "00002.local" and "00003.local," and the CNAME is "web.local"
  • The LF host's name is "00001.local" and the CNAME is "lf.local"

 

Each server has a certificate issued in the CNAME for that server.

Here is an example of a working configuration:

Web Server Repository: server - 00001.local, repository - myrepo, SSL - No

Services: Laserfiche Web Client Host URL - https://web.local/laserfiche

Here is an example of a NON working configuration:

Web Server Repository: server - lf.local, repository - myrepo, SSL - No (or Yes, both fail)

Services: Laserfiche Web Client Host URL - https://web.local/laserfiche

 

So it seems that using an CNAME might be an issue.

Any thoughts?

 

1 0

Replies

replied on November 2, 2020 • Show version history

I just ran into this. All other services were required to be updated to use the subject name of the SSL certificate when the Laserfiche Server service was switched to allow SSL, even if they were not connecting with SSL, which is illogical to me.

We updated the Web Client thinking it was also a requirement there (turns out it is not, you can use localhost when not making SSL connections)

However using the subject name for a certificate causes all domain users to be told their password is invalid, which is not true. Why would it say the password is invalid, unless the domain controller states that specifically.

Also how is it that Forms is able to connect to the repository using the subject name without any problems logging in?

We found this post which saved the day! as we would have never known that you must use localhost or machine name or IP address to connect the web client because we were sure that the password must be wrong if the domain controller said so.

1 0
replied on July 23, 2021

Yeah, why????

0 0
replied on July 23, 2021 • Show version history

Also, you're welcome. Are you also using F5 or some other load-balancer?

0 0
replied on March 7, 2019

What kind of Windows authentication are you using?  Integrated, or user types their credentials in to the web client login dialog?  When you say it breaks, that means LFS returns an access denied error?

"Each server has a certificate issued" refers to an SSL certificate?

And just to be clear, the only difference between the case that works and doesn't is the hostname you use for LFS when you configure the repository in the web client configuration?

0 0
View 5 previous replies
replied on March 7, 2019 • Show version history

Hi Brian,

I think I see what your asking.

The LFS and WebAccess installations are on the same box.

With the CNAME configured, Kerberos and NTLM both fail. When I type the domain\uname and password, I get the error: "The user name or password is incorrect."

Kerberos just stares blankly at me.

Yes, I'm referring to an SSL cert. However, for my testing I've tried with and without SSL enabled, when using the CNAME (the SSL is issued to the CNAME not the host name).

And yes, that's the only difference. When I use the hostname, not the cname, Kerberos and NTLM work.

I don't have any issues with the fat client and clicking "use windows auth" works.

In all cases, repository logins work with the web client.

0 0
replied on March 7, 2019 • Show version history
Laserfiche Web Client
10.3 (10.3.1.51)
Laserfiche Repository Access
10.3.0.242
 

This is the trace for the integrated login. 

stack trace:
  Laserfiche.WebAccess.Common.Util.ErrorHandler.LogException
  Laserfiche.WebAccess.Common.Util.ErrorHandler.Standardize
  Laserfiche.WebAccess.Common.<>c__DisplayClass46_0.<CheckConnectedInternal>b__1
  Web.Util.SingleComputationLock.Synchronize
Exception details:
  Message: Access denied. [9013]
  Stack trace:    at Laserfiche.RepositoryAccess.Session.SendLogInRequest(String idnRepName, HttpCredential credentials)
   at Laserfiche.RepositoryAccess.Session.LoginToServer(RepositoryRegistration repository, HttpCredential credentials)
   at Laserfiche.WebAccess.Common.ConnectionManager.AuthenticateSessionWithWindowsId(Session sess, RepositoryRegistration repoReg, WindowsIdentity winId)
   at Laserfiche.WebAccess.Common.ConnectionManager.AutoLogon(String repoName, HttpContext context, Boolean forceLogin, WARepository waRepo)
   at Laserfiche.WebAccess.Common.ConnectionManager.<>c__DisplayClass46_0.<CheckConnectedInternal>b__1()

0 0
replied on March 8, 2019

Load balancers really complicate Kerberos.  The browser sees the one host name, which it uses to construct an SPN for which to request a Kerberos ticket, but that ticket isn't used on the load balancer, it is passed on to a Web Access machine.  F5 has an article that might be helpful: https://devcentral.f5.com/articles/kerberos-is-easy-part-1

I'm still hazy on your setup though.  You say that "LFS and Web Access installations are on the same box", but how does that fit with the load balancer?  For the dns, it's really getting away from my areas of expertise, but I'm imagining something like:

lf.local A w.x.y.z

00001.local CNAME lf.local

But I'm not sure, are you saying that the second one is also an A record?  I think 2 A records would cause a similar problem to what I described earlier - the SPN that's constructed will no longer be correct.  See https://help.k2.com/kb001151 .

0 0
replied on March 8, 2019

And I meant to also say, SSO with LFDS avoids all of the complications of Kerberos.

0 0
replied on March 8, 2019 • Show version history

Hi Brian,

Thanks for that. I'll look into it. 

I didn't explain very clearly.

The PROD environment will have two web servers (behind F5) and a third server for the repository. Both web servers share the same CNAME and the repository server has an CNAME. Forget my examples above, it's more like web.prod.com and lfs.prod.com.

The DEV environment uses a single server (so single-hop) and isn't behind the F5. There are multiple CNAMEs though. The DEV server can be addressed as web.dev.com or lfs.dev.com.

Never-the-less, I wonder why NTLM doesn't work when I use the CNAME (lfs.dev.com) in the repository config page of Web Access. 

We can't upgrade to to take advantage of SSO just now. But I wish we could!

0 0
replied on March 8, 2019 • Show version history

Also, I realise I've calling the alias "ANAME" when I should have said "CNAME." I've just updated my posts.

0 0
replied on March 13, 2019

Hi Brian, any further thoughts?

0 0
replied on March 14, 2019

No, I don't know why impersonating to LFS would fail or succeed depending on the host name used.

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

Sign in to reply to this post.

Details
Related Posts
Loading ...