[gptalk] Re: Password Policy
- From: "Dave Palombi" <dave.palombi@xxxxxxxxx>
- To: gptalk@xxxxxxxxxxxxx
- Date: Mon, 21 Apr 2008 20:42:43 -0400
Thanks for all your help. If it was up to me, I would change the password
age from 0 to 42 now and take the brunt of it. Management wants to wait on
this one. Doesn't matter we will get hit when ever they decided to make the
change. You have been a great help but I knew this was comming. I will do
what I can with what I have.
Thanks,
Dave
On Mon, Apr 21, 2008 at 3:50 PM, Cruz, Jerome L <jerome.l.cruz@xxxxxxxxxx>
wrote:
> 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>
> wrote:
>
> That is great thanks.
>
>
>
> Dave
>
> On Thu, Apr 17, 2008 at 5:25 PM, Cruz, Jerome L <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] *On
> Behalf Of *Dave Palombi
> *Sent:* Thursday, April 17, 2008 1:26 PM
> *To:* 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>
> 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>
> 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] *On
> Behalf Of *Dave Palombi
> *Sent:* Thursday, April 17, 2008 12:08 PM
> *To:* 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:
