Re: [ActiveDir] userAccountControl 544
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
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
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
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
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
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
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
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!
[ActiveDir] userAccountControl
Hello, I am looking at some of these saved queries below and I don't see how they work. http://www.netpro.com/forum/messageview.cfm?catid=29threadid=257 I *think* I understand how the bit flags work but how does the LDAP query correspond to those flags? If I look at say, the disabled user query it is: ((objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.1 13556.1.4.803:=2)) How does 1.2.840.113556.1.4.803 translate to the second bit? Just wanting to get this straight. Thanks again for the help. Mike. Mike Newell Sr. Network Engineer Dimensional Fund Advisors 310-633-7889 This message and any attachments (the Message) may contain confidential, proprietary and/or privileged information and are only for their intended recipient(s). If you are not the intended recipient, you should notify the sender and delete the Message. E-mail transmissions cannot be guaranteed to be secure or error-free. This Message is provided for information purposes and should not be construed as a solicitation or offer to buy or sell any securities or financial instruments, or to provide investment advice in any jurisdiction where the sender is not properly licensed or permitted to do so. This Message is subject to additional conditions and restrictions. Please read them here: http://legal.dimensional.com/email/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] userAccountControl
Mike Newell wrote: ((objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.1 13556.1.4.803:=2)) How does 1.2.840.113556.1.4.803 translate to the second bit? Just wanting to get this straight. 1.2.840.113556.1.4.803 is RuleOID corresponding to AND test and 1.2.840.113556.1.4.804 is RuleOID for OR test. so userAccountControl:1.2.840.113556.1.4.803:=2 is a bitwise AND comparison of userAccountControl value with 2 (decimal value reflecting all bits that should be included in a test). Straight enough?:) -- Tomasz Onyszko http://www.w2k.pl List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] userAccountControl
Thanks everyone for the info! Mike Newell Sr. Network Engineer Dimensional Fund Advisors 310-633-7889 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge de Sent: Tuesday, October 18, 2005 9:29 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] userAccountControl It doesn't! 1.2.840.113556.1.4.803 is the equivalent of AND which is a LDAP matching rule object identifier (OID) It is bit 2 not because of the =2 but because of: 2^0=1 (1st bit) 2^1=2 (2nd bit) Etc. 2^9=512 (10th bit) Etc. 2^12=4096 (13th bit) Etc. 2^16=65536 (17th bit) Etc. userAccountControl:1.2.840.113556.1.4.803:=2 MEANS: bit 2 (2^1) from the userAccountControl attribute is ON (which means USER=DISABLED) (!(userAccountControl:1.2.840.113556.1.4.803:=2)) MEANS: bit 2 from the userAccountControl attribute is OFF (which means USER=ENABLED) Think binary ;-) (like IP addresses) (bin) = 0 (dec) 1 1 1 1 1 1 1 1 (bin) = 255 (dec) 1x2^7 1x2^6 1x2^5 1x2^4 1x2^3 1x2^2 1x2^1 1x2^0 128 64 32 16 8 4 2 1 = 255 (dec) 1 1 1 0 1 0 1 1 (bin) = 235 (dec) 1x2^7 1x2^6 1x2^5 0x2^4 1x2^3 0x2^2 1x2^1 1x2^0 128 64 320 8 0 2 1 = 235 (dec) You can find more info and explanations at: http://www.microsoft.com/technet/scriptcenter/resources/qanda/may05/hey0 512.mspx http://www.alvestrand.no/objectid/1.2.840.113556.1.4.803.html http://www.petri.co.il/ldap_search_samples_for_windows_2003_and_exchange .htm http://www.tek-tips.com/faqs.cfm?fid=5667 Cheers, jorge -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Newell Sent: Tuesday, October 18, 2005 17:45 To: ActiveDir@mail.activedir.org Subject: [ActiveDir] userAccountControl Hello, I am looking at some of these saved queries below and I don't see how they work. http://www.netpro.com/forum/messageview.cfm?catid=29threadid=257 I *think* I understand how the bit flags work but how does the LDAP query correspond to those flags? If I look at say, the disabled user query it is: ((objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.1 13556.1.4.803:=2)) How does 1.2.840.113556.1.4.803 translate to the second bit? Just wanting to get this straight. Thanks again for the help. Mike. Mike Newell Sr. Network Engineer Dimensional Fund Advisors 310-633-7889 This message and any attachments (the Message) may contain confidential, proprietary and/or privileged information and are only for their intended recipient(s). If you are not the intended recipient, you should notify the sender and delete the Message. E-mail transmissions cannot be guaranteed to be secure or error-free. This Message is provided for information purposes and should not be construed as a solicitation or offer to buy or sell any securities or financial instruments, or to provide investment advice in any jurisdiction where the sender is not properly licensed or permitted to do so. This Message is subject to additional conditions and restrictions. Please read them here: http://legal.dimensional.com/email/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This message and any attachments (the Message) may contain confidential, proprietary and/or privileged information and are only for their intended recipient(s). If you are not the intended recipient, you should notify the sender and delete the Message. E-mail transmissions cannot be guaranteed to be secure or error-free. This Message is provided for information purposes and should not be construed as a solicitation or offer to buy or sell any securities or financial instruments, or to provide investment advice in any jurisdiction where the sender is not properly licensed or permitted to do so. This Message is subject to additional conditions and restrictions. Please read them here: http://legal.dimensional.com/email/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir
[ActiveDir] UserAccountControl Bitwise question
I thought flagging an account to require password change would change the UserAccountControl attribute from 512 to 8388608 (0x80). (per article KB 305144) But its not happening. Accounts that are flagged for that are still 512. Am I misunderstanding something? likely J Mark Creamer Systems Engineer Cintas Corporation Honesty and Integrity in Everything We Do
RE: [ActiveDir] UserAccountControl Bitwise question
Shouldn't that be changed to 8389120 instead (512 + 8388608)? From: Creamer, Mark [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 4:22 PMTo: [EMAIL PROTECTED]Subject: [ActiveDir] UserAccountControl Bitwise question I thought flagging an account to require password change would change the UserAccountControl attribute from 512 to 8388608 (0x80). (per article KB 305144) But it's not happening. Accounts that are flagged for that are still 512. Am I misunderstanding something? likely J Mark Creamer Systems Engineer Cintas Corporation Honesty and Integrity in Everything We Do
RE: [ActiveDir] UserAccountControl Bitwise question
Yeah, I guess thats probably right, just like disabling an account is 512 + 2 = 514. Still, if anyone knows why it wouldnt be changing when the password is expired mc -Original Message- From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 4:35 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] UserAccountControl Bitwise question Shouldn't that be changed to 8389120 instead (512 + 8388608)? From: Creamer, Mark [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 4:22 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] UserAccountControl Bitwise question I thought flagging an account to require password change would change the UserAccountControl attribute from 512 to 8388608 (0x80). (per article KB 305144) But it's not happening. Accounts that are flagged for that are still 512. Am I misunderstanding something? likely J Mark Creamer Systems Engineer Cintas Corporation Honesty and Integrity in Everything We Do
RE: [ActiveDir] UserAccountControl Bitwise question
The problem is the KB article, not you Mark. The userAccountControl attribute isn't updated when the password expires. Same for the lockout flag. Regards. Robbie Allen http://www.rallenhome.com/ http://www.rallenhome.com/blog/adcookbook/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Creamer, MarkSent: Thursday, December 04, 2003 4:44 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] UserAccountControl Bitwise question Yeah, I guess thats probably right, just like disabling an account is 512 + 2 = 514. Still, if anyone knows why it wouldnt be changing when the password is expired mc -Original Message-From: Mulnick, Al [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 4:35 PMTo: '[EMAIL PROTECTED]'Subject: RE: [ActiveDir] UserAccountControl Bitwise question Shouldn't that be changed to 8389120 instead (512 + 8388608)? From: Creamer, Mark [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2003 4:22 PMTo: [EMAIL PROTECTED]Subject: [ActiveDir] UserAccountControl Bitwise question I thought flagging an account to require password change would change the UserAccountControl attribute from 512 to 8388608 (0x80). (per article KB 305144) But it's not happening. Accounts that are flagged for that are still 512. Am I misunderstanding something? likely J Mark Creamer Systems Engineer Cintas Corporation Honesty and Integrity in Everything We Do
