File Director

Home

This page refers to an older version of the product.
View the current version of the online Help.

Kerberos authentication

In this section:

Prerequisites for Kerberos authentication
Configure Kerberos in the File Director admin console
Kerberos Constrained Delegation
Two-factor 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:

The Kerberos keytab to be acquired from a user account so the server can trust the authorized user to access it.
Preauthentication checks.
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.
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:

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.

Note, to ensure the correct default domain is used, the username for this account must include the relevant realm name.
The required format is username@REALM, for example, [email protected]. The realm must be entered in uppercase.
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.
Ensure DNS references the File Director server and always use the full DNS name to access the File Director server in the future.
You must also ensure DNS reverse references are set up for the SMB file server.

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.
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.
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

In the File Director web admin console, select Configuration > Kerberos.
Click Add Realm.

The Add/Edit Kerberos Realm dialog displays.
In the Domain field, enter the default domain name.
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.
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.
Repeat steps 2 to 6 for all relevant realms. This ensures successful authentication to all shares added as map points.
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. The username can be entered as username or username@REALM. Where the realm is used, it must be in upper case - for example, [email protected]. This is the preferred format where multiple domains are configured.

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

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 (see admin guide for configuring NTP), File servers and domain controllers
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

Locate your preauthentication account in Active Directory Users and Computers.
From the preauthentication account properties, select the Delegation tab.
Select Trust this user for delegation to the specified services only to enable the associated options.
Select Use any authentication protocol.
Click Add to select the resources you wish to access using Kerberos constrained delegation
Click Users or Computers button to allow you to search AD.
Select the computer account for the file server you want to access. If you have multiple file servers, select all of them.
In the Service Type field for the server, select cifs.
Click OK.
Click Apply,

Your File Director preauthentication account is setup for Kerberos Constrained Delegation to access the selected servers.

Web client secondary authentication

From release 2019.3, File Director can support secondary authentication methods (such as smart card readers for example) to further protect web interface access.
With Kerberos SSO and secondary authentication enabled, users of domain-joined machines can log on to the web client seamlessly.

This functionality is supported for IE11. Administrators configuring seamless authentication must be aware of IE Intranet zone security settings and the issues that can occur when the FQDN is entered. For further information, refer to this Microsoft document.