Bug 705 - net ads join generates wrong (suboptimal) Kerberos service principals
Summary: net ads join generates wrong (suboptimal) Kerberos service principals
Status: RESOLVED DUPLICATE of bug 1651
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.0
Hardware: Other other
: P2 normal
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
Depends on:
Reported: 2003-10-31 16:01 UTC by Eric Horst
Modified: 2004-10-29 06:32 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Eric Horst 2003-10-31 16:01:06 UTC
Example: The hostname of the Samba server is host.dom.washington.edu and it is 
joined to the domain windom.washington.edu. When trying to access files using
\\host.dom.washington.edu\service it fails.  It fails because the service 
principals are in the wrong name.

'net ads status' shows that 'net ads join' had generated service principals:

  servicePrincipalName: CIFS/host.windom.washington.edu
  servicePrincipalName: CIFS/host
  servicePrincipalName: HOST/host.windom.washington.edu
  servicePrincipalName: HOST/host

The problem:  The DNS name or name being used to access the host must agree 
with the service principal name. Windows servers don't act like this.  We 
currently have Windows and Samba servers in several DNS domains joined to a 
single Windows domain.  Kerberos principals work out right so they can be 
accessed with their DNS name.  I suggest that this is a bug and that service 
principals (at least CIFS) be generated using the hostname of the host rather 
than taking liberties by chopping the name and appending the domain it is 
Comment 1 Gerald (Jerry) Carter (dead mail address) 2003-12-12 08:28:04 UTC
reseting target milestone.  3.0.1 has been frozen.  WIll have to 
re-evaluate these.
Comment 2 Gerald (Jerry) Carter (dead mail address) 2004-10-26 07:50:59 UTC
Comment 3 Gerald (Jerry) Carter (dead mail address) 2004-10-29 06:32:18 UTC

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