Comments inline prefixed with Tim> : -----Original Message----- From: Jeffrey Altman [mailto:[EMAIL PROTECTED] Sent: 08 September 2004 09:19 To: Tim Alsop Subject: Re: "key type not supported" and XP SP2 changes ?
Tim Alsop wrote: > Jeffrey, > > We have been using DES keys with MS AD KDC's for last 4 years and now > we have discovered we can use RC4-HMAC tgt with XP SP2. Before SP2 we > have been able to use RC4 tgt with Windows 2000 workstations only. We > are therefore trying to make it work with XP SP1. This statement is one of the most confusing. Under what conditions will XP not obtain an RC4-HMAC session key? I've been using XP for a long time now and it always uses an RC4-HMAC key unless the user account has been marked as DES only. Tim> Yes, it will not get an RC4 session key when the account in AD is marked as DES only. This is the only time it will not be RC4 as far as I am aware and this is what I was referring to. I hope this clears up any confusion. Let us continue ... > As I mentioned before we are not requesting the tgt so we cannot ask > for a DES-CBC-CRC or DES-CBC-MD5 tgt in the request. We are simply > reading the LSA cache and the Microsoft code is requesting the tgt > from AD. The way I understand it works is that our code reads the tgt > to check it is present and valid, then we read the service ticket to > see if this is present and valid. If the MS LSA sees a request to read > a ticket that is not present it asks AD to issue the ticket rather > than answering "ticket not present". I also understand that our code > is validating the ticket by looking at the etype and this is causing > the problem when it sees the > RC4 key. This is where you are making your mistake. The API for Requesting a Ticket from the KDC is the KerbRetrieveTicketMessage. If you ask it for a service ticket of the form "krbtgt/[EMAIL PROTECTED]" you are asking for a query to be sent to the KDC. It is up to the LSA to determine if the request is satisfied from the cache or not. Requesting the TGT should not in general be used to determine if the LSA is appropriately authenticated using "Kerberos". It does not matter if there is a TGT there or not as Windows caches the username and password at logon. If there is no valid TGT, Windows will obtain one (if possible) when you query for an arbitrary service ticket. Tim> Ok, I am not a developer so I was not aware of this, but your explanation makes sense. Thank you for educating me :-) However, if you want to ensure that you obtain a TGT with a DES enctype all you do is specify the EncryptionType of the KERB_RETRIEVE_TKT_REQUEST to be DES_CBC_MD5 or DES_CBC_CRC and you will get a TGT returned to you with a session key of the specified type. Windows does not provide any API other than the KerbRetrieveTicketMessage to obtain the body of a Kerberos ticket so I know this is the API you must be using. Tim> ok, as you know a gss-api application does not ask for a tgt so we must be just asking for a service ticket (during the initiate context request). When we ask for a service ticket the LSA will presumably determine that a tgt already exists (with rc4 session key) and then (for some reason) we get an error because our code does not recognise the rc4 etype. If all you want to know is whether or not the cache contains a ticket that is named "krbtgt/[EMAIL PROTECTED]" with a valid expiration time, then you should not be using KerbRetrieveTicketMessage but instead should be using either KerbQueryTicketCacheMessage (on Win2000) or KerbQueryTicketCacheExMessage (on XP). However, as I pointed out above the failure to find a TGT in the cache is really meaningless given the fact that the username and password for the Windows account used to obtain the TGT are cached in the LSA. Tim> we are not planning to change the way our code works - we just want to understand why we get this problem with SP1 and see if there is a way to make SP1 work same way as SP2. Clearly there are many things we can do to our code to circumvent the Sp2 upgrade and this is being considered as one of the options, but the preferred option is for MS to issue a hotfix in order to allow the SP2 functionality to be available in pre-SP2 XP workstations. > In response to Sam's suggestion about mapping unsupported keytypes - > yes, this is an option for us, but we are trying to investigate all > options available and make a decision about the best way forward in > short term. It appears the main options are (in no particular order) > (i) convince customer to upgrade to SP2, (ii) add rc4 support to our > code quicker than previously planned, (iii) modify our code so it > ignores the error or maps rc4 onto null etype, (iv) use des keys for user accounts. There is no need for any of this. Tim> So, if there is no need for (i) (ii) (iii) or (iv). What do you suggest is the answer to our problem ? > We are only looking for this solution for 1 client who cannot upgrade > to > SP2 for other reasons. Our product is the first product that will be > using kerberos other than MS operating system use of the protocol. I > don't understand why upgrading kerberos.dll is any different to being > able to apply the part of SP2 that is needed - are you suggesting that > SP2 will break other third party products ? Yes. SP2 has broken third party products. Third party products have been forced to modify their use of the LSA in order to obtain the same level of functionality. Vendors test the OS Version and Service Pack level to determine which set of functionality is available in each OS release. The XP SP2 functionality is equivalent to the 2003 functionality. This is different from the 2000 through 2000 SP4 functionality and the XP through XP SP1 functionality. I expect that 2000 SP5 will support a different subset and that 2003 SP1 will be significantly changed as well. Tim> Sounds like we will have "fun" for many years to come then :-) > Yes, we plan to open a PSS request with MS if we decide this is the > best way forward in short term. > > Thanks again, > > Tim. -- ----------------- This e-mail account is not read on a regular basis. Please send private responses to jaltman at mit dot edu ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
