Home / server / Questions / 92823
Accepted
smoak
Asked: 2009-12-10 15:23:55 +0800 CST

Windows File sharing using Active Directory Groups

  • 772

I've got one Domain Controller for our small network (~20 users). It's running Win Server 2k3.

I have added a Global Security Group (MYDOMAIN\GroupA) and added 3 users to it (MYDOMAIN\UserA, MYDOMAIN\UserB, MYDOMAIN\UserC).

I have a separate computer running Windows Server 2k3 that's named fileserver (you guessed it, it just has file shares on it). It's joined to the domain.

I have a share:

D:\Docs\ShareOne

I have set it up to be shared with Share Permissions: "Everyone / Full Control"

Then the NTFS permissions only permit MYDOMAIN\GroupA to have Full Control over it.

However, I'm experiencing very strange problems.

I have 3 workstations (2 XP and one Vista) that are joined to the domain and UserA, UserB, and UserC are all logged in to MYDOMAIN.

UserA who is running XP can run \\fileserver\ShareOne and access the files fine.

UserB (on XP) and UserC (on Vista) however type in \\fileserver\ShareOne into Explorer, hit enter and are greeted with a friendly "Access Denied" error.

I even had UserB (whos on XP) restart their entire machine, relogin and they still cannot access the share.

Why would this be happening? Something very very strange is happening.

active-directory

5 Answers

  1. Best Answer

    I'd strongly recommend turning on auditing of "Logon" failures in the local security policy of FILESERVER (Start / Run / GPEDIT.MSC - Navigate to "Computer Configuration", "Windows Settings", "Security Settings", "Local Policies", "and "Audit Policy"), run "GPUPDATE", and watch the "Security" event log after a failure to see what shows up. (I am assuming, by way of directing you to the local security policy, that you don't have domain policy overriding it.)

    Can you verify that other combinations of client computers and users do or do not exhibit the problem (i.e. "UserA" on the comptuer normally used by "UserB", etc)?

    This has the feel of a problem re: SMB signing or NTLM level, but I'd think that all your OS's are set to their stock confgurations and should work fine. Just for kicks, run Resultant Set of Policy on a working and non-working client computer and compare the settings in "Computer Settings", "Windows Settings", "Security Settings", "Security Options" related to "Domain Member: ..." and "Microsoft network client: ...".)

    One more silly thing: Is the name FILESERVER resolving to the same IP address on all the clients?

    • 2

  2. Have you tried the two user accounts that are denied on the computer than has the user working fine? This may at least work as a process of elimination. If they can access it okay through that computer then perhaps suspect the computer configuration or domain/computer relationship. Perhaps disjoin them and rejoin them to the domain. But first check if the user accounts can access the shares on that other computer. Or you could create another share with everyone with access to it and see if these user accounts can access this on at all. This may give you a little bit more insight into the matter as well.

    • 1

  3. Silly question but are UserB and UserC in a group that has a "deny" entry in the ACL? You might want to check the Advanced permissions here too, as sometimes entries there don't show in the standard list.

    If that's not it, generally what I do in these scenarios is try to narrow it down to a user or a machine problem, so I would get UserB to log on to UserA's machine (and vice-versa) and see what happens. Same with UserA and UserC. Based on the info from that exercise you should know whether to go looking at the user accounts or something on or with the PCs for further troubleshooting.

    If you determine that it's the users, the next logical step would be to create test user accounts by copying the live ones, then trying to reproduce the problem yourself.

    • 0

  4. Here's a long shot. Can your client machines browse to the server on the network and actually see the share? I have seen similar behaviour in the past that was related to browsing issues. Permissions were find but the machines couldn't locate the server and Windows error messages are known to be somewhat misleading at times.

    • 0

  5. Check the permissions on the volume (drive) where the share is. Each user needs to have the "Bypass Traverse Checking" user right in order to get to the shared folder and it's contents, regardless of the permissions on the share itself. Make sure that the users have the "Traverse Folder\Execute File permission at the volume (drive) level.

    • 0