Incorrect expiration time for tickets returned from Windows KDCs

[Douglas E. Engert]

Eric STeadle wrote:
> Hi Douglas, 
> 
> Thanks. I appreciate your suggestion. I guess I should have mentioned that this is a product which was deployed well over 2 years ago and is in the field today (as a sunsetted product). I don't have the ability to upgrade to a new library version because the applications were compiled statically. 
> 
> I'd like to understand whether this is a new problem that was introduced by the uprev of Windows 2003 server to SP1, or whether I have to look elsewhere (for someone to blame :) I had hoped that someone in the community would tell me "nope, I'm using 1.2.5 with Windows 2003 SP1 with absolutely no problems" or "yep, Windows 2003 SP1 doesn't work with 1.2.5 because the blah blah doesn't understand that whatsit thingie". 
> 
> My current suspicion (after re-reading the troubleshooting chapter in Jason Garman's excellent book "Kerberos The Definitive Guide) is that the password for the account that is retrieving the tgt has never been changed on the KDC / AD server, and as a result has a key which used the RC4/HMAC encryption type rather than DES encryption. I would think that a problem like this would manifest as an unsupported encryption type error, but my experience with Kerberos thus far is that nothing should be assumed nor ruled out based on the error code alone.
> 
> Again, I appreciate any help, insight, or suggestion that anyone offers. 
> 

I see you have some network trace program. The ethereal network
tracer, http://www.ethereal.com/ which knows about the Kerberos protocols.
You can then look at the AS_REQ, AS_REP and KRB_ERROR messages between the
client and KDC.


> Thanks,
> 
> Eric Steadle
> 
> 
> 
> ----- Original Message -----
> From: "Douglas E. Engert" 
> To: "Eric STeadle" 
> Subject: Re: Incorrect expiration time for tickets returned from Windows KDCs
> Date: Mon, 22 Aug 2005 14:10:57 -0500
> 
> 
>>Start with a up today Kerberos implementation. MIT 1.2 does not 
>>support some features
>>you will need when using AD as the KDC, including TCP support for 
>>large tickets.
>>You need at least 1.3.2 MIT currenly has 1.4 wich is even better.
>>
>>
>>
>>Eric STeadle wrote:
>>
>>
>>>Hi, I've written a kerberized application that uses the MIT 
>>>Kerberos libraries to obtain tickets from a Microsoft KDC. I'm 
>>>using version 1.2.5 of the libraries for this application, and 
>>>it's worked just fine until recently. Now, all of a sudden, 
>>>tickets are apparently being returned from the Authentication 
>>>Server with their expiration time set to 0 (Jan 1, 1970, 00:00). 
>>>When these tickets are re-presented to the TGT to obtain service 
>>>tickets for the application, the KDC replies with 
>>>KRB5KRB_AP_ERR_TKT_EXPIRED. I have a packet trace between my 
>>>host, and the KDC, which looks roughly like this: 

 >>>1 AS-REQ (Client: HOST/SERVER01, Server: krbtgt/SERVER.DOMAIN.COM)
>>>2 AS-REP  (KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN)
>>>3 AS-REQ  (Client: username, Server:krbtgt/SERVER.DOMAIN.COM)
>>>4 AS-REP  (Success, ticket returned)

What are the times in this AS_REQ and AS_REP ticket? Can you use
ethereal to look at them?


>>>5 TGS-REQ (Server: ldap/dc1/SERVER.DOMAIN.COM)
>>>6 TGS-REP (KRB4REP_AP_ERR_TKT_EXPIRED)
>>>
>>>Although I can't decrypt the ticket returned in 4 from the packet 
>>>trace, my suspicion is that the expiration time returned by the 
>>>KDC in that ticket is set to "0". I confirmed this by listing the 
>>>ticket cache with klist:
>>>
>>> Valid starting     Expires            Service principal
>>> 08/18/05 12:29:49  12/31/69 16:00:00 
>>>krbtgt/SERVER.DOMAIN.COM at SERVER.DOMAIN.COM

I tried a MIT-1.2.3 version on Solaris against  W2003 and could not
reproduce the problem, but did not change the AD.

Since you are speculating that the admins changed something in AD,
you might want to also try the kinit -r options to see if
renewal has anything to do with it.

You could also try the latest Kerberos on the client to see
if it has the problem, or gets a better error message.


>>>(This host is set to PST, so the expiration time makes sense if I 
>>>take into account the 8 hour difference between it and GMT). I do 
>>>not have access the KDC to determine whether there are registry 
>>>settings that may be affecting the tickets returned by the KDC, 
>>>however, I have asked to have those settings reported back to me. 
>>>My suspicion was that the Kerberos policy on the KDC was 
>>>modified. One of the settings listed at the link below allows the 
>>>administrator to set the default user and service ticket 
>>>lifetimes to something other than 10 hours. Setting this value to 
>>>0 is supposed to make the ticket good for eternity.

Not a good idea, defeats the purpose of Kerberos. If they really
really want long tickets, how about a 1 year ticket instead?

>>> This seemed 
>>>reasonable so I tried modifying the default service ticket 
>>>lifetime on my test KDC, to see how this affected tickets 
>>>retrieved by kinit.

Which service did they change? It looks like it is krbtgt service
ticket that has the problem. Was the krbtgt changed? Or was the ticket
lifetime for the user changed?

If you use the Windows kerbtray.exe (ints in the resource kit I beleiev)
you can see what an all Microsoft ticket looks like. (KfW could also
show this when it imports tickets.)


  What I found was that it didn't seem to
>>>affect tickets returned by kinit. Regardless of the setting on 
>>>the KDC, the client gets tickets which are valid for 10 hours. 
>>>The only way to affect the ticket lifetime seems to be to specify 
>>>a shorter timeout period to kinit via the "-l" option. 
>>>(Specifying longer timeouts does not result in lifetim
>>
>>es!
>>
>>>  appreciably longer than 10 hours -- I believe this is a known 
>>>bug with the libraries at v 1.2.5). 
>>>http://www.windowsitpro.com/Article/ArticleID/15313/15313.html
>>>
>>>
>>>
>>>
>>>Does anyone have any suggestions as to how to diagnose this 
>>>problem? I've tried everything I can think of. I searched through 
>>>the archives and the only reference to the error reported above 
>>>that I could find doesn't seem relevant: 
>>>http://mailman.mit.edu/pipermail/krb5-bugs/2004-January/002141.html
>>>
>>>
>>>
>>>Thanks for help and suggestions. Eric Steadle
>>>
>>>
>>>
>>
>>--  Douglas E. Engert  
>>  Argonne National Laboratory
>>  9700 South Cass Avenue
>>  Argonne, Illinois  60439
>>  (630) 252-5444
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444