Discovering folders with severed inheritance

What do you do when you find your network file share permissions are a little...weird?  That when you go to add permissions to a folder, some of the sub folders still remain out of reach?  Then, when you check them manually, you find that someone, at some point, disabled inheritance on that folder, and for no good reason.  Or, worse, someone set up the shares with a bunch of severed inheritance, mainly because they didn't know how to manage folder permissions well.

Whatever the reason, knowing where inheritance is severed in your file shares is not only useful, but critical to properly manage your shares.  To discover those inheritances, just go through each folder, one by one, and write down each one tha...

Wait!  There's got to be a better way to do this!

Fortunately, Get-Acl is here to help.  The AccessControl.DirectorySecurity objects it returns for folders has a property called "AreAccessRulesProtected", which when set to True, means inheritance is disabled.  So, I wrote a quick script to help locate and document this.  Note that you will need to be using an account with at least read permissions to all of the folders you are targeting; also, I've done this for a single server with multiple shares, each share I've put in a text file.  It will be easy to modify that as you need. 

File server permissions audit

This is another one of those quick and dirty snippets to solve a problem or answer a question (I'm a real fan of those); it could easily be modified to create a much more professional looking report.

I was asked to go through a file server share and find out who had access to what at a pretty basic level; mostly, we're comparing groups in an old domain to make sure the corresponding groups have been set in the new domain, but this can be tweaked to help answer many questions.

I'm positive there's a better way to target only domain permissions without calling them directly, and when I find it, I'll come back and update this post; but for now, this works.  Note that to strip out inherited permissions, you will need at least version 3 of PowerShell (that property isn't returned by v2's Get-Acl).

Depending on the size of the file shares you target, this will very likely take a long time to complete, and could give your shell a nice, very large memory footprint, so you'll want to watch for that.  Once you have the output, though, you could easily do some quick manipulation in the shell, or export it to CSV and load it up into Excel to analyze it with pivot tables (the best reason for keeping Excel around, in my opinion).

Oh, and you will need access to read permissions on everything for this to actually work.

Update: There were issues with the original iteration of the snippet, mostly in that the output got messed up somehow when dealing with large-ish data sets (like you'd expect from any file server that's been in production for a length of time): it seemed to get "stuck" (for lack of a better word) on security principals and just list permission after permission tied to the same principal (which a quick sanity check against the file or folder's actual permissions showed to be false).  I solved that by outputing each object to a temporary csv file, then importing it back at the end of the process, rather than hold everything in a variable while it worked.