Procedure for configuration of Kerberos authentication in a ProxySG or Advanced Secure Gateway (ASG) environment.
Configuring Kerberos on a Proxy
Pre-Setup : Setting up the Windows environment
In order to function properly in Microsoft Windows environments, Kerberos requires certain conditions to be met on both the client and the Domain Controller. Therefore, before configuring any Blue Coat elements in the network, ensure that the following Windows components are in order:
1. Setup a valid Active Directory (AD) environment. All clients must be part of this AD domain in order to use Kerberos. If the client is not part of the domain, the only option is to use constrained Kerberos delegation. See
Configuring Kerberos Constrained Delegation (KCD).
2. The ProxySG appliance must have a valid DNS "A record" entry (a CNAM will not work). In this example scenario, we will create a DNS "A record" for the ProxySG, mapping the Hostname/FQDN to the IP address:
In this example, the Hostname "proxysg" and FQDN of "proxysg.davidv.local" maps to the IP address of 10.91.25.10.
Use the NSLOOKUP tool to check that the clients use this DNS server and then ping both the Hostname and FQDN of the Proxy looking for the properly resolved IP address.
There are two ways to Get Authentication working on the ProxySG; Direct Join the ProxySG (recommended) or Use Legacy BCAAA
Setting up Direct Join with ProxySG (Recommended)
Set the Primary DNS server on the ProxySG as the AD domain DNS Server
Configuration > Network > DNS
Set NTP on the ProxySG to be the same time as the AD Domain
Configuration > General > Clock
Go to Configuration > Authentication > Windows Domain > Enter the Hostname of the ProxySG resolvable in DNS
Go to Configuration > Authentication > Windows Domain > Click Add New Domain
Create Name for the Domain Alias
Go to Configuration Tab > Authentication > Windows Domain > Click on Named Domain Alias > Click Join
Enter in the DNS server to query
Enter Username and Password for service account with Admin Privileges
Note: If any issue, please refer to the references below:
Create credentials for a Domain User that BCAAA will use. In this example we create a new user "BCAAA user" in the AD domain.
During the user creation process, untick "User must change password" option.
Open the group policy object editor: Computer configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Act as part of the operating system. Add the BCAAA user here.
Open the group policy object editor: Computer configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Log on as a service. Add the BCAAA user here.
Refresh the Group Policy Object by executing the command "gpupdate" on the command line
Download and install the version of the BCAAA executable that is provided with the version of SGOS that is on the Proxy. These both can be found in the MySymantec website (Note: Symantec credentials required).
During the setup of the BCAA installation, it is acceptable to use the BCAAA setup defaults.
Open "services.msc", and locate the BCAAA service. Edit the service's properties and ensure that under the "Log On" tab, the BCAA domain user is set. Restart the service:
Set up an IWA realm on the proxySG appliance. This is done under "Configuration > Authentication > IWA". Enter the correct IP of the BCAAA server, and ensure that "Allow Kerberos credentials" is ticked:
Set up a Web Authentication layer with the action being "Authentication using Proxy / ProxyIP" using the IWA realm:
That is all that is required on the ProxySG side. Most of the configuration is Windows related, as will be most of the troubleshooting of any problems that may arise.
Post-Setup: Setting Up the Windows Environment
Add the ProxySG hostname to the "Computers" section in AD:
Note: This entry MUST match the DNS entry
Open a command prompt, as Administrator, on the Domain Controller and register the SPN for the BCAAA service by using the following command (case sensitive):
setspn -A HTTP/proxysg.davidv.local BCAAAuser
where "proxysg.davidv.local" is the FQDN of the ProxySG, and BCAAAuser is the AD User the BCAA service is using for a logon.
Please note: It is possible to associate multiple Service Principal Names to the User account that the BCAAA service runs as. Hence, it is possible to have multiple ProxySG's sharing the same BCAAA service. It is possible to run the setspn command multiple times and associate different service names with the same BCAAA account. But, the command cannot register the same SPN to more than one account. However, Microsoft Windows does not throw an error if this occurs. Manually check to make sure that the SPN is not registered twice by using the setspn -l command, and remove any overlapping SPNs by using the setspn -d command.
Post-Setup : Setting up the client environment (Explicit Proxy ONLY)
IE7+ or Mozilla Firefox. For either, set the browser to use the Hostname/FQDN of the proxy when explicitly configured:
The following steps were performed with IE:
Under Tools > Internet Options > Advanced, scroll to the bottom of the list and ensure that the option Enable Integrated Windows Authentication is enabled. IE will only use Kerberos to sites that are in its "Intranet Zone". Under Internet Options > Security > Local Intranet > Sites > Advanced, add the ProxySG's FQDN:
Verifying the use of Kerberos:
There is no way of forcing the use of Kerberos. By default, the clients will try to use Kerberos, and if this fails, it will downgrade to using NTLM for authentication. There is no way of disabling NTLM. It can only ensure that the conditions are correct to favour Kerberos over NTLM.
Ensure the proxy is sending out the "Negotiate" option when asking for authentication. This is most easily seen in a packet capture on the client:
The NEGOTIATE method by itself will not guarantee the client uses Kerberos. NEGOTIATE gives the client the option of either Kerberos or NTLM
Ensure the client is using Kerberos. This can be done in one of three ways:
From the client packet capture. Use the wireshark display filter "Kerberos" and it's possible to see both the authentication requests from the client to the Domain Controller, as well as the Kerberos ticket included in the HTTP GET request:
Using the event viewer on the Domain Controller, under the security logs, it's possible to see two successful authentication events of type "ACCOUNT LOGON". The keyword to look for is "ticket":
Download the utility "kerbtray", available from Microsoft:
Install this utility on the client, and after visiting a website through the ProxySG, it should be possible to see a ticket being used for the proxy:
Note: In explicit proxy deployments, the above Kerberos authentication works for both HTTP and HTTPS site authentication, as evidenced by the below packet capture (notice the CONNECT request followed by Kerberos traffic).
Imported Document ID: 000021561
Subscribing will provide email updates when this Article is updated. Login is required.