|
Yep the reason is because it is divisible by 7. As Al
mentioned I have written this up here and in the newsgroups multiple multiple
times.
From watching an environment with over 200k IDs and daily
password changes measuring in the thousands we noticed that with a 91 day policy
the password changes per day leveled out into a very stable pattern with
exceptions only around holidays instead of most Monday's being heavier as the
weekend changes than catch you on Monday as the dates get pulled due to the
non-divisable by 7.
Don't take my word for it. If you aren't doing it, measure
your password changes by running scripts daily to determine how many accounts
have had their passwords changed and start graphing that over a long term and
then start using that for watching for issues. After you get a good baseline
switch to a value that is divisable by 7 and then watch the stabilization.
The reason stabilization is nice because it can help the
amount of issues the help desk is dealing with. Say you normally have 2000
password changes a day, if you are pulled one day that one day will get 4000
changes - again this is on a monday or the day after people return (and holidays
are even worse then). That can be serious load on the help desk. Another thing a
lot of companies will find that they have normal high points over the entire
password change period, think of mass adds or an issue that forced a lot of
people to reset their password for some reason. Doing this can help you find
that and keep the help desk prepared for it (i.e. a note that says we expect 30%
more password changes the 2nd week of June than most weeks so be ready)[1] or
work on trying to stabilize it by working with users and having them change
their passwords early purposely to level that out a little.
Someone who is running an SBS or other small environment
with only hundreds or thousands of users is probably thinking huh? But the
enterprise world is considerably different. Small things can really add up fast.
joe
[1]
Why is it important for the help desk to know? So they know the call volume
could go up as people forget how to change their password properly or forget
their new password and lock themselves out.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, June 06, 2006 11:09 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] max password age > where else to look? Yeah, I realised that shortly afterwards. The value of this
approach escapes me, however :)
I don't care which day of the week I change my password on
and nor should the users IMHO.
neil
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Sent: 06 June 2006 15:07 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] max password age > where else to look? Think “divisble by
7”… From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of
[EMAIL PROTECTED] I'll second guess joe -
91 stops ppl from using cyclic passwords, which use dates or quarters to
generate a password. e.g. passwordq12006, passwordq22006
etc. Hopefully joe will give
an authoritative response :) neil From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Steve Okay. I'll ask the question that everyone else is
afraid to.... why 91 and not 90? Cheers On 5/31/06, joe <[EMAIL PROTECTED]>
wrote: :o) I can
imagine.... Something I like to
recommend to folks is to monitor password changes. Depending on how big you are
you may even want to do it daily. It is a great way to keep an eye open for
various issues. For instance if passwords aren't being changed in the normal
periods at the normal rates, your policy may not be working. If more than usual
are being changed then possibly you have some DC issues. You will even be able
to graph out the password changes and possibly find interesting trends. Oh
to go along with this, I recommend a password age of 91 days for the obvious
reasons... Actually I always recommend that over 90 days.
joe From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]] On
Behalf Of Douglas W Stelley Subject: RE:
[ActiveDir] max password age > where else to
look?
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]] On
Behalf Of Al Mulnick you echo the intMaxPwdAge value? I'm wondering if you're
not pulling back the max password age value correctly either through a
misspelling or some other error prevents you from getting the value.
Having used that method before, I can tell you it does work in a Windows
2000 environment and a Windows 2003 environment. Native, DFL, etc.
PLEASE READ: The information
contained in this email is confidential and intended for the named recipient(s)
only. If you are not an intended recipient of this email please
notify the sender immediately and delete your
copy from your system. You must not
copy, distribute or take any further action in reliance on it. Email is
not a secure method of communication and Nomura International plc ('NIplc')
will not, to the extent permitted by law, accept responsibility or liability
for (a) the accuracy or completeness of, or (b) the presence of any virus,
worm or similar malicious or disabling code in, this message or any
attachment(s) to it. If verification of this email is sought then please request
a hard copy. Unless otherwise stated this email: (1) is not, and should
not be treated or relied upon as, investment research; (2) contains
views or opinions that are solely those of the author and do not necessarily
represent those of NIplc; (3) is intended for informational purposes only and
is not a recommendation, solicitation or offer to buy or sell securities or
related financial instruments. NIplc does not provide investment services
to private customers. Authorised and regulated by the Financial Services
Authority. Registered in no. 1550505 VAT No. 447 2492 35.
Registered Office: 1 PLEASE READ: The
information contained in this email is confidential and
intended for the
named recipient(s) only. If you are not an intended
recipient of this
email please notify the sender immediately and delete your
copy from your
system. You must not copy, distribute or take any further
action in reliance
on it. Email is not a secure method of communication and
Nomura International
plc ('NIplc') will not, to the extent permitted by law,
accept
responsibility or liability for (a) the accuracy or completeness of,
or (b) the presence
of any virus, worm or similar malicious or disabling
code in, this
message or any attachment(s) to it. If verification of this
email is sought then
please request a hard copy. Unless otherwise stated
this email: (1) is
not, and should not be treated or relied upon as,
investment research;
(2) contains views or opinions that are solely those of
the author and do
not necessarily represent those of NIplc; (3) is intended
for informational
purposes only and is not a recommendation, solicitation or
offer to buy or sell
securities or related financial instruments. NIplc
does not provide
investment services to private customers. Authorised and
regulated by the
Financial Services Authority. Registered in England
no. 1550505 VAT No.
447 2492 35. Registered Office: 1 St Martin's-le-Grand,
London, EC1A 4NP. A
member of the Nomura group of companies.
|
