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

Steve French smfrench at gmail.com
Wed Aug 20 17:25:19 GMT 2008


Working around the broken servers by adding the 2nd OID seems a higher
priority.  Whether the 2nd fix (not yet written) for the MechList
should be merged fast or wait till 2.6.28 depends on how big/risky it
is (it is late in the 2.6.27 cycle).

On Wed, Aug 20, 2008 at 10:58 AM, Jeff Layton <jlayton at redhat.com> wrote:
> On Wed, 20 Aug 2008 16:43:04 +0400
> Igor Mammedov <niallain at gmail.com> wrote:
>
>> 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.
>>
>> We certainly can try server supplied principal first in both cases and if
>> needed fall back to a standard principal name.
>>
>> I can fix patch for it by this Friday.
>>
>> PS:
>> It would be nice to remove commit 3d96409c115b3ad4ef29ff75e40b39a26e316afe
>> if possible from samba git tree. So that I could add a fall back support to
>> the corresponding patch, I've sent recently, without resolving merge
>> conflicts first.
>>
>
> Actually, because these are really two separate problems, I'd prefer to
> leave that patch in place and just patch on top of it. It's not clear
> to me that we really want to worry about trying to deal with the
> mechListMIC for 3.2, but we do want to make sure we can handle
> sec=mskrb5 with it.
>
> My suggestion would be that we leave the 3.2 branch as-is and plan to
> deal with the mechListMIC in the 3.3 branch with a patch that applies
> on top of what's already there.
>
> Steve, do you have any thoughts on this?
> --
> Jeff Layton <jlayton at redhat.com>
>



-- 
Thanks,

Steve


More information about the samba-technical mailing list