3

Is there anyway to stop the Kerboros cached ticket from being deleted after Windows enter the lock screen.

Upon first login to Windows, klist.exe shows 2 cached tickets. However, after there is a Windows lockscreen event, klist.exe shows that 0 cached tickets.

Thanks in advance.

RemicoAL
  • 33
  • 4
  • I am checking on how the issue is going. If we've answered your question please mark it as such so that it may help others; otherwise please let us know if any. – T-Heron Jan 13 '17 at 20:51

1 Answers1

2

This is by design. There is no way to prevent the Kerberos service ticket(s) from being purged after a screen lock. As soon as you access a new Kerberos-protected resource again, a new authentication procedure takes place and new tickets will appear. It is important to understand a distinction between Kerberos tickets - there are two types - the ticket granting ticket (TGT) and the service ticket (ST). You can ensure that the Kerberos TGT remains in the client cache and does not cleared out after a screen lock if your computer is participating in an Active Directory domain and you make what is known as a Group Policy change in order to change the behavior (see note below). If you are not the Active Directory administrator, you will have to contact them to have them do this for you. To retain the TGT after a screen lock, open the Group Policy Management Console Editor, locate a GPO which is linked to the machine, and set policy to not require contact with a domain controller in order to unlock the machine. Doing this will ensure the machine retains a cached Kerberos TGT for re-authentication. Even if you configure Group Policy in this way, the Kerberos service ticket issued for your web server won't get retained. Again, in this scenario, only the TGT remains in the machine Kerberos cache after un-locking the workstation, no service tickets (such as those issued for network resources) will remain. But for you, this could allow the ST to be requested more easily, as the TGT doesn't have to be re-requested. While you can try as much as you want on the application server side to program around this, there is really no way to control Kerberos overall security behavior on the client side from the application side.

Everything below this part of the answer and is an EDIT made in response to the follow-up comment. Please avoid making any edit to the Default Domain Controllers Policy as the policy will only apply to Domain Controllers. As a note, whenever I'm personally making a new Group Policy change in an Active Directory domain, unless I am very familiar with the particular setting, I like to create a brand new GPO, name it according to the setting change I'm making, and then link it to the OU to where the computer or user object(s) reside(s). Alternatively, you can also link the GPO at the domain level if you feel the change is considered "safe" and won't wholesale and negatively effect everybody.

  1. To do this, open the Group Policy Management Console Editor, and create a new GPO.
  2. Name it Cached Logons Allowed.
  3. Edit the Cached Logons Allowed GPO.
  4. Navigate to Computer Configuration > Policies> Windows Settings > Security Settings > Local Policies > Security Options > and configure both of the following:

Interactive logon: Number of previous logons to cache (in case Domain Controller is not available): 1 logons

Interactive logon: Require Domain Controller authentication to unlock workstation: DISABLED

Next, reboot the client workstation 2-3 times. Technically, you can run the command gpupdate /force to do this, but I have found that for some settings, particularly this one, the client workstation needs not only a reboot but sometimes 2, maybe even 3 reboots, due to yet another GPO setting called Fast Logon Optimization. Anyway, that story is for another thread.

T-Heron
  • 5,385
  • 7
  • 26
  • 52
  • Thats odd. The Java Kerberos application I am using does not create any new tickets when the ticket cache is 0. Is there anyway I can modify the source code to create the neccessary tickets without the need of re-entering a password like Kinit.exe? – RemicoAL Jan 10 '17 at 07:07
  • I edited the answer in response to your new comments. – T-Heron Jan 10 '17 at 15:47
  • I am lost at the GPO steps. After opening Group Policy Management Console Editor, I couldn't find a GPO which is linked to the machine. The closest I could get was Expanding domain tree>Group Policy Object>Edit Default Domain Controllers Policy>Expand Computer Configuration>Policies>Windows Settings>Security Settings>Local Policies>Security Options>Interactive logon:Require Domain Controller authentication to unlock workstation. I set this field to disabled and still had 0 tickets after unlocking machine. Not really sure what I am doing wrong. – RemicoAL Jan 12 '17 at 09:38
  • Asking for the specific Group Policy steps wasn't part of your original question; I'll edit my answer one more time but I would say that the original question was answered. In the meantime, please add the tag 'active-directory' to your question. – T-Heron Jan 12 '17 at 13:28
  • I tried the GPO steps and had the same difficulties in ticket cache getting removed after a Windows screen lock. A colleague assisted me in testing by using his machines and we realized that the ticket cache issue can be OS dependent as well. I ran my ticket cache tests on Windows 10 whilst he ran his on Windows 7 and Windows 2012 and he faced no problems. I am marking T-Heron answer as accepted. The Windows 10 issue seems unsolved but that is probably OS dependent.Could Windows 10 be more secure with Kerberos and is there anyway to keep Kerboros tickets after a screen lock? – RemicoAL Jan 16 '17 at 03:33
  • I confirm the same GPO behavioral differences you are seeing between Windows 7 and Windows 10. Given the same custom GPOs with regards to Windows AD cached logons, Windows 7 keeps the TGT after a screen lock but Windows 10 does not. Looks like a bug. If you happen to open a Microsoft case on this, I hope that you'll post back with their reply. I couldn't find anything on this after a quick Internet search. – T-Heron Jan 16 '17 at 04:39
  • @T-Heron, I'm sorry, but how can I set my application as kerberos-protected resource for the system? I have client and server on Java and the client app uses LSA ticket to generate token from KDC. How can I make the system to regenerate cached tickets? You said "As soon as you access a new Kerberos-protected resource again, a new authentication procedure takes place and new tickets will appear" but I don't get how is it working. – wazz Jul 05 '18 at 15:36
  • @T-Heron, hello, I opened a question https://stackoverflow.com/questions/51203494/retrieve-kerberos-cached-ticket-from-windows-machine-after-lock-screen – wazz Jul 06 '18 at 05:23
  • My question is not why the tickets are purged. But why they are not generated again like it work when the user login. – wazz Jul 06 '18 at 05:40