Configure Kerberos authentication for ProxySG or Advanced Secure Gateway

Products

• Advanced Secure Gateway Software - ASG
• ProxySG Software - SGOS

Issue/Introduction

Learn how to configure Kerberos authentication in a Broadcom ProxySG or Advanced Secure Gateway (ASG) environment.

Resolution

Set up the Windows environment

To function properly in Microsoft Windows environments, Kerberos requires certain conditions on both the client and the Domain Controller. Before configuring any Broadcom elements in the network, ensure that the following Windows components are in order: 

• Set up a valid Active Directory (AD) environment. All clients must be part of this AD domain 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).
• The ProxySG appliance must have a valid DNS "A record" entry (a CNAME does not work). In this example scenario, we 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. Next, ping both the Hostname and FQDN of the Proxy looking for the properly resolved IP address.

Configure authentication on ProxySG

The following two ways can be used to get authentication working on ProxySG:

• Direct join the ProxySG (recommended)
• Use legacy BCAAA

Setting up Direct Join with ProxySG (Recommended)

1. Set the Primary DNS server on the ProxySG as the AD domain DNS Server
1. Configuration > Network > DNS
2. Set NTP on the ProxySG to be the same time as the AD Domain
1. Configuration > General > Clock
3. Go to Configuration > Authentication > Windows Domain > Enter the Hostname of the ProxySG resolvable in DNS
1. Apply Change
4. Go to Configuration > Authentication > Windows Domain > Click Add New Domain
1. Create Name for the Domain Alias
2. Apply Change
5. Go to Configuration Tab > Authentication > Windows Domain > Click on Named Domain Alias > Click Join
1. Enter in the DNS server to query
2. Enter Username and Password for service account with Admin Privileges
3. Click OK

Note: If any issue, please refer to these references:

ProxySG First Steps WebGuide - Configure IWA Direct

SGOS Administration Guide (6.7.x)

Authentication WebGuide (6.5.x and later)

Setting up the BCAAA Components

1.  Create credentials for a Domain User that BCAAA uses. 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
2. 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).
3. During the setup of the BCAA installation, it is acceptable to use the BCAAA setup defaults.
4. 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:
   

      5. Set up an IWA realm on the proxySG appliance, under "Configuration > Authentication > IWA". Enter the correct IP of the BCAAA server, and ensure that "Allow Kerberos credentials" is ticked:
         

       6. Set up a web authentication layer with the action being "Authentication using Proxy / ProxyIP" using the IWA realm: 
           

       7. That is all that is required on the ProxySG side. Most of the configuration is Windows-related, as is most of the troubleshooting of any problems that may arise.

Post-Setup: Setting Up the Windows Environment

1. Add the ProxySG hostname to the "Computers" section in AD:

• Note: This entry MUST match the DNS entry
1. 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 used for logon.

Please note: It's possible to associate multiple Service Principal Names to the User account that the BCAAA service runs as. Hence, It's possible to have multiple ProxySG's sharing the same BCAAA service. It's possible to run the setspn command multiple times and associate different service names with the same BCAAA account. Yet the command cannot register the same SPN to more than one account. Microsoft Windows does not throw an error if it occurs. Manually check to make sure that the SPN is not registered twice by using the setspn -l command. Remove any overlapping SPNs by using the setspn -d command.

Post-Setup: Setting up the client environment (Explicit Proxy ONLY)

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

1. Under Tools > Internet Options > Advanced, scroll to the bottom of the list and ensure that the option Enable Integrated Windows Authentication is enabled. IE only uses 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's no way of forcing the use of Kerberos. By default, the clients first try using Kerberos, and if a failure occurs it downgrades to using NTLM for authentication. There's no way of disabling NTLM. It only ensures that the conditions are correct to favor Kerberos over NTLM.

1. Ensure that the proxy sends out the "Negotiate" option when asking for authentication, most easily seen in a packet capture on the client:
   

     The NEGOTIATE method by itself does not guarantee the client uses Kerberos. NEGOTIATE gives the client the option of either Kerberos or NTLM

2. Ensure that the client uses Kerberos in one of three ways:

1. From the client packet capture. Use the Wireshark display filter "Kerberos". It's possible to see both the authentication requests from the client to the Domain Controller, as well as the Kerberos ticket that is included in the HTTP GET request:
   
2. 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":
   

1. Download the utility "kerbtray", available from Microsoft:

• http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4e3a58be-29f6-49f6-85be-e866af8e7a88&DisplayLang=en
• Install this utility on the client. It should be possible to see a ticket is used for the proxy after visiting a website through the ProxySG:
   

Note: In explicit proxy deployments, the previously mentioned Kerberos authentication works for both HTTP and HTTPS site authentication. The packet capture shows the evidence (notice the CONNECT request precedes Kerberos traffic).