Kerberos authentication

In this section:

• Prerequisites for Kerberos authentication
• Configure Kerberos in the File Director Admin console
• Kerberos Constrained Delegation
• Web client secondary authentication

Kerberos authentication for single sign-on (SSO) maintain the client's authentication credentials over the two-stage connections required:

• Between the Windows client and the appliance
• Between the appliance and the File Server.

Prerequisites for Kerberos authentication

These prerequisites are only required for configuring Windows Client Kerberos SSO.
Reverse DNS lookup must be enabled for the file server.

In order to use Kerberos authentication against the File Director appliance, Active Directory needs to be configured with a user that allows:

1. The Kerberos keytab to be acquired from a user account so the server can trust the authorized user to access it.
2. Preauthentication checks.
3. Kerberos Ticket Granting services, which are part of Active Directory, to determine the ‘service principal’ used to access the File Director appliance and obtain a ticket to establish an authorized connection to the File Director appliance.
4. The re-use of service tickets sent to the platform so that the service can access data upon the user’s behalf (Kerberos Unconstrained Delegation). This is required if setting up Kerberos on the client.

To perform the setup, complete the following steps:

1. Create a user account in Active Directory for this purpose and set a password to be used by the appliance to perform actions A and B. It is recommended that this account is not an admin account.

2. Set the account so that the password cannot be changed and never expires. This is recommended  because it removes the need to reconfigure the platform to use new credentials.

3. Ensure DNS references the File Director server and always use the full DNS name to access the File Director server in the future.
   

4. You must also ensure DNS reverse references are set up for the SMB file server. Confirm that the file server name can be resolved by IP address.

   DNS should be an A record that points to either the File Director appliance or, in the case of a clustered environment, the NLB VIP. A CNAME record can be used by clients as the server address, but the SPN must be registered against the A record.

5. Take the DNS name and use the setspn tool from a domain controller to add HTTP Kerberos service principals that match the DNS name to the user account.

   For example, if the user account is called ‘fdpreauth’ and the DNS name that will be used to access the user account is ‘fd.mycompany.com’, issue the following setspn commands on a domain controller and ensure they run error free:

   setspn -S http/fd.mycompany.com fdpreauth

   If the client endpoints point to a DNS CNAME address that references an A record, the SPN needs to be registered against the A record rather than the CNAME.

   Following step 4, a new Delegation tab appears in Active Directory Users and Computers associated with the user account. This tab is used to allow the Kerberos Ticket Granting server in AD to locate the key information associated with the user account and allow a token to be returned to the client system to access the File Director appliance.

6. Select the Delegation tab for the preauthenticated user and select Trust this user for delegation to any service (Kerberos only). The File Director appliance has authorization to use the Kerberos ticket forwarded to it by the File Director client or web browser so that it can reuse the user identity to access file service resources.

The process describes how to configure File Director for Kerberos Unconstrained Delegation. If you are using Credential Guard on a Windows 10 client, you need to configure Kerberos Constrained Delegation.

Configure Kerberos in the File Director Admin console

This process describes how to configure the File Director Admin console for Kerberos authentication.

Kerberos Realm

1. In the File Director web Admin console, select Configuration > Kerberos.

2. Click Add Realm.

   The Add/Edit Kerberos Realm dialog displays.

   

3. In the Domain field, enter the default domain name.

4. Enter the fully qualified domain name of the domain Key Distribution Center (Primary KDC). This is usually the same DNS as the Active Directory controller.

   If you are unsure of the KDC name, use nslookup _kerberos._tcp.<domainFQDN> from a domain-joined client to get the IP of the KDC. The use ping -a <ip address> to get the name of the KDC.

   Optionally, enter the domain name of your Backup KDC.
   In the event that your primary server is offline, the appliance will automatically use the backup for Kerberos authentication.

5. Click OK.

   Details of the realm are added to the Kerberos section of the screen. The name of the realm is automatically added. Realm names are case sensitive and are usually the same as the domain name in upper-case letters.

   

6. Repeat steps 2 to 6 for all relevant realms. This ensures successful authentication to all shares added as map points.
7. Click Save.

Kerberos Token Size

Set the maximum token size for users in your environment. The default value is 12k and this can be increased up to 64k to accommodate users with large tokens.

Setting the token size too large can have a effect on performance. For more information about checking the size of tokens, see blogs.technet.microsoft.com/askds/2007/11/02/whats-in-a-token/.

Kerberos Preauthentication

This setting is required when configuring encryption for Kerberos from the client. A preauthentication user is not required for username and password authentication.

Select Configuration > Kerberos.

In the Kerberos Preauthentication section, enter the username and password for the preauthentication user.

When configuring the preauthentication account in the File Director admin console, ensure the correct default domain is used. The username for this account must include the relevant realm name and can be entered as username or username@REALM. This is the preferred format where multiple domains are configured. Note that the realm must be entered in uppercase.

Example:

[email protected]

Only one preauthentication user can be added. See the prerequisites for details about setting up this user.

Test Kerberos credentials (2021.1)

A functionality test allows you to quickly validate the Kerberos authentication credentials entered.

1.Click Test.

2.Connectivity and validation is immediately performed, and test results are displayed:

•A successful test is confirmed within the dialog.

•If the test is unsuccessful, a Kerberos Connection Test Failure message is displayed.
Where possible, this identifies the reason for the failure, and provides technical details.

Kerberos constrained delegation

Credential Guard was introduced in Windows 10 Enterprise and uses virtualization-based security to isolate NTLM password hashes, Kerberos Ticket Granting Tickets, and credentials stored by applications as domain credentials - all so that only privileged system software can access them. File Director supports cross-realm Kerberos constrained delegation, where users/endpoints are in different domains to the storage and preauthentication account.

If Credential Guard is enabled on a Windows 10 client, users' ticket granting ticket is not forwarded to the File Director server and the File Director server fails to authenticate the user. Enabling Kerberos Constrained Delegation allows the File Director server to create a ticket on behalf of the user. Preauthentication accounts must use constrained delegation with any protocol, to enable Windows server support for MS-S4U.

Environments

Kerberos Constrained Delegation has been tested in the following environments:

Users, endpoints and preauthentication account and storage in the same domain

Users and endpoints in example.com, file servers and preauthentication in trusted child domain child.example.com

File servers and preauthentication example.com with users and endpoints in trusted child domain child.example.com

Users and endpoints in forest users.net with file servers and preauthentication account in forest resources.net

For the configuration below, Active Directory must be setup in a 2-way transitive forest trust to allow Kerberos tickets to be utilized across realms.

Installing Credential Guard to support Kerberos constrained delegation

Prerequisites

• Microsoft require that the domain/forest functional level be at least 2003 in order to support Protocol Transition.
• If the users and resources are in different forests, there must be a 2-way transitive forest trust configured. The Forests should be configured to support Kerberos constrained delegation/protocol transition. This may require the deployment of a Forest search order policy if not already present - see Configure Kerberos Forest Search Order (KFSO).
• If the users and resources are in different domains, there must be a 2-way transitive trust relationship established.

• The maximum Kerberos token size must be ascertained and configured in the Admin console. For more information, see blogs.technet.microsoft.com/askds/2007/11/02/whats-in-a-token/

  base64 encoding adds around a third extra overhead to the actual size of the token - be sure to allow for this when configuring the maximum size.

• Clock accuracy must be ensured on endpoints, appliances, File servers and domain controllers (see also NTP in Advanced Configuration).
• The SPN (Service Principal Name) used by File Director clients must point to a DNS A record, not a CNAME
• Kerberos AES128 encryption must be allowed in KDC policy (as per default)
• Endpoints must have connectivity to a domain controller as well as the File Director appliance to acquire a service ticket
• File Director server version must be 4.2+

Configuring Kerberos constrained delegation for File Director preauthentication account

Kerberos constrained delegation can be configured for File Director in one of two ways:

Web client secondary authentication

File Director supports single sign-on for the web client (File Director 2019.3 and later). This includes 2-factor authentication methods (such as smart card readers for example) to further protect web interface access.

With Kerberos configured, users of domain-joined machines can log on to the web client seamlessly.

Prerequisites for web client single sign-on:

•File Director server configured for Kerberos authentication

•Domain user / domain joined machine

•Internet Explorer (IE) 11

•Appropriate IE Intranet zone security settings for the URL. For further information, refer to this Microsoft document.

The File Director Web Client will fall back to basic authentication should any of the prerequisites not be in place.

Related topics

Single sign-on