1

This just started recently (or at least we just noticed it). Any new AD groups created are no longer working for folder permissions or shares. If I create a new shared folder and give the group access to the folder, no members of the group can access it. If I add individual or authenticated users, it works fine. So I add authenticated users to the share, and everyone can now open the share, but the sub folders behave the same way. I explicitly add a group and no group members can access the folders. I have created new folders and given them the exact same permissions as folders that already exist except using the new groups created and members cannot access them. I can reproduce this by making multipole groups, in multiple OUs and creating shares on multiple servers. Server is Windows 2019DC.

26 Spice ups
2

I am not sure how you have the shares setup. But, one thing I learned long ago is that when creating the share itself, make sure the share permissions are Everyone Full Control. Do not limit the share itself by setting permissions on it.

Instead, on the folders inside the share use file/folder level permissions as needed for the groups. Putting permissions on both can cause a lot of headaches trying to figure out where it is broken at. Even Microsoft recommends doing only file/folder level permissions to secure them.

Example:

The folder path C:\ShareMe needs to be shared out. \MyComputer\ShareMe is shared out with Everyone Full Control share permissions.

Then for file/folder permissions on C:\ShareMe, I might make everyone have this folder-only read-only permissions. Then for specific folders as needed, assign group permissions. So, C:\ShareMe\IT would have folder permissions for the following set for this folder and all sub-folders & files of “IT” has full control, System has full control, Administrators has full control, Domain Admins has full control, and that is it. So while everyone might be able to see that IT exists, unless they are in the IT group, they would not be able to go into it.

I hope that makes sense.

@waltersalvatore

5 Spice ups
3

Be sure that after you create the groups and add the members, that the users log off of the workstation and log back in again to pickup the new group memberships.

12 Spice ups
4

This may sound obvious but it is a ‘Security’ group you have created not a ‘Distribution’ group?

6 Spice ups
5

It sounds like Kevin has the right answer, any group membership changes require the user to logout and back in to pick up the new security token (wait 15 or so minutes for ad to sync too if you have multiple sites)

To expand on SiFox’s comment:

When using shares, the resulting access is the LOWER of the combination of share permissions and folder permissions. e.g if you give the share Everyone/full, and the folder Everyone/read, then everyone will have read permissions (lesser of the 2 from folder permission), conversely if the share has Everyone/Read and the folder has Everyone/Modify, then everyone will again have read permissions (lesser of the 2 from share permission).

That’s why there’s a tendency to give everyone/full on the share and just work with folder permissions. Personally I tend to give Everyone/Modify on the share and add Domain Admins with full (otherwise anyone could amend the share permissions).

4 Spice ups
6

Already thought of that. Created a new folder under a share that everyone already uses and has access to. The group permissions still will not work.

So basically, we have a servername\dept folder share that all departmental folders are under. Everyone has access to the Dept share, and each sub folder is only for each department group. Works fine and has for years. I create a new folder under the dept folder, and change the permissions to match every other folder in the dept folder, except using a new group. Group has no access. If I add an existing group, it works just fine.

7

Myself and a test account are currently the only members of the groups for testing, and both have logged out and in several times.

8

Not distribution. I have tried both Global and Universal security groups, with the same results.

9

Can you run the following in PowerShell and confirm that the permissions match what you’re expecting?

Get-ACL [FILEPATH] | Format-Table -Wrap
10

It shows the new group and the administrator groups.

For the group that is having issues, it is supposed to have modify rights.

“domain\newgroupl Allow Modify, Synchronize”

11

How many DCs are in your Domain?

Have you experienced any power outages in the recent past? If you have more than one DC did the outage affect all DCs?

Can you view your Group Policies?

12

There aren’t any deny permissions tripping you up? Domain controllers are replicating properly?

The command “gpresult /v /scope:user” will list the security groups you are a member of - are you getting membership in the group?

1 Spice up
13

Not true at all. For one thing, that may actually be against some regulations such as HIPPA. Allowing everyone to “see” a share that exists. I have been in IT for 23 years now and administrating AD domains including many file shares and never set the share permissions to the default EVERYONE FULL.

3 Spice ups
14

Can you check to make sure that the user has membership in the new group using cmd.exe on the client computer?

net user USERNAME /domain

Just for fun, try purging your kerberos ticket(s)

klist purge
15

Have you tried going into the properties of the new folder, security, advanced and did the “Effective Access” and choose the new group?

Could one of the higher directories be set to not inherit security?

16

Do not provide full-control on share level. Here one should stick with change permissions.

The reason is that if you give full control on share level and e.g. change permissions on NTFS level, then a user can still modify permissions for anything the user created. The user who created a folder or file has the ownership and ownership grants full control. That could result in a situation where the user manipulates permissions and that is something you do not want.

3 Spice ups
17

No power outages. We have multiple DCs located around the city.

18

All DCs are syncing as expected. We do not use deny permissions except on a very few folders and only in the IT department.

19

“ I am not sure how you have the shares setup. But, one thing I learned long ago is that when creating the share itself, make sure the share permissions are Everyone Full Control. Do not limit the share itself by setting permissions on it.”

This is some of the worst advice I have ever seen on this forum!

3 Spice ups
20

Are you using ABE (Access based enumeration)?

Also, do you have any GPOs which might be affecting access OR is this only a Share/NTFS permissions issue?