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

Q (Igor Mammedov) niallain at gmail.com
Wed Aug 20 19:08:41 GMT 2008


On Wed, Aug 20, 2008 at 7:58 PM, 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.

+1 for server supplied principal to be in 3.2 is because of it is
reference behavior
for an older windows and it makes an auth less troublesome because of
it does not
require to know a hostname used for a service principal.


>
> 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.

Why only 3.3 branch?
I think, It will take a lot of time for 3.3 to be ready for a release
and +more for
being included into distrs.

I would put cifs.upcall with a server supplied principal to the both
branches so that
when a kernel supporting the feature is released it will just work
instead of building
and installing new samba with a kernel upgrade.

> Steve, do you have any thoughts on this?
> --
> Jeff Layton <jlayton at redhat.com>
>


More information about the samba-technical mailing list