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: servicePrincipalName: HOST/csil-fs-01.cs.surrey.sfu.ca servicePrincipalName: HOST/CS-LOUGHEED servicePrincipalName: HOST/cs-lougheed.surrey.sfu.ca Now, after running 'net ads join', the SPNs for Samba clients look as such: servicePrincipalName: CIFS/sc-testing2.ad.sfu.ca servicePrincipalName: CIFS/sc-testing2 servicePrincipalName: HOST/sc-testing2.ad.sfu.ca servicePrincipalName: HOST/sc-testing2 servicePrincipalName: CIFS/csil-synopsys.ad.sfu.ca servicePrincipalName: CIFS/csil-synopsys servicePrincipalName: HOST/csil-synopsys.ad.sfu.ca servicePrincipalName: HOST/csil-synopsys 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 NT_STATUS_TRUSTED_RELATIONSHIP_FAILURE [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 NT_STATUS_TRUSTED_RELATIONSHIP_FAILURE Using the short name (\\csil-synopsys) works fine. Reproducible: always under these conditions (differing subdomains, NTLMV2 auth enforced via domain policy) How to fix: basically, SPNs should be generated from FQDN, rather than HOSTNAME.ADREALM (or in addition to).
please don't opne new copies of the same bug. *** This bug has been marked as a duplicate of 2414 ***