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

[Jeff Layton]

On Tue, 26 Aug 2008 08:14:47 +1000
Andrew Bartlett <abartlet at samba.org> wrote:

> 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?
> 

Definitely a legit question. If we can always fall back to NTLM then
there's very little reason to ever trust the server-supplied principal.

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


Is this no longer the case?

-- 
Jeff Layton <jlayton at redhat.com>