Why wouldn't failover happen, to a secondary/alternate domain controller?
search cancel

Why wouldn't failover happen, to a secondary/alternate domain controller?

book

Article ID: 381877

calendar_today

Updated On:

Products

ASG-S500 ISG Proxy

Issue/Introduction

The proxies were configured to use two Domain Controllers (Primary, Secondary) The secondary domain controller was down due to an upgrade. However, issues were seen, where authentication popup messages appeared during web authentication. Is this a normal behavior, even though there was a secondary domain controller?

Environment

SG/ASG/ISG-Proxy

Resolution

If the Edge SWG (Edge SWG (ProxySG)) appliance was configured to failover to the secondary Domain Controller (DC) but did not, there are a few areas to investigate based on Broadcom’s typical failover mechanism for authentication servers, as referenced in the Broadcom Tech. Article 166463:

  1. Connectivity to the Secondary DC: If there was a network issue or firewall rule preventing the Edge SWG (ProxySG) from communicating with the secondary DC, it might have been unable to connect during the failover attempt.

  2. Authentication Mode Configuration: For failover to work as expected, the Edge SWG (ProxySG) configuration must specify the secondary DC as a fallback option in the IWA Direct settings. Double-check that the configuration points to the secondary DC accurately and that it’s configured as a backup rather than just an alternative in a non-failover setting.

  3. DNS Resolution: Edge SWG (ProxySG) uses DNS to locate the DCs in most setups. If the Edge SWG (ProxySG) couldn’t resolve the secondary DC due to DNS configuration or replication issues, failover would not occur. Verifying that both DCs are resolvable by name from the Edge SWG (ProxySG) is essential.

  4. Load Balancing and Failover Timeouts: The Edge SWG (ProxySG) has load-balancing and failover timeouts that govern how long it waits before switching to a secondary DC. If these timeouts are set too high, or if the primary DC status did not update promptly, the Edge SWG (ProxySG) might have delayed switching to the secondary DC, causing authentication popups.

  5. Cached Authentication State: The Edge SWG (ProxySG) may cache connection states with DCs to improve performance. However, if it cached the state with the primary DC, this could delay the failover process.

To pinpoint the cause, consider enabling debug logs (LSA Debug log, Auth debug log, & PCAP) to capture the authentication process and network connectivity to the secondary DC. You may also want to review the specific IWA configuration in the Edge SWG (ProxySG) to confirm that the secondary DC is set up correctly and test failover manually to ensure it works as expected. 

Note:

On the Edge SWG (ProxySG), Domain Controller (DC) failover indeed functions only with NTLM authentication, not with Kerberos. For Kerberos authentication of the clients, Edge SWG does not need to talk to DCs and Edge SWG will decrypt the Kerberos tokens provided by the clients.