Incorrect expiration time for tickets returned from Windows KDCs

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Incorrect expiration time for tickets returned from Windows KDCs

Eric STeadle
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/[hidden email]
(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 lifetimes!
  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



--
_______________________________________________

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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Incorrect expiration time for tickets returned from Windows KDCs

Eric STeadle
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/[hidden email]
> > (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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: Incorrect expiration time for tickets returned from Windows KDCs

Wachdorf, Daniel R
In reply to this post by Eric STeadle
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: [hidden email] [mailto:[hidden email]] On Behalf
Of Eric STeadle
Sent: Wednesday, August 24, 2005 1:55 PM
To: [hidden email]
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/[hidden email]
> > (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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev



_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Incorrect expiration time for tickets returned from Windows KDCs

Douglas E. Engert
In reply to this post by Eric STeadle


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/[hidden email]

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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: Incorrect expiration time for tickets returned from Windows KDCs

Andrew Bartlett
In reply to this post by Wachdorf, Daniel R
On Thu, 2005-08-25 at 14:46 -0600, Wachdorf, Daniel R wrote:
> 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.  

This sounds like a case of a growing PAC, when the user becomes a member
(directly or indirectly, as it is a flattened list) of another group.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Incorrect expiration time for tickets returned from Windows KDCs

Matt Crawford
> This sounds like a case of a growing PAC, when the user becomes a  
> member
> (directly or indirectly, as it is a flattened list) of another group.

There used to be a boolean bit of preauth data you could include  
which meant "don't include the PAC in the ticket."  Did it go away??  
I ran into it when users changing their non-windows Kerberos password  
from the Windows secure-channel box would generate an AS_REQ with  
that padata in it.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Incorrect expiration time for tickets returned from Windows KDCs

Andrew Bartlett
On Sun, 2005-08-28 at 19:53 -0500, Matt Crawford wrote:
> > This sounds like a case of a growing PAC, when the user becomes a  
> > member
> > (directly or indirectly, as it is a flattened list) of another group.
>
> There used to be a boolean bit of preauth data you could include  
> which meant "don't include the PAC in the ticket."  Did it go away??  
> I ran into it when users changing their non-windows Kerberos password  
> from the Windows secure-channel box would generate an AS_REQ with  
> that padata in it.

I've not finished figuring that area out (just got the PAC generation
working in our KDC), but remember the flag is negative - if you do not
encode it particularly, you will get a PAC, even to an unknowing client.
(Because it is still useful, for example smbclient to a windows file
server).

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Incorrect expiration time for tickets returned from Windows KDCs

Luke Howard
In reply to this post by Matt Crawford

>> This sounds like a case of a growing PAC, when the user becomes a  
>> member
>> (directly or indirectly, as it is a flattened list) of another group.
>
>There used to be a boolean bit of preauth data you could include  
>which meant "don't include the PAC in the ticket."  Did it go away??  
>I ran into it when users changing their non-windows Kerberos password  
>from the Windows secure-channel box would generate an AS_REQ with  
>that padata in it.

The flag works for the AS-REQ only, not the TGS-REQ. You have to use
the userAccountControl hotfix to avoid including the PAC in service
tickets.

-- Luke

--
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Incorrect expiration time for tickets returned from Windows KDCs

Douglas E. Engert
In reply to this post by Matt Crawford


Matt Crawford wrote:

>> This sounds like a case of a growing PAC, when the user becomes a  member
>> (directly or indirectly, as it is a flattened list) of another group.
>
>
> There used to be a boolean bit of preauth data you could include  which
> meant "don't include the PAC in the ticket."  Did it go away??   I ran
> into it when users changing their non-windows Kerberos password  from
> the Windows secure-channel box would generate an AS_REQ with  that
> padata in it.

I believe it is still there. You have to sent the PA-PAC-REQUEST to the KDC.
But the MIT KDC had problems if this was used. It may be fixed by now.
AD only honored this on the AS_REQ not the TGS_REQ

There is also in AD a way to set NO_AUTH_DATA_REQUIRED "No PAC needed" for
a selected service ticket.  http://support.microsoft.com/kb/832572/





>
> _______________________________________________
> krbdev mailing list             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev