Access Denied to SYSVOL from DC when using UNC path

Question

I'm trying to solve an issue for a customer and I'm running out of ideas.

We've upgrading all the hardware and server OS's. The domain now has two new Server 2019 DC's. The old DC's have been decommissioned. The forest was at 2012 functional level and was brought up to 2016. Also, FRS was upgraded to DFRS just prior to adding the new servers. I don't know if any of that matters to the issue.

When logged into a DC, we can not write to the SYSVOL when using a UNC path such as \domain.local\netlogon. It gives an Access Denied error. By going to c:\Windows\SYSVOL\ we are able to write to the folder. This only happens when logged into a DC. If you demote the same DC, it works.

From one of the two DC's, I can write to netlogon when using \192.x.x.x\netlogon but this does not work from the other DC.

The errors show Access Denied in the SMB Server logs but not further information.

If I demote a DC, I can use SYSVOL via UNC path. When I promote it back, I lose the ability again. Also, any non-domain controller can access the SYSVOL via UNC normally.

I've tried the following: -Disabled firewall -Disabled UAC -Disabled SMB Signing offloading on the NIC -Disabled SMB Signing -Prefer IPv4 over IPv6 -Disabled IPv6 -Transferred FSMO roles and repromoted DC's -Changed NIC in ESX to VMX3 from the e1000 -Scoured GPO and Local Policies -Moved DC to Computers OU -Tried a new Domain Admin account -Cleaned up DNS

Solution 1

Can you please undo all of that stuff you've done to troubleshoot, especially with disabling IPv6 - it's required. And DCs in the the Domain Controllers OU. Just undo everything you've done, including the SMB signing stuff, firewall, etc.

You can't just treat DCs like any random server.

Firstly, where are you trying to write TO? Netlogon and SYSVOL actually point to different locations inside sysvol. They are also junction points on disk - you can't just write to random places in there. https://support.microsoft.com/en-au/help/324175/best-practices-for-sysvol-maintenance (it mentions FRS, but the structure hasn't changed).

