[PATCH 0/3] cifs.upcall: attempt to use AD-style service principals

[Jeff Layton]

On Thu, 17 Nov 2011 21:16:40 +1100
Andrew Bartlett <abartlet at samba.org> wrote:

> On Wed, 2011-11-16 at 11:08 -0500, simo wrote:
> > On Wed, 2011-11-16 at 08:37 +1100, Andrew Bartlett wrote: 
> > > On Tue, 2011-11-15 at 09:15 -0500, Jeff Layton wrote:
> > > 
> > > > Ok, based on the comments so far, how does this sound for a potential
> > > > scheme:
> > > > 
> > > > 	INPUT: foo
> > > > 	TRY:
> > > > 	    FOO$
> > > > 	    cifs/foo.[guessed domain]
> > > > 
> > > >	INPUT: foo.example.com
> > > > 	TRY:
> > > > 	    cifs/foo.example.com
> > > > 
> > > > To summarize, for shortnames, we'd try SHORTNAME$ first. If that fails,
> > > > then guess a domain name, append the value to the hostname, and prepend
> > > > it with "cifs/".
> > > 
> > > No, we should never use FOO$ (this is AD only, and equivalent to
> > > cifs/foo), so we should instead simply do:
> > > 
> > > INPUT: foo
> > > TRY:
> > >     cifs/foo
> > 
> > This ^^^^ is also AD-only, so what's the point of objecting to one or
> > another ?
> > At least when you see FOO$@REALM, admins know it is an AD only thing.
> 
> The reason that we should not translate between foo and foo$ on the
> client side is that a server may have multiple service principal names.
> A host with multiple names will have only one machine account in AD, and
> we have no way to know that this particular name is that of the machine
> account.
> 
> Also, while requests for cifs/foo will cause a lookup of host/foo and
> foo$ on the server side, this is a server-side fallback, not an absolute
> rule.  If an account has the more specific form as a
> servicePrincipalName, then implicit mappings are not needed.  We cannot
> on a client make assumptions about how the administrator has configured
> their domain.
> 
> Finally, cifs/foo is a perfectly valid and reasonable kerberos service
> principal name, and the name that other cifs clients such as Samba 3.6,
> and Windows will use, and so we should ensure constancy with those
> clients to reduce the administrator burden in the non-AD case. 
> 
> Indeed, it is this final reason why this process is futile.  The correct
> fix is to ensure that the non-AD KDC has principal entries for each
> aliases (cifs/foo and cifs/foo.domain) by which the server can be
> resolved. 
> 

Ok, to summarize:

Andrew says that there's no reason to ever try to get anything but
a "cifs/" principal. In the case of an unqualified hostname, we should
try to get a "cifs/" principal with the given hostname first, and then
append a guessed domain name if that fails.

Simo are you in agreement here? Or can you think of any cases where we
should try to do anything different?

Another question:

Most KDC's are case-sensitive, but DNS is generally case-insensitive.
Should we attempt to convert the hostname to all-lowercase when
constructing the principal name to use? I don't think we want to
encourage admins to put in principals for all possible combinations of
upper and lower case...

-- 
Jeff Layton <jlayton at samba.org>