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.
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:
Note, to ensure the correct default domain is used, the username for this account must include the relevant realm name.
The required format is [email protected], 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. 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.
Take the DNS name and use the
setspntool 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
setspncommands 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.
This process describes how to configure the File Director Admin console for Kerberos authentication.
- 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.
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/.
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 [email protected]. 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.
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.
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
- 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
Kerberos constrained delegation can be configured for File Director in one of two ways:
This is known as constrained delegation. In this configuration the File Director appliance uses the service ticket for the user, provided by the client to authenticate with the back end storage.
1.Locate your preauthentication account. From the Start menu click Programs> Administrative Tools >Active Directory Users and Computers.
2.From the preauthentication account properties, select the Delegation tab.
3.Select Trust this user for delegation to the specified services only . Associated options are enabled within the Delegation properties dialog.
4.Select Use Kerberos only.
5.Click Add to select the resources you wish to access using Kerberos constrained delegation.
6.Click Users or Computers button to allow you to search AD.
7.Select the computer account for the file server you want to access. If you have multiple file servers, select all accounts required.
8.In the Service Type field for the server, select cifs.
This is known as constrained delegation with protocol transition. In this configuration the File Director appliance uses the S4USelf and S4UProxy Kerberos protocol extensions to authenticate with the backend storage.
From release 2019.3, File Director can support single sign-on for the web client. 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.
Note, this functionality is only supported for IE11.
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.