Weird access issues NETLOGON/SYSVOL

[CHiLL]

Sorry if this post is difficult to read/comprehend - I'm struggling with how to word my experiece here.

 

I can't figure out what's going on with our SYSVOL share. I'm getting "Destination Folder Access Denied. You need permission to perform this action." messages when I attempt to create files/folders or modify files. I have checked our default Domain\Administrators group in ADUC and can see that our admin accounts are listed both explicitly and also via the Domain Admins nested group.

 

I've checked permissions and they are as follows:

Authenticated Users = Read & execute - This folder, subfolders and files
Server Operators (Domain\Server Operators) = Read & execute - This folder, subfolders and files
Administrators (Domain\Administrators) = Special (Everything except Full control, Delete subfolders and files and Delete) - This folder, subfolders and files
SYSTEM = Full control - This folder, subfolders and files
CREATOR OWNER = Special (Everything except Full control, Delete subfolders and files and Delete) - Subfolder and files only

 

Scenario:

I log onto my own workstation as a regular user, not a domain admin (though the account used to be a domain admin until I removed those permissions as a security precaution and I test that I can still do what I need). I have a separate individual Domain Admin account for when I need to use certain tools, where I use Run As to specify these credentials. I use Server Manager to log onto our servers, which I use Run As to run it in my domain admin's context and also has specified my domain admin account credentials specified as the logon credentials.

 

On my PC, logged on as my non-domain admin account, browsing to \\fqdn\sysvol just leaves me with read and execute permissions, which is expected.

However, if I use Server Manager (running as and logging in as my domain admin account) to log onto either of our DCs, I get the "Destination Folder Access Denied. You need permission to perform this action." message when trying to create/edit files.

The same happens if I specify other domain admin accounts.

 

In a strange twist, I can log onto my PC as my domain admin account and use File Explorer to navigate to SYSVOL and create and edit files. BUT...I CANNOT delete files or folders. Even stranger, while logged on as my domain admin account, when I remote to either of our DCs - using the same domain admin credentials I'm logged on either - I get the "Destination Folder Access Denied. You need permission to perform this action." message again, despite being able to access it via my non-DC workstation!

 

The same weirdness is also happening on other domain admin accounts we have, including my manager's.

 

SYSVOL persmissions are not something I'm just going to troubleshoot/change on a whim. Can anyone offer any suggestions as to what's going on?!

[Michael]

Any reason why you cannot demote the problematic DC and re-promote it?

[Koldov]

This happens on both DCs.

 

