Bug 11975 - net ads join -k kerberos authentication is not site-aware (part 2)
net ads join -k kerberos authentication is not site-aware (part 2)
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Tools
4.4.4
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on: 11769
Blocks:
  Show dependency treegraph
 
Reported: 2016-06-15 06:59 UTC by Alexander Bokovoy
Modified: 2016-06-17 09:13 UTC (History)
6 users (show)

See Also:


Attachments
patch for 4.4 (1.70 KB, patch)
2016-06-15 13:48 UTC, Andreas Schneider
ab: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bokovoy 2016-06-15 06:59:45 UTC
+++ This bug was initially created as a clone of Bug #11769 +++

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.

--------------------------------------------------------------------------

The original fix lacked promotion of the sitename to the new local private krb5.conf created just before the join.
Comment 1 Andreas Schneider 2016-06-15 13:48:18 UTC
Created attachment 12180 [details]
patch for 4.4
Comment 2 Alexander Bokovoy 2016-06-15 13:51:57 UTC
Comment on attachment 12180 [details]
patch for 4.4

looks good.
Comment 3 Andreas Schneider 2016-06-16 07:13:50 UTC
Karolin, please add the patch to the 4.4 branch. Thanks!
Comment 4 Karolin Seeger 2016-06-16 09:11:35 UTC
(In reply to Andreas Schneider from comment #3)
Pushed to autobuild-v4-4-test.
Comment 5 Karolin Seeger 2016-06-17 09:13:45 UTC
(In reply to Karolin Seeger from comment #4)
Pushed to v4-4-test.
Closing out bug report.

Thanks!