Re: heimdal 0.8.1 w2k interop

[Andy Polyakov <appro@fy.chalmers.se>]

Hi,

I apologize for not responding in timely fashion. Vacation and other 
activities were in a way.

>> We've found ourselves in catch 22 situation. There was one thing
>> preventing us from upgrading our KDCs from heimdal-0.6.x and that was
>> Windows 2000 clients. But now we've got another kind of clients on
>> network, namely Thursby's ADmitMac, which unconditionally want to
>> perform pre-authentication with encryption type not supported by
>> 0.6.x :-( Attached patch makes it possible for 0.8.1 KDC to
>> inter-operate with Windows 2000, yet authenticate newer clients. There
>> are apparently two things Windows 2000 are allergic to: encryption
>> types "newer" than ETYPE_DES3_CBC_SHA1 in PA_ENCTYPE_INFO, and
>> [paradoxically enough] own ETYPE_ARCFOUR_HMAC_MD5 tickets. And that's
>> basically what we try to address. The patch was tested with Windows
>> 2000, XP, Vista, MIT krb5 1.3.x, whatever found in Solaris 8, not to
>> mention ADmitMac.
> 
> So basicly sending anything other then
> 
> ETYPE_DES_CBC_CRC
> ETYPE_DES_CBC_MD4
> ETYPE_DES_CBC_MD5
> ETYPE_DES3_CBC_SHA1
> ETYPE_ARCFOUR_HMAC_MD5
> ETYPE_ARCFOUR_HMAC_MD5_56
> 
> In etype-info pa is a bad idea ?

Worse. Even ETYPE_ARCFOUR_* confuses W2K, so that above list ends at 
ETYPE_DES3_CBC_SHA1. In fact, if you take W2K domain controller and 
*unjoined* W2K workstation, run ksetup /addkdc on the latter and point 
at the former as if it was a generic KDC, it *won't* work. Apparently 
ETYPE_ARCFOUR_* types are allowed only when W2K knows for sure it's 
talking Kerberos to actual domain controller or in other words is joined 
to corresponding domain. Presumably it's explicitly hard-coded limitation.

> I sure ETYPE_ARCFOUR_HMAC_MD5 works with XP just fine.

I had problems even on XP with "own" acrfour tickets, naturally on 
*unjoined* client. More specifically I have a secondary Kerberos logon 
application, http://fy.chalmers.se/~appro/nt/klogon/, which attempts to 
overcome particular runas /netonly limitation by acquiring session key 
to "itself," i.e. to currently logging in user principal. Trouble is 
that if returned ticket is arcfour encrypted, then AcceptSecurityContext 
SSPI function fails (I can't recall error code).

> What part of ADmitMac will take a password ?

I don't understand the question. ADmitMac implements plugin for 
loginwindow application, but I don't know if it passes the password to 
some other component and obtains TGT itself and passes on the ticket. In 
either case, normally negotiation goes like "give me tgt," "you have to 
pre-authenticate, btw, here are available etypes," "all right, here is 
pre-auth data encrypted with this algorithm, can I have tgt now?" 
ADmitMac goes like "here is pre-auth data encryped with acrfour-hmac, 
give me tgt." Does this answer question? A.