6

In Windows systems (particularly Windows Server 2008R2 which I an using), sometimes when I add a local user to a local group, the user needs to log-off and log-on back again before this new group is registered to him.

But Sometimes as well, the group registration is done immediately.. without the user having to log-off and log-on back again..

why is this so?

user1034912
  • 1,335
  • 3
  • 14
  • 20

2 Answers2

11

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.)

(Not mentioning 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 thread.

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • Thanks for the explanation. But sometime I don't need to authenticate. It just works when I add in a user to a group. It's really funny.... – user1034912 Nov 29 '13 at 06:39
  • Lots of things can go on in the background that silently cause authentications without you knowing it. Windows Services doing impersonations, scheduled tasks, etc. An application that queries the group membership directly instead of querying the currently logged on user's token can also get around this. – Ryan Ries Nov 29 '13 at 18:32
  • 1
    @RyanRies: One nitpick on the the `runas` trick: the new token will only apply to the process you launch and its children. Any existing processes or children of those processes will continue to inherit the original token. – charleswj81 Jan 09 '14 at 02:54
  • @charleswj81 Agreed - a full logoff/logon is best. – Ryan Ries Jan 09 '14 at 13:06
0

This video in a way answers the question https://vimeo.com/73500318

The video also solves the problem of user getting access to a resource whose group membership an individual has just been added to without having to log off and log in again.

Here is the summary of the solution that avoids the hassle of login logoff:

  • Open Command Prompt Kill

  • Kill explorer.exe process (It will only kill the windows explorer. All your other applications are safe).

  • In the command prompt type the following command: runas /user:DOMAIN\ explorer.exe

    • You will be prompted to enter your password. Enter your password.

In the above example, the username that you would use is the same as the one that you are already logged on as.

Moiz Tankiwala
  • 101
  • 3