[PATCH 0/3] cifs.upcall: attempt to use AD-style service principals
jlayton at samba.org
Tue Nov 15 07:15:10 MST 2011
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, 15 Nov 2011 12:10:08 +1100
Andrew Bartlett <abartlet at samba.org> wrote:
> On Mon, 2011-11-14 at 18:04 -0500, simo wrote:
> > On Tue, 2011-11-15 at 09:45 +1100, Andrew Bartlett wrote:
> > > On Mon, 2011-11-14 at 09:44 -0500, Jeff Layton wrote:
> > >
> > > > The above scheme isn't perfect, but in many cases it will happen to
> > > > work. It's true that there's no reliable mapping between DNS and
> > > > samAccountName, but in a lot of cases the samAccountName *is* the
> > > > capitalized host portion of the DNS name. Does it hurt anything to
> > > > attempt to get a ticket with that name if "cifs/fqdn" fails?
> > >
> > > We should never ask for a machine$ name. It is always the wrong thing
> > > to do, because it will only exist on AD servers, which already do the
> > > mapping between cifs/foo and foo$ internally.
> > You are contradicting yourself here.
> > First you say foo may not be the short name then you advocate for not
> > using foo$. But asking for foo$ comes handly exactly when the short name
> > is not the same as the fqdn truncated, as a use may pass on the command
> > line and that's why it was added.
> You should never truncate a FQDN. If the user connects with a FQDN we
> should always use cifs/FQDN as the only name that is attempted.
> > > We should also not map between cifs/ and host/ - cifs/ is a separate
> > > service, just as nfs/ and http/ are.
> > And yet it is possible to have cifs servers work when using the host/
> > ticket. Trying and failing is not a big deal.
> I disagree, and just because some servers accept the host/ principal
> does not mean we should use it. Kerberos specifically defines service
> types, and we should use them as intended.
> > > > Over the years, we've seen a lot of confused users on the list who are
> > > > not sure what name they need to put in the host portion of the UNC to
> > > > get their krb5 mount to work. This scheme seems like it'll make that a
> > > > bit more forgiving.
> > >
> > > I certainly understand the need to make krb5 more forgiving, and
> > > certainly if the KDC indicates that cifs/foo does not exist, then
> > > guessing the DNS domain and asking for cifs/foo.<guessed domain> is
> > > reasonable.
> > >
> > > > If the wrong guesses just end up slowing down the upcall, then I'm ok
> > > > with that. If they potentially open a security hole then that's another
> > > > matter entirely. That's my main question here -- are we opening up any
> > > > vulnerabilities with this scheme?
> > >
> > > Each time you second-guess the name, you open up a small security hole,
> > > because you potentially allow a connection that was to be to a trusted
> > > host to be impersonated by less trusted member of the same kerberos
> > > realm. For that reason, any client-side canonicalisation should be
> > > strictly limited.
> > While this is somewhat true, it is not always true. Sometimes
> > convenience is more important. If a user wants to be sure to get to the
> > right server he only has to provide the full fqdn, and the right match
> > will be done. The only case when the wrong case may happen is when the
> > user only provides the short name. But there isn't much you can do
> > there, unless you want to flatly refuse to work if users do not give a
> > fqdn.
> Allowing the local domain to be appended seems quite reasonable, after
> cifs/ is not found. We could also follow the policy of the local
> kerberos library for other applications.
> > > Furthermore, you may do more than just slow down the upcall - if you
> > > connect to the right server with the wrong ticket (because you guessed
> > > wrong - cifs vs host etc), the only way to find out is if the server
> > > gives you a LOGON_FAILURE error, and I think this will be even harder to
> > > debug.
> > If cifs/ failed and later host/ also fails then there isn't much you can
> > do anyway. You'd be right to complain if we tried host/ first. We are
> > not doing that.
> I still think we should never use host/.
> > > I do want kerberos to be easier to use, and to 'just work' more often.
> > > I care passionately that Kerberos should be both secure and 'just work'
> > > - falling back to NTLM is an even worse fate.
> > >
> > > I just want to ensure we do not become the source of new expected
> > > behaviour patterns for non-AD domains (such as looking up foo$ or
> > > host/foo for cifs shares), as once we start, it will be very hard to
> > > undo.
> > hard in what sense ?
> Patterns of server and administrator behaviour are in part set by
> patterns of client behaviour. Therefore, if Samba starts asking for foo
> $ or host/foo tickets, then administrators attempting to debug failures
> will start creating such principals in their non-AD KDCs, and soon it
> becomes internet folklore and 'best practice'. Once this starts, it is
> very hard to undo, which is why I strongly advocate for doing the exact
> minimum to make this work, and no more.
> No other cifs client asks for foo$ or host/, and Samba even stopped
> doing so indirectly with 3.5.8 (using the server-supplied principal).
Ok, based on the comments so far, how does this sound for a potential
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/".
If we get something that looks like a FQDN, then just prepend it with
"cifs/" and then give up if that doesn't work.
Sound about right?
Jeff Layton <jlayton at samba.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the samba-technical