I encounter many Active Directory forests that were built and maintained for years by other organizations, and then through mergers or acquisitions or business reorgs, I need to help bring them into the fold with the rest of my portfolio of AD forests.
AD permissions can be a deep rabbit hole, especially when sitting down to a new directory sight unseen. Administrators make subtle changes to AD objects over the years and a lot of entropy happens. Entropy that's not always easy to see or keep track of.
In this particular instance, we had an issue where a delegation of control was not working correctly and/or consistently. It was the common IT task of delegating the ability to reset passwords and unlock accounts (but nothing else) to a special "help desk" sort of security group. It was allowing members of the "help desk" group to reset the passwords of certain users, but not others. None of them were administrative users, or members of the Domain Admins group, the Account Operators group, etc. etc.
Turns out, the problem was that some security groups were not including inheritable permissions from the domain root object, so users who were members of these certain groups were immune to the effects of the delegation.
At first I actually thought to go and click on every single security group in the domain, checking on whether they were applying inheritable permissions or not. Then a few seconds I realized, "Don't be an idiot Ryan. The GUI is not your friend! Don't succumb to its siren song!"
After glancing at this excellent SDDL reference here for about 5 minutes, I whipped this up:
Foreach($_ In Get-ADGroup -Filter *)
[bool]$Inherits = $($(Get-ADGroup $_ -Properties *).nTSecurityDescriptor.Sddl.Contains('OI'))
If($Inherits -EQ $False)
And presto - a list of all security groups in the domain that are not applying inheritable permission from their parents.
PS - I admit, I still have to use a cheat sheet when reading SDDL. :P