[linux-cifs-client] Re: [PATCH] Add support for using server supplied principal (mic option)

[Andrew Bartlett]

On Mon, 2008-08-25 at 14:57 -0400, Jeff Layton wrote:
> On Mon, 25 Aug 2008 11:30:50 -0400
> Jeff Layton <jlayton at redhat.com> wrote:
> 
> > On Mon, 25 Aug 2008 18:02:04 +0400
> > Igor Mammedov <niallain at gmail.com> wrote:
> > 
> > > Jeff Layton wrote:
> > > > On Mon, 25 Aug 2008 13:31:35 +0100
> > > > Love Hörnquist Åstrand <lha at kth.se> wrote:
> > > > 
> > > >>> A correct configuration would use many CNAMEs all pointing to 1 A  
> > > >>> NAME,
> > > >>> the one used to join AD.
> > > >>> I would stick to a secure behavior and disable fetching a ticket using
> > > >>> the MIC information by default.
> > > >> Use "setspn -a host/alias computername" to add the aliases to the SPNs  
> > > >> and it doesn't matter what name the client uses.
> > > >>
> > > >> The gssapi library does dns canon, its wrong, but there is no good way  
> > > >> to stop doing since that breaks stuff :(
> > > >>
> > > > 
> > > > I'm not that familiar with setspn, but I assume it's a server side
> > > > tool.
> > > 
> > >  
> > > > Sometimes it turns out that people are using Linux in
> > > > environments with windows admins that aren't cooperative, or it's just
> > > > too much hassle to do the paperwork to get them to do anything
> > > > server-side. 
> > > 
> > > That's exactly what happens at my work place, complicated by wrong
> > > hostnames used as DFS refferals (i.e. all submounts are automatic).
> > > Server supplied name solves this problem.
> > > 
> > > > We'd like to allow users to still use krb5 in these
> > > > environments. Anything we can do on the client-side to make this
> > > > possible without compromising security is probably something we want to
> > > > pursue.
> > > > 
> > > > Allowing the user to explicitly specify the server principal seems like
> > > > it might also help the canonization problem, though I also haven't
> > > > tested this. Does anyone forsee an issue with that approach?
> > > 
> > > I do not see why supplying principal explicitly can help?
> > > Specifying a principal or hostname explicitly implies that we know a valid 
> > > (registered in KDC) principal or hostname. So we may use just a valid
> > > hostname and don't bother with an additional option for a principal.
> > > 
> > 
> > Right, it does mean this. My understanding of this, please correct me
> > if I'm wrong:
> > 
> > Currently, the "host" that we pass to the upcall is basically what's in
> > the host portion of the UNC. We may not be able to build the correct
> > principal name from this info or by doing a reverse lookup of the IP
> > addr of the server. Different DNS servers, CNAMES, etc. are certainly a
> > way that this could happen, but there are other possible problems too.
> > The default krb5 realm of the host could be different than what's
> > needed, for instance, or maybe the canonization of the hostname changes
> > the case or the domain so that the principal won't match.
> > 
> > We could allow someone to specify a different hostname as a mount
> > option and pass that to the upcall, but why do it in such a limited
> > way? If we allow someone to specify the exact principal that should be
> > used then that's less ambiguous and should help in working around all
> > of these potential problems.
> > 
> > Anything that I'm missing by this?
> > 
> 
> Errr...of course this idea does nothing to help people that are chasing
> DFS referrals. For those, I don't see much that can be done aside from
> adding a mount option to allow the kernel to parse out and trust the
> mechListMIC as a server-provided principal.

So, we have sites that use CIFS to non-Microsoft servers from Linux
clients to AD, that use MSDFS, but not any windows clients (which will
not use this hack) to those servers?

Seriously, why bother with kerberos for security if you are going to
compromise it?

The original reason we allowed this in the first place (in Samba3) was
that machine accounts were not permitted to do NTLM, and we needed a
'way in' to Microsoft domain controllers, on broken networks.  If the
admin cannot set up the correct environment for kerberos, then let them
knowingly use NTLM.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080826/dedc0d82/attachment.bin