Both a computer object and an user object have an attribute called "userAccountControl".

The "userAccountControl" attribute is not an ordinary attribute like any other attribute (e.g. description) that represents just ONE meaning. No, the "userAccountControl" attribute represents several different meanings. In other words, the "userAccountControl" attribute is made of several bits/flags and each bit/flag represents something. Other attributes that are similar to this attribute are "searchFlags" (actually this is a attribute property) and "systemFlags".

 

For an explanation of each bit/flag within the "userAccountControl" attribute I suggest you read:

 

Now what could be so interesting to blog about this attribute? Several people are still unaware of the possible security issues with delegating the task to manage this attribute. The most common bits/flags used and known are:

  • "Account is disabled" (BIN: 00000010, DEC: 2, HEX: 0x00000002)
    • When the bit/flag is set (1) the computer or user is disabled
    • When the bit/flag is NOT set (0) the computer or user is enabled
  • "Password never expires" (BIN: 10000000000000000, DEC: 65536, HEX: 0x00010000)
    • When the bit/flag is set (1) the password of a user account will never expire (most commonly used with service accounts)
    • When the bit/flag is set (0) the password of a user account will expire according to the defined password policy of the AD domain.

 

So, when looking at this attribute of some user account, which by default has the "normal account" bit/flag set (BIN: 1000000000, DEC: 512, HEX: 0x00000200), and you see a decimal value of 66050 it means the following bits/flags are set:

  • Normal account (DEC: 512)
  • Account is disabled (DEC: 2)
  • Password never expires(DEC: 65536)

 

So, lets say I want to delegate some admin group the ability to disable/enable user accounts as they see fit. In that case you delegate "read property (RP)" and "write property (WP)"

Using DSACLS it would look like:

  • DSACLS "<DN of some OU>" /G "<sAMAccountName of some group>:RPWP;userAccountControl;user" /I:S

 

So, what happens now? You not only delegated the ability to disable/enable user objects, you delegated the ability to configure ALL the bits/flags represented by the "userAccountControl" attribute. As you can imagine that might NOT be a desired situation.

 

A solution to this problem can be the use of some third party tool where you do have the ability to delegate each and every bit/flag within the "userAccountControl" attribute.

 

Always be aware WHAT you are delegating!

 

 

Cheers,

Jorge

--------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
--------------------------------------------------------------------------------------------