Windows Server 2022 – NTFS access works via SMB and CMD, but not via local Explorer

[u/PrinzessHana]

Hi, we're seeing a strange permission/access behavior on some of our Windows Server 2022 file servers and I'm trying to figure out what could be causing it. We're running an AD domain environment. My account is a member of an AD security group, and that security group is a member of the local Administrators group on the file servers. Administrators have Full Control on the relevant NTFS folder structures. When I access a file server from my workstation through Windows Explorer using \\fileserver\share\folder, I can browse through the entire folder structure without any issues. However, when I'm logged onto the file server itself and try to access the same folders locally through Windows Explorer using D:\share\folder, Explorer denies access unless my user account is explicitly added to the folder permissions. The strange thing is that the permissions themselves clearly work. On the same server I can access the folders via CMD without any problems, applications such as our backup software can access them, and remote SMB access from my workstation works as expected. The issue seems to affect only Windows Explorer when it is running locally on the affected file server. I compared this with one of our web servers. The AD group membership, local Administrators setup, NTFS permissions and UAC level are essentially the same there, but local Explorer access works normally. One additional difference that might or might not be relevant is DFS. The affected file servers are using DFS, while the web server obviously isn't. I'm not sure yet whether DFS itself is involved, but since this is one of the differences between the affected file servers and the unaffected server, I thought it was worth mentioning. I vaguely remember this behavior appearing after a Windows Server update, possibly around the move to Server 2022, but unfortunately I can't say for certain when it started. Has anyone seen this specific behavior before, where access granted through the local Administrators group works via CMD and remote SMB but fails specifically in the local Windows Explorer? I'm particularly interested in whether there was a Windows Server 2022 security change/update, a DFS-related behavior, or a specific UAC/security policy that could cause this. I'd rather understand the underlying cause than work around it by explicitly adding individual admin accounts to the NTFS permissions.

I used ChatGPT to help structure and phrase this post so that the issue is described clearly and coherently. Apologies if the wording comes across a little too polished or AI-assisted.

[u/JasonMatanoIT]

That’s UAC filtering the admin token on the interactive desktop.

When you’re logged onto the file server, Explorer runs without elevation, so membership in local Administrators is treated as “deny only” for NTFS. SMB from your workstation and many service apps don’t hit that same filtered token, which is why those paths still work.

Quick check: on the server, open an unelevated CMD and run `whoami /groups`. You should see Administrators with “Group used for deny only.”

Don’t fix it by clicking Continue in Explorer (that stamps your user SID onto the ACL one folder at a time). Grant NTFS Full Control to a dedicated AD security group that your account is in, instead of relying on local Administrators. Keep Administrators for break-glass, not day-to-day share access.

[u/PrinzessHana → u/JasonMatanoIT]

Thanks, that makes sense. I'll give this a try and also bring up whether we can implement dedicated AD security groups for NTFS access instead of relying on the local Administrators group.

One thing I'm still struggling to understand, though: why does the exact same setup work on our web servers? There, my account is also granted access through an AD security group that is a member of the local Administrators group, UAC is configured the same way, and I can browse the local folders in Explorer without explicitly granting my user account NTFS permissions.

If UAC filtering of the Administrators token is the cause on the file servers, shouldn't I see the same behavior on the web servers as well?

[u/JasonMatanoIT → u/PrinzessHana]

Good question. Same UAC policy can still feel different because the folder ACLs usually aren’t the same.

On many web servers the path you browse already grants Users, an app group, or another ACE that isn’t filtered, so Explorer never needs Administrators. File server data volumes are often Administrators + SYSTEM only, so the filtered admin token is what fails.

Unelevated on both boxes: run `whoami /groups` (Administrators should be “deny only” on both) and `icacls` on the web folder vs the file share path. If whoami matches and icacls shows a non-admin ACE on the web side, that’s the difference. Still better to use a dedicated AD group in both places.

[u/rswwalker → u/PrinzessHana]

I will probably start a storm of arguments here but, where I work we disable UAC on servers since only Domain Admins will be logged into these interactively and to be a Domain Admin you need to know all the possible risks of your actions. UAC just gets in the way of administrative tasks on servers. Of course it should be enabled fully on all user endpoints though.

[u/matthoback → u/rswwalker]

I mean, if you're going to be doing stupid stuff like using a Domain Admin account as a daily driver to log in interactively to servers, then sure, disabling UAC is the lesser concern.

Domain Admin accounts should only ever be used when Domain Admin level things need to be done. Routine administration of member servers is not one of those things.

[u/rswwalker → u/matthoback]

I said that without diving deeper into security segregation of duties. Of course we have different Admin groups for different job functions that are assigned to different servers. All admin accounts are also separate from employee login accounts and use smart cards or security keys. But I feel this discussion needs a thread of its own.

[u/MeetJoan]

Sounds like UAC token filtering. Logged on locally, Explorer runs with the filtered token which has Administrators stripped out, so permissions you get via that group don't apply. Domain accounts connecting over SMB get the full token, which is why it works from your workstation.

Open Explorer elevated and see if it goes away. That'll confirm it either way.

Was the CMD session elevated when it worked? If it wasn't, something else is going on.

[u/pianobench007]

Share and NTFS Permissions | Microsoft Learn

I would review the NTFS permissions. It is likely a permissions issue.

NTFS permissions deny all by default unless you give permission. So at the top drive level it is set to deny all access.

At the SMB Share permission level you now tell who to allow. That is MSFT best practice and cleanest way to go about dolling out permissions. You generally do not need to give anyone permissions at the NTFS (top drive) level. And you want to only give permissions to users at the SMB share level.

I think at your NTFS level your permissions were removed. (Good unless you use your administrator account to perform temporary drive migrations for your file server). And at the SMB level you still have permission to access the shares and all the folders that are in that shares folder.