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. 

Find-PCBCrypto: Function to aid in finding CryptoLocker encrypted files

CryptoLocker is a nasty beast of a bug causing all manner of havoc.  If it's done nothing else, one positive impact it has had on IT is that we're making sure our backups aren't being ignored.

One of the hardest parts still, though, is finding what got hit, and who got hit, and in a timely enough manner to minimize the damage done.  Part of that problem is that there is no scanner that can definitively detect CryptoLocker encrypted files, specifically because they just look like any encrypted file; there is no virus fingerprint to be had.

So, how to scan for its fingerprints proactively?  It seemed like a nearly impossible task (I'm no malware expert, so figuring out how to detect something like this isn't my forte).  When I started digging in to the problem, though, I did learn a few key pieces to the puzzle.

Read More

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.