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

[Igor Mammedov]

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? 

-- 

Best regards,

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