New AD Groups no longer working

chivo243 · 2023-06-22T12:13:07.000Z

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?

phildrew · 2023-06-22T12:25:26.000Z

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?

Quest-John · 2023-06-22T12:28:17.000Z

Sifox:

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.

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.

chris-kelly · 2023-06-22T12:30:15.000Z

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

Quest-John · 2023-06-22T12:34:07.000Z

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?

mr-s · 2023-06-22T12:43:40.000Z

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.

waltersalvatore · 2023-06-22T12:46:54.000Z

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

waltersalvatore · 2023-06-22T12:48:32.000Z

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

gary-m-g · 2023-06-22T12:52:46.000Z

“ 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!

gary-m-g · 2023-06-22T12:55:59.000Z

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?

waltersalvatore · 2023-06-22T13:00:24.000Z

OK, it seems to be working now. We

power cycled the file server then each domain controller one by one. After all servers where rebooted it seems to be working correctly now. It did not work after the file server or the first few DCs, so it seems it required all of them to be rebooted. All tests are showing the DCs are syncing correctly, We even did a manual sync using repadmin, checked all files created in the netlogon folders were replicated to all DCs quickly, etc. Not sure what could of caused this, but it seems it wanted the whole domain rebooted.

roboox · 2023-06-22T14:14:16.000Z

Are you using DFS for file shares?

it-monkey-mike · 2023-06-22T15:11:42.000Z

Walter3776:

OK, it seems to be working now. We

power cycled the file server then each domain controller one by one. After all servers where rebooted it seems to be working correctly now. It did not work after the file server or the first few DCs, so it seems it required all of them to be rebooted. All tests are showing the DCs are syncing correctly, We even did a manual sync using repadmin, checked all files created in the netlogon folders were replicated to all DCs quickly, etc. Not sure what could of caused this, but it seems it wanted the whole domain rebooted.

Power issues can cause this. I know in your earlier post you said there were no power outages, but there could have been “dirty power” sent to one (or more) DCs, causing this behavior. Power dips or spikes can be worse than outages (especially since they can be harder to detect). We had a similar issue here about a month ago. One of our VM hosts caused all of the VMs to behave “glitchy.” There were no signs of a power outage, but the symptoms fit.

waltersalvatore · 2023-06-22T15:15:18.000Z

All of our DCs are VMs, and the power in our city is bad so it very well may be the issue.

chivo243 · 2023-06-22T18:58:55.000Z

Glad it’s sorted… When I experienced a power outage, I ended up removing one DC, and standing up a new one, after going grey chasing the issue.

chrisf7 · 2023-06-27T12:48:27.000Z

I’ve learned that making share permission changes during to biz hours often causes access issues. Unless you log out and back in as @kevinhsieh suggested.

sifox · 2023-07-03T13:26:17.000Z

Quest John:

Sifox:

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.

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.

@johnt0828 - With all due respect, I have also been doing the exact same thing for 23 years, including 20 years at clinics and a hospital. It is recommended by Microsoft even that this be done that way. It does not violate HIPAA* in any way.

References:

Understanding Access Levels: Share vs NTFS, & How to Set Individual Access | Global Knowledge
- Last two paragraphs:
- "DOES GRANTING FULL CONTROL AT THE SHARE ALSO GRANT PERMISSION TO MANAGE THE SHARE?
  
  The answer is no. Giving someone Full Control of the share does not give them permission to manage or do anything to the share. You can only control a share if you are an Administrator or Server Operator on the server where the share exists.
  
  WHAT’S THE LAST WORD ON BEST PRACTICES?
  
  So, the bottom line is, go ahead and overshare on your share permissions. It’s OK. Nobody will think any worse of you for it. In fact, it may simplify your life as an Administrator to the point where you actually have time to do some of that oversharing on your social media for a change!"
Best Practice Security - Windows file sharing - Active Directory & GPO - Spiceworks
- Reference Step 2, including the picture:
- "Echoing some of the best practices set forth by Microsoft:
  1. Use centralized data folders. 2) Use intuitive, short labels for shared resources. 3) If users log on locally to access shared resources, such as on a terminal server, set permissions by using NTFS file system permissions or access control.
  Create a folder and share it. We will restrict users at the NTFS permission level in step 3."

Additionally, I said it could be setup that way. Depending on his environment, he could setup file enumeration and set it up such that if they do not have permissions to a folder, they do not even see it. There are many ways to setup a share that would depend on his environment what he can do, what is requested of him by the department/whoever, what is required of him by his supervisor/director/network administrator, etc.

With regards to your comment about even knowing a folder exists, as long as someone does not have access to the data itself, that is what matters. Knowing whether a folder name in general exists doesn’t matter. If someone has named a folder or file with a patient name, DOB, etc, then that is a problem, but that is a problem with the user and training/education. You wouldn’t ever set up a share on a patient named folder.

So again, I will still advocate that the share permissions be set to Everyone Full Control as it will not help anymore than locking down things at the file/folder level. If anything, it will hinder any troubleshooting needed trying to figure out a possible cause.

sifox · 2023-07-03T13:28:49.000Z

@chrisf7 - To clarify, it’s not making changes to the share that is the problem. The problem is actually adding someone to a group that they were not a member of at the start of the day.

Whether it is an old group or new group, the group membership tokens are set when a user logs on. You can have an existing share that “Finance” already has established permissions to, that was setup 3 years ago without issue. But if you add Bob to it during the day, Bob will not be able to get into it until they log off and back on again.

sifox · 2023-07-03T13:32:56.000Z

@mr-s - Incorrect. The only way someone can make permission changes is if they have permissions at the file/folder level to do so. This has nothing to do with the permissions set at the share level. Nor can they change the permissions of the share itself unless they have the correct permissions at the file/folder level.

sifox · 2023-07-03T15:05:47.000Z

@garygreenberg - I welcome your references to back up that what I said is wrong. Please see my references above as to why what I said is valid.
Additional references supporting my position:

[SOLVED] Share permissions - Windows Server - Spiceworks
See the best answer last sentence.
“The reason the best practice is to assign Everyone Full Control is because that way the NTFS permissions will always be the most restrictive (and therefore effective) permissions.”- NTFS\Share Permissions - Best Practice - Microsoft Q&A \
- The primary question references Microsoft best practices setting Everyone with Full Control on the share. Additionally, the best answer points out that anything else is only needed if there is not adequate permissions set at the file/folder level.
- "I can see still lots of resources on the web that state its best practice to set “Everyone\Full Control” at the share level and restrict access using NTFS permissions.
  
  I can remember this being taught in the training courses back in the day…"
- "…using everyone on share permissions simplifies the management, requiring changes to only to be made in one place.
  
  The other advantage of using the everyone permission on the share, is that directory traversal is easier to implement."
Best practices: sharing folders, NTFS+share permissions and the Everyone permissiion - Microsoft Community Hub
- Look at the best answer.
- "Now share the folder and leave it’s share permissions on „Everyone/Full Control.“
Control what a user can do at the directory and file level - Azure Files | Microsoft Learn
- The below points out that even if Everyone has “Full Control” at the share level, it is restricted by the file/folder permissions. So, by setting share to Everyone Full Control as I stated, but then being precise about your file/folder permissions as I stated, then you’re good to go, but you have taken out a huge variable in case things do not work and you have to troubleshoot.
- “Both share-level and file/directory-level permissions are enforced when a user attempts to access a file/directory, so if there’s a difference between either of them, only the most restrictive one will be applied. For example, if a user has read/write access at the file level, but only read at a share level, then they can only read that file. The same would be true if it was reversed: if a user had read/write access at the share-level, but only read at the file-level, they can still only read the file.”

@johnt0828