One of my friends pointed me out to an intersting and useful article about How to update group membership without logoff/logon/restart. Yes, it really explains a handy method of updating your Kerberos tickets. Right, you can refresh your Kerberos tickets with KLIST PURGE. I use it myself.
But it is not the whole story. There are few cases in which the method would not work or may produce chaotic results.
It is not so simple even over a network connection (see later). But we start with some notes about local behavior.
Local access tokens
When you log on to a workstation or a server interactively (i.e. either by pressing CTRL-ALT-DEL locally, or when you connect remotely over RDP), the system creates a memory structure called access token. The access token contains all SIDs (security IDs) that are related to your account. Your AD user account has a SID and may also have some SID history. The user account is always member of some groups, either directly or indirectly (nested groups). The groups have SIDs as well and may have SID history. In addition, your access token receives some system default groups like INTERACTIVE, Everyone, Authenticated Users and such.
Note: not importantly here, but the number of SIDs in an access token is limited to 1025. In fact, this limitation cannot be changed anywhere in registry (this is not the Kerberos limit that you can affected by the MaxTokenSize registry value). If your account accumulates to many SIDs, the system denies you logon.
Every process you run receives a copy of the access token. If you enable UAC (user account control), there are actually two access tokens - the normal one (limited) and the elevated.
System processes (those that run under SYSTEM, Network Service, Local Service, NT SERVICE or IIS APPPOOL) also have got access tokens. Again, this is built from contents of the computer's respective Active Directory computer account.
When a process tries to access a local (I stress the word local) resource (such as file, registry, other process, window, desktop or a certificate), system uses the process's access token to check access permissions and user rights. This also applies to processing of Group Policy in some cases (for instance if you have the Deny Apply Group Policy permission).
Note that access token is not actually present in user-mode process memory, so that the user code cannot change it directly. User code must use security API functions (Win32 API which maps to Native NTAPI) to work with the access token and thus cannot elevate its permissions by modifying its access token.
Access token does not refresh with KLIST PURGE. To have access token refreshed, you must log off. In case of system's access token, you must restart.
This applies not only when you access local resources. The same access token is also used when you access local services. Such as local SQL server, local IIS web server, local Exchange, local certification authority etc. Not always (out of scope of this article), but system mostly reuses the local access token. Once again, you must log off to get that updated.
Always log off twice! And the case of COM servers
Wait here! That is important. Access token is always built from registry cache (since Windows XP). Although you are online, you might not be. Access token registry cache refreshes only after a successful online logon. This means that you must log off and log on again twice. First time to get the cache of access tokens updated. The second time to finally get the updated access token for your new processes.
Note: this registry cache I talk about is the logon cache, which computers store in HKLM\Security\Cache and which is affected by the notorious Interactive logon: Number of previous logons to cache (in case domain controller is not available) policy. The registry cache can store up to 10 different access tokens by default, plus contains their associated password hashes.
Note that the cache does not store password hashes in their original form which is MD4. On Windows 2003 and older systems, the original password hash is hashed once again with MD4 and only then stored. Beginning with Windows Vista, in order to further improve cache security, the original hashes are rehashed several thousand times with SHA-1. These measures are applied to prevent direct MD4 hash extraction from registry and also make their cracking much harder as well.
Also note my previous experience with some COM servers. A user may start some application which runs in the form of an out-of-process COM server. The COM application may not terminate during your log of, so it would keep your previous access token until restarted.
Network authentication is not so simple as well
First, there are actually four network authentication methods, that we must take into account. Kerberos, NTLM (meaning all the versions), Schannel (TLS certificate authentication) and Basic methods (or LDAP Simple Bind).
Yes, Kerberos is the primary method. But is not always used. Yes, you can purge Kerberos tickets from your local client's cache with KLIST or KerbTray.
But do not forget about UAC. With UAC in effect, there are actually two separate Kerberos ticket caches. One for the normal, limited logon session, the other for the elevated session. If you want to purge everything, you must do it twice. Both from the limited CMD and from an elevated command line as well.
Then it comes to TCP connections
TCP connections are usually authenticated only when they start (although HTTP traffic authenticates every GET/POST with Kerberos tickets, while NTLM does this only for the first one on a single TCP connection). Until the connection is reset, the group membership is also not updated. You must restart at least the client applications that your are troubleshooting to get the TCP connections closed. Even if you purged the Kerberos cache with KLIST.
In case of SMB and NamedPipes and their TCP sessions, you cannot easily close the session from client side. System itself establishes file sharing client connections and it keeps them connected until some timeout or logoff.
NTLM, Schannel and Basic authentications, finally
NTLM and Schannel update membership immediatelly. They must go to DC for every new TCP connection. They do not (and cannot) cache anything. So the network group membership gets updated in the process.
Funny thing happens with Basic authentications (TMG, UAG, ISA, HTTP, SMTP, POP3, LDAP, etc.). The servers actually cache access tokens after the first time you authenticate successfuly. Just in memory, not in the registry. They do not purge the cache when any TCP connection is closed. IIS token cache expires only after 15 minutes by default. You can always change the timeout in registry according to the following article - Changing the Default Interval for User Tokens in IIS.
This way, later logon attempts are faster, even for new TCP connections. They do not need to be checked against a DC. The server's local LSASS (local security authority subsystem) just validates the clear-text credentials against the (in-memory) cached access token. You cannot purge the server side cache from a client. To be sure, you must restart the server operating system.
If the server uses Kerberos delegation (whichever mutation there is), the server may also cache some Kerberos tickets. Once again, you cannot purge server's cache from the client. You must restart the server operating system instead. And if I say the operating system, I mean it. As of my experience, it is usually not sufficient to restart the server process only.
I have already spent nights coping with Kerberos delegations that didn't work just because I didn't restart the whole OS.