[linux-cifs-client] [PATCH 0/5] cifs: add support for MSKRB5 authentication

Jeff Layton jlayton at redhat.com
Wed Aug 20 11:26:36 GMT 2008


On Wed, 20 Aug 2008 13:46:53 +0400
Igor Mammedov <niallain at gmail.com> wrote:

> Jeff Layton wrote:
> > On Mon, 18 Aug 2008 15:41:04 -0400
> > Jeff Layton <jlayton at redhat.com> wrote:
> > 
> >> We've now had support for some time for "regular" KRB5 authentication,
> >> but there are some servers that only support the Microsoft KRB5
> >> auth flavor. This patch adds support for that auth flavor to Linux CIFS.
> >>
> >> The main change is that the "mechListMIC" string is now parsed out of
> >> the SPNEGO reply from the server. We then pass that to userspace as
> >> part of the upcall string. The upcall program then can use that info
> >> to build a SPNEGO blob for MSKRB5 authentication.
> >>
> >> Igor Mammedov already has a patch that adds this support to the
> >> upcall program, and I can confirm from network captures that I can
> >> successfully authenticate to a Win2k3 server using MSKRB5.
> >>
> >> I'll plan to commit his cifs.upcall patch if this approach looks OK.
> > 
> > As Steve and I discussed on #samba-technical today, it turns out that
> > all of this parsing of the mechListMIC is unnecessary. The *only*
> > difference between the KRB5 and MSKRB5 is the OID used. They are
> > exactly the same otherwise. Supposedly, this was a bug in win2k and for
> > compatibility reasons, later windows versions generally send this broken
> > OID first.
> > 
> > So it turns out that we really only need patch 5 in this set, though
> > patch 1 is also a good cleanup. Steve has taken those in. I've respun
> > the cifs.upcall patch and will be sending it out soon. 
> 
> Practically there is a difference between using mechListMIC or not with
> MS_KRB5. Server supplies in it principal that is ALWAYS VALID for realm where
> server located (assuming that we have MS ADS as auth server).
> Now lets suppose that we have several aliases for server's ip, but usually
> only one of them is listed in ADS as "servicePrincipalName" in long and
> short form like:
> "servicePrincipalName" = HOTS/hostname
> "servicePrincipalName" = HOST/hostname.domain.name
> Here is problem, KDC will not issue service ticket for alternative hostnames
> because of there is no such principal in ADS. Possible solution is to use
> principal supplied by server in mechListMIC when doing MS_KRB5.
> Thats why cifs mount will fail when any Windows client will work anyway.
> 
> That will affect many current ADS installations.
> I've seen that case in my place when using cifs with DFS: as referral for share
> cifs gets server1.domain.foo  from DFS ref response, in negotiation stage with 
> server1.domain.foo it says that it can do MS_KRB5 with mechListMic = machine_name$@MY.REALM.
> Doing auth with server1.domain.foo as principal will fail because of it is just
> another name for server not reflected in ADS but doing auth with principal 
> machine_name$@MY.REALM will succeed without trouble because ADS always has principals
> for workstations in its domain.
> 
> As Simo once said we would like to make it working for the most possible environments,
> and if possible without fighting with windows admins for fixing/changing settings on their
> ADS/DNS servers (if I recall correctly because of there is no linux officially in
> the enterprise and penguins went underground :) ).
> 
> So could you reconsider handling of mechListMIC? 
> 

We can certainly reconsider it, but these are really two separate
problems:

1) there are servers that *only* understand the MS_KRB5 OID -- for
instance, the NetApp filer in the original bug report and apparently
some or all Win2k versions. The kernel and userspace patches already
committed should fix this.

2) the problem you mention above where CNAME's or broken DNS
configuration make it difficult to construct the principal name from
the hostname that the client has. If parsing out the mechListMIC makes
this better, then I'm all for it.

However, if we're going to parse out the mechListMIC, then why only
handle it for MS_KRB5? Shouldn't we plan to use it for "normal" KRB5 as
well? Here's what I'm thinking:

Have the kernel parse out the mechListMIC and pass it to the upcall
(like the other patches in the set I proposed before did). Have the
upcall prog try to use the mechListMIC as the principal name. If that
fails, then we'd fall back to using host/hostname.domain.name or
cifs/hostname.domain.name, like we do today.

Thoughts?
-- 
Jeff Layton <jlayton at redhat.com>


More information about the samba-technical mailing list