-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 15 Nov 2011 12:10:08 +1100
Andrew Bartlett <abartlet@xxxxxxxxx> 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@xxxxxxxxx>
-----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-----
ÿôèº{.nÇ+?·?®??+%?Ëÿ±éݶ¥?wÿº{.nÇ+?·¥?{±ýÈ?³ø§¶?¡Ü¨}©?²Æ zÚ&j:+v?¨þø ¯ù ®w¥þ?à2?Þ?¨èÚ&¢)ß¡«a¶Úÿÿûàz¿äz¹Þ?ú+?ù???Ý¢jÿ?wèþf
