2 account options and where the flags are set

[Brandon McCombs]

Hello,

Where are the flags set that are equivalent to the user account options
corresponding to "User must change password at next logon" and "User
cannot change password"? I check either of those checkboxes and then I
view the userAccountControl attribute for the user using ADSIEdit.msc
and the value doesn't change from the normal account value of 512. All
the other options seem to change this value though. Obviously these
options take effect because when I login as the test user I am prompted
to change my password, so where else is ADS keeping track of this?

thanks
Brandon

 

[Richard Mueller]

Where are the flags set that are equivalent to the user account options
corresponding to "User must change password at next logon" and "User
cannot change password"? I check either of those checkboxes and then I
view the userAccountControl attribute for the user using ADSIEdit.msc and
the value doesn't change from the normal account value of 512. All the
other options seem to change this value though. Obviously these options
take effect because when I login as the test user I am prompted to change
my password, so where else is ADS keeping track of this?

thanks
Brandon

When you select "User must change password at next logon", the value of the
pwdLastSet attribute of the user object is set to 0. When you select "User
cannot change password" two ACE's (Access Control Entries) are set in the
DACL (discretionary access control list) of the user object. These ACE's
deny permission. To allow the user to change their password these ACE's are
removed.

 

[Brandon McCombs]

When you select "User must change password at next logon", the value of the
pwdLastSet attribute of the user object is set to 0. When you select "User
cannot change password" two ACE's (Access Control Entries) are set in the
DACL (discretionary access control list) of the user object. These ACE's
deny permission. To allow the user to change their password these ACE's are
removed.

OK thanks for the info. By chance is there any way to determine whether
the current value of the pwdLastSet attribute is high enough to hit the
threshold for locking an account out? Or is there a better way for
determining whether an account is locked out if using the ADUC snap-in
is not an option?

I've noticed that attribute seems to be set to the # of times that a
user entered a wrong password but the only way to know (as far as I can
tell) whether that value is really enough to lock an account is to
compare it to the GPO setting for locking accounts based on the # of bad
passwords.


As a side note, when I manually set the Change Password permission to
Allow the "user cannot change password" checkbox is not updated
accordingly. I thought that wasn't very consistent.

thanks

 

[Richard Mueller]

OK thanks for the info. By chance is there any way to determine whether
the current value of the pwdLastSet attribute is high enough to hit the
threshold for locking an account out? Or is there a better way for
determining whether an account is locked out if using the ADUC snap-in is
not an option?

I've noticed that attribute seems to be set to the # of times that a user
entered a wrong password but the only way to know (as far as I can tell)
whether that value is really enough to lock an account is to compare it to
the GPO setting for locking accounts based on the # of bad passwords.


As a side note, when I manually set the Change Password permission to
Allow the "user cannot change password" checkbox is not updated
accordingly. I thought that wasn't very consistent.

thanks

You are thinking of the badPwdCount attribute. This keeps a count on each
Domain Controller of the number of bad password attempts by the user against
that DC. The pwdLastSet attribute is a 64-bit (largeInteger) representing
the time when the password was last set. When badPwdCount reaches the domain
limit (the value of the lockoutThreshold attribute of the domain object),
the account is locked out. I use ADSI Edit (part of the W2k admin tools) to
view the values of these attributes, but there are other tools as well.
badPwdCount is not replicated, so a separate count for each user is kept on
each DC. pwdLastSet will typically be a very large number.

 

[Brandon McCombs]

You are thinking of the badPwdCount attribute. This keeps a count on each
Domain Controller of the number of bad password attempts by the user against
that DC. The pwdLastSet attribute is a 64-bit (largeInteger) representing
the time when the password was last set. When badPwdCount reaches the domain
limit (the value of the lockoutThreshold attribute of the domain object),
the account is locked out. I use ADSI Edit (part of the W2k admin tools) to
view the values of these attributes, but there are other tools as well.
badPwdCount is not replicated, so a separate count for each user is kept on
each DC. pwdLastSet will typically be a very large number.

Oh yeah I didn't realize I had specified the wrong attribute. I don't
know where my head was. The lockoutThreshold is what I'm looking for to
at least compare badPwdCount to something accessible from a 3rd party
tool that may not be on the DC. Couldn't it be said that since
badPwdCount isn't replicated that for a particular account that one DC
thinks is locked out that another DC would not? If not, what does
Windows do to make all DCs think that an account is locked out of all
DCs and thus the entire domain?

 

[Brandon McCombs]

You are thinking of the badPwdCount attribute. This keeps a count on each
Domain Controller of the number of bad password attempts by the user against
that DC. The pwdLastSet attribute is a 64-bit (largeInteger) representing
the time when the password was last set. When badPwdCount reaches the domain
limit (the value of the lockoutThreshold attribute of the domain object),
the account is locked out. I use ADSI Edit (part of the W2k admin tools) to
view the values of these attributes, but there are other tools as well.
badPwdCount is not replicated, so a separate count for each user is kept on
each DC. pwdLastSet will typically be a very large number.

I realized just now that what probably happens is that as soon as
someone surpasses lockoutThreshold through 1 DC the users's Account
Locked flag is set which is what prevents them from getting into another
DC although I'm not sure whether their badPwdCount values get reset on
those other DCs when the account gets unlocked.

 

[Joe Richards [MVP]]

lockoutTime replicates, so once a single DC locks out an account it
replicates throughout the domain.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm