AD and enforced password policies

Blake T. Pfankuch blake at pfankuch.me
Mon Jan 2 17:15:08 CST 2012


I would very much agree with this as far as the "user annoyance" side.  We have had customers enforce 12 characters and complexity for all users, and you end up with sticky notes under the keyboard or other objects on the desk.  I would also make sure to set a reasonable timeout to force a workstation locking as well.  However I would say 365 day expiration is a little long, 3 months is about the average in a non financial oriented network.  

Depending on your AD structure, you can easily enforce different policies for different types of users.  Meaning you can give your average minion a 8 character password with 90 day expiration, 4 password history and 3 of 4 groups for characters.  Then you can give your domain admin accounts (your normal support staff doesn't have domain admin on their day to day accounts do they??) a more restrictive policy like 12+ characters, 30 day expiration 24 history and full complexity (via third party modules).

-- Blake

-----Original Message-----
From: Jimmy Hess [mailto:mysidia at gmail.com] 
Sent: Monday, January 02, 2012 3:33 PM
To: Jones, Barry
Cc: Nanog at nanog.org
Subject: Re: AD and enforced password policies

On Mon, Jan 2, 2012 at 2:27 PM, Jones, Barry <BEJones at semprautilities.com>wrote:

> I have a requirement to enforce password policies on AD (a tacacs and 
> windows domain). I don't have a great deal of Windows AD knowledge - 
> so a newbie ;-) this is a little off topic, but I thought I'd ask...
>

This is very basic built-in functionality of AD,  that those maintaining an AD implementation really ought to already be aware of;  to implement it, you edit or create applicable group policy to apply a  Password policy in the security section of the applicable group policy for the Computer account configuration at the domain level, specify the minimum length and, either check the "password must meet complexity requirements box", or supply a custom filter  --

http://technet.microsoft.com/en-us/library/cc875814.aspx#ECAA
http://technet.microsoft.com/en-us/library/cc786468%28WS.10%29.aspx

My recommendation would be to not go too far with password policies.
Implement only the least restrictive requirements in AD to achieve the best  security benefits per unit of user annoyance;  e.g. a minimum length of 8 is a good choice;  if you try and force users to pick a minimum of 15, with complexity, and expire their password every 10 days, you'll actually get users with simple passwords  (or password sticky notes on the monitor).

The sole root cause for "easily guessable passwords"  is  not  lack of technical restrictions. It's also:  lazy or limited memory humans who need passwords that they can remember.

Firstname1234!    is very easy to guess, and meets complexity and usual
length requirements.


There are password filters on the market that can perform a simple dictionary check, which is a better check to perform than number of
character classes.     Use the custom password filter and a  30 minute
account lockout after the 3th failed login attempt,  to prevent most
password guessing attacks.          An event log monitoring tool should be
used to alert a sysadmin.

Specifically, I need to enforce the use of length, special characters, and
> be able to validate the enforcement of such.


You can ensure the enforcement by putting the password policy into effect;
make sure it is enforced on all domain controllers.   And then at a later
date check the "must change password at next login"  checkbox for all users you need to enforce against, and utilize the GPResult command for each user to ensure that the policy is applied.

The last password change date will verify the user has updated their password at the time the policy was in effect

Another thing to consider is to have user passwords expiring once every 365 days,  with checks to prevent reuse of  previously used passwords;  then typical scripts to monitor applied policy and last password change times can be utilized to verify compliance.

--
-JH



More information about the NANOG mailing list