An AD member is joined to a domain using the "net ads join" command, and adding the "-k" switch causes all authentication to use Kerberos. The documented way of doing this is prior to running winbindd, hence the winbindd Kerberos locator is not operational at this stage. As a result, the process of finding a KDC is not site-aware, and an off-site KDC can be contacted.

The process of finding a DC for creating the machine account (via SMB/ldap) *is* site-aware, so once there's a service ticket to that DC, everything continues in a site-aware manner.

At first glance this does not appear to be a significant issue, since joining the domain is a one-time operation. However, the site-unaware operation sometimes prolongs the ticket acquisition up to a point of failing the whole operation.

It appears to be customary in some enterprises to block (drop) communication between sites, so while off-site DCs appear in DNS records, they are not reachable. A UDP Kerberos handshake would fail after a few seconds (depends on Kerberos libs), and a TCP handshake would take longer to fail because the typical OS TCP timeout if SYN packets are dropped is ~15 seconds.

In one enterprise with 70-80 DC's across multiple sites, it has taken more than two minutes to obtain the service ticket. However, since smbd starts obtaining the service ticket only after it has contacted the (on-site) DC and done SMB2 negotiation, the DC drops the connection after 60 seconds (an established TCP connection past the negotiate phase but no session-setup attempted). This fails the join even if the user is willing to wait the 2 minutes (which he might not be, since this all could be wrapped in a shiny REST API and a GUI).

On the other hand, if we make the process site-aware, we first find on-site DC using CLDAP - this could take a few sec because of the firewall, but no SMB connection is open at this stage.