OU

Fix Active Directory broken security inheritance problem

Ran into a situation at a client location where in Active Directory, the security permissions applied to an OU were not getting inherited permissions on to the objects. Basically, security inheritance was broken.This causes a problem when the administrative accounts or groups needing to modify an attribute on the AD object throw errors, or are unable to edit the AD object.

To find out which objects were not getting the inherited permissions run the following :

I ran it on the entire domain to identity potential problem accounts. 🙂

To fix the issue:

Reference:

https://docs.microsoft.com/en-us/dotnet/api/system.security.accesscontrol.objectsecurity.areaccessrulesprotected?view=netframework-4.8
https://blogs.msdn.microsoft.com/adpowershell/2009/10/22/viewconfigure-protected-acl-and-fixing-broken-inheritance/

The Lazy Way To Do Active Directory Inventory

From time to time admins have to run an inventory of what is running in the AD environment. This is a good practice for audits, inventory, removing decommissioned servers, or any other good reason. The details that are required are like when was computer/ server created, when was it last logged into, what is the OS, Service Pack, and OU details if any organization was done in structuring the OU.

Luckily PowerShell can provide all of that information in a nice .csv file which can be later edited in Excel to do filtering as needed.

Open up PowerShell in Admin mode on the DC or create a session if doing this remotely.

Result: