When joining an Active Directory when subdomains are being used, the servicePrincipalNames inserted
in AD are incorrectly generated.
Scenario: our AD domain is ad.sfu.ca. Machines that join the domain are not necessarily in this domain
(two particular examples are surrey.sfu.ca and cs.surrey.sfu.ca, the primary two we're concerned with
below). Correctly generated servicePrincipalNames for a Windows client joining the domain look like:
Now, after running 'net ads join', the SPNs for Samba clients look as such:
Because DNS for these hosts is in a different subdomain, not ad.sfu.ca, using their full hostnames
(\\csil-synopsys.cs.surrey.sfu.ca) results in both Samba and Windows reporting that the trust
relationship between the machine and the domain failed
(NT_STATUS_TRUSTED_RELATIONSHIP_FAILURE): Log level 10 for the appropriate section:
[2005/03/02 15:37:43, 1] libsmb/cliconnect.c:cli_full_connection(1489)
failed tcon_X with NT_STATUS_ACCESS_DENIED
[2005/03/02 15:37:43, 10] passdb/secrets.c:secrets_named_mutex_release(714)
secrets_named_mutex: released mutex for ADSERVER7
[2005/03/02 15:37:43, 0] auth/auth_domain.c:domain_client_validate(170)
domain_client_validate: Domain password server not available.
[2005/03/02 15:37:43, 5] auth/auth.c:check_ntlm_password(271)
check_ntlm_password: winbind authentication for user [patl] FAILED with error
[2005/03/02 15:37:43, 2] auth/auth.c:check_ntlm_password(312)
check_ntlm_password: Authentication for user [patl] -> [patl] FAILED with error
Using the short name (\\csil-synopsys) works fine.
Reproducible: always under these conditions (differing subdomains, NTLMV2 auth enforced via domain
How to fix: basically, SPNs should be generated from FQDN, rather than HOSTNAME.ADREALM (or in
*** Bug 2416 has been marked as a duplicate of this bug. ***