ProxySG- AD account keep getting locked by BCAAA Service when using IWA-BCAAA authentication
search cancel

ProxySG- AD account keep getting locked by BCAAA Service when using IWA-BCAAA authentication


Article ID: 235867


Updated On:


ProxySG Software - SGOS


Domain account keep getting locked by BCAAA Service. Based on the AD server log, the account being locked by process name bcaaaa-realm.exe.



SGOS 6.7.x.x and later

BCAAA-: 6.1.4 and later


Account lockouts if showing the source as proxy/BCAAA is caused by wrong credentials being shared back by applications using the proxy. 
This could be caused any machine using wrong (or old) credentials of a user. 
If this is happening very frequently for specific users, do check their machine to see whether any application other than browser is having saved credentials


1. Enable BCAAA debugs


2. In the debug logs, check for the following error

2022/01/20 08:08:24.403 [6428] [6976:6428] Failed NTLM Authentication for user: 'DOMAIN\adminuser'; status=1909:0x775:The referenced account is currently locked out and may not be logged on to.

3. Check the Eventlogs on ProxySG to identify the machine ip 

Go to https://<proxy-ip>:8082/Eventlog/download/events.log 
Save the output as eventlog.txt

Search for DOMAIN\adminuser

Event log will show

Authentication failed from <xx.xx.xx.xx>: user 'DOMAIN\adminuser', realm='<realm-name>'

4. Alternative option to identify machine ip address

To find the computer that is causing this issue, a Policy Trace of the authentication requests made to the ProxySG will be necessary.

Use the following steps to set up this trace: 

. Open VPM within the Management Console.

. Open the Web Authentication Layer that holds the IWA-BCAAA  based Authentication Rules.

. For each rule in this layer that authenticates users, a trace will be added:

   * In the track cell for the authentication rule, right click and choose Set.

   * Provide a name for the trace (this is what you will see in the rule).

   * Ensure Verbose Tracing is checked.

   * Provide a filename of the trace (this is what the actual file will be called).

   * Click OK, then OK at the previous window.

. Add this same trace to each rule within the Web Authentication Layer that would be responsible for authenticating this particular user.

All authentication requests that are made by the ProxySG will now be logged to this trace file. After the user lockout occurs, you will then be able to search this trace file for all transactions related to that particular user and then determine what IP addresses the requests came from, narrowing the search for the service that has the expired/invalid credentials


It is highly recommended that the ProxySG be monitored closely while this Trace is active, as it will require more resources than the ProxySG typically uses. Ensure that the Trace will not be too resource intensive on the ProxySG before letting it run unattended for long periods of time.

5. Investigate on the machine xx.xx.xx.xx identified in step-3 and/or step-4