Configuring Kerberos in an explicit proxy deployment (BlueCoat).
Hopefully this will get published in the bluecoat KB soon, but till then, enjoy🙂 It’s centred around Bluecoat’s implementation, but the steps are generic enough to be useful in general proxy deployments.
Configuring Kerberos in a Bluecoat explicit proxy deployment.
Pre-Setup : Setting up the Windows environment
In order to function properly in windows environments, Kerberos requires certain conditions to be met on both the client and the Domain Controller. Therefore, before configuring any Bluecoat elements in the network, one must ensure that the following windows components are in order:
1. You must setup a valid Active Directory 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 KB3919 for further details regarding this subject)
2. You must have a valid DNS entry for the proxy. In this example scenario, we will create a DNS “A record” for the proxy, mapping the FQDN to the IP address:
In other words, the FQDN of “proxysg.davidv.local” maps to the IP address of 10.91.25.10 in this example.
Ensure that the clients use this DNS server and that they can ping this FQDN with the proper resolved IP address
3. Create a domain user that BCAAA will run under. In this example we create a new user “BCAAAuser” in the AD domain.
- i. During the user creation process, make sure to untick the “user must change password” option.
- ii. 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.
- iii. 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.
- iv. Make sure to refresh the GPO using the cmd command gpudate
Setting up the Bluecoat Components
4. Download and install the proper version of the BCAAA executable from the BTO website (note: BTO credentials required). During setup, it is acceptable to use the BCAAA setup defaults.
5. Open “services.msc”, and locate the BCAAA service. Edit the service’s properties and ensure that under the “Log On” tab, the purposely created domain user is set, and restart the service:
6. Setup an IWA realm on the proxySG unit. This is done under “Configuration > Authentication > IWA”. Enter the correct IP of the BCAAA server, and ensure that “Allow Kerberos credentials” is ticked:
7. Setup a Web Authentication layer with action being authentication using Proxy / ProxyIP using the IWA realm:
That is all that is required on the bluecoat side of things. As you can see, most of the configuration is windows related, as will be most of the troubleshooting and problems that may arise.
Post-Setup : Setting up the Windows environment
8. Open a command prompt as administrator on the Domain Controller and register the SPN for the BCAAA service by using the following command (note case sensitive):
setspn –A HTTP/proxysg.davidv.local BCAAAuser
where “proxysg.davidv.local” is the FQDN of the proxy, and BCAAAuser is the AD user the service is using as a logon.
Please note: you cannot have two SPNs registered for the same service. However, windows does not throw an error when this happens. 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
- IE7 and above is needed, or Mozilla firefox. For either, set the browser to use the 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 it’s “Intranet Zone”. Under Internet options > security > local intranet > sites > advanced, add the proxy 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 failover to NTLM. There is no way of disabling NTLM. You 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 you should 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, you should see two successful authentication events of type “ACCOUNT LOGON”. The keyword to look for is “ticket”:
- Using the utility “kerbtray”, available from microsoft:
Install this utility on the client, and after visiting a website through the proxy, you should 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)
Note: When setting up transparent proxy, the above procedure remains the same, except you use the virtual authentication URL instead of the proxy URL
Update: The above article has been published on the bluecoat Knowledge Base: