470,632 Members | 2,554 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,632 developers. It's quick & easy.

Change to Local Group Membership Requires Reboot?!

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.

Sep 26 '05 #1
2 7849
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.

Sep 26 '05 #2

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! :)

Sep 27 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Evgeny Zoldin | last post: by
3 posts views Thread by =?Utf-8?B?QXhlbCBEYWhtZW4=?= | last post: by
5 posts views Thread by =?Utf-8?B?SmVycnkgQw==?= | last post: by
1 post views Thread by Korara | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.