Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Password expiration.

0 views
Skip to first unread message

Lars Falch

unread,
Dec 12, 2001, 6:47:08 AM12/12/01
to
Hi all,

When are users forced to change their password, when we set the Maximum
Password Age to XX - will all users have to change their password
immediately after the option is set (as their passwords are most likely
older than XX) or will they be forced to change their password after XX
days.

Another possibility is that the passwords will expire on different days, as
this option has been enabled earlier. It was temporarely disabled during our
W2K migration.

It's a bit of a brain-teaser - hope you guys can help!

By the way, you would configure this for the entire domain, by configuring
it in the Default Domain Policy (group policy on the domain), right?


Thanks,
Lars


Amiri Jones [MVP]

unread,
Dec 12, 2001, 10:51:39 AM12/12/01
to

"Lars Falch" <lfa...@deloitte.dk> wrote in message
news:Omo5QLwgBHA.2172@tkmsftngp05...

> Hi all,
>
> When are users forced to change their password, when we set the Maximum
> Password Age to XX - will all users have to change their password
> immediately after the option is set (as their passwords are most likely
> older than XX) or will they be forced to change their password after XX
> days.
>
When a maximum password age is set, after having not been set in the
past, Windows will use the date that the policy is set as the first day. In
other words, if you set the age to N days, then everybody will have to
change their password N days after you put the policy into effect.


> Another possibility is that the passwords will expire on different days,
as
> this option has been enabled earlier. It was temporarely disabled during
our
> W2K migration.
>

When you put the policy back into effect, those old dates will be
overwritten with today's date.


> It's a bit of a brain-teaser - hope you guys can help!
>
> By the way, you would configure this for the entire domain, by configuring
> it in the Default Domain Policy (group policy on the domain), right?
>
>

That's the ONLY place you can activate this policy. Setting it in any
other policy will have no effect.


Lars Falch

unread,
Dec 13, 2001, 2:47:38 AM12/13/01
to
Hi Amiri,

> When a maximum password age is set, after having not been set in the
> past, Windows will use the date that the policy is set as the first day.
In
> other words, if you set the age to N days, then everybody will have to
> change their password N days after you put the policy into effect.

Sounds reasonable.

> When you put the policy back into effect, those old dates will be
> overwritten with today's date.

Which means that in our case, with the policy coming back into effect, we
could expect that everyone will need to change their password in N days? I
just want to make sure I get this right! ;-)

> That's the ONLY place you can activate this policy. Setting it in any
> other policy will have no effect.

That what was I thought. Thanks.


Lars

Amiri Jones [MVP]

unread,
Dec 13, 2001, 10:30:41 AM12/13/01
to

"Lars Falch" <lfa...@deloitte.dk> wrote in message
news:OYZOFq6gBHA.2496@tkmsftngp03...

> Hi Amiri,
>
> > When a maximum password age is set, after having not been set in the
> > past, Windows will use the date that the policy is set as the first day.
> In
> > other words, if you set the age to N days, then everybody will have to
> > change their password N days after you put the policy into effect.
>
> Sounds reasonable.
>
> > When you put the policy back into effect, those old dates will be
> > overwritten with today's date.
>
> Which means that in our case, with the policy coming back into effect, we
> could expect that everyone will need to change their password in N days? I
> just want to make sure I get this right! ;-)
>
Yup. I'm pretty sure that's how it'll work. Wouldn't bet my car on it
<g>, but I seem to remember it being described that way once.....


Joe Richards [MVP]

unread,
Dec 15, 2001, 5:24:36 PM12/15/01
to
I have to disagree with you on this one Amiri....

Both because we had to do it a couple of years ago and because the way
password expiration dates are maintained I don't think it could possibly
work that way.

Password expirations are a calculated value based upon the maxPwdAge
attribute of the Domain and the pwdLastSet value of the user in question. If
the last set + max pwd >= current time/date the password is expired.

If you set a 91 day policy the next time a user tries to use that ID the
calculation will be done and if they are over 91 days they will have to be
reset.

The best thing to do is to do a complete audit of the domain for the
password age spread (get userdump from www.joeware.net free win32 tools) and
then try to pick a specific number of changes you think your help desk staff
could help users with in a given day and then slowly roll back your
expiration date so that you don't exceed that planned number until you get
to the date in question.

Alternatively you can use Expire from the free win32 tools page to
selectively batch expire IDs and when you have gotten through them all then
set the password expiration policy directly. This will give you more control
over which specific ID's would be expiring so you could post a list or send
an email ahead of time.

Finally I recommend a 91 day password policy so that people can generally
reset their password on the same day each week each period as 91 is evenly
divisible by 7. This helps you chart your password changes/resets and
reduces the pull in the numbers associated with having a value that doesn't
align on week boundaries. You still get some pull as the warnings start 14
days out generally and you can't control when people will actually reset
their passwords (some do it right away others wait for the last second) but
you can still get a good feel for the numbers. Once you have the trends
layed out you can actually see how smoothly the system is working on any
given day because the numbers will spike.

We think a lot about passwords at the company I work for if you didn't get
that impression. The population of users combined with the expiration policy
sets our minimum daily rate at about 1200-1500 password changes a day. We
had outsourced our support for the domains to a third party IT company and
near the end of the time they were managing the domains the password change
rate was at 2500-2700 per day and trending up indicating a great many domain
issues. Once insourced and the domain configurations started getting
corrected we have seen the trends going down and within 4-6 weeks had
reduced to 1700 changes per day and was trending down.

joe


--
Joe Richards
www.joeware.net
---

"Amiri Jones [MVP]" <som...@dontsendemail.net> wrote in message
news:OKRC5TygBHA.1960@tkmsftngp04...

Amiri Jones [MVP]

unread,
Dec 18, 2001, 1:16:23 PM12/18/01
to

"Joe Richards [MVP]" <humore...@hotmail.com> wrote in message
news:uUPHfdbhBHA.2348@tkmsftngp02...

> I have to disagree with you on this one Amiri....
>
Join the club! You're not the first..... ;)

> Both because we had to do it a couple of years ago and because the way
> password expiration dates are maintained I don't think it could possibly
> work that way.
>
> Password expirations are a calculated value based upon the maxPwdAge
> attribute of the Domain and the pwdLastSet value of the user in question.
If
> the last set + max pwd >= current time/date the password is expired.
>
> If you set a 91 day policy the next time a user tries to use that ID the
> calculation will be done and if they are over 91 days they will have to be
> reset.
>

Okay, okay, you got me here....... But hey, that's why we have these
groups, right? :)

[snip]


Joe Richards [MVP]

unread,
Dec 22, 2001, 2:55:52 PM12/22/01
to
> Okay, okay, you got me here....... But hey, that's why we have these
> groups, right? :)

Yep. :o)

0 new messages