Setting Windows ACLs to allow sub-subdirectory access

Question

We're in the process of moving some directories from NetWare to Windows, and have run into a difference of permissioning. Because NetWare makes this easy, we have whole volumes where no users have any rights at the top of the volume, and the first, second, and third tiers of directories are where the rights are granted. Due to how the NetWare trustee system worked, if you had access to a directory deep in the tree, you'd be able to browse to it from root with no problem. This had the handy side-effect of only showing the directories you have access to when you enumerate a directory you otherwise have no permissions to be in.

The 'only showing the directories you have access to' thing is resolved through Microsoft's Access Based Enumeration (ABE), and yea this is a good thing.

The problem we're having is figuring out what rights and security policies need to be set to in order to allow users to browse from a root share down to a directory they have access to. Examples make this easier to explain.

\\server\share\finance\audit\auditreports\HR-Q4-2007

The audit team grants rights for the HR Managers to the audit report directory above ("HR-Q4-2007"). Under NetWare, this would allow the HR managers to start at \\server\share\ and then browse through finance, audit, and auditreports, to get to the directory. One permission, and it just worked.

The "Bypass Traverse Checking" security policy means that the HR managers can map a drive directly to \\server\share\finance\audit\auditreports\HR-Q4-2007\ and it'd just work. That's not what we want, we want the user to be able to start at the top and browse down.

Does this require the use of the 'Traverse Folder' NTFS right to enable this? If so, it means a much more complex permission environment, but we can work it out. How is this problem solved when ABE is also in use?

Solution 1

You're looking for "List Folder Contents" permission (which includes the "Traverse Folder" right) applied to folders w/o inheritance. In order for access-based enumeration to work, though, you can't inherit that permission down the hierarchy, so you have to get a bit crazy with it.

At the root of the share, add the permission "HR Managers - List Folder Contents", and then in the "Advanced" settings, set that permission to apply to "This folder only". Because you're not inheriting the new permission to subfolders or files ABE will "hide" the subfolders and files the user doesn't have access to but still allow the "HR Managers" users to traverse the top level folder of the share.

Repeat that moving down each level of the hierarchy until you hit the level where permissions have become permissive for "HR Managers".

Doing this for a lot of different groups can make for large ACLs on folders and the potential for a lot of administration headache. I end up using "Authenticated Users - List Folder Contents" applied to the root of shares with restricted folders right off the root. I also try to keep my permission hierarchies as shallow as possible so that I don't have to do this "This folder only" trick with other groups at lower levels, if possible.

It's an ugly hack, but it's the best way I know to get access-based enumeration to do what you want. An "inherited rights filter" would be SO nice and would do exactly what we want, but Microsoft didn't implement such a thing.

(I never particularly liked Netware, but the permission model on the filesystem w/ respect to real-time inheritance and inheritance filtering is pretty sweet.)

Solution 2

Been there, done that. Migrated from Netware to Win2K about 8 years back, and yes, the differences in how permissions work can be a stumbling block. The best advice I can give is to not be too hung up about it, and to sometimes accept a less-than-perfect solution.

You'll never be able to replicate the precise behaviour, so what it boils down to is what's required to enable your users to get at the data they need. I can't tell you how to get it working exactly the same way as it did under Netware, but I can give some tips on how to avoid creating something that might come back to bite you.

In this case I'd aim to keep the structure as simple as possible. Splitting out the "auditreports" folder as a separate group folder would be my first step. Technically there's no real reason to do this, it would work fine as a subfolder with the correct permissioning on, but from the perspective of keeping your side of the house manageable it makes things easier.

The next thing I do, every time, is put the UNC to a group folder into the group description in AD. This way, you can write a logon script that reads the groups a user is a member of, pulls out the description property, and maps a drive to it. I'm not certain if you have AD from your post, but having a logon script that you never have to update saves on a LOT of admin overhead. If you can do it in your environment, do it.

Finally, and going back to my first point, coming at Windows file sharing with your Netware hat firmly on is not a good idea. They're differnent OSs and they just work differently. In an ideal world you'd just migrate and absolutely nothing would change so far as the users are concerned, but sometimes you just gotta break those eggs to make that omlette.

Comments

[Deb]

Yish, that IS ugly. But it'll work. The NetWare file-systems are some of the most metadata-heavy file-systems I've ever run in to (thus making NSS's port to Linux so tricky), but it makes a complex permission environment EASY. I'll miss it, and our backup admins will miss salvage.

[Spence]

My only gripe w/ Netware's filesystem permission model was that silly "Execute only" permission. I recall writing a loader in 16-bit DOS assembler language years ago just to prove somebody wrong when they SWORE to me that there was no way to recover the code from a program marked "Execute only" in the Netware permission. Heh heh.