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

[Igor Mammedov]

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.

-- 

Best regards,

-------------------------
Igor Mammedov,
niallain "at" gmail.com