Change to Local Group Membership Requires Reboot?!

[innesm]

Hi,
Although I havent been able to find any documentation to confirm it, it
looks like any change to a windows local group's membership is only
reflected in the group editing UI (and the command-line tool 'net
localgroup'), and requires a full reboot of windows to take effect for
any other applications.

Can anyone confirm this, or explain why I am getting behaviour that
gives this impression?
I've written a small C# application to demonstrate this:

IsInRole.cs:
============
using System;
using System.Security.Principal;
class App
{
static void Main(string[] args)
{
WindowsPrincipal wp =
new WindowsPrincipal(WindowsIdentity.GetCurrent());
string group = args[0];
bool isInRole = wp.IsInRole(group);
string name = wp.Identity.Name;
Console.WriteLine("User {0} is in role {1}: {2}",
name, group, isInRole);
}
}
Here's the output, comparing with 'net localgroup':
==================

C:\>net localgroup testgroup
....
Members
-----------
MYDOMAIN\me
....

C:\>isinrole MYCOMPUTER\testgroup
User MYDOMAIN\me is in role MYCOMPUTER\testgroup: False
As you can see, 'net localgroup' can see that MYDOMAIN\me is a member
of the local group, but WindowsPrincipal.IsInRole cannot.

If I reboot windows, WindowsPrincipal.IsInRole gives the correct
answer, until I remove MYDOMAIN\me from the group, when it incorrectly
indicates that the user is still in the local group.

[Chris McCarron]

Actually, changes to group memberships are immediate in the OS and they don't
require a reboot. What you're seeing is the effect of caching the SIDs of
the groups to which a user belongs in the users token.

The way it works is something like this. When you log a user into a machine
a security token gets created. At that time - and tht time only - the system
determines - among other things - to which groups the user belongs. This is
held in the token. Most access checks (the ones in the OS anyway) will walk
through the groups in the token.

The alternative to this caching would be to have every check be dynamic
against the underlying authoritative source. This would have two undesirable
effects. The first is that it would be slow. The second is that it would be
very hard for applications to ensure that they were acting consistently
because the results of access checks might change at seemingly random times
based on changes to group memberships.

Of course, this is the behavior you're expecting so it may just seem wrong
to you. You aren't the first person to trip on this - this is the way
Windows has always behaved.

Chris

"in****@gmail.com" wrote:

Hi,
Although I havent been able to find any documentation to confirm it, it
looks like any change to a windows local group's membership is only
reflected in the group editing UI (and the command-line tool 'net
localgroup'), and requires a full reboot of windows to take effect for
any other applications.

Can anyone confirm this, or explain why I am getting behaviour that
gives this impression?
I've written a small C# application to demonstrate this:

IsInRole.cs:
============
using System;
using System.Security.Principal;
class App
{
static void Main(string[] args)
{
WindowsPrincipal wp =
new WindowsPrincipal(WindowsIdentity.GetCurrent());
string group = args[0];
bool isInRole = wp.IsInRole(group);
string name = wp.Identity.Name;
Console.WriteLine("User {0} is in role {1}: {2}",
name, group, isInRole);
}
}
Here's the output, comparing with 'net localgroup':
==================

C:\>net localgroup testgroup
....
Members
-----------
MYDOMAIN\me
....

C:\>isinrole MYCOMPUTER\testgroup
User MYDOMAIN\me is in role MYCOMPUTER\testgroup: False
As you can see, 'net localgroup' can see that MYDOMAIN\me is a member
of the local group, but WindowsPrincipal.IsInRole cannot.

If I reboot windows, WindowsPrincipal.IsInRole gives the correct
answer, until I remove MYDOMAIN\me from the group, when it incorrectly
indicates that the user is still in the local group.

[innes]

Chris McCarron wrote:

Of course, this is the behavior you're expecting so it may just seem wrong
to you. You aren't the first person to trip on this - this is the way
Windows has always behaved.

Thanks for the explanation. I can see that the way I expected it to
behave could result in some potentially confusing situations. Still
annoyed though! :)