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

[Jeff Layton]

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.

-- 
Jeff Layton <jlayton at redhat.com>