Access Denied to SYSVOL from DC when using UNC path

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