[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: heimdal 0.8.1 w2k interop
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
> 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.