Trying to understand this value. Seeing it set on some of my user
objects. So 512 would be a normal user but 32 means that no
password is required. When a new user object is created, my
understanding (by reading quite a few threads) is that 544 is the
default uac. Does this sound right?
Is there a point when something doesn't need to listen to domain policy?
It should fail to meet standards by the password length now, I'm not
sure how I can verify the actual password is set to nothing. on
particular account, I've tried logging in with a blank password but get
a bad password failure.
Thanks all!

I think I've figured it out. J Thanks all.

:m:dsm:cci:mvp | marcusoh.blogspot.com

From: ActiveDir-owner (AT) mail (DOT) activedir.org
[mailto:ActiveDir-owner (AT) mail (DOT) activedir.org] Behalf , Marcus
(CCI-Atlanta)
Sent: Monday, 16, 2006 11:57 AM
To: ActiveDir (AT) mail (DOT) activedir.org
Subject: [ActiveDir] userAccountControl 544

Trying to understand this value. Seeing it set on some of my user
objects. So 512 would be a normal user but 32 means that no
password is required. When a new user object is created, my
understanding (by reading quite a few threads) is that 544 is the
default uac. Does this sound right?

Is there a point when something doesn't need to listen to domain policy?
It should fail to meet standards by the password length now, I'm not
sure how I can verify the actual password is set to nothing. on
particular account, I've tried logging in with a blank password but get
a bad password failure.

Thanks all!

userAccountControl 544If you create with ADSI, e.g. VBScript, and don't set a password before the initial setInfo you get 2 + 32 + 512. If you then set the password, you can un-set 32. If you don't set a password and you have a password restriction policy, you cannot un-set 32 or 2.

Setting the password won't change the value of userAccountControl, you have to do that by yourself.

Note. Although it doesn't really do much if you have password policies in place, it is probably not recommended to set 32, therefore you need to instruct your provisioning people on how to properly create a user object.

Note also. The cookbook code () will end up with a value of 544. So you need to take this into account and set uac at the end in addition to enabling the user (personally, I would not use accountDisabled() and would set uac to what I want).

If you want to go through what you have and correct this, assuming all users have a password, you can do this with ADMD:

adfind -default -bit -f "&(objectCategory=person)(objectClass=user)(userAcco untControl:AND:32)" userAccountControl -adcsv |admod userAccountControl::{{userAccountControl::CLR::32} } -unsafe

[Re] Note. If you have a pwd policy in place, you must set passwords first.

Message
From: M (AT) cox (DOT) com
To: ActiveDir (AT) mail (DOT) activedir.org
Sent: Tuesday, 17, 2006 6:24 AM
Subject: RE: [ActiveDir] userAccountControl 544

D*mn I'm glad you can understand my gibberish. I reread that post and came up with a 'what the h*//?'

In the circumstance w/ ADSI, what would be the proper routine to follow? After the user is created and the password set, do you change the value of 544 back to 512?

I've noticed the same about 544. The user doesn't appear to have sufficient rights to reset their password to a blank password. The administrator (or someone with full control on the object - have not verified what permissions exactly) can set their password to null all day long. That's kind of dismaying.

Also, 544 doesn't go back to 512 after the user password has changed so it's kind of subject to always holding the capacity for a blank password. Don't really like that either.

Thanks for the information, as always. I picked up your book, by the way. Fun read.

From: ActiveDir-owner (AT) mail (DOT) activedir.org [mailto:ActiveDir-owner (AT) mail (DOT) activedir.org] Behalf joe
Sent: Tuesday, 17, 2006 12:43 AM
To: ActiveDir (AT) mail (DOT) activedir.org
Subject: RE: [ActiveDir] userAccountControl 544

Depends on how the user is created. If using ADSI, you cannot specify a password while creating the user so if you have a password length policy then you have to create the account disabled or set to allow a blank password or both.

With the raw LDAP API (and I would expect S.DS.Protocols), you can create an enabled user because you can specify the password in the ADD op. You can do that with admod if you like.

Note that an account set with 544 doesn't necessarily have a blank password, but it could be.

--
'Reilly Active Directory Third Edition -

From: ActiveDir-owner (AT) mail (DOT) activedir.org [mailto:ActiveDir-owner (AT) mail (DOT) activedir.org] Behalf M (AT) cox (DOT) com
Sent: Monday, 16, 2006 5:19 PM
To: ActiveDir (AT) mail (DOT) activedir.org
Subject: RE: [ActiveDir] userAccountControl 544

I think I've figured it out. J Thanks all.

:m:dsm:cci:mvp | marcusoh.blogspot.com

From: ActiveDir-owner (AT) mail (DOT) activedir.org [mailto:ActiveDir-owner (AT) mail (DOT) activedir.org] Behalf , Marcus (CCI-Atlanta)
Sent: Monday, 16, 2006 11:57 AM
To: ActiveDir (AT) mail (DOT) activedir.org
Subject: [ActiveDir] userAccountControl 544

Trying to understand this value. Seeing it set on some of my user objects. So . 512 would be a normal user but 32 means that no password is required. When a new user object is created, my understanding (by reading quite a few threads) is that 544 is the default uac. Does this sound right?

Is there a point when something doesn't need to listen to domain policy? It should fail to meet standards by the password length. now, I'm not sure how I can verify the actual password is set to nothing. on particular account, I've tried logging in with a blank password but get a bad password failure.

Thanks all!