Security group membership makes it impossible to list network shares (very strange issue)

Question

We are having a very unusual problem on our network.

There are two sites: main office (1x SBS 2003 server and 20x PCs: a mixture of Win7 and XP) and a remote site connected via VPN (1x XP PC, also on the same domain as the PCs at the main office).

There are around 10 security groups on our domain, used to provide domain users with access to various network drives. At the main office everything works as expected.

At the remote site, however, some domain users have serious network problems if they are made a member of one particular security group (called "_publicprograms"). Instead of getting more access (as happens at the main site with this security group), they instead cannot view any shares on the server (\\server) if they are a member of this security group.

If the user is then removed from the "_publicprograms" security group, logs out of the PC at the remote site, then back in again, they can once again view and access shares on the server in the normal fashion (both those related to security group and others, such as network printers attached to the server). This issue is 100% repeatable.

This is odd because:

• this problem does not happen at the main site with the same domain user account, on PCs in the same OU as the PC at the remote site

• there is nothing obviously different about this security group's configuration in AD compared to any of our other security groups

• I would not have even thought it possible for security group membership to be able to prevent listing any (or all, in this case) shares on the server in this way. I am not talking just about the user being simply denied access to shares (as could be explained by NTFS permissions)- but being unable to simply list shares on the server.

Evan: here is the server's own Resultant Set of Policy as you requested.

Perhaps you will be able to find a clue here:

Summary:

Settings:

Policy Events:

Answer 1

I finally solved this problem after working on what I thought was a completely unrelated issue in AD.

The previous IT guy had set up around 10 completely unnecessary security groups- some nested within others (many having only 1 or 2 members). It was a mess and shows he had made some lazy assumptions about how the organization would use their network drives (making it impossible to freely pick and choose which individual drives to provide access to a user, as some ended up lumped together). Generally it still worked- and tidying up AD was not at the top of my list of priorities (which is why I had not got around to working on it so far).

Reorganizing AD became a more urgent issue this week after I realized the new user was a member of a security group that was part of a chain of nested security groups ("groupA" was a member of "B", which was a member of "C" etc.) -which ultimately led to the user getting 2 additional network drives mapped at logon which they were not supposed to see.

At the main site, the user could log on as normal, and would simply get access to these extra mapped drives and could still browse the server shares. At the remote site (possibly somehow related to the 3G network's relatively low bandwidth) the user lost all access to the same server over VPN (as per my question) when a member of this one security group. Very strange- but you can see why I was tempted to wipe the OS on the workstation in the hope that would fix the problem.

After nearly a day of reorganzing NTFS permissions on the data partition, reorganizing group membership, and deleting as many superfluous security groups as possible (as well as ensuring that no security groups were members of others- mainly because there was no need for that in this relatively small organization) the issue I posted here instantly disappeared. I never even had to go in to the office, let alone do a reload of the OS on the workstation at the remote site- all I needed to do was remote in to the server and tidy up everything related to security groups in AD.

The problem seems to have arisen due to a combination of the remote site having a slower connection (VPN over 3G cellular network) combined with the multiple nested security groups.

Incidentally- before untangling and simplifying our AD security groups, I had also tried recreating the problem on my home PC by linking it to the office via the same LogMeIn Hamachi VPN link, joining it to the domain- then logging on as the problematic account. I was unable to recreate the issue. My home network gets 25Mbps down, 2.5Mbps up, which is why I think bandwidth (or latency) could have been a contributing factor here.

Perhaps the moral of the story here is: if you completely run out of ideas with a problem that could potentially be related to permissions... roll up your sleeves, put the kettle on, and be prepared to spend a day carefully tidying up Active Directory!