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

[Steve French]

These days it better be NTLMv2 ...

On Mon, Aug 25, 2008 at 7:27 PM, Jeff Layton <jlayton at redhat.com> wrote:
> 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>
>



-- 
Thanks,

Steve