Security Group Policies - Account Policies Settings (Domain Level)
Perhaps you are familiar with setting password length and account lockout
from your NT 4.0 days? This section will guide you through these and
many more security group policies for Active Directory Users.
Do
remember that the Account Policies on this page must be configured at the
Domain level. If you try to set these polices for an OU, then you will
be disappointed. This is because the Security Settings at the OU level
have no affect on Domain Users.
Before you start experimenting, I urge you to take advantage of
Microsoft's built in templates. What I suggest is that you add the
Security Template snap-in to your MMC.
Inside
the template folder are half a dozen files with settings for each type of
machine. The first task is to choose the nearest template to your
situation, for example 'securedc' would be suitable for a domain controller.
Once you have selected a template, then immediately right click, 'Save
AS', and give it a new name, for example MyDomain. This technique will
preserve the built-in settings so that you can always start again with a
clean template.
Your chosen template will act as a base for creating your own Security
Settings. When you are happy with your policy, load your settings with
the Security Configuration and Analysis snap-in (see diagram).
If you get in a
pickle with Security Settings, revert to the 'DC Security' template, that's
the easiest way of removing all policies. As 'DC Security' is just a
blank shell, this template neatly resets your mistakes, and lets you start
again.
As an MCT trainer, I can thoroughly recommend TrainSignal because they
provide practical hands on training. In particular, I like the way TrainSignal cover all learning methods, instructor lead, video and of course text material. You can either take one module, for example Group Policy or go for
a combination of modules.
See more about Group Policy training here
This password section really does come as a package, I will explain why
you need to consider how these Group Policies interact as we go along.
The first decision is, 'Minimum
Password Length'; 8 letters is considered long enough by most security
experts. To make it harder for hackers to guess passwords you can
enforce - 'Passwords must meet complexity requirements'. This means
that the word must contain 3 of these characteristics, UPPERCASE, lowercase,
number or non-alphanumeric e.g. £ @ symbols.
At first I thought that it would be too much to expect people to remember
such complex passwords, but as time went on I realized, we humans are a most
adaptable animal and we do learn to cope with passwords like P@ssw0rd or
better a phrase like: B££r & sk1ttl£s.
Once we set the length and complexity, the next decision is how often do
users have to change their passwords? 60 days, 90 days - you decide.
To prevent users just switching between two passwords, you can set * 'Enforce
Password History'.
Just when you think you have the users under control, some 'clever Dick'
cycles through 24 passwords in their tea break and comes back to the
original password. To stop them 'thumbing their nose' at you, fix the
minimum password age at 1 day. If you set the 'Minimum Password Age'
too long then that can create new problems. Specifically, if the user
forgets their old password and they are given a new password which must be
changed at first logon. No can do. They would either have to
wait days to logon, or else the support staff would have to remove the tick
next to 'Change Password at logon'.
Controlling Account Lockout is a tricky and contentious area. My
advice is to set the 'Account Lockout
Threshold' to 7-9. Most administrators prefer a value of 3, but I
would argue that 7 or more attempts will give the users more chance to
remember their password without compromising security.
Enabling 'Account lockout duration', means that the account will unlock
itself after the time you choose. This would save work at the help
desk, but make the system less secure than if an administrator has to
manually reset locked accounts.
Probably the hardest of these security Group Policies to explain is the 'Reset Account Lockout
after'. Take the scenario where you know the lockout threshold is 3,
you have got the password wrong twice, you pause to think. 'If I try again
and get it wrong, my account will be locked out and I will have to ask the
administrator nicely to reset my account. Or, I can wait half an hour
and so have the full three chances to try my passwords again.'
Guy Recommends: SolarWinds Engineer's Toolset v10
The Engineer's Toolset v10 provides a comprehensive console of utilities
for troubleshooting computer problems. Guy says it helps me
monitor what's occurring on the network, and the tools teach me more about how the system
itself operates.
There are so many good gadgets, it's like having free rein of a
sweetshop. Thankfully the utilities are displayed logically: monitoring, discovery, diagnostic, and Cisco tools.
Download your copy of the Engineer's Toolset v 10
Best to leave these Group Policy settings at their defaults - not configured.
However, if logon is troublesome and especially if you start getting Kerberos errors
in the Event Log, then you could research the Kerberos principles and make
informed decisions on increasing the ticket life.
Kerberos is named after the three headed guard dog Cerberus of Greek Mythology.
The idea behind Kerberos is to minimise the need for a user's password to cross the network.
The concept behind the Kerberos ticket is that all their SIDs, Group SIDS and user rights,
are encrypted in the ticket. So when the user needs a resource like a
file in a network share, they present their tickets, not
their passwords!
To investigate Kerberos, install Kerbtray. To investigate Kerberos, install Kerbtray.
Check your Group Policy for security settings such as Password Policy and Account Lockout Policy. This section holds the classic Windows Server 2003 Domain Security Policies.
Take the time to investigate the Security Account Templates and thus set and record your settings in a central location.