Here is the general document for configuring Kerberos in the BCAAA environment:
Enabling Kerberos in a BCAAA Deployment
Prepare for a Kerberos Deployment
A good resource to review the flow:
Edge SWG (formerly ProxySG) Kerberos Authentication Flow with IWA-BCAAA
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.
IWA-BCAAA with load balancer in front of multiple explicit proxies
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
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
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