3

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?

Improve this question

3 Answers 3

Reset to default
7

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.)

Improve this answer
2
  • 1
    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.
    – sysadmin1138 ♦
    Jun 25, 2009 at 18:21
  • 1
    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.
    – Evan Anderson
    Jun 25, 2009 at 18:27
1

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.

Improve this answer
1
  • 1
    It's the user-revolt we're fearing. If we change how their data is organized, there will be great wailing and gnashing of teeth. Because we've been netware for so long, they're still deeply enmeshed in drive letters. Homedirs are on U. Shared directories are on P. Period. Windows is more flexible that way, but we need to ease them into it.
    – sysadmin1138 ♦
    Jun 25, 2009 at 23:40
0

These instructions are the "End All" and correct process for doing this.

Pre-Req: Enable access-based enumeration.

  1. Server Manager > File and Storage Services > Shares
  2. On particular Share, right click > properties > settings > Check - Enable access-based enumeration

Secondly: Create Active Directory Group

  1. Navigate to your Users folder. Below folder, create or use existing Groups OU.
  2. Create new Group and name it accordingly (e.g Folder Permission - Sub_Folder1)
  3. Add User to the new Group

Assign permission to Sub_Folder1 exclusively.

  1. Navigate in server's explorer to Sub_Folder1 (e.g. Sharing_Folder > Sub_Folder1)
  2. Right Click > Properties
  3. Security > Advanced > Disable Inheritance > Convert
  4. Add new Group with whatever permissions you need. Check "Replace all child..."
  5. Close out of properties.

Now properly share it so Enumeration occurs dynamically.

  1. Right click Sub_Folder1
  2. Share with ... > Specific People
  3. Choose new Group.
  4. Make sure permissions for that group is correct... Either Read, or Read/Write.
  5. Then Share.

Confirm

  1. Now have user log out of windows and back in.
  2. New path should be accessible, and only that specific path to Sub_Folder1 should be seen.
  3. Full control will be allowed in Sub_Folder1 if those were the permissions you gave.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .