Kerberos and Integrated Windows Authentication in a load balanced environment
- Article Number: 000008726
- Products: Forcepoint Web Security, TRITON AP-WEB
- Version: 8.5, 8.4, 8.3, 8.2
- Last Published Date: July 28, 2020
Notes & Warnings
Verification and Troubleshooting:
To verify that the client is authenticating to the proxy with the load-balancer’s Kerberos ticket, the client’s Kerberos ticket cache can be checked.
Here is an example of klist output with the load balancer's FQDN as the authenticated service. This illustrates what Kerberos should look like from a client when authentication is working correctly.
1. Verify that the instance of Content Gateway has a good connection to the Domain controller.
2. Log on to the WCG manager and navigate to Configure > Access Control > Integrated Windows Authentication.
It is important to distinguish the Administrative Account and Service Account terms:
Kerberos authentication requires that clients send Content Gateway's Kerberos ticket to Content Gateway. Because the clients are pointing to a load-balancer's VIP via the FQDN, the client instead sends the load-balancer's ticket to Content Gateway, which causes Kerberos authentication to fail.
It's not possible to configure clients to request Content Gateway's Kerberos ticket, because the client's OS handles the ticket request based on the FQDN of the proxy to which the clients are explicitly pointed. As a result, Integrated Windows Authentication (IWA) using Kerberos fails client authentication in a load-balanced environment when Content Gateway is deployed as an explicit proxy.
Note: The following applies to explicit proxy deployments only. Transparent proxy deployments do not require this configuration to authenticate successfully using Kerberos in a load balanced environment.
Note: This functionality described below is part of the v8.2 release of TRITON AP-WEB and above (including v8.5.3). Support for this is also available for versions v7.8.4 - v8.1, but a hotfix is required. Please contact Technical Support for assistance.
Enabling the Functionality:
1. Set the Service Principal Name (SPN) to the account that will be used to join WCG's to the Active Directory domain.
You may name your account anything. In this example we will call it "forcepoint_svc".
Note: Unless explicitly enforced by security settings, this account does not have to be Administrator. The account used should have privileges sufficient to join the domain, as defined by company policy. For information on required permissions, see Permissions Required for Accounts Used to Join Proxies to a Domain for Integrated Windows Authentication.
Standard users can join up to 10 machines to the domain. (This is a default Microsoft limit.)
You may also want to remove it from any sensitive groups in the AD.
Note: For Rules Based Authentication with Multiple Realms, you will need to create different service accounts for the different domains.
In multi-realm configuration, the user used for joining the machine to all but the first domain must be a domain admin because a computer in the AD that uses a hostname outside the domain must be added. (See the "Samba Client is not in the same domain as the AD domain" section of this site.)
To enable the account, right click and choose "Enable":
Add the service principal to the Active Directory account using the safe mode of the setspn command.
For example, if the Load Balancer FQDN is "LB.domain.org" and the domain account is "forcepoint-svc", use the following command:
setspn -S HTTP/lb.domain.org forcepoint_svc
Note: It is important that the "HTTP" text in the SPN is uppercase as shown in the example, otherwise the WCG code responsible for reading the SPN will not locate it and authentication will fail.
a. Open the Content Gateway console and join the domain(s) using the account created that contains the SPN for the load balancer handling traffic for our proxies. In this example, we are using "forcepoint_svc".
b. Repeat for the remaining Content Gateway appliances that are handled by the load balancer.
Each machine must be joined as their unique hostnames. If the computer objects do not already exist in AD, they will be created upon joining.
a. After joining the domain, run IWA "Run Test" in the UI. (Monitor > Integrated Windows Authentication > Run test)
b. Look for the output of the "net ads keytab list" command in the diagnostic output above. It should list additional keytabs containing the LB hostname.