You mention local users and groups, so setting aside Active Directory.
You should always need to re-authenticate in order for the user's security token to contain the new group membership. This typically means you need to re-login. LSASS only hands this token out when the user authenticates, which is usually only at logon but you can do something like
C:\> runas /user:Yourself cmd.exe and that will prompt you for your password and you will go through authentication again and your new group membership will be picked up. (But I cannot guarantee that any other running applications that may have queried for your group memberships are going to refresh their data without restarting those applications, etc.)
klist.exe because we are only talking about local users and groups.)
This article is pretty much the authority on the matter.
When a user is authenticated, the Local Security Authority (LSA)
creates an access token — in this case, a primary access token — for
that user. An access token contains a security identifier (SID) for
the user, all of the SIDs for the groups to which the user belongs,
and the user’s privileges. If you add a user to a group after the
user’s access token has been issued, or modify privileges assigned to
the user account, the user must log off and then log on again before
the access token will be updated.
Whenever a thread or process interacts with a securable object or
tries to perform a system task that requires privileges, the operating
system checks the effective access token to determine its level of
authorization. If a thread is impersonating, the effective token is
usually taken to be the token on the thread. If a thread interacting
with the securable object is not impersonating, then the token on the
process is examined for the access decision.
Thus, there are two kinds of access tokens, primary and impersonation.
Every process has a primary token that describes the security context
of the user account associated with the process. A primary access
token is typically assigned to a process to represent the default
security information for that process. Impersonation access tokens, on
the other hand, are usually used for client/server scenarios.
Impersonation tokens enable a thread to execute in a security context
that differs from the security context of the process that owns the