Kerberos with BCAAA in Load Balanced Environment
search cancel

Kerberos with BCAAA in Load Balanced Environment

book

Article ID: 276306

calendar_today

Updated On:

Products

ProxySG Software - SGOS Advanced Secure Gateway Software - ASG ISG Proxy SG-VA

Issue/Introduction

Here is the general document for configuring Kerberos in the BCAAA environment:

Enabling Kerberos in a BCAAA Deployment
https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-network-security/edge-swg/7-3/authentication_co/IWA_configure_st/IWA_BCAAA_st/Kerberos_IWA_BCAAA_ta.html 

And:

Prepare for a Kerberos Deployment
https://techdocs.broadcom.com/us/en/symantec-security-software/web-and-network-security/edge-swg/7-3/getting-started/page-help-configuration/page-help-authentication/about-iwa/prepare-kerberos.html 

A good resource to review the flow:

Edge SWG (formerly ProxySG) Kerberos Authentication Flow with IWA-BCAAA
https://knowledge.broadcom.com/external/article/249765/edge-swg-formerly-proxysg-kerberos-authe.html

However, the setup described in those assumes that the proxies are not load balanced and there is only one proxy. In a load balanced scenario, the configuration in the Windows environment is going to be different when registering the SPN.

Environment

IWA-BCAAA with load balancer in front of multiple explicit proxies

Resolution

The setup described in the above documents assumes that the proxies are not load balanced and there is only one proxy. In a load balanced scenario, the configuration in the Windows environment is going to be different when registering the SPN.

When using load-balanced Kerberos, users connect to a load-balancer hostname when they are routed through the proxies. The load-balancer hostname SPN is assigned to the IWA BCAAA user account so that the BCAAA agents can properly validate the Service Ticket.

For IWA-BCAAA with load balancer in front of multiple proxies, for Kerberos to work the setspn should be with the format below.

setspn -A HTTP/<FQDN_of_LB> <BCAAA_domain_service_account>

All the BCAAA agents should use the same domain service account to login for the BCAAA service. 

Check is to see whether there is dup or the spn entry is registered correctly by running:

setspn -l FQDN_of_LB

and

setspn -l BCAAA_domain_service_account

Query AD and check if the BCAAA user account is returned using:

setspn -F -Q HTTP/<FQDN_of_LB>

 

There is a section in this article called "Verify Kerberos Authentication" which explains how to verify in a PCAP that Kerberos is working:

Blue Coat ProxySG Authentication Guide
https://techdocs.broadcom.com/content/dam/broadcom/techdocs/symantec-security-software/web-and-network-security/proxysg/common/SGOS_Auth_guide.pdf

If the client has provided the Kerberos token to BCAAA and if it is not able to decrypt it, the BCAAA debug log will shed some light into it.

Gather BCAAA debug logs
https://knowledge.broadcom.com/external/article/166076/gather-bcaaa-debug-logs.html