Re: [ActiveDir] userAccountControl 544

2006-10-17 Thread Paul Williams
Title: userAccountControl 544



If 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 (http://techtasks.com/code/viewbookcode/1555) 
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 
ADMOD:

adfind-default -bit -f 
"(objectCategory=person)(objectClass=user)(userAccountControl: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.


--Paul


  - Original Message - 
  From: 
  [EMAIL PROTECTED] 
  To: ActiveDir@mail.activedir.org 
  
  Sent: Tuesday, October 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: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of joeSent: Tuesday, October 17, 2006 12:43 
  AMTo: ActiveDir@mail.activedir.orgSubject: 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. 
  
  
  --
  O'Reilly 
  Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
  
  
  
  
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of [EMAIL PROTECTED]Sent: Monday, October 16, 2006 
  5:19 PMTo: ActiveDir@mail.activedir.orgSubject: RE: 
  [ActiveDir] userAccountControl 544
  I think I’ve 
  figured it out. J Thanks 
  all.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  :m:dsm:cci:mvp| 
  marcusoh.blogspot.com
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of Oh, Marcus (CCI-Atlanta)Sent: Monday, October 
  16, 2006 11:57 AMTo: 
  ActiveDir@mail.activedir.orgSubject: [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. One on particular account, I’ve tried 
  logging in with a blank password but get a bad password 
  failure.
  Thanks 
  all!


RE: [ActiveDir] userAccountControl 544

2006-10-17 Thread joe
Title: userAccountControl 544



Yes once the user is created and the password set, change 
the UAC to 512. 


--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
[EMAIL PROTECTED]Sent: Tuesday, October 17, 2006 1:24 
AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] 
userAccountControl 544


D*mn 
Im 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?

Ive 
noticed the same about 544. The user doesnt 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. Thats kind of 
dismaying.

Also, 
544 doesnt go back to 512 after the user password has changed so its kind of 
subject to always holding the capacity for a blank password. Dont really 
like that either 

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



From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of joeSent: Tuesday, October 17, 2006 12:43 
AMTo: ActiveDir@mail.activedir.orgSubject: 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. 


--
O'Reilly 
Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm







From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of [EMAIL PROTECTED]Sent: Monday, October 16, 2006 
5:19 PMTo: ActiveDir@mail.activedir.orgSubject: RE: 
[ActiveDir] userAccountControl 544
I think Ive 
figured it out. J Thanks 
all.





































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



From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Oh, Marcus (CCI-Atlanta)Sent: Monday, October 16, 
2006 11:57 AMTo: ActiveDir@mail.activedir.orgSubject: 
[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 doesnt need to listen to domain policy? It should 
fail to meet standards by the password length now, Im not sure how I 
can verify the actual 
password is set to nothing. One on particular account, Ive tried logging 
in with a blank password but get a bad password failure.
Thanks 
all!


RE: [ActiveDir] userAccountControl 544

2006-10-17 Thread joe
The password attribute is unicodePwd.

If you want to see it in action, here is a command that will create 100
enabled userids in a domain. Do a network trace and you will verify that
there is but a single LDAP call for each and every ID.

admod -sc adau:100;SomePassword1!;cn=mytestuser,ou=testou,dc=domain,dc=com

That is a shortcut switch which submits the following real switches to
admod...

Selected Switches
-add
-autobase 100:ou=testou,dc=test,dc=loc
-bmod {{*RDN*}}_{{*cnt*}},{{*parent*}}
-csv
-expand
-exterr
-kerbenc

Selected Attributes
unicodepwd::SomePassword1!
objectclass::user
useraccountcontrol::512
pwdlastset::-1
samaccountname::{{*name*}}_{{*cnt*}}
 


--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm 
 

-Original Message-
From: Michael B Allen [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 17, 2006 2:15 AM
To: ActiveDir@mail.activedir.org
Cc: [EMAIL PROTECTED]
Subject: Re: [ActiveDir] userAccountControl 544

On Tue, 17 Oct 2006 00:42:59 -0400
joe [EMAIL PROTECTED] wrote:

 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? How? What's the name of the attribute?

Mike

-- 
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/

List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx


RE: [ActiveDir] userAccountControl 544

2006-10-17 Thread joe
Title: userAccountControl 544



You have to love the new bitwise capabilities of admod... I 
love it and and have to say how cool it is even though I wrote the darn 
functionality. Very very useful. :) The new admod cuts down considerably 
on the _vbscript_ I have to write now. 


--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Paul 
WilliamsSent: Tuesday, October 17, 2006 4:48 AMTo: 
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] 
userAccountControl 544

If 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 (http://techtasks.com/code/viewbookcode/1555) 
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 
ADMOD:

adfind-default -bit -f 
"(objectCategory=person)(objectClass=user)(userAccountControl: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.


--Paul


  - Original Message - 
  From: 
  [EMAIL PROTECTED] 
  To: ActiveDir@mail.activedir.org 
  
  Sent: Tuesday, October 17, 2006 6:24 
  AM
  Subject: RE: [ActiveDir] 
  userAccountControl 544
  
  
  D*mn 
  Im 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?
  
  Ive 
  noticed the same about 544. The user doesnt 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. Thats 
  kind of dismaying.
  
  Also, 
  544 doesnt go back to 512 after the user password has changed so its kind of 
  subject to always holding the capacity for a blank password. Dont 
  really like that either 
  
  Thanks 
  for the information, as always. I picked up your book, by the way. 
  Fun read.
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of joeSent: Tuesday, October 17, 2006 12:43 
  AMTo: ActiveDir@mail.activedir.orgSubject: 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. 
  
  
  --
  O'Reilly 
  Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
  
  
  
  
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of [EMAIL PROTECTED]Sent: Monday, October 16, 2006 
  5:19 PMTo: ActiveDir@mail.activedir.orgSubject: RE: 
  [ActiveDir] userAccountControl 544
  I think Ive 
  figured it out. J Thanks 
  all.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  :m:dsm:cci:mvp| 
  marcusoh.blogspot.com
  
  
  
  From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  On Behalf Of Oh, Marcus (CCI-Atlanta)Sent: Monday, October 
  16, 2006 11:57 AMTo: 
  ActiveDir@mail.activedir.orgSubject: [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 doesnt need to listen to domain policy? It 
  should fail to meet standards by the password length now, Im not sure how I 
  can verify the actual 
  passw

RE: [ActiveDir] userAccountControl 544

2006-10-16 Thread Marcus.Oh
Title: userAccountControl 544








I
think Ive figured it out. J
Thanks all.











































































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















































































From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Oh, Marcus (CCI-Atlanta)
Sent: Monday, October 16, 2006 11:57 AM
To: ActiveDir@mail.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 doesnt need to listen to domain policy? It should
fail to meet standards by the password length now, Im not sure how I can
verify the
actual password is set to nothing. One on particular account, Ive tried
logging in with a blank password but get a bad password failure.

Thanks all!








RE: [ActiveDir] userAccountControl 544

2006-10-16 Thread joe
Title: 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. 


--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
[EMAIL PROTECTED]Sent: Monday, October 16, 2006 5:19 
PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] 
userAccountControl 544


I think Ive 
figured it out. J Thanks 
all.





































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



From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Oh, Marcus (CCI-Atlanta)Sent: Monday, October 16, 
2006 11:57 AMTo: ActiveDir@mail.activedir.orgSubject: 
[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 doesnt need to listen to domain policy? It should 
fail to meet standards by the password length now, Im not sure how I 
can verify the actual 
password is set to nothing. One on particular account, Ive tried logging 
in with a blank password but get a bad password failure.
Thanks 
all!


RE: [ActiveDir] userAccountControl 544

2006-10-16 Thread Marcus.Oh
Title: userAccountControl 544








D*mn Im 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?



Ive noticed the same about 544. The user doesnt
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. Thats kind of dismaying.



Also, 544 doesnt go back to 512 after the user password
has changed so its kind of subject to always holding the capacity for a
blank password. Dont really like that either 



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







From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of joe
Sent: Tuesday, October 17, 2006 12:43 AM
To: ActiveDir@mail.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. 







--

O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm

















From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Monday, October 16, 2006 5:19 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] userAccountControl 544

I
think Ive figured it out. J
Thanks all.











































































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















































































From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Oh, Marcus (CCI-Atlanta)
Sent: Monday, October 16, 2006 11:57 AM
To: ActiveDir@mail.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 doesnt need to listen to domain policy? It
should fail to meet standards by the password length now, Im not
sure how I can verify the actual password is set to nothing. One on
particular account, Ive tried logging in with a blank password but get a
bad password failure.

Thanks all!