Updated Kerberos documentation

replied on October 23, 2024 • Show version history

BY FAR the cleanest way to handle Kerberos anything in a fresh Windows Server 2022 installation is:

Run Laserfiche applications as built-in service accounts (Network Service, Local System, default IISAppPoolIdentities, etc.). Use dedicated SQL login accounts (not "sa" please) with the db_owner database-level role in SQL Server (Microsoft Learn) for SQL connections.
Use Computer Name Aliases in place of DNS CNAME Records (Microsoft Community Hub) for any and all friendly names/aliases. These set DNS records and all necessary Kerberos SPNs and settings (for the built-in machine accounts) in a single operation.

That's it. Those are the steps. You can ignore the entire Kerberos white paper if you just do that instead.

"But what if we have a Kerberos 'double-hop' scenario?" you might ask.

Change your design so you don't have one. No better time than a clean deployment.

The most common reasons for needing that in the past were either:

Using Windows Authentication with Web Client or Forms directly (not through Directory Server)
1. This is effectively obsolete with Directory Server. Use Windows Authentication through LFDSSTS instead.
Using Windows Authentication with a remote LFDSSTS instance, where the double-hop was between the LFDSSTS IIS web app and the LFDS Windows service on a different machine.
1. Either (a) set up a SAML Linked Provider so users can log into the remote LFDSSTS instance as their Windows user identities using an Entra/Okta/etc. SAML logins do not involve Kerberos. Or (b) still use Windows authentication but direct users to the LFDSSTS instance on the same machine as the LFDS service, so there's no Kerberos double-hop.

0 0

replied on October 24, 2024

I'm not sure that's going to work for us - our volume files are stored on a network file share so we can't use Local System as the account for our Laserfiche Server service and if I try to use Network Service the LFS.exe service won't start.

0 0

replied on October 24, 2024 • Show version history

Note: Edited to emphasize the security implications of the information here. We do not recommend granting repository volume file access rights to an AD Computer object as that grants volume access to every process running on that machine. It's a privilege/access escalation attack path that's best to avoid.

Managed Service Accounts do not have this issue, and we (and Microsoft) recommend their use over AD User type service accounts in most scenarios where an AD service account is needed.

----

Ah, but you can, even though you shouldn't for security reasons. Local System (and Network Service and IIS AppPoolIdentity) authenticate to network resources as the AD Computer trustee.

When you go to set permissions on the file server directory, the trustee selector's Object Type filter defaults to "Users, Groups, or Built-in security principals".

If you select "Object Types", you can add the "Computers" type to the search filter. After which, you can search and add the machine by hostname. Again, note that this gives the whole computer (all processes on it) to the specified directories.

Same deal if you want to use any type of Managed Service Account, you need to select the "Service Accounts" type.

If you use a gMSA/dMSA Service Account on the machine hosting, Laserfiche Repository Server, it will automatically set the SPNs necessary for that Service Account on that machine, when using the true machine FQDN and not an alias. I believe you'd have to set SPNs manually if using an aliased name and Service Account together.

Managed Service Accounts are great. Use them instead of AD "User" type service accounts for most scenarios.

0 0

Question

Question

Replies

Sign in to reply to this post.