The construction should be occuring at the moment the attribute is being
requested. If I had to guess how this works and I do because again I don't
have access to that branch of the source yet, is that you ask for the
attribute, the code pulls the pwdLastSet attribute and then compares it to
the local machine policy (which could and probably is impacted by the domain
policy) but neglects to check for a forced expiration.


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

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Coleman, Hunter
Sent: Tuesday, January 31, 2006 10:03 PM
To: [email protected]
Subject: RE: [ActiveDir] ADAM msds-UserPasswordExpired

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/

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/

Reply via email to