"Rob" <> wrote in message
news:72edabef-8556-4151-9726-...
> All,
>
> My scenario:
> Server 2003, IIS (ASP web apps, no local login - all access via
> https), access control through Windows SAM database & NTFS
> permissions, 30 day password policy, 800+ users.
>
> The problem:
> When accessing users through ADSI getObject("WinNT://machinename/
> username"), invalid date values are given for PasswordLastChanged and
> PasswordExpirationDate when UserMustChangePasswordAtNextLogin
> (UMCPANL) is True. FYI, PasswordLastChanged = Now() and
> PasswordExpirationDate = Now() + N days (based on group policy).
>
> Though there is no exploit (the validity of the user's password isn't
> implicitly extended so they can't authenticate in the context of our
> web apps), user listings/reports imply recent activity, its logically
> wrong, and ugly.
>
> Questions:
> 1) UMCPANL is irrelevant in my scenario since users do not log on
> locally...
> 1a) What (in absolute terms) causes this setting to be applied?
> N.B. I haven't noticed this in 2-3 yrs operation & have not
> conciously applied this flag.
> 1b) Can UMCPANL be turned off (e.g. through scheduled task)
> without implicitly extending password validity?
> 2) Is the behaviour described a recognised "feature" or is it a bug?
> 3) Does anybody have a workaround or other useful suggestions?
>
> Thanks in advance,
>
>
> Rob.
First, the PasswordLastChanged property method is not supported by the WinNT
provider. If you are using code, we may need to see more of it. What you
describe cannot be duplicated. However, the results you report make some
sense. If you set "User must change password at next logon" in ADUC, this
assigns the value 0 to the pwdLastSet attribute. This actually corresponds
to the date January 1, 1601, a date so long in the past that any method
should report that the password is expired. As soon as the user logs on (and
changes their password), pwdLastSet will be changed to the current
date/time, so that then the password will expire in the future according to
domain policy. The PasswordExpirationDate method apparently assumes this,
and when pwdLastSet is 0, returns a date in the future as if the user just
changed their password. I would not describe this as a bug, but behaviour as
designed. If pwdLastSet is 0, no other result would make sense.
For purposes like this, you should be using the LDAP provider. I know the
code looks simpler when you use the WinNT provider, but this provider
assumes an NT domain (or local SAM account database).
To remove the setting "user must change password at next logon" you can
assign the value -1 to the attribute pwdLastSet (using the LDAP provider of
course). This assigns a value to pwdLastSet that corresponds to the current
date/time, so the password will expire in the future according to domain
policy.
--
Richard Mueller
MVP Directory Services
Hilltop Lab -
http://www.rlmueller.net
--
Linear Mode
