Incorrect expiration time for tickets returned from Windows KDCs

Thu Aug 25 16:46:37 EDT 2005

I don't know specifically about the expiration time issue, but I do know
you need to be really careful because Microsoft KDCS will throw error
code 52 - which means you PAC is too big and the KDC wants you to use
TCP.  I don't know what causes this but we have had applications
compiled with older libs work fine until one day the KDC decides to
throw error code 52.  I don't know what changed but it no longer will do
UDP for that user.  

-dan

-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
Of Eric STeadle
Sent: Wednesday, August 24, 2005 1:55 PM
To: krbdev at mit.edu
Subject: Re: Incorrect expiration time for tickets returned from Windows
KDCs

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.

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

-- 
_______________________________________________

Search for businesses by name, location, or phone number.  -Lycos Yellow
Pages

http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default
.asp?SRC=lycos10

_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev