Here’s a useful tool for troubleshooting permissions problems arising from membership in groups.

If you find that permissions are not working properly for a user on some resource, it may be because of the groups the user belongs to. Access to shared resources is usually granted to groups, not users, so if you don’t know all the groups a user belongs to, the permissions the user has on the resource may not be what you expect.

It’s not as easy as you may think to find out what groups a user belongs to. Opening up the properties of their user account in Active Directory Users and Computers, you can examine the Members Of tab to try and determine this. But if your Active Directory network is running in Windows Server 2003 domain or forest functional level, groups can be nested within groups to any degree, and the Members Of tab for a user only shows the immediate groups the user explicitely belongs to, not groups he may belong to implicitly through nesting.

Fortunately, you can determine all the groups a user belongs to by logging on as that user and typing whoami /groups at the command prompt. This will display all groups the user belongs to, both explicitely and implicitely, including special identities like Everyone and Authenticated Users.

But there’s a catch–if the user belongs to any distribution groups then these memberships may not be displayed because whoami doesn’t show groups nested within distribution groups. And although this may not seem an issue since permissions aren’t directly assigned to distribution groups, it can be an issue since this can hide permissions on nested security groups. So don’t nest distribution groups within security groups as it can make group permissions troubleshooting more difficult.

Article written by MyComputerAid.com