[148087] in North American Network Operators' Group
RE: AD and enforced password policies
daemon@ATHENA.MIT.EDU (Blake T. Pfankuch)
Mon Jan 2 18:16:12 2012
From: "Blake T. Pfankuch" <blake@pfankuch.me>
To: Jimmy Hess <mysidia@gmail.com>, "Jones, Barry"
<BEJones@semprautilities.com>
Date: Mon, 2 Jan 2012 23:15:08 +0000
In-Reply-To: <CAAAwwbUXNEUCqirVE+KidGVjn2nt=r_rY5EhBu_w7uQXcZEh_g@mail.gmail.com>
Cc: "Nanog@nanog.org" <Nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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 des=
k. I would also make sure to set a reasonable timeout to force a workstati=
on locking as well. However I would say 365 day expiration is a little lon=
g, 3 months is about the average in a non financial oriented network. =20
Depending on your AD structure, you can easily enforce different policies f=
or 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 gr=
oups for characters. Then you can give your domain admin accounts (your no=
rmal support staff doesn't have domain admin on their day to day accounts d=
o 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@gmail.com]=20
Sent: Monday, January 02, 2012 3:33 PM
To: Jones, Barry
Cc: Nanog@nanog.org
Subject: Re: AD and enforced password policies
On Mon, Jan 2, 2012 at 2:27 PM, Jones, Barry <BEJones@semprautilities.com>w=
rote:
> I have a requirement to enforce password policies on AD (a tacacs and=20
> windows domain). I don't have a great deal of Windows AD knowledge -=20
> 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, y=
ou edit or create applicable group policy to apply a Password policy in th=
e security section of the applicable group policy for the Computer account =
configuration at the domain level, specify the minimum length and, either c=
heck the "password must meet complexity requirements box", or supply a cust=
om 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, wit=
h 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 tech=
nical restrictions. It's also: lazy or limited memory humans who need pass=
words 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 dictiona=
ry 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 use=
r to ensure that the policy is applied.
The last password change date will verify the user has updated their passwo=
rd 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 t=
ypical scripts to monitor applied policy and last password change times can=
be utilized to verify compliance.
--
-JH