You may have had customised perms on your legacy DCs, and now you're trying to do something that used to work, but won't with the out-of-box perms (which means you need to carefully consider what you're trying to do and how best to do so securely).

After your DFSR implementation, did you do thorough checks to see if replication was working properly? Actually, check these things:

• Does repadmin /replsum show recent replication on each DC?
• Does NET SHARE show SYSVOL and NETLOGON shared on all DCs?
• Run dcdiag on each DC. Are there any errors? If there are, STOP and troubleshoot that!
• Is the time on your DCs from an NTP source and are they within 5 minutes of each other?
• Are there any firewalls between the dcs or whatever client you're using to open sysvol

Here's the share info on a minimally-changed DC install:

C:\>net share netlogon
Share name        NETLOGON
Path              C:\Windows\SYSVOL\sysvol\mydomain.com\SCRIPTS
Remark            Logon server share
Maximum users     No limit
Users
Caching           Manual caching of documents
Permission        Everyone, READ
                BUILTIN\Administrators, FULL


C:\>net share sysvol
Share name        SYSVOL
Path              C:\Windows\SYSVOL\sysvol
Remark            Logon server share
Maximum users     No limit
Users
Caching           Manual caching of documents
Permission        Everyone, READ
                BUILTIN\Administrators, FULL
                NT AUTHORITY\Authenticated Users, FULL

Here are my perms - you may have extras, but you should not have LESS - here we've specifically added the Group Policy Creator Owners to allow them to manage the logon scripts

C:\>icacls C:\Windows\SYSVOL\sysvol\mydomain.com\SCRIPTS
C:\Windows\SYSVOL\sysvol\mydomain.com\SCRIPTS CREATOR OWNER:(OI)(CI)(IO)(F)
                                            NT AUTHORITY\Authenticated Users:(OI)(CI)(RX)
                                            MYDOMAIN\Group Policy Creator Owners:(OI)(CI)(M)
                                            NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                                            BUILTIN\Administrators:(RX,W,WDAC,WO)
                                            BUILTIN\Administrators:(OI)(CI)(IO)(F)
                                            BUILTIN\Server Operators:(OI)(CI)(RX)

C:\>icacls C:\Windows\SYSVOL\sysvol
C:\Windows\SYSVOL\sysvol NT AUTHORITY\Authenticated Users:(RX)
                        NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(GR,GE)
                        BUILTIN\Server Operators:(RX)
                        BUILTIN\Server Operators:(OI)(CI)(IO)(GR,GE)
                        BUILTIN\Administrators:(RX,W,WDAC,WO)
                        BUILTIN\Administrators:(OI)(CI)(IO)(WDAC,WO,GR,GW,GE)
                        NT AUTHORITY\SYSTEM:(F)
                        NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
                        BUILTIN\Administrators:(RX,W,WDAC,WO)
                        CREATOR OWNER:(OI)(CI)(IO)(WDAC,WO,GR,GW,GE)

If there's something wierd with your SYSVOL share, this guide is a good place to start. Do NOT muck around with trying to "reset" perms using icacls or whatever if something important is missing. Just recreate SYSVOL. If you've added a custom permission, try removing it. Given what's been going on with your testing, I wouldn't be surprised if SYSVOL was in a dirty shutdown state. https://support.microsoft.com/en-au/help/2958414/dfs-replication-how-to-troubleshoot-missing-sysvol-and-netlogon-shares.

For further help, please ensure you've returned your DC configs to a proper state, that there are no DCDIAG or SYSVOL or time or replication errors, and where you're trying to write to in SYSVOL. Also do a whoami /groups to ensure you're really in Domain Admins and, if you're logged onto a DC, that it shows you're also a member of BUILTIN\Administrators. And that you've logged off and on again (or run klist purge) if you make any changes - I recommend bouncing the DCs. One at a time. Transferring the FSMO roles in between.

If you've got actual errors in the logs or DCDIAG, give the text.

Solution 2

Basically, you are not supposed to do this. This is a security protection put in place to avoid unwanted modification of very critical domain files. The correct way to modify the SYSVOL contents is via the c:\windows\sysvol location on a DC that you mentioned in your post. The changes will replicate to other DCs with normal DFS-Replication.

You can see more information from duplicate question Bizarre - Domain Admin has no rights to modify domain scripts directory

Comments

[Greg Askew]

From one of the two DC's, I can write to netlogon when using \192.x.x.x\netlogon but this does not work from the other DC. What are the share permissions on the DC where it does not work?

[Rhys W]

Creator - Full (Subfolders and files) Auth Users - Read & Execute (All) SYSTEM - F (All) Admin group - Full (subfolders and files) Admin group - Special - all but modify (This folder only) Server Operators - Read and execute (all)

[Greg Askew]

Those aren't share permissions, those are NTFS permissions.

[Rhys W]

Gotcha. Everyone has full access to share

[bjoster]

There are just two things: Share Permissions and NTFS ACLs. When you are checking those, always remember UNC. The "administrator" is and will not be (at least in explorer) a "Domain Admin". You'd have to use other processes for that (a shell for example).

[Rhys W]

What do you mean by this? "The "administrator" is and will not be (at least in explorer) a "Domain Admin""

[duct_tape_coder]

Does this answer your question? Bizarre - Domain Admin has no rights to modify domain scripts directory

[Rhys W]

Thanks for your helping! I'd already walked back all that stuff so no worries there. Also, these are new DC's, added to an existing domain. The old DC's were properly removed and that's been checked as well. 1. dcdiag shows no errors 2. repadmin /replsum shows no errors 3. SYSVOL shows in state 4, Normal 4. whoami /groups shows correct group membership 5. acls are identical to yours, including GPO Creator Owners 6. DC's had been bounced, including moving FSMO 7. Time is right 8. The firewall is disabled, it happens even when the client\server are the same. Again, ONLY happens on DC's

[LeeM]

OK, so where exactly are you trying to copy your files to? Or are you just trying to open \\mydomain.com\NETLOGON and write something there? Which should work. And what about going via the drive share - assuming your SYSVOL is on C: - \\dc1\C$\Windows\SYSVOL\sysvol\mydomain.com\scripts ? I am assuming you've tested your file with the local path. Is your test copying an existing file, or are you creating a new one?

[LeeM]

Do you have ANY GPOs making changes to SMB security, NTLM, NetworkServer, NetworkClient for the DCs other than the defaults? Run GPResult to check. What about errors in Microsoft-Windows-SMBServer/Security and Operational or Microsoft-Windows-SMBClient/Security event logs? Is SMB2 enabled if you run Get-SmbServerConfiguration ? NullSessionPipes include netlogon,samr,lsarpc? EnableStrictNameChecking set to False? Finally, how about a brand new account outside of your standard OUs that's added to Domain Admins?

[Rhys W]

I can't write\delete new files or save existing. From DC1 and DC2 to \\domain.local\netlogon. Both give the error. SMB events show Access Denied. If I drill to C:\Windows\SYSVOL*, it does work. ---SMB2 is enabled ---NullSessionPipes have the netlogon, samr, lsarpc ---EnableStrictNameChecking is set to True.

[LeeM]

EnableStrictNameChecking must be FALSE on the DCs. Remember, you're going via \\[domain name], which is an alias, not the actual server name. Maybe your server build process sets it, or you have a GPO writing it. It's an OS default after Server 2008 (R2?), but I've just checked random 2012+ DCs from 6 different domains, and they all have it disabled. Run Set-SmbServerConfiguration -EnableStrictNameChecking $false. I don't know if you have to bounce the box, but try it and see. If it doesn't seem to have worked, check whether it's been reset to True and look for a GPO.

[Rhys W]

No luck. I disabled it and reboot both DC's and same error.

[LeeM]

And has the setting reappeared? If so, you must have a GPO or something that's reenabling it. If not, time to call MSFT.

[Rhys W]

EnableStrictNameChecking is still set to False. I'll see about MSFT. Thank you for trying!

[duct_tape_coder]

@Trix Can you elaborate on why you think IPv6 is required for DCs? I've worked in multiple environments that disabled IPv6 on all systems including DCs. This has never been an issue and moreso has always been considered "best practice" for security reasons. Usually the stated reason is that not all software is correctly configured to handle, or protect, IPv6.

[LeeM]

It's not why "I think" IPv6 is required, it's that disabling IPv6 is an unsupported configuration - it breaks LDAP over UDP. Disabling IPv6 has not been a security "best practice" anywhere I'm familiar with - we used to disable it to just not have the interface chattering away when it's not needed. If your routers aren't forwarding the traffic, you don't need to worry about it. IPv6 is used in the loopback interface on all modern Windows OSes. Also, you shouldn't have random software on your DCs.

[duct_tape_coder]

Thanks for the link. Do you have one of official Microsoft documentation indicating it's not supported? We don't set the DisabledComponents flag, we just remove the ipv6 binding from all the NICs. I was able to confirm just now in our production environment that a UDP ("Connectionless") SSL connection to port 389 is still possible using Wireshark and LDP.exe. Also worth noting in your link they use 0xFFFFFFFF which is called out as incorrect here support.microsoft.com/en-us/help/929852/… (correct is 0xFF)

[LeeM]

This is nothing to do with SYSVOL permissions and especially not via a remote share. It's also not current security best-practice on Windows.