Laserfiche 12 and Windows Authentication

SELECTED ANSWER

replied on November 7, 2024

I opened a support case on this and were able to resolve the issue locally (i.e. client and server on same machine) by reattaching the repository using the FQDN.

However the issue persisted on remote desktop clients until I changed the service account of the LFS 12 service to use a domain account (it was previously a local admin service account). Not sure at this stage if this is a requirement.

0 0

View 1 previous reply

replied on November 7, 2024 • Show version history

This is a Kerberos error behind the scenes. Were you using an aliased name for the Laserfiche Repository Server FQDN?

If so, to use an alias when running the Repository Server service as built-in service account (Local System, Network Service), you need to set a Computer Name Alias to get the right Kerberos SPNs in place for Windows authentication from remote machines to work. See: Using Computer Name Aliases in place of DNS CNAME Records | Microsoft Community Hub

The Computer Name Alias guidance applies to any Laserfiche service running as a built-in account that a client with authenticate to with Kerberos Windows Authentication.

1 0

replied on July 18

Hi Sam. Our VAR recently upgraded our Laserfiche servers to version 12. We have Directory Server and a repository installed on SERVER01. The Windows Authentication on the Desktop Client works when connecting to SERVER01. We have another server, SERVER02, that doesn't allow us to connect with Windows Authentication post-upgrade. It was working prior to the upgrade.

Our VAR through in another variable because we used to have our Laserfiche service running on a domain account. However, they switched it to run under the Local System account during the upgrade because that was the best practice recommended by Laserfiche.

The other weird thing is that Windows Authentication seems to work when connecting to both servers from the client for my account but not for any other users. I am a full admin on both servers. Is there any settings that I can check or Kerberos troubleshooting steps that you can recommend. I don't want to blindly start trying things.

0 0

replied on July 18

Hi Rob,

I'm out on vacation this week but flagged this to look at again on my return. I'd recommend starting by switching the service identity back to the prior domain account as a diagnostic test. See if the behavior changes with that variable. If it does, how? That's valuable information for the root cause. Check what SPNs exist for the domain account as well - that might provide a useful point of comparison for the machine SPNs.

If you're accessing either server at any address that's anything other than its fully qualified domain name (FQDN), you need to set a Computer Name Alias for it if you're running services as built-in accounts like Local System/Network Service/Local Service. See: Using Computer Name Aliases in place of DNS CNAME Records | Microsoft Community Hub.

0 0

replied on July 24

This issue has finally been resolved. Our VAR worked with Laserfiche Support. I believe that the licensing needed to be reapplied. When I was trying to diagnose, I noticed that the LF.licx file in C:\Program Files\Laserfiche\Server seemed to missing a section that was present in that file on the servers that were working correctly. The section was NamedObjects, which looks like it stores Usernames and License types. So maybe usernames need to get populated into that file from Directory Server for Windows Auth to work??

0 0

Question

Question

Laserfiche 12 and Windows Authentication

Answer

Replies

Sign in to reply to this post.