Kerboros cached ticket deleted after using Windows

问题:

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.

回答1:

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.