Jorge's Quest For Knowledge!

All You Need To Know 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!

(2008-05-20) Denying The Change Of Password Related Bits On User Objects

Posted by Jorge on 2008-05-20


In every AD domain it is possible to implement one or more password and account lockout policies. In W2K/W2K3 AD domains you can only define one password and account lockout policy and in W2K8 AD domains you can define multiple password and account lockout policies. For more info about that see:

So, as a domain admin you set up one or more password and account lockout policies, you delegate either the creation of user accounts or write permissions for the "userAccountControl" attribute (for example to disable user accounts) and you are good to go! The delegated admins that create user accounts should use passwords according to the definitions in the password policies. That is true, but there is a small "but…" here you might have missed.

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!

Everyone that is allowed at least write permissions on the "userAccountControl" attribute is able to change the bits it represents and therefore also the password related bits like configuring a password never to expire or configuring a password with reversible encryption or configuring the account without the need of a password.

I’m talking about the following bits:

  • "Password Never Expires" which can be configured with ADUC
  • "Store password using reversible encryption" which can be configured with ADUC
  • "Enable Password Not Required" which can be configured from the command line using NET USER….

Remember the password policy you just created that everyone MUST use? Because of the permissions on the "userAccountControl" attribute might go down the drain and you might still end up with accounts that do not comply with the password policies that are configured

So, is it possible to prevent this? Yes!

In W2K you can only prevent this by using a third party proxy tool to manage user objects. In W2K3 and later you can use three new extended permissions to prevent those bits from being edited, even if the admin has the permissions mentioned earlier. The three (new) "Extended Rights" are:

  • "Enable per user reversible encryption"
  • "Unexpire password"
  • "Update password not required bit"

These need to be configured at the domain level (required!) for "This Object only" with either ALLOW or DENY for a certain group. By default "Authenticated Users" have permissions for those three extended rights. But, it does not mean authenticated users can screw around with the password related bits in the "userAccountControl" attribute. You still need to have at least the permissions mentioned earlier. So, what you can do is create ONE group in AD for ALL three extended rights or ONE group in AD for EACH of the mentioned extended rights and configure it at domain level with a DENY ace and put everyone in the corresponding group(s) that has at least Full Control on user objects or write permissions on the "userAccountControl" attribute, BUT should not be able to screw around with the password related bits on the "userAccountControl" attribute. In the picture below you will find an example of such configuration

image

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

One Response to “(2008-05-20) Denying The Change Of Password Related Bits On User Objects”

  1. […] exceptions to this statement. One of those exceptions can be read through the following blog post (2008-05-20) Denying The Change Of Password Related Bits On User Objects. The list of userAccountControl bits can be found in the KB article How to use the […]

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

 
%d bloggers like this: