Bug 2414 - servicePrincipalName incorrect when joining AD subdomains
Summary: servicePrincipalName incorrect when joining AD subdomains
Status: NEW
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: net utility (show other bugs)
Version: 3.0.11
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
: 2416 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-03-02 22:51 UTC by Pat Lougheed
Modified: 2021-08-06 03:17 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pat Lougheed 2005-03-02 22:51:21 UTC
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).
Comment 1 Gerald (Jerry) Carter (dead mail address) 2005-03-03 10:30:29 UTC
*** Bug 2416 has been marked as a duplicate of this bug. ***