Alan's Blog

"Yeah. I wrote a script that will do that."

Remove Active Directory Delegations

Posted on 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

Tags: , , ,
Filed under Active Directory, Alan's Favorites, Functions, My Best, PowerShell, Scripting, Security, Windows Administration | No Comments »

Too many permissions in AD

Posted on 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”.

Tags: ,
Filed under Scripting, Windows Administration | No Comments »

Please Note

All the scripts are saved as .txt files. Newer files have a "View Script" button which will let you save or open a script in notepad. For earlier posts, the easiest way to download with IE is to right click on the link and use "Save Target As". Rename file from Name_ext.txt to Name.ext.

To see a full post after searching, please click on the title.

PowerShell Scripts were written with Version 3 or 4.

https connections are supported.

All new users accounts must be approved, as are comments. Please be patient. It is pretty easy to figure out my email address from the scripts, and you are welcome to contact me that way.

Site Search

Categories

Archives

SQL Site

Bad Behavior has blocked 169 access attempts in the last 7 days.