Weird Permissions Issue

Ok, I don't know if I am just missing the obvious staring at me in the face or what, but I am encountering a very weird permissions issue on our four dfs file servers. I do not believe this is a dfs issue at all, but since dfs is involved and replicates everything, I am including the information about it.

Here is how we are setup:

3x 2008 R2 DFS file servers, each in their own AD site
1x 2008 DFS file server, in its own AD site
DFS is at Domain-based 2008 Mode
Each DFS server is also a Namespace server

DFS/File server folder structure

All folders under "users" dfs target is a single target in dfs. So the shares, temp, and users folders all exist on the same lun or disk array depending on location.

Folder contents:
shares - department shares
temp - temp document storage that isn't backed up but allows "sharing" between departments instead of emailing files
users - user my documents redirected

NTFS Permissions (identical between all four servers since dfs)

I just added (Monday) the Traverse folder / execute file allow on the shares to see if that would resolve the issue. This isn't checked on the "users" folder. So that is the only difference between the shares and users folder, but the issue exists with or without that option checked.

Issue:
The below issue only occurs with Windows 7 computers. Windows XP doesn't have this issue.

Users (W7) can traverse the "users" folder without issue. This allows them to see all users folders, but only access their own.
Users (W7) can't traverse the "shares" folder. They get access denied with a standard event id 4656 audit failure in security logs. This only occurs on the 3x 2008 R2 servers. They can traverse the 1x 2008 just fine.

I know that since Vista/2008, they removed the "Bypass Traverse checking" that was enabled by default on XP/2003 and before. This option IS NOT manipulated in anyway via local or gpo. So it should be disabled as per Microsoft default for Vista/W7.

Anyone have any ideas or thoughts? NTFS permissions are identical and working as expected otherwise without issue.

Thanks!

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

instant000

Can you check your settings for SMB signing?
and also for NTLMv1/v2?

That's the first thing comes to mind as some features that fluctuate in default settings between Windows versions that could adversely affect your ability to access shares.

Hope this helps.

Please let us know your resolution.

About7Narwhal

Clear the cached offline files on a client computer and see if the issue is resolved. Also, I assume you can access [URL="file://\\server\share"]\\server\share[/URL] without issues (UNC non-DFS)? Lastly, try to manually map your DFS and see if they can connect. We had this issue a lot on my old contract.

crrussell3

@instant000 I will look into those here and let you know. Not really sure it can be a version issue, as users can access the "users folder" without issue, but not the "shares folder".

*** EDIT ***
Both smb signing and NTLM v1/v2 settings are default. We don't have any local or gpo manipulating these.

Below is a screen shot while logged into one of the dfs servers (all are setup the same way) showing the local file structure (not dfs, though it presents the same). We use dfs just to mask the file share location for migration purposes, failover, and automatic replication between sites.

@About7Narwhal That is the thing. I get the exact same results no matter what method I use. It can be unc to dfs (\\domain.org\dfs\users) or the server share (\\server\share$) itself. Same results when I manually map a network drive via dfs or unc. Offline files are disabled by default except on a handful of laptops, which are experiencing the same issue.

local.jpg