We help IT Professionals succeed at work.

How to report fileshare permissions with cascading groups in a mixed workstation/domain system?

High Priority
Last Modified: 2019-10-09
I started to build a spreadsheet but decided there must be a better way:

I have a domain with workstation fileshares.
For each:

I've followed common practice in setting local groups (because there are non-joined accesses to be allowed).
One might call this the "permissions" level.

And, I've established domain groups.
One might call this the Role level.

And, I've made the domain groups members of the local groups.
Nice and tidy....  It's easy to remember the structure because it's consistent; i.e. used consistently.

But it's not so easy to analyze because there are groups within groups.  
Who has permission?
Are there any duplicate or conflicting permissions?

What's a good way to *see* all this?
It should be easy.
For a small organization, it should fit on one page.

Part of the challenge is that some of the information is only on the workstation and some is only on the AD Server.  
Maybe a PowerShell script?
I've not found any commercial or other tools that seem to address this.
Watch Question

kevinhsiehNetwork Engineer

Well, duplicate permissions shouldn't be an issue, From an organizational perspective, why would it matter if HR executives got access to a folder by virtue of being in HR or an Executive?

How can permissions conflict? Standard practice is to only apply allow permissions. Windows permission model is cumulative, so permissions cannot conflict unless you have an explicit DENY. A DENY always takes precedence over ALLOW. So, if you grant a Domain Admin Full control over a folder, but Deny Domain Users all access, the Domain Admin will be denied because they are also a member of Domain Users.

Once you move fully over to domain groups, your group names should be descriptive enough so that it is fairly easy to know what groups/users are members. Maybe you need to list all nested groups on the spreadsheet. There shouldn't be too many.

There are all sorts of programs that can list this out, but I have never really needed them in 25 years.
Fred MarshallPrincipal


Yes, that makes sense. I guess my challenge is that there are local and domain users and groups mixed for now.    The local users can only be at the lowest levels of the hierarchy.  Soon enough the local users won't exist.  Duplicate permissions will matter if some are ALLOW and others are DENY.  But, as you point out, that may not be "conventional" or even necessary.  That you've not needed any tools for this is revealing and probably tells me why there aren't such things evident really.

Thanks for the input!
Steve KnightIT Consultancy

How many systems with file shares in are you talking about, also are these then permissions on the shares or ntfs permissions on individual files or folders?

Share permissions is easy enough to enumerate, ntfs permissions of course you have to scan every file on the share as any one of them could have had different permissions applied.

Of course of you know it is well controlled and users have never had full control access then only IT can have made permission changes and hopefully ntfs only contains groups

There are scripts around that will dump all permissions from a volume and that would show local and finding users and group names.

I would get a list of group memberships from the server where the local groups are and see how many users and domain groups are listed in each for starters?
Fred MarshallPrincipal


My apologies:  When I said "I have a domain with workstation fileshares." it would have been more accurate to say:  I have a domain AND a workgroup both with workstation fileshares.  For the moment at least, it's complicated.  I did ONE workstation fileserver set of permissions yesterday (both Share permissions and NTFS permissions) with a spreadsheet and it was what we call "interesting".   I expect everything to be in a domain context soon but that's not today and I have to keep things working.  So, unfortunately, there are local groups and domain groups that affect the same share.  There are also some legacy "individual" permissions of non-human Users.  These could be in local groups of course. It's really not a mess but it is complicated because there are 2 or 3 levels of permissions and both Share permissions and NTFS permissions are important in combination.  

Steve Knight:
I would get a list of group memberships from the server where the local groups are and see how many users and domain groups are listed in each for starters?
That's the sort of thing that I was hoping to avoid - leads to a spreadsheet.

There aren't that many systems with file shares - maybe 6 or 7.  Why is that important?  

I'd like to know of those "scripts around".  Searches didn't find them but maybe I wasn't on the right search vector?

Good point re: share permissions vs. NTFS permissions in terms of application.
kevinhsiehNetwork Engineer

There are tools. Just google "ntfs permissions reporter". Lots of hits.
IT Consultancy
The no. of servers I questioned as obviously 1 server and 4 file shares you might treat differently to 500 servers with 1000...

I'd have a think about what you want to see:

local users in local groups
local users in share permissions
local users in ntfs permissions

local groups in ntfs permissions
local groups in share permissions

AD groups in local groups
AD groups in share permissions
AD groups in ntfs permissions

AD users in local groups
AD users in share permissions
AD users in ntfs permissions

Owner of file but not listed in NTFS permissions

And of course deal with the fact that Mr X could be in a group or direct in NTFS permissions for one file 10 levels deep which has groups in higher up areas that don't allow access, or actually he is not in the share permissions so can't get as far as the NTFS permissions.

Also in typical legacy servers you might have a "Shared" area which is shared and then also various sub areas shared under different names - so a user could get to \\server\share\somedept\info\files also as \\server\share\files$

So... as has been said lots of scripts and tools which will lookup info, e.g. this simple powershell will pull all NTFS permissions in directory structure out into CSV file which I use for quick audits.  You might want to exclude in the scripts BUILTIN\Users, CREATOR OWNER, NT AUHORITY\SYSTEM etc.

 $OutFile = "\\server\home\Export-Permissions.csv" 
 $maxdepth = 5
 $RootPath = "\\server\share" 
 $actual_depth_param = [int]([regex]::Matches($RootPath, "\\")).count + [int]$maxdepth + 0
 $Folders = dir $RootPath -recurse | where {$_.psiscontainer -eq $true}

 foreach ($Folder in $Folders)
     if (([regex]::Matches($Folder.fullname, "\\")).count -lt $actual_depth_param)
         $ACLs = get-acl $Folder.fullname | ForEach-Object { $_.Access } 
         Foreach ($ACL in $ACLs)
             if (($ACL.IsInherited -eq $FALSE) -and !($ACL.IdentityReference -eq "MyDomain\Domain Admins"))
                 $OutInfo = "`"" + $Folder.Fullname + "`",`"" +  $ACL.IdentityReference + "`",`"" + $ACL.AccessControlType + "`",`"" + $ACL.IsInherited + "`",`"" + $ACL.InheritanceFlags + "`",`"" + $ACL.PropagationFlags + "`",`"" + $ACL.FileSystemRights + "`""
Add-Content -Value $OutInfo -Path $OutFile


Open in new window

I would suggest with your environment because of the local users and depending upon how many shares and whether they are all under a common root area you would be wanting to pull out info like this along with local group memberships and then linked global group memberships.

I'm listening here too for any good suggestions of tools to use, I normally write something myself to scan permissions and compare with what is documented, i.e. if someone has been added into NTFS except for group names of certain structure etc. rather than trying to dump out everything but depends... I have a site with 1000 users using a handful of top level file shares, others using DFS and one a couple that I have inherited with many hundreds of file shares on each of several servers - even down to users 'home' directories being shared individually 1990's NT4 style and even better no tie up between the format of name and their AD username!

Fred MarshallPrincipal