0

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:

enter image description here

Settings:

enter image description here

Policy Events:

enter image description here

Austin ''Danger'' Powers
  • 1,180
  • 6
  • 21
  • 51
  • I just read through your other questions and it sounds, to me, like somebody has done some nasty voodoo with security policy and this one security group. I'd scour through Resultant Set of Policy on the server computer looking for any references to this problematic group. – Evan Anderson Jul 10 '13 at 21:34
  • I have updated my question with what I see when I run RSOP on the server. It does not seem to even recognize the domain user account that is having these problems. What could this mean? – Austin ''Danger'' Powers Jul 10 '13 at 22:08
  • I'm interested in the RSoP for the server computer itself-- not for any particular user. Just the computer account. The user account for the "problem user" won't be listed because they never have logged-on to the server interactively. (I mean, they shouldn't be-- it's a DC.) – Evan Anderson Jul 10 '13 at 22:17
  • I don't know if this is related to your actual issue, but a security group membership *can* very well prevent access to something, if there's an explicit `deny` ACE for that group. – Massimo Jul 10 '13 at 23:16
  • So, the server computer is "NH1" and it's not even applying Group Policy to itself properly? Am I reading that right? – Evan Anderson Jul 10 '13 at 23:26
  • @Evan: I ran the RSOP wizard on the server, but "NH1" is the remote PC where the problem happens. – Austin ''Danger'' Powers Jul 10 '13 at 23:50
  • @Massimo: it's not an explicit deny unfortunately. That would've been nice and easy to fix! :) – Austin ''Danger'' Powers Jul 10 '13 at 23:53
  • I'm interested in the server computer's own RSoP. – Evan Anderson Jul 11 '13 at 00:24
  • @EvanAnderson: I've updated my question with the RSoP for the server (as opposed to the workstation). I don't see any references to the name of the security group causing the problem ("_publicprograms"). Was that what you were looking for, or something else? – Austin ''Danger'' Powers Jul 11 '13 at 08:47
  • That was, though I'm getting a broken image for the settings (what I really care about). – Evan Anderson Jul 11 '13 at 08:57
  • The yellow boxes all over the screenshots were just me obscuring the domain name (I'm not sure if that's what you were referring to?) I had a good look through all the RSoP results and none of our custom security groups are mentioned anywhere (they would be easily recognizable as we start them with an underscore). Where else can I look? I am almost tempted to do a wipe and reload of the XP box- potentially a same-day resolution. I could put a different hard drive in, install XP, join the domain, then try to recreate the problem. If that doesn't fix it then I can just revert to the old drive. – Austin ''Danger'' Powers Jul 11 '13 at 10:13

1 Answers1

0

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!

Austin ''Danger'' Powers
  • 1,180
  • 6
  • 21
  • 51