Bug 2416 - servicePrincipalName incorrectly generated when joining Active Directory using subdomains
Summary: servicePrincipalName incorrectly generated when joining Active Directory usin...
Status: RESOLVED DUPLICATE of bug 2414
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control (show other bugs)
Version: 3.0.11
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-03 10:08 UTC by Pat Lougheed
Modified: 2005-03-03 10:30 UTC (History)
0 users

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-03 10:08:53 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:28 UTC
please don't opne new copies of the same bug.

*** This bug has been marked as a duplicate of 2414 ***