A local group cannot be found if it is nested inside another group on a Windows Server-based or Windows-based client

Consider the following scenario.

• You have a client computer that is running Windows Vista, Windows XP, Microsoft Windows 2000, or Windows Server 2003.
• You use Computer Management Console (Compmgmt.msc) to add a local group to the group membership of another local group on the same client. For example, you add <Power Users> to Remote Desktop Users on the same client.

In this scenario, when you click Check Names, you receive the following error message: You receive this error message even though the specific local group that is mentioned in the error message may exist on the computer.

This behavior is by design. Windows does not support the nesting of local groups on domain clients or on workgroup clients.

To work around this problem on a Windows client, you can add user accounts from the local computer to local groups on the same computer. Additionally, if the client participates in a domain, you can add user accounts and global groups from that domain and from trusted domains. You can successfully create the setup that is mentioned in the "Symptoms" section by using the Local Users section in the Computer Management snap-in or by using the legacy command line tool, Net.exe.

Notes

• A user who belongs to a group has all the rights and permissions granted to that group. If a user is a member of more than one group, the user has all the rights and permissions granted to all those groups.
• Adding a new local group to the membership of another local group on the same computer is not supported if the addition results in a nested local group membership for the users.

The Computer Management interface detects the nested group membership addition for local groups, and logs the error message that is mentioned in the "Symptoms" section. The command line tool, Net.exe, lets you create a nested local group structure through the �net localgroup� syntax. However, the nested group membership does not work. This occurs because the user token for the user reflects only the direct local group to which the user is added as a member. The token does not list the nested local group. Also, the user cannot access the resource that is granted permission to the nested local group.

Consider the following example.

• User A is a direct member of Localgroup1 and of Localgroup2. When User A logs on, this user's token includes both Localgroup1 and Localgroup2.
• User B is a member of Localgroup1 and is added together with Localgroup1 to the membership of Localgroup2 by using the net localgroup command.

In this example, when User B logs on, this user's token includes Localgroup1, but it does not include the nested group Localgroup2. This is the expected behavior.