[gptalk] Re: Password Policy
- From: "Cruz, Jerome L" <jerome.l.cruz@xxxxxxxxxx>
- To: "gptalk@xxxxxxxxxxxxx" <gptalk@xxxxxxxxxxxxx>
- Date: Mon, 21 Apr 2008 12:50:09 -0700
Dave,
I think you are going to get bit on this one. Now that I see your settings, the
"kicker" is the fact that you have max password age - 0 (passwords never
expire). From the way I read it, the moment you set it to anything other than
zero, all the passwords will 'expire' and need to be reset (and that seems to
explain the behavior you observed). The MS Windows Server 2008 Security guide
(the most recent guide) has this to say about that setting.
Maximum password age
This policy setting defines how long a user can use their password before it
expires. Values for this policy setting range from 1 to 999 days. (You can also
set the value to 0 to specify that passwords never expire.) The default value
for this policy setting is 42 days. Because attackers can crack passwords, the
more frequently you change the password the less opportunity an attacker has to
use a cracked password. However, the lower this value is set, the higher the
potential for an increase in calls to help desk support due to users having to
change their password or forgetting which password is current.
[I also checked some of their older Security Guides and their Threats and
Countermeasures guide as well and there was nothing additional to add. I wish
they'd document these kinds of "settings change" behaviors, but I guess that
what forums are for.] I advise going to a lab environment and double-checking
to make sure that it's this one setting.
===============================
This is the behavior you are going to get because it's the DCs that "read" and
"respond" to these domain root GPO settings, not the user accounts themselves.
This behavior is by MS design and it sort of work like this: a domain user's
account password expires; the end user opens the change password interface,
enters a new password, and clicks OK; the interface contacts the Domain
Controller (which only sees one set of settings for the entire domain-from the
GPOs at the root of the domain-the "GPO rules" as it were), the DC validates
the password change according to the "GPO rules" and updates the user's domain
account in AD; the DC then sends confirmation back to the user's local
interface that the change was successful. As you can see, for a Domain Account,
there's "only" the Account Settings that the DC s have, therefore the "GPO
rules" apply once per domain and they cannot be filtered anymore granularly.
Side Notes The domain GPO settings normally also apply to each local device's
SAM account settings, but MS allows GPOs in down-level OUs to override that
behavior, but again, only for local SAM accounts. Therefore Local SAM accounts
password settings 'can' be different from domain accounts. Also confusing
things is the fact that if local SAM account's settings 'are' different from
domain account settings, the local SAM user interface displays messages to the
end user based only upon the local SAM settings. This can REALLY confuse the
End User trying to change their domain account. I guarantee that this situation
leads to calls to the help desk as users try to change their password and the
local system displays local SAM messages when the rules on the domain are
different. Doesn't help us much, does it?]
I would guess that when you made the initial change, you were receiving calls
from End Users that they were being prompted to change their password and most
didn't understand what was going on. And you added password complexity at the
same time.
Things to Try
First, I do not see anything that would prevent you from changing and
implementing the other settings. Namely the min password age - 2 and password
complexity - enabled settings. But test in the lab first as noted.
Second, when you implement the Min Password Age setting, understand that the
setting only prevents the End User from using the Windows GUI interface to
change their password for two full days. Nothing at all prevents them from
"resetting" their password directly using "password reset" tools (if they have
that right in AD). One example is the Active Directory Users & Computers
interface. An Admin can point to an End User's account and directly engage the
password reset function as many times as necessary. At my work-place, we have a
third-party web-based tool that End Users may utilize to sync all their
passwords from all systems at once and it uses the password 'reset' model as
well.
Next: If I were you, I might investigate sending out notifications to all
domain user accounts, that they are going to have to start changing their
passwords regularly and that they must use complex passwords. Something like
the following could be included in that notification (similar to what I use
internally):
Using Complex Passwords
For your password change to be successful you must create your new password
following the rules below.
* It must be at least 8 characters in length.
* It must contain at least one numeric character (0 - 9).
* It must contain at least one upper case character (A-Z).
* It must contain at least one lower case character (a-z).
* It must not be one you have used before.
* It must not contain your User ID or name.
* It must not contain repeating or sequential patterns (e.g.,
"abc1abc1).
* It must not contain any spaces, punctuation, or special characters.
* It must not contain any international or extended characters.
This list was developed after extensive testing before I enabled complex
passwords in my environment. The last two items are not 'really' true, but
considering that many companies have several computing systems to use, that
most of those do not support extended "Windows" character sets, AND that most
user's tend to use the same password on their systems, they are advisable to
include. Also a short tutorial on using pass phrases could be provided (e.g.
"H0w!KnowBrown!C0w"... hey that's 17 chars, VERY complex, and easy to
remember). [The only problem we've seen is that a sizeable number of folks
started to use that exact example phrase...sigh....].
Next, I suppose you could wait to make changes until you deploy Windows Server
2008. Then you could use the new Granular Account Settings features to better
control the roll-out of this setting by placing your user accounts into groups,
but that only leaves you more vulnerable for longer and also will still
probably behave the same way for each set of user accounts you activate...it
just breaks up the number of affected accounts into something that may be more
manageable for your help center over a period of time rather than all users at
once. Besides, perhaps this will help provide a 'driver' for upgrading to
Windows Sever 2008 DCs earlier for you (never hurts to have more ammunition in
your business case).
Lastly, you 'could' investigate the use of a third party vendor tools to see if
they have anything that would work for this 'today'. I expect that some of
those folks monitor this forum, so don't be surprised if you are contacted.
[Normally considered 'bad form' for them to advertise their products in a 'help
forum' like this, but if there are no other alternatives or work-arounds...?]
Good luck,
Jerry
PS. I'd recommend that you consider raising the Password History setting to its
full Windows value of 24.
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Dave Palombi
Sent: Friday, April 18, 2008 12:37 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Password Policy
I have implimented this policy. It is at the domain level. As soon as I
changed it. I was prompted right away to change my password. I have changed
this back and so far no more calls. What would be the best course of action?
This is the policy now.
min length - 8
max password age - 0
min password age - 0
enforce password history -12
and I want to change it to
min length - 8
max password age 90
min password age - 2
enforce password history - 12
password complexity - enabled.
What is the best possible coarse of action to get this done?
On Thu, Apr 17, 2008 at 5:33 PM, Dave Palombi
<dave.palombi@xxxxxxxxx<mailto:dave.palombi@xxxxxxxxx>> wrote:
That is great thanks.
Dave
On Thu, Apr 17, 2008 at 5:25 PM, Cruz, Jerome L
<jerome.l.cruz@xxxxxxxxxx<mailto:jerome.l.cruz@xxxxxxxxxx>> wrote:
From a Domain perspective, password policy settings essentially apply the new
settings when the passwords are "changed". For example, say you have a "Maximum
password age" set to 90 days (3 months). You then enable the "Password must
meet complexity requirements" setting. At that point all users "changing"
passwords will have to use complex password as the passwords are cycled for
each user over the next 3 months. It'll take three months to apply. Also, your
user account (usually service accounts) which may never expire will never be
switched to using a complex password.
We have over 150,000+ users and made a similar switch recently. No issues. All
End User accounts are now switched and did so a bit at a time daily as they
expired.
Jerry
From: gptalk-bounce@xxxxxxxxxxxxx<mailto:gptalk-bounce@xxxxxxxxxxxxx>
[mailto:gptalk-bounce@xxxxxxxxxxxxx<mailto:gptalk-bounce@xxxxxxxxxxxxx>] On
Behalf Of Dave Palombi
Sent: Thursday, April 17, 2008 1:26 PM
To: gptalk@xxxxxxxxxxxxx<mailto:gptalk@xxxxxxxxxxxxx>
Subject: [gptalk] Re: Password Policy
What would happen if I changed the policy? Would users be asked to change
their passwords right away?
Dave
On Thu, Apr 17, 2008 at 3:18 PM, Dave Palombi
<dave.palombi@xxxxxxxxx<mailto:dave.palombi@xxxxxxxxx>> wrote:
Darren,
Thanks for the info. We are trying to migrate certain sections with different
password policy's until everyone has been done then one big policy at the end.
How would I be able to achive this.
Dave
On Thu, Apr 17, 2008 at 3:14 PM, Darren Mar-Elia
<darren@xxxxxxxxxx<mailto:darren@xxxxxxxxxx>> wrote:
Dave-
Are you trying to apply password policy to a domain user or a local user
account on a workstation or member server? Password policy, as you've noticed,
does not apply to users. IT applies only to computers where the accounts
reside. In the case of domain user accounts (i.e. held in AD), you can only set
one password policy for a given domain and that must be in a GPO linked at the
domain level. For local user accounts-those housed on member servers and
workstations, you have to make sure that the GPO is linked to those containers
where those computers reside, not the users.
Darren
From: gptalk-bounce@xxxxxxxxxxxxx<mailto:gptalk-bounce@xxxxxxxxxxxxx>
[mailto:gptalk-bounce@xxxxxxxxxxxxx<mailto:gptalk-bounce@xxxxxxxxxxxxx>] On
Behalf Of Dave Palombi
Sent: Thursday, April 17, 2008 12:08 PM
To: gptalk@xxxxxxxxxxxxx<mailto:gptalk@xxxxxxxxxxxxx>
Subject: [gptalk] Password Policy
Hello,
I have a question about implementing a password policy. I am trying to
implement a password policy and it works but it is not being applied to the
user. All settings are with in the computer settings. When I do a gpresult,
the policy shows under not applied section and this it says filtering: not
applied (empty)
Your thoughts.
Dave
Other related posts:
