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. 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. 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. 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. > 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. > 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. > 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
