[gptalk] Re: Password Policy

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: