Description of problem:
-----------------------
(Much of the following text has been copied directly from https://pagure.io/SSSD/sssd/issue/2702, which this BZ is being raised specifically to be linked to)

Currently, AD site discovery as it is implemented in SSSD follows this document:
https://docs.pagure.org/SSSD.sssd/design_pages/active_directory_dns_sites.html 

The problem with this process is, that it assumes all domain controllers are accessible from the client. If they are not (for example different geographical region behind a VPN), we are in a danger of timeout (even after determining the site, since we cannot guarantee that all DC’s registered for a particular site are responsive).

The solution (proposed in 2016 by Ondrej Valousek in https://pagure.io/SSSD/sssd/issue/2702) is:

1. Run _ldap._tcp.domain.name SRV query to obtain list of all DC’s for domain (no change)
2. Send LDAP ping to ALL DC’s in parallel (instead of sequentially as currently happens)
3. Attempt to extract client site from whichever DC response is received first
4. Proceed with service discovery, only communicating with DC’s that responded to LDAP ping

This would cover scenario where only couple of DCs are accessible to the client and would be also more in line of the AD locator process as described here: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc978011(v=technet.10) :

Quote:

4. The Net Logon service sends a datagram to the discovered domain controllers ("pings” the computers) that register the name. For NetBIOS domain names, the datagram is implemented as a mailslot message. For DNS domain names, the datagram is implemented as an LDAP UDP search.
5. Each available domain controller responds to the datagram to indicate that it is currently operational and then returns the information to DsGetDcName.
6. The Net Logon service returns the information to the client from the domain controller that responds first.

Also as Ondrej observes in https://pagure.io/SSSD/sssd/issue/2702#comment-223568, the site discovery process is being run periodically, which is unnecessary since the site is almost guaranteed not to have changed if the client IP address is unchanged. Site discovery should only be run during startup or after a network reconfiguration event.

Version-Release number of selected component (if applicable):
--------------------------------------------------------------
1.16.4-21.el7_7.1

How reproducible:
------------------
Every time

Steps to Reproduce:
--------------------
1. Join domain and configure sssd-ad (without using ad_site parameter)
2. Enable debug logging of the domain (0x7770) 
3. Monitor for a period of 24 hours or so

Actual results:
--------------
At startup and on a periodic schedule (every 12 hours) the AD backend will:
1.	Query DNS for a list of all DC’s in the domain
2.	To each DC in turn, send an ‘LDAP ping’/netlogon query to determine client site, until one sensible response is received. (If the currently selected DC is unavailable or behind a firewall, the process is subject to certain pre-defined timeouts, which are generally in the order of whole seconds)

Expected results:
-------------------
At startup and after a network reconfiguration event the AD backend should:
1.	Query DNS for a list of all DC’s in the domain
2.	Send an LDAP ping to all DC’s simultaneously
3.	Attempt to extract client site from whichever DC response is received first
4.	Proceed with service discovery, only communicating with DC’s that responded to LDAP ping

Additional info:
---------------
The only known workaround for this behaviour is to disable site discovery altogether by manually specifying the site using the ad_site parameter, but this inconvenient when one is attempting to engineer an automated service capable of deploying into multiple sites, regions, networks and AD domains.