We have a further Administrator permission, do you have the following (in 'Security > Advanced)...?

 

 

Server 2019

[djm968]

Have you tried recreating your local profile for the non-admin account?

[CHiLL]

Any reason why you cannot demote the problematic DC and re-promote it?

I have demoted and re-promoted the server last night and the same issue still persists.

 

Have you tried recreating your local profile for the non-admin account?

I tried your suggestion and deleted the profile from both DCs, but the problem still exists when the profile was recreated.

[HPlum78]

Out of interest what happens when you try to modify a GPO/ create a new GPO? More importantly what happens when you select the default domain controller policy. Edited November 29, 2022 by HPlum78

[CHiLL]

Out of interest what happens when you try to modify a GPO/ create a new GPO? More importantly what happens when you select the default domain controller policy.

I can still edit GPOs, including both the Default Domain Controllers Policy and Default Domain Policy.

 

Edit 1: Though I am noticing that when logged onto DC1, loading Group Policy Management and editing the policy, it's pulling the policies from DC2 (our PDC) and not itself. For example, the name of the windows when editing the Default Domain Policy GPO will say "Default Domain Policy DC2.network.local] Policy". I don't know if that's normal behaviour or not, but I'd have thought DC1 would have pulled the policy from itself, since it's also a DC with GP management.

 

Edit 2: I can see that DC1 shows under "1 Domain controller(s) with replication sync", so it looks like it is working correctly.

Edited November 29, 2022 by CHiLL

[Chclark]

This sounds similar to issue we had on the new central network we have just implemented, and it was harden paths we noticed every now and again policy's where not applying as sysvol wasn't accessible. Unable to Access SYSVOL and NETLOGON folders from Windows 10 | Windows OS Hub

[CHiLL]

This sounds similar to issue we had on the new central network we have just implemented, and it was harden paths we noticed every now and again policy's where not applying as sysvol wasn't accessible. Unable to Access SYSVOL and NETLOGON folders from Windows 10 | Windows OS Hub

Thank you! Implementing this on one machine resolved it immediately after a reboot. I will test it a little more before rolling it out, but it looks like this was the cause of the issue and the resolution to fix it.

[Chclark]

Thank you! Implementing this on one machine resolved it immediately after a reboot. I will test it a little more before rolling it out, but it looks like this was the cause of the issue and the resolution to fix it.

 

Glad it helped was a pain as at one point we thought it was aload of new desktops we had just bought been effected luckily started seeing the issue on other devices after a while.

[CHiLL]

Glad it helped was a pain as at one point we thought it was aload of new desktops we had just bought been effected luckily started seeing the issue on other devices after a while.

Update, it worked that once and hasn't worked again since!

[Chclark]

Update, it worked that once and hasn't worked again since!

 

Assuming your pushing the keys via gpo? Has the entry been set on a rebooted machine on ones we notice we would install the key manually if it hadn't pulled it

[CHiLL]

Assuming your pushing the keys via gpo? Has the entry been set on a rebooted machine on ones we notice we would install the key manually if it hadn't pulled it

Yeah, I can confirm that the machine I'm testing on has the regsitry keys via GPO and it has also been rebooted recently.

[Koldov]

Can I ask some basic and probably stupid questions.... I'm missing something here and unfortunately reading the page linked I'm not sure what the issue is and what the solution is...

 

Are you saying harden the paths:

 

RequireMutualAuthentication=1,RequireIntegrity=1,RequirePrivacy=1

 

Or are you saying DO NOT harden the paths:

 

RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0

 

If this setting is not put into a GPO and it remains 'unconfigured' does that mean they are 'hardened' by default in the Server OS?

 

Also, what the link seems to be saying is that by setting these to '0' the security of the SYSVOL/NETLOGON folder is significantly reduced and that the only benefit is being able to access them by I.P. or other NTLM negotiated means, which may be why it isn't granting the permissions needed (and therefore there may be many other factors at play).

 

I seem to remember messing about with this years ago when a post mentioned they would help with GPO 'software installation'... must see if that GPO is still 'live'...

Edited January 20, 2023 by Koldov

[robyholmes]

Sorry to re-open a old thread. But I've been working for a client with issues accessing SYSVOL randomly from certain machines for months. I've read about every thread I could on the internet and tried every solution apart from disabling Hardened Paths. I wasn't willing to give up on this security for a quick fix.

 

Anyway, we've found a solution of sorts to our issue. It turned out to be UE-V being enabled on the machines which was causing it. They no longer used UE-V so disabling this wasn't a problem, doing so has fixed the issue with SYSVOL access. All while keeping the UNC Hardened paths on. I just wanted to put this out there as another solution to try.

I suspect the cause is a compatibility issue between a Windows Update, NIC driver (Maybe Intel, but more likely Realtek we think) & UE-V, but our testing shows disabling UE-V was the only solution as updating NIC drivers did nothing.

[broadld]

Good morning all,

 

We keep on having strange issues like this. Does this only seem to affect one make / model of PC's?

We look in the event logs of an affected machine and it is like it can't access the sysvol folder. Try to browse to the sysvol folder \\domain\sysvol and it says access denied!

The strange thing is it affects PC's randomly. One minute they are working fine and applying GPO's the next they don't.

If you browse to this individually on each domain controller it works fine. We do have UEV configured so may test switching this off to see if our issues dissapear.

[robyholmes]

I think it's linked to a driver, but not sure which one. But that would then sort of follow make and model as they'd use the same driver (Although it's a third party one, likely the NIC driver I suspect).

 

Once we disabled UE-V we stopped having issues (Once that policy applied mind, as disabling it can fail to apply of course). We also found you have to have the Domain Default policy in place and ideally not changed in anyway. Group Policy always seems to check this policy first (Even if others are higher than it in GP) and if it couldn't get to it for any reason, it would throw this error. Sometimes it would then apply others, sometimes it wouldn't.