What not to do with access control lists on Active Directory objects

Although Active Directory can give a very fine level of control over properties of objects, its best to perform a bit of planning before making changes.  Some ACL entry changes can give a lot of access, while adding very little to an Access control list, while other property specific changes can make a huge size difference on your access control list.

For those not familiar with access controls, basically all objects in active directory have an attribute on them which specifies the access to the object.  This can be referred to as an Access Control List (ACL), security descriptor (SD, SDDL), or object security.  Within the ACL, there are entries which may be referred to as Access Rules, or Access Control Entries (ACE).  You will see different terminologies in different tools and .NET classes that manipulate the information.  There are also different formats that the rules can be read in.  Typically everyone is familiar with the security tab in Active Directory Users and Computers (available in advanced view).  In the advanced mode of this, you have a better view of the access control entries.  The ACE's themselves contain information such as:

ActiveDirectoryRights :  ReadProperty, WriteProperty
InheritanceType          :  None
ObjectType                :  e45795b2-9455-11d1-aebd-0000f80367c1
InheritedObjectType     : 00000000-0000-0000-0000-000000000000
ObjectFlags                : ObjectAceTypePresent
AccessControlType     : Allow
IdentityReference         : S-1-5-10
IsInherited                   : False
InheritanceFlags           : None
PropagationFlags         : None

You can find more about decoding these in my previous post which provides a script for this.  In the background though, you have uglier formats to deal with like:

SDDL language   O:DAG:DAD:AI(A;;LCRPLORC;;;PS)
Binary: hex code

If you look at technet on Security Descriptors, the maximum size of an ACE is 64k or roughly 1820 entries.  That's quite a few, but its not too hard to shoot yourself in the foot with this.  For example, you want to give someone access to almost every property of an object, but then you decided that there is one or two specific properties you don't want them to have.  So you may start with giving "read all properties" and "write all properties" rights to the account.  Then you go back into advanced view and uncheck a few properties.  This removes the previous few entries for read/write all, and expands it into hundreds of ACE's for each specific property.  We can see here how this affects the size.  I created a directoryservices.directoryentry object pointing to a computer object

PS> $de.psbase.objectsecurity.getsecuritydescriptorbinaryform()|measure-object
Count    : 11112

Here we see how many bytes are in the ACL.  Now if I go and do what I just described to the ACL

PS> $de.psbase.objectsecurity.getsecuritydescriptorbinaryform()|measure-object
Count    : 45692

The size has quickly exploded to a value that is edging towards the maximum size.  When we hit the max size, we may end up with various failures in different places, with perhaps some very vague errors as to what the real problem is.  The functions that manage the ACL and do conversions may be limited to a length value of 64K, causing exceptions to be thrown when they are processed.

If you really need to do something like this, what you should do is grant the broad level of access and then create a few separate deny permission entries for the few properties that they shouldn't have access to.