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

[simo]

On Wed, 2008-08-20 at 07:26 -0400, Jeff Layton wrote:
> 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?

Looks completely reasonable.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <simo at redhat.com>