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

Jeff Layton jlayton at redhat.com
Mon Aug 25 15:30:50 GMT 2008


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?

-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list