I've been working on this off and on for weeks now, and I'm really getting nowhere. We have a network share that everyone in our company has access to, called SharedFiles. It's located on our server, running SBS 2008. Recently, we wanted to start closing down access to certain folders - only those in the IT security group can access the Applications sub-folder and such. So I set up the security groups, granted permissions, and tested them with the Effective Permissions feature. Everyone has the appropriate permissions according to that, but in practice whenever someone tries to access a folder they should have rights to, they are given "Access is Denied". The permissions grant full control of a folder to specific groups. Folder A grants full control to members of the SecA security group, for example. While no one is denied permission explicitly, not even Administrators are listed as having permission. Our goal is that having admin privileges isn't enough to access. We want the user to be part of the SecA group.
Initially, I was getting this "Access Denied" problem with Administrators as well, but now it's only Domain Users. I managed to find a thread that confirmed this was caused by UAC and mentioned that Administrators can avoid this problem while still maintaining UAC on the server by adding special permissions the Authenticated Users group in the top level folder, the one that is actually shared:
Authenticated Users - (List Folder / Read Data) (Read Attributes) (Read Extended Attributes) and (Read Permissions) applied to "This folder only"
That did work for all users with Administrative rights. They can access folders that they have rights to, but are denied other folders they don't have rights to. For example, we have Folder A and Folder B. Admin1 is part of the SecA group, but not the SecB group. With the above Authenticated Users permissions in place, Admin1 can access Folder A, but not Folder B. This is what we expect and what we want. However, the same does not apply to Domain Users. Regular users with no admin rights are denied access, even when the Effective Permissions confirms that they should have full control. Thus far, I have not found a way to properly clamp down access. In theory I could just turn off UAC and be done with it, but I don't feel that's really a solution. What can be done to get this to work?
Did you check the share permissions on the folder?If both permissions are set correctly, I dont think Authenticated user's needs permissions on top level folder.
Users effective permissions are combination of both Share and NTFS permissions. Use the below tools check the effective share and NTFS permissions on the folders.
If you found this post helpful, please give it a "Helpful" vote. If it answered your question, remember to mark it as an "Answer". This posting is provided "AS IS" with no warranties and confers no rights! Always test ANY suggestion in a test environment before implementing!
Are you using both Share and NTFS security. Did you consider setting the "Everyone" group to Full Control and managing permissions through NTFS only? I have a new 2008R2 server and have hit this wall with the application installs. I'm wondering if I should cut it down to only one place to manage.
- Proposed as answer by n8gr8 Thursday, December 13, 2012 5:53 PM
Hey, sorry for the delay, I've been swamped with other projects.
Ralph: I'm actually working on a test share at the moment with dummy folders, and the share permissions grant full control to everyone already.
iamrafic: I ran the two applications you linked. According to what I can see in AccessEnum, there isn't any problem with the NTFS permissions. My test user is listed as as having permission to the folder I want them to access. However, in practice, they cannot access this folder. Something that does concern me is that when I run the ShareEnum, nothing is listed for our domain. Nothing at all. We do, however, have plenty of shared directories and I'm not having any issues with almost all of them, as our security concerns aren't as extreme for those directories.
Ultimately, I'm still in the same place - I cannot get domain users to access folders that every single permissions check tells me that have full control over. This seems to overlap with a problem with Access Based Enumeration with the fileserver. When that option is enabled, the error messages change from access denied to "this directory does not appear to exist." That's all well and good and is what I'd expect, except I can always see the folder. I haven't found a way to make it actually disappear. Seems to defeat the entire point if the computer can't see the directory, but the user can. Still, I wouldn't worry about that if I could just get the access working.
I should add that I'm doing all of my work with the Active Directory snap-in, not the SBS Console. I have already ruled out the SBS Console (same result, groups/users added in the console have the same 'access denied' problems as the AD groups/users.) I just mention it in case it's relevant somehow.
- Edited by ClancyDamon Thursday, September 08, 2011 11:39 PM Additional Information
Okay, I think I figured it out. This whole time I've simply been setting my share permissions to Everyone - Full Control because I thought that meant exactly that - everyone has full control on the share level. On a whim, I added my custom security group and gave it full control as well. I logged in as my user and accessed my shared directory, and suddenly everything was EXACTLY as I'd been expecting to see for a while. The other folders that user had no access to were completely unviewable, and the one folder I did have access to was now accessible. I could go into it and peruse the folders. This entire time I neglected the Shared Permissions because, again, I thought Everyone was supposed to mean EVERYONE. Apparently, it does not. I'd say that's a bit misleading.
I know this a common problem out there as I've seen it in a lot of forums, so to reiterate for anyone else with this issue:
If you have a custom group that should have permission, but users of that group do not have permission in practice (they get 'Access Denied' errors), then add that group to the Shared Permissions. The Everyone group is apparently useless when it comes to Share Permissions and does not grant the appropriate permissions to Everyone.
I can only suspect this is because Shared Permissions has only three options - Read, Write, and Full Control. Somehow, that does not imply Read Permissions and Read Attributes? That's my only guess.
Anyways, thanks for the help Ralph and iamrafic.
This problem includes any other groups. Say, for example, a folder is only accessible to a group you've made called Security1. This folder is in a Share that you've setup to be accessible to all Domain Users. Your user who is a member of both Domain Users and Security1 cannot access the folder, even the share permissions says Domain Users have Read and Write access. That's not good enough, you need to add Security1 the share as well. So, you can't have an umbrella group that grants everyone access to a share and lock it down from there. You need to micromanage your permissions from top to bottom.
And it stopped working. I monitored it all weekend, and nothing has been changed in the configuration - groups, rights, accounts, all are the same. Suddenly, it stopped working. Domain users are no longer able to access directories that previously they had access to. Of course, the effective permissions clearly states that these same users have full control of these folders.
The only way I was able to restore access to the folders was to blow out all of my custom security permissions and simply say Domain Users have read/write access. Of course, that worked instantly. I'm starting to lose my mind, this should not be that difficult to implement. What the hell am I missing?
I had problems that seemed exactly like you were describing, but I found that my biggest problem was that when I added someone to a new security group that I had created for a folder, it wasn't taking effect for the user until the user logged out and back in, so it seemed like the only way to get the user to have access was for Domain Users to have access, but that was only because he had not yet taken on the privileges of the new group.
I was having a very similar problem if not the same at a company where I work.
We had a shared folder called ScanTamp which a scanner would write files too. everyone (the people) could access it apart from two people even though the group "everyone" have full control.
It turned out (after reading this post) that because these two users where part of other groups those permissions from the other groups were over-riding the "everyone" access - so I added Domain Users and another group which I won't mention for confidentiality reasons.
But that appeared to fix the problem and they could gain read-write access again.
So I'm not sure if your's will be such a simple fix or not.
But the entire IT team were stumped as to why these two people couldn't gain access "Access denied" every time they tried to access this folder.
even though all the permissions were correct and I'll say *technically* they should have be allowed access, but adding another one or two of there groups to the share permissions solved my problem.
Hope this may help someone.
I recently had issue with a user that is a member of Active Directory group that should provide Read Access to a folder. Ran GPUPDATE /FORCE on her PC with her logged in. Also ran GPRESULT and the PC recognizes she is a member of the AD group. Yet she gets access denied to the folder on the server. User is running XP SP3. Any suggestions?
Clancy's suggestion was the solution for us. We had setup the shares through the SBS console and then applied NTFS permissions to individual folders and sub-folders (we're using Access Based Enumeration). Then logged in as a member of the group that had write permissions and could not write. Argh. After seeing Clancy's post, I looked at the Share permissions as managed in the SBS console and "Everyone" only had read access. Changing the Share permissions for Everyone to read and change fixed the issue. Only those within the approved groups can access and read according to the NTFS permissions, but since those groups are a subset of "Everyone" on the Share, the Share permissions need to allow "Everyone" to change the folders.
- Proposed as answer by JWeil Wednesday, September 18, 2013 5:13 PM