What is strange, though, is that a bind attempt using an account with pwdLastSet of 0 fails, and a subsequent query (using a different account) of msds-UserPasswordExpired on the original account still doesn't show it as true. I would have expected the construction to occur on the later query.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Tuesday, January 31, 2006 7:28 PM To: [email protected] Subject: RE: [ActiveDir] ADAM msds-UserPasswordExpired The attribute msds-UserPasswordExpired is constructed. It depends entirely on how that construction is occurring. It sounds like it is only checking pwdLastset against policy and isn't acknowledging a value of 0 in pwdLastSet. That source hasn't been posted yet for us to view so I sent an email to someone inside of MS to see if I can get clarification. joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mr Oteece Sent: Tuesday, January 31, 2006 4:19 PM To: [email protected] Subject: Re: [ActiveDir] ADAM msds-UserPasswordExpired The users are not set to not expire password. On 1/31/06, Al Mulnick <[EMAIL PROTECTED]> wrote: > The only thing that comes to mind as to why this might be the case is > that your useraccountcontrol value is incorrect for what you're trying > to do. In order for the user to be required to reset their password, > UF_DONT_EXPIRE_PASSWD must not be set as well as I understand it. Can > you check the user account control and make sure that the user object > is not configured to never expire the password? > > > If this value is set to 0 and the User-Account-Control attribute does > not contain the UF_DONT_EXPIRE_PASSWD flag, then the user must set the > password at the next logon > > > On 1/30/06, Mr Oteece <[EMAIL PROTECTED]> wrote: > > > > I am using ADAM R2. I am setting the password and pwdLastSet > > attributes via the ADAM ADSI Edit program. msDS-UserPasswordExpired > > does become TRUE if you backdate the password (to backdate the > > pwdLastSet, I set the system time back a year, set the pwd, then > > return it to current time). It just doesn't become TRUE if > > pwdLastSet is 0. > > > > > > > > On 1/30/06, Al Mulnick <[EMAIL PROTECTED]> wrote: > > > Just so we're on the same page, which version of ADAM are you > > > testing > this > > > against? Also, what are you using to set and test the test conditions? > > > > > > Al > > > > > > > > > On 1/27/06, Mr Oteece <[EMAIL PROTECTED]> wrote: > > > > > > > > I am looking at ADAM to store bindable users for authentication. > > > > I am seeing some unexpected behavior when it comes to the > > > > various attributes that ADAM is using instead of > > > > userAccountControl. I would expect that setting pwdLastSet to 0 > > > > would cause msds-UserPasswordExpired to become TRUE. Attempting > > > > to bind with a user with pwdLastSet = 0 does indeed fail. Yet > > > > looking at the attributes in ADSIEDIT or LDP shows > > > > msds-UserPasswordExpired to still be false. > > > > > > > > Is that as expected? Is the logic to check both attributes to > > > > determine if a pwd is expired? Or just check pwdLastSet and > > > > ignore the msds-UserPasswordExpired attribute? 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/ 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/
