none
Does a user get prompted to reenter this password when their TGT (ticket granting ticket) reaches the end of it renew until date

    Question

  • Hello All

    Can someone please help me with the following question

    I saw a similar post to my question at the following location

    https://social.technet.microsoft.com/Forums/office/en-US/e7919d47-1d64-4f6c-9f2f-74c6b4b82f45/domain-user-reauthentication?forum=winserverDS&prof=required

    which also referenced a document at the following location

    https://technet.microsoft.com/en-us/library/cc772815(WS.10).aspx#w2k3tr_kerb_how_pzvx

    The above document in particular is quite thorough, however it does not answer (unless I missed it) the question I need an answer to; at least it does not state the answer although it may infer it, but I may come to the wrong conclusion when something is inferred, if you see what I mean :) 

    Lets say we have a user logged in from a Windows 7 desktop computer to a domain running Windows 2012 R2 

    I am only concerned about the TGT (ticket granting ticket) in this instance 

    by default the maximum renewal life time of the TGT (renew until) is 7 days

    the 'cache' as referred in the above document is held in RAM, so let's assume the user does not logoff his/her computer (always computer is always on and user never logs off) and therefore the cache is still available and held in memory

    what 'actually happens' with regard to the TGT at the end of the 7 days for example

    1) Does the logon GINA (CTRL+ALT+DEL logon screen) suddenly appear and ask the user for credentials? 

    2) Does the GINA appear when the user requests a new TST (ticket service ticket) for a new resource for example, as they cannot use the currently cached TGT

    3) Is a brand new TGT (not a renewal) issued to the user, 'but without' the GINA coming into play as the sub-systems (LSASS) uses the 'cached' information (users long term key, or is that never cached even in RAM) to encrypt a 'new' pre-authenticator 

    Basically I am thinking about a situation where a PC is left alone (on top of a shelf in a cupboard for example) and you return to it three weeks later, will the user that originally logged on to the computer have a 'current' TGT e.g. the initial 7 day TGT has gone but the information in the cache on the computer was enough (e.g. users long term key) to create a 'new pre-authenticator' and thereby obtain a brand new TGT from the KDC (without further user intervention)

    Thanks all in advance

    __AAnotherUser



    AAnotherUser__

    Monday, February 6, 2017 10:47 AM

Answers

  • Hi; I've read your entire post and your reply asking for clarification.  You are asking a very straightforward question in the Subject line:  "Does a user get prompted to reenter this password when their TGT (ticket granting ticket) reaches the end of it renew until date?"  The answer is no, the user does not get prompted.  The reason why is simple.  Here's an analogy I like to use.  As long as the user is logged in (or logged in and the workstation is locked), Kerberos ticket renewal works like DHCP, they will just keep on automatically renewing with no user intervention.  "The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password."  Kerberos is my favorite subject and as such, I found this reference for you, which is where the quoted statement came from:  Kerberos Explained.  

    To get to your other questions, copied in from both of your posts: "so let's assume the user does not logoff his/her computer (always computer is always on and user never logs off) and therefore the cache is still available and held in memory  what 'actually happens' with regard to the TGT at the end of the 7 days for example.

    1) Does the logon GINA (CTRL+ALT+DEL logon screen) suddenly appear and ask the user for credentials?  

    Answer:  No

    2) Does the GINA appear when the user requests a new TST (ticket service ticket) for a new resource for example, as they cannot use the currently cached TGT  

    Answer:  No.  (And you don't call it TST, just "ST".)

    3) Is a brand new TGT (not a renewal) issued to the user, 'but without' the GINA coming into play as the sub-systems (LSASS) uses the 'cached' information (users long term key, or is that never cached even in RAM) to encrypt a 'new' pre-authenticator    

    Answer:  Yes.  Brand-new TGT is obtained as needed automatically, without GINA coming into play. For the sake of brevity, basically, the long-term key never leaves the user's workstation, it stays inside the LSASS cache.  Only an authenticator (along with some other information, you can find it in the reading material) is sent outbound to the KDC to prove identity.

    4) As far as I am aware (need to do a bit more reading), when a user logons on to his/her workstation/laptop they have to get a TGT but also a service ticket for their workstation/laptop they are logging on to.

    Answer:  Yes

    5) I also believe (from the limited amount I have read so far) when you present a service ticket (for example to access a CIFs Share on a remote computer) you present your service ticket (e.g. the one you got from the KDC) (and your authenticator) to access to the Service at which point the computer running the service checks your service ticket to make sure it is still valid as far as time goes e.g. not expired (apart from decrypting the ticket that is)

    Answer:  Yes

    6) So lets assume a user logs on to their workstation and then maps a drive to a network share. next they start a script to create a new file on the share every 30 minutes  then they walk away from their workstation and come back two months later (assuming you do not have to change your password every 30 days etc.)    It occurs to me as the users workstation and the server running the CIFs share checked the service tickets (the one to access the workstation and the one to access the CIFs share) and both ticket were valid at the time of checking, then the script will still be creating new files on the share every 30 minutes even thought the original service tickets (and the TGT including any renewals) had long expired.

    Answer:  Correct, but you are thinking about this wrong.  The logged-in session will have obtained new TGT from KDC as needed, per earlier explanation, in order to keep on presenting a fresh ST to the CIFS share.


    Best Regards, Todd Heron | Active Directory Consultant

    • Marked as answer by AAnotherUser Tuesday, February 7, 2017 5:07 PM
    Tuesday, February 7, 2017 12:54 PM
  • I've answered the original question; you should mark it as such so that it may help others when searching for the same or similar question.  You asking about a lot of things in one question, it is not fair to the one answering the questions.  The question about the PAC is yet another question.  The ST and there PAC inside of it is checked one time, and an authentication token is constructed off of that and the application will then hand back to the client some sort of session key to continue to verify the user if it feels the need to do so.  These session keys can time out.  It is entirely up to the application when to re-check the session key, or if, it wants to demand to see the Kerberos ST again; it is not up to Kerberos.  So your mileage may vary depending upon the application.  The long-term key is held somewhere on the client system and never leaves it.  Not sure exactly where - you'll have to read the docs to be certain of it.  Don't forget to mark all responses as answers if you've found these helpful.

    Best Regards, Todd Heron | Active Directory Consultant

    • Marked as answer by AAnotherUser Tuesday, February 7, 2017 5:08 PM
    Tuesday, February 7, 2017 4:49 PM

All replies

  • Hi,
    As far as I know, a Kerberos ticket has two lifetimes: a ticket lifetime and a renewable lifetime. After the end of the ticket lifetime, the ticket can no longer be used. However, if the renewable lifetime is longer than the ticket lifetime, anyone holding the ticket can, at any point before either lifetime expires, present the ticket to the KDC and ask for a new ticket. That new ticket will generally have a fresh ticket lifetime dating from the current time, although constrained by the renewable ticket lifetime.
    That means you have to renew a ticket before it expires. You can't renew a ticket after it expires. But renewing a ticket doesn't require re-entering credentials, like a password or the key from the keytab. It can therefore be done quietly on the user's behalf by a program. After the renewable lifetime is exhausted, or if one doesn't renew the ticket before the ticket lifetime expires, you have to re-enter credentials or use the key from a keytab.
    Best Regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, February 7, 2017 5:41 AM
    Moderator
  • Hello Wendy

    Thanks very much for taking the time to reply

    That is kind of what I am thinking (its just that the information security department where I work want to know the finer details), I will probably have to test in a LAB and leave the computer on all the time

    When you think about it a TGT is just a particular type of service ticket e.g. for the TGS (ticket granting service) 

    As far as I am aware (need to do a bit more reading), when a user logons on to his/her workstation/laptop they have to get a TGT but also a service ticket for their workstation/laptop they are logging on to.

    I also believe (from the limited amount I have read so far) when you present a service ticket (for example to access a CIFs Share on a remote computer) you present your service ticket (e.g. the one you got from the KDC) (and your authenticator) to access to the Service at which point the computer running the service checks your service ticket to make sure it is still valid as far as time goes e.g. not expired (apart from decrypting the ticket that is)

    so lets assume a user logs on to their workstation and then maps a drive to a network share.
    next they start a script to create a new file on the share every 30 minutes

    then they walk away from their workstation and come back two months later (assuming you do not have to change your password every 30 days etc.) 


    It occurs to me as the users workstation and the server running the CIFs share checked the service tickets (the one to access the workstation and the one to access the CIFs share) and both ticket were valid at the time of checking, then the script will still be creating new files on the share every 30 minutes even thought the original service tickets (and the TGT including any renewals) had long expired.

    I assume as soon as the user presses ctrl+alt+del (to unlock their workstation) to check how his/her file creating is doing (e.g. two months latter) the LSASS (local security agent subsystem) and NetLogon processes will take the password the user types in and go get a new TGT and service ticket (i.e. as with a new logon). However if you look the the files on the share you will see one created with the last 30 minutes (or there abouts)

    what do you think?

    Thanks

    __AAnotherUser


    AAnotherUser__

    Tuesday, February 7, 2017 6:41 AM
  • Hi; I've read your entire post and your reply asking for clarification.  You are asking a very straightforward question in the Subject line:  "Does a user get prompted to reenter this password when their TGT (ticket granting ticket) reaches the end of it renew until date?"  The answer is no, the user does not get prompted.  The reason why is simple.  Here's an analogy I like to use.  As long as the user is logged in (or logged in and the workstation is locked), Kerberos ticket renewal works like DHCP, they will just keep on automatically renewing with no user intervention.  "The TGT has a default lifetime of 10 hours and may be renewed throughout the user's log-on session without requiring the user to re-enter his password."  Kerberos is my favorite subject and as such, I found this reference for you, which is where the quoted statement came from:  Kerberos Explained.  

    To get to your other questions, copied in from both of your posts: "so let's assume the user does not logoff his/her computer (always computer is always on and user never logs off) and therefore the cache is still available and held in memory  what 'actually happens' with regard to the TGT at the end of the 7 days for example.

    1) Does the logon GINA (CTRL+ALT+DEL logon screen) suddenly appear and ask the user for credentials?  

    Answer:  No

    2) Does the GINA appear when the user requests a new TST (ticket service ticket) for a new resource for example, as they cannot use the currently cached TGT  

    Answer:  No.  (And you don't call it TST, just "ST".)

    3) Is a brand new TGT (not a renewal) issued to the user, 'but without' the GINA coming into play as the sub-systems (LSASS) uses the 'cached' information (users long term key, or is that never cached even in RAM) to encrypt a 'new' pre-authenticator    

    Answer:  Yes.  Brand-new TGT is obtained as needed automatically, without GINA coming into play. For the sake of brevity, basically, the long-term key never leaves the user's workstation, it stays inside the LSASS cache.  Only an authenticator (along with some other information, you can find it in the reading material) is sent outbound to the KDC to prove identity.

    4) As far as I am aware (need to do a bit more reading), when a user logons on to his/her workstation/laptop they have to get a TGT but also a service ticket for their workstation/laptop they are logging on to.

    Answer:  Yes

    5) I also believe (from the limited amount I have read so far) when you present a service ticket (for example to access a CIFs Share on a remote computer) you present your service ticket (e.g. the one you got from the KDC) (and your authenticator) to access to the Service at which point the computer running the service checks your service ticket to make sure it is still valid as far as time goes e.g. not expired (apart from decrypting the ticket that is)

    Answer:  Yes

    6) So lets assume a user logs on to their workstation and then maps a drive to a network share. next they start a script to create a new file on the share every 30 minutes  then they walk away from their workstation and come back two months later (assuming you do not have to change your password every 30 days etc.)    It occurs to me as the users workstation and the server running the CIFs share checked the service tickets (the one to access the workstation and the one to access the CIFs share) and both ticket were valid at the time of checking, then the script will still be creating new files on the share every 30 minutes even thought the original service tickets (and the TGT including any renewals) had long expired.

    Answer:  Correct, but you are thinking about this wrong.  The logged-in session will have obtained new TGT from KDC as needed, per earlier explanation, in order to keep on presenting a fresh ST to the CIFS share.


    Best Regards, Todd Heron | Active Directory Consultant

    • Marked as answer by AAnotherUser Tuesday, February 7, 2017 5:07 PM
    Tuesday, February 7, 2017 12:54 PM
  • > As far as I am aware (need to do a bit more reading), when a user logons on to his/her workstation/laptop they have to get a TGT but also a service ticket for their workstation/laptop they are logging on to.
     
    Correct.
     
    > It occurs to me as the users workstation and the server running the CIFs share checked the service tickets (the one to access the workstation and the one to access the CIFs share) and both ticket were valid at the time of checking, then the script will still be creating new files on the share every 30 minutes even thought the original service tickets (and the TGT including any renewals) had long expired.
     
    Unfortunately, yes. As long as the session to the server does not close due to inactivity, it will be valid regardless of the TGS expiration. See the second link below...
     
     
    Tuesday, February 7, 2017 1:08 PM
  • Hello Todd
    Thanks very much for taking the time to give a detailed explanation, Kerberos is becoming one of my favourite subjects too :)  

    So in a nutshell the users long term key is always held in the LSA cache in RAM (as long as the user does not logoff etc) and this can be used to create a new pre-authenticator to present to the KDC when requesting a new TGT after 7 days (default renew until), a new TGT is issued and away we go again.
    Is the above it in a nutshell?

    One a related query (if you do not mind helping with the following, I promise I will read the docs too :) )
    I believe the ST is checked periodically to see if the user account (as the ST contains a PAC from which the users access token is created in order to compare against the ACL of the service in question) to see if the user account has been disabled/locked-out/password expired etc. Therefore in our scenario if one month down the line (e.g. files still being created on the share) an admin disabled the user's account in AD, the next time the ST is checked (or at least the access token created from it is checked) the user would lose access to the resource and not be able to write any more files? or is that not the case?

    Thanks

    _AAnotherUser


    AAnotherUser__

    Tuesday, February 7, 2017 3:55 PM
  • I've answered the original question; you should mark it as such so that it may help others when searching for the same or similar question.  You asking about a lot of things in one question, it is not fair to the one answering the questions.  The question about the PAC is yet another question.  The ST and there PAC inside of it is checked one time, and an authentication token is constructed off of that and the application will then hand back to the client some sort of session key to continue to verify the user if it feels the need to do so.  These session keys can time out.  It is entirely up to the application when to re-check the session key, or if, it wants to demand to see the Kerberos ST again; it is not up to Kerberos.  So your mileage may vary depending upon the application.  The long-term key is held somewhere on the client system and never leaves it.  Not sure exactly where - you'll have to read the docs to be certain of it.  Don't forget to mark all responses as answers if you've found these helpful.

    Best Regards, Todd Heron | Active Directory Consultant

    • Marked as answer by AAnotherUser Tuesday, February 7, 2017 5:08 PM
    Tuesday, February 7, 2017 4:49 PM
  • I meant to say thanks too to you Martin

    I note Wendy say the following above, taking about the TGT

    After the renewable lifetime is exhausted, or if one doesn't renew the ticket before the ticket lifetime expires, you have to re-enter credentials or use the key from a keytab

    When she says 'or use the key from a keytab' (aka key table) I guess in this situation the keytab could be the still cached long term key.

    Just to see all this in action I setup a LAB (using my MSDN subscription) with a 2012 R2 DC and a 2012 R2 member server and a Windows 10 workstation

    I shortened the Kerberos ticket lifetimes to the minimum I could (via the GUI) e.g. renewal time 1 hour and renew until 1 day.

    I then mapped to a network share (from Windows 10 to member server) and started a script to create a new file every 30 minutes in on the share.

    I will check what happens after 36 hours (e.g. after end of renew until for TGT) and then  will disable the user account and see what happens after that and post my findings. I am sure they will line up with the above, but just want to check for real 

    Thanks all

    __AAnotherUser


    AAnotherUser__

    Tuesday, February 7, 2017 5:06 PM
  • Thanks again Tobb

    I marked your questions and Answered :)

    Appreciate your time

    __AAnotherUser


    AAnotherUser__

    Tuesday, February 7, 2017 5:08 PM
  • You're welcome.  And I saw you mention the word "keytab".  In the Windows world, keytabs are only used in mixed environments where you have Windows Active Directory in charge of your Kerberos infrastructure and where a non-Windows platform is running the application server (eg, J2EE server or Apache HTTPD on Linux).  In a pure Windows-only network, keytabs are never needed.  See more about keytabs in my article on them here:  Kerberos Keytabs – Explained

    Best Regards, Todd Heron | Active Directory Consultant


    • Edited by Todd Heron Tuesday, February 7, 2017 5:31 PM
    Tuesday, February 7, 2017 5:30 PM
  • Thanks agaoin Todd

    Coincidentally KeyTab files is one of the items I wanted to read up on so that was well timed :)

    Thanks to Wendy and Martin for their input too

    __AAnotherUser 


    AAnotherUser__

    Tuesday, February 7, 2017 9:44 PM
  • Quick reply to close off this thread

    As suspected from the above replies the LAB experiment (as I outlined above) showed the following results

    the client kept on creating new files on the remote share long after the clients TGT renew until time had expired. conclusion (although I did not do a packet trace to confirm)

    either one of both the of the following happened

    1) The client renewed its TGT using the long term key in its LSA cache (without intervention from the user e.g. GINA logon again) and therefore the client was also able to renew it service tickets for the share if required to do so

    2) the server running the CIFs share checked 'once' (at time of presentation) the service ticket was valid and not expired 'at that time' and never rechecked it at any time (therefore new TGT, service ticket not relevant)

    Also

    After a few days when I eventually went back into AD and disabled the users account (the one running the script and copying the files to the share) after 40 minutes (the TGT/service tickets had a maximum TTL of 1 hour) the copying stopped as the account was locked out. which leads me to think 1 above is more likely Or another methods on the CIFs server (over and above kerberos) was going back periodically and check the clients ticket/account; or the the client went to get a new TGT (or possible service ticket) it could not (due to account checks at time to asking for a ticket e.g. account expired, outside allowed login hours, account disabled etc) and therefore did not both to try and carry on with the file creation process (possible as it could not renew its service ticket to its own workstation).

    Thanks all once again for helping me understand the real world workings of kerberos

    __AAnotherUser


    AAnotherUser__

    Sunday, February 12, 2017 4:28 PM