Kerberos authentication for SMB shares

Introduction

By default, Foldr authenticates to backend SMB file servers using NTLM. It can be configured to use Kerberos instead, on a per-share basis. This is most useful in environments where IT administrators are disabling NTLM as part of a hardening initiative.

How Foldr authenticates with Kerberos

When a share has Kerberos enabled, Foldr selects one of three authentication modes automatically based on the share’s other settings and the signed-in user. You don’t pick the mode directly; you configure the inputs and Foldr does the rest.

Mode	Selected when	Needs a vaulted user password?	Needs AD constrained delegation?
Service account (machine account)	Share has both Use Kerberos for authentication and Use machine account as service account enabled	No	No
S4U2Proxy delegation	Share has Use Kerberos for authentication enabled and the user has no vaulted password	No	Yes
Password-based	Share has Use Kerberos for authentication enabled and the user has a vaulted password	Yes	No

A short summary of each:

Service account (machine account). Foldr authenticates to the file server as itself, using the computer-account credentials in /opt/minnow/foldr/system/krb5/http.keytab. All access is performed as that account, regardless of which Foldr user is making the request. Typically combined with Use service account for all access and full ACL support so that per-user permissions are still enforced by reading the file system’s ACLs. Equivalent to the existing service-account model, but with no shared password to manage.

S4U2Proxy delegation. Foldr uses its computer account to request a Kerberos service ticket on behalf of the signed-in user, then presents that ticket to the file server. The file server sees the request as coming from the user, so per-user NTFS permissions apply directly. Removes the need to vault user passwords. Requires constrained delegation to be configured on the Foldr computer object in Active Directory (covered below).

Password-based. Standard Kerberos: Foldr uses the user’s vaulted password to obtain a TGT and a service ticket, and presents that to the file server. No special AD configuration needed beyond the realm being reachable.

Prerequisites (all modes)

• The Kerberos realm / Active Directory domain is configured in Foldr Settings > Single Sign On > Kerberos. Kerberos SSO does not need to be enabled for this feature to work, only the realm settings.
• The Foldr server has a keytab installed. The simplest way to create one is the Join Domain button in Foldr Settings > Single Sign On > Kerberos, which registers a computer object in AD and writes the keytab automatically. Alternatively, create a keytab for a dedicated service account yourself and upload it on the same tab (covered below), which avoids joining the Foldr server to the domain.
• Share paths use the file server’s hostname, either fully-qualified or short with a matching Search Domain configured in Appliance > Network. IP addresses do not work because Kerberos service tickets are bound to SPNs, which are name-based.
• The Foldr server’s clock is in sync with the domain controllers (within ~5 minutes). Time skew is the single most common cause of “ticket rejected” errors.

Enabling Kerberos on a share

1. Ensure the realm is configured in Foldr Settings > Single Sign On > Kerberos

Click Save Changes.

2. If short / non-fully-qualified share paths are being used (Active Directory home folders, or shares configured in Files & Storage with a short host), ensure a suitable Search Domain is configured in Appliance > Network

3. Ensure the SMB share is configured fully-qualified

A non-fully-qualified path may be used if a Search Domain is configured. In that case the path looks like:

smb://server/marketing

4. On the share’s Access tab in Foldr Settings > Files & Storage

5. Open the Advanced section and enable Use Kerberos for authentication

6. Optionally enable Use machine account as service account. This switches the share to the service-account mode (Foldr authenticates as itself, no per-user password and no constrained delegation needed). Typically combined with Use service account for all access and full ACL support enabled.

Click Save Changes.

The configuration is now complete. The Foldr server will authenticate against the SMB share using Kerberos instead of NTLM.

Using a service account keytab instead of joining the domain

Some organisations prefer not to create a computer account for the Foldr server. S4U2Proxy delegation also works from a keytab you build yourself against an ordinary domain service account. The steps below are run on a domain controller (or any machine with the AD admin tools and an elevated prompt).

1. Create a dedicated service account (for example svc-foldr). Don’t reuse an account that does anything else. Set the password to never expire, and tick This account supports Kerberos AES 256 bit encryption in the account options.

2. Check the account’s User Principal Name matches its account name:

Get-ADUser svc-foldr -Properties userPrincipalName

This should show [email protected]. It matters more than it looks: Active Directory derives the account’s Kerberos key from the UPN, not the account name, so if the two disagree the keytab you generate will carry the wrong key and authentication fails with “Preauthentication failed” (which reads as a wrong password, and almost never is one). If a previous ktpass run has left an SPN sitting in the UPN, correct it before generating the keytab.

3. Register an HTTP SPN for the Foldr server against the account. The SPN is required for delegation to work, and registering it also makes the Delegation tab appear on the account in Active Directory Users and Computers:

setspn -S HTTP/foldr.your.domain svc-foldr

(-S rather than -A checks the SPN isn’t already registered elsewhere; an SPN must be unique across the domain.)

4. Generate the keytab. The principal is the account name at the uppercase realm, not the HTTP SPN; an SPN-named entry can accept tickets but can never obtain one, so a keytab built around the SPN cannot perform delegation:

ktpass -princ [email protected] -mapuser [email protected] -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass * -out C:\foldr.keytab

You’ll be prompted for a new password for the account, and the keytab is written with the matching key.

5. Upload the keytab in Foldr Settings > Single Sign On > Kerberos, with the domain entered in upper case, and click Save Changes. Once installed, the tab shows the principal Foldr will authenticate as next to the Keytab installed badge; check it reads [email protected]. If your keytab holds more than one account and the wrong one is being picked, the Service principal setting selects one explicitly.

6. Configure constrained delegation on the service account, covered in the next section.

To replace an installed keytab later (a new password, a new kvno, a different account), use Replace keytab on the same tab; there’s no need to delete first. Deleting the keytab disables Kerberos and resets the realm settings with it.

One note on handling: this keytab, combined with the delegation rights below, lets whoever holds it act as any of your users against the file servers on the delegation list. Treat it like a privileged credential, keep the account dedicated to Foldr, and if you need Kerberos keytabs elsewhere (a reverse proxy, for instance) use a separate account for those rather than copying this one around.

Configuring constrained delegation (S4U2Proxy)

This step is only required if you are using S4U2Proxy mode, i.e. you have Kerberos enabled on a share, are not using the machine-account mode, and the signed-in users do not have vaulted passwords.

In Active Directory, on a domain controller (or any machine with the AD admin tools installed):

1. Open Active Directory Users and Computers.
2. Locate the account Foldr authenticates as: the Foldr server’s computer object if you joined the domain (typically the appliance hostname), or the service account if you uploaded your own keytab. The Kerberos tab in Foldr Settings > Single Sign On shows the principal in use next to the Keytab installed badge.
3. Right-click and choose Properties, then the Delegation tab. (On a service account the Delegation tab only appears once the account has an SPN registered; see the previous section.)
4. Select Trust this computer for delegation to specified services only (Trust this user… on a service account).
5. Select Use any authentication protocol. This is the setting Windows calls protocol transition, and it’s required: Foldr requests tickets on the user’s behalf without ever holding the user’s own ticket, which Use Kerberos only does not permit.
6. Click Add…, browse to each file server’s computer account, and choose the cifs service.
7. Repeat for every file server that hosts a share where Foldr should authenticate via S4U2Proxy.

If you add a new file server to Foldr later, remember to extend this list, or that server will reject S4U2Proxy ticket requests.

A short way to check the configuration is in place: from any machine with setspn available, run

setspn -L <foldr-computer-name>

and confirm that cifs/<file-server-fqdn> appears in the allowed-to-delegate-to list (visible in PowerShell via Get-ADComputer <foldr> -Properties msDS-AllowedToDelegateTo, or Get-ADUser for a service account).

Verifying

The quickest functional check is to browse to a Kerberos-enabled share and confirm the file listing loads. If it does, authentication has succeeded somehow (Kerberos or, in some misconfigured edge cases, fallback to NTLM).

To confirm exactly which path was used, enable SMB request logging by setting app.integrations.smb.log-requests to true in Foldr Settings > General. The Foldr log will then include lines such as:

• SMB auth: ... krb5_share=yes machine_account=yes ... (service-account mode)
• Krb5 machine account auth: principal=... (service-account mode confirmed)
• S4U2Proxy delegation: [email protected] target=cifs/[email protected] service=... (S4U2Proxy mode)
• SMB krb5: using password-based Krb5Auth (user has stored password) (password mode)

Disable the logging once you’ve confirmed the setup. SMB request logging is verbose and not intended for ongoing production use.

Troubleshooting

Clock skew too great. The Foldr server’s clock differs from the KDC by more than ~5 minutes. Sync the appliance time (NTP or a configured time source on Appliance > General) and retry.

Server not found in Kerberos database. The target file server doesn’t have a CIFS SPN registered, or the share is configured with a short hostname with no Search Domain to expand it. Check that the file server’s computer object has cifs/<fqdn> in its servicePrincipalName attribute, and that the Foldr share path uses a name (not an IP).

KDC has no support for encryption type. The Foldr keytab uses encryption types your domain controllers no longer accept (or vice versa). Re-join the domain from the Kerberos tab, which negotiates current types with the DC, or regenerate your service account keytab with AES256 as shown above.

Preauthentication failed. The key in the keytab doesn’t match the key the account holds, and despite what the message suggests, the password is rarely the culprit. Active Directory derives a user account’s key from its User Principal Name rather than its account name, so a keytab built while the two disagreed carries the wrong key even with a matching kvno. Check the account’s UPN matches its name (step 2 above) and regenerate the keytab.

Client not found in Kerberos database. The principal Foldr is authenticating as isn’t one AD can issue a ticket to, most often because the keytab was built around an SPN (HTTP/...) rather than the account’s own name. Rebuild the keytab with the account name as the principal, keeping the SPN registered on the account.

S4U2Proxy: no valid TGT / cannot delegate. The account Foldr authenticates as is missing constrained delegation entries for the target file server’s CIFS service, or is set to Use Kerberos only rather than Use any authentication protocol. See the section above.

Delegation works for most users but fails for some. Members of the Protected Users group, and accounts with Account is sensitive and cannot be delegated set, cannot be impersonated by design. Domain admins commonly fall into this category, so test with a standard user account.

Falling back to NTLM unexpectedly. Check the SMB request log lines. If you see Kerberos-related errors, those rows tell you which mode failed and why. If you see NTLM in use without the Kerberos toggle being enabled, double-check the share’s Advanced tab.