Troubleshooting BCAAA Account Mismatch and "Invalid Service Account Referenced" Warnings
Article ID: 446605
Updated On:
Products
Issue/Introduction
In an environment utilizing the Blue Coat Authentication and Authorization Agent (BCAAA), legacy or incorrect service accounts (e.g., service-bcaaa) may appear to be in use despite updated accounts (Service-Dev_BCAAA or Service-Prod_BCAAA) being configured in DEV and PROD environments respectively.
This can trigger Microsoft-Windows-Kerberos-Key-Distribution-Center Event ID 202 warnings, indicating the Key Distribution Center (KDC) detected unsupported RC4-HMAC-NT usage for a service account with insecure keys - these event logs report the usage of legacy BCAAA accounts that are supposedly decommissioned e.g.
Event ID: 202
Warning Message: "The Key Distribution Center (KDC) detected RC4-HMAC-NT usage that will be unsupported... service account only has insecure keys."
Service Name identified in logs: service-bcaaa (or equivalent legacy account).
NTLM is the authentication protocol defined - why do we see Kerberos events?
Why do we see legacy account show up when it is not in use?
Environment
BCAAA.
NTLM based authentication.
Edge SWG.
Cause
The issue typically occurs because an invalid or legacy service account is still referenced within the authentication environment or on the ProxySG, leading to mismatched account reporting and insecure encryption usage (RC4).
Resolution
- Verify Service Account References: Ensure the ProxySG and BCAAA configuration only references the intended current service accounts (e.g., Service-Np_Bcaa or Service-Prod_Bcaaa).
- Validate SPNs: Check for duplicate or invalid Service Principal Name (SPN) references. Run the following commands from a domain member machine to list SPNs for the accounts in question
- setspn -L service-bcaaa
- setspn -L Service-Np_Bcaa
- setspn -L Service-Prod_Bcaaa
- Identify Client Origin: Check the IP address and Account Name listed in the KDC warning (Event 202) to identify which system or user is still attempting to authenticate using the legacy service account.
- Correct Service Account: Ensure the environment is not referencing an invalid service account in the BCAAA configuration.
Additional Information
There is an explanation of why NTLM setup is triggering Kerberos events, and why the legacy account is caught in the middle. Our ProxySG and BCAAA typically utilize IWA (Integrated Windows Authentication). IWA is not a single protocol; it uses a wrapper called SPNEGO (Negotiate).
When a user's browser talks to the proxy, SPNEGO always follows this logic:
- Try Kerberos First: The client browser automatically attempts to request a Kerberos ticket from the Domain Controller for the proxy's address.
- Fallback to NTLM: Only if Kerberos fails (e.g., no Service Principal Name is found, or DNS doesn't match) will the browser fall back to NTLM. This should be happening.
In terms of why service-bcaaa triggers Kerberos, but the another account doesn't ... the Legacy Account has an SPN: The old service-bcaaa account likely still has a Service Principal Name (SPN) registered to it in Active Directory. Because that SPN exists, the Domain Controller thinks, "Ah, we are using Kerberos for this request!" It attempts to issue a Kerberos ticket, realizes the old account only has weak RC4 keys, and logs Event 202.
The Prod Account doesn't have an SPN: If the new Service-Prod_Bcaaa account does not have any SPNs mapped to it, Kerberos fails immediately and silently. The system seamlessly falls back to NTLM just like you intended, which is why you see no Kerberos errors for the production account.
If the corporate policy dictates NTLM for this traffic, we must strip the Kerberos configuration from the legacy account so the browser stops trying to use it.
To do this, we will need to find and delete the SPN attached to the old account. Run this in a command prompt to find it:
CMD prompt: setspn -q */service-bcaaa
Once you locate the SPN (e.g., HTTP/proxy.example.com), delete it using following command:
CMD prompt: setspn -d HTTP/proxy.example.com service-bcaaa
The browser will stop attempting Kerberos, fail over to NTLM immediately, and Event 202 will hopefully disappear.
Feedback
