Posts Tagged ‘OU permissions’

Remove Active Directory Delegations

Saturday, February 25th, 2017

Over time, Active Directory delegations tend to accumulate and drift from the standards in the enterprise.  Removing the delegations for a user or group can be slow, especially if you do it manually.  Microsoft has a good article about this process, but none of the methods I found did what I needed.  I wanted a script which could look at all or selected OUs in AD for a delegation, and then delete them all.

Remove-DelegatedOUPermissions.ps1 is an advanced function which can be used to report and remove assigned delegated permissions from OU objects and containers.  You can choose the domain and searchbase, and you can search for full name or partial matches.  For example, if you wanted to report on or delete the delegations for Site1PWAdmins and Site2PWAdmins, you could simply specify “PWAdmins”.  The search is case-insensitive, and you can search for more than one string by separating your search terms with a comma.

This function always creates a log file.  The default name is derived from the domain name, and the default location is the desktop.  The function requires the ActiveDirectory module, but unlike Set-ACL, it can be used to write permissions in another domain.  It supports WhatIf, and a confirmation is required before you commit changes.  Because it is an advanced function, you can use Get-Help for details about use.

Script Text

Too many permissions in AD

Friday, May 6th, 2011

From MSKB 2001769: When you propagate the permissions on an object such as an organizational unit (OU), group, user, or computer in Active Directory, you may receive the following error:

“Unable to save permission changes on ObjectName. A constraint violation occurred.”

Cause: This will happen when the Access Control List (ACL) size on the object exceeds 64 KB, or approximately 1,820 Access Control Entries (ACEs) depending on the size of the ACEs.

What is the best practice here?  This is what our lead AD admin said:

The way I cleaned this up was as follows:

  • Review the individual accounts on all the OUs to get a list of the permissions those folks were granted.
    • As you might expect, they were granted FULL (for both their admin and regular accounts)
    • PLUS they were granted additional, specific sets (as if FULL didn’t already grant them that)
  • I then created a brand new OUAdministrator group (it covers more than one site, so I figured OU was the best I could do) and plunked only their admin account in that group
    • I gave that group FULL control
    • Then I went through the OUs as follows:
    • Turned on inheritance & applied that change
    • Added the OUAdministrator group to the top OU and granted it FULL (generic)
  • Then on each OU, I went through and deleted the following:
    • All individual user accounts (‘cause they were included in the group)
    • All duplicative permission sets for other groups they had already granted FULL (generic) permissions—they have about 3 or 4 admin groups on the ACLS. Most had FULL (generic) PLUS individual sets of ACLS on long lists of 50 or more attributes for individual objects)
  • I would also have removed broken SIDS at this point, but there weren’t any

Technically, I could also have removed the additional admin groups since they were redundant, but I just needed to get the ACLs down to a manageable size.

This is why granting generic permissions can be a good thing. For example, for folks like workstation/server admins, just grant them FULL (generic) on computer objects. There’s no point in trying to be more specific since they can’t “do” anything bad with computer accounts and it reduces the number of permissions required on the ACL.

The problem is definitely a case of “being too specific”.