Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2006-12-26) "userAccountControl" Attribute – It Can Be A Pain To Delegate!

Posted by Jorge on 2006-12-26

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!

* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
############### Jorge’s Quest For Knowledge #############
######### ########


One Response to “(2006-12-26) "userAccountControl" Attribute – It Can Be A Pain To Delegate!”

  1. […] Because the delegated admins either have full control over user objects or at least write permissions on the "userAccountControl" attribute, they are allowed to change each single bit that is represented by that attribute. For more info also see: "userAccountControl" attribute – It can be a pain to delegate! […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: