Authentication communication with BCAAA server does not fall back to original primary BCAAA server

Products

• ProxySG Software - SGOS

Issue/Introduction

• For BCAAA, the realm is considered healthy (and therefore does not fail over) if the EdgeSWG (ProxySG) appliance is able to establish a connection to the BCAAA service. This means that the appliance can complete the TCP handshake with BCAAA on port 16101 (or whichever port the BCAAA service is configured to use), and it was able to send BCAAA its login message.
• If the BCAAA service crashes or is stopped, but the Windows system on which it is running remains available, Windows resets the EdgeSWG (ProxySG) appliance’s TCP connection. In this case, the appliance attempts to reconnect, but fails. Only then the appliance fails over to the secondary BCAAA server.
• If the Windows server on which BCAAA is running crashes or becomes unavailable, it cannot reset the TCP connection. In this case, BCAAA must wait for the EdgeSWG (ProxySG) appliance’s TCP stack to time out. This can take a couple of minutes, and does not occur until the appliance attempts to send a new authentication request.
• If the BCAAA server loses its connection to the Windows Domain Controller (DC), it automatically fails over to a different DC. However, a limitation of the current BCAAA failover process is that it does not properly handle the case where the primary BCAAA service cannot reach any DCs. In this case, all authentication requests fail, but because the connection between the BCAAA service and the appliance is still considered healthy, the appliance does not fail over to the secondary BCAAA service.
• In addition, authentication requests can be slowed significantly if BCAAA is querying a slow Domain Controller. However, this does not cause the EdgeSWG (ProxySG) appliance to fail over to the secondary BCAAA server. By default, BCAAA will query whichever DC is chosen at boot time by the server it is installed on, and it only changes if the DC goes down or the server reboots. You can see and/or modify what DC the BCAAA server is communicating with using the nltest.exe command line utility, which is part of Windows Support Tools.

Environment

EdgeSWG IWA Realm using BCAAA  

Cause

When the primary BCAAA server fails, the expected behavior is that the appliance switches to the secondary BCAAA server.  After the primary BCAAA server comes up again, the appliance doesn't switch back to the primary BCAAA server. 

The appliance will not trigger a fail over unless it loses connection with the BCAAA server that is currently in use.

Resolution

For the appliance to use the primary BCAAA again: 

1. In the Management Console, select Configuration > Authentication > Realms and Domains . Select the BCAAA realm name from the drop-down menu.
2. Remove the secondary BCAAA server IP address and click Apply. The appliance will detect that there is no secondary BCAAA server and start using the primary BCAAA server again. 
3. Confirm that health checks show OK for authentication.
4. Add the secondary BCAAA IP address again and Apply.

 

Additional Information

To determine which DC the BCAAA server is communicating with, issue the following command:

nltest /sc_query:internal.domain.com

To switch to a different DC, issue the following command:

nltest /sc_reset:internal.domain.com\new_dc_name