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

[Jeff Layton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
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/".

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)

iQIcBAEBAgAGBQJOwnPvAAoJEAAOaEEZVoIV3MkP/jIf1sUkP3WmWa/8TI3jqxvH
pAwahEGP0QM56rRKHkcnwIBClwwZ+fO8VxF4gXs42Hqqe1DozsKVcWp2N93VW7X7
o+Z221Z+HEO2WpXGl7NxaJcno0+/lXDUTL+Ui6eEsS55jv3ieHk8tehNv6MFJc2D
2bmdLyNWIOBFDlxIHIK1ChjCSE5j7DDgtOYI/7bf4wHKYhtbFNYvOXyPOSFDl5eT
9cqZMu8hD5vuNDNdAfHpe0pA7j+qRkXuOa61ElKL8fTUOz67iOS0jwg4gg8xQe8o
ipWW3M5rxsGoAnUagA/acwoqcymvpDoDwtDYKBzdwZUbN/+9fmMIC7AMtyad8n59
wENO/xlXnO6TUizWdNSrOLZQ3sZekkn/hzJkOP/iWnrCDWjsWUmRFxq4FZ7E6SGl
GP9ABiNwLf/f8u43I4ojqRVDGOcj7dL8JxEtAzVJB9uKUg6vbCw3zJv1oEeXl/wl
S9vmzy0D2TnAMImnGUR/Vm1XBBgQSOVkHl/rUIO2R2tefiel+f7FSQphVBk/NTvj
A2TpSk5otm5RwvEpBfPJ2QsbaNpkDJAqost7ScABOGqWqKAw3Xvv5VrLXo9vx+uO
OJ4yIq5HHA0e0aBGzXXw27+7wUDW6PqZMZA7gGtaSNMbcRiMqKNowm6F1r5fzCJ3
5u6wb7Z/ZRU8W69thBAf
=pkM5
-----END PGP SIGNATURE-----