In this video from IT Free Training I will look at how to configure the password policy
for your domain. The password policy allows the administrator to configure options like
how often a user password will need to be changed and how complex the password will
need to be. Security is an important consideration in
the modern work place. Often security and costs do not go hand in hand and a tradeoff
between security and cost will often have to be made. By the end of this video you will
not only know how to configure the password policy for your domain, but also have a good
understanding of which settings to configure to give you the best results for your organization.
In a Domain, the password settings for the domain are configured using the Default Domain
Policy. If you want to change the password settings for the domain, it must be done
here. If you configure the settings in another group policy, these settings will be ignored.
Active Directory does support multiple password polices for different users which I will cover
in the next video. In this video I will only look at configuring the default password policy
options. For the present, any of the password policy
settings that are configured in the Default Domain Policy will be applied to all users
in the domain. For this reason, it is considered best practice to only configure password settings
in the Default Domain Policy. For example, settings like desktop settings and software
deployment should be in a separate Group policy. Essentially, any settings other than Password
Polices settings should be configured in a separate GPO.
To configure these settings, open Group Policy Management from Administrative Tools under
the start menu. At the top is Default Domain Policy. This is created when the domain is
created and is the only place you should consider configuring the default password settings
for your domain. Once I edit the Default Domain Policy the
password policy settings are found under, Computer Configuration, Windows Settings,
Security Settings, and Account Policies. The settings are divided into 3 parts, Password
Policy, Account Lockout Policy and Kerberos Policy. If I now exit out of here, I will
have a closer look at the settings that are available.
Under password policy there are six settings. The first setting is “Enforce password history”.
This allows you to determine how many previous passwords will be kept before Windows will
allow the user to use the same password again. This prevents the user when asked to change
their password simply changing the password to a password they have used before. By default,
this value is set to 24 and thus a user would only be able to reuse their current password
after they have changed their password 24 times.
The next setting, “Maximum Password Age” determines the maximum number of days a user
can use a password before they will be forced to change it. If the user does not change
the password before this, they will be forced to change it next time they login. If they
are already logged in, they will find that they will not be able to access resources
on the network. This setting can be particular annoying for user accounts that are always
logged in or for service accounts if the password is not changed in time.
If I open Active Directory Users and Computer from the start menu. I will locate a user
and then open the properties for that user. If I open the account tab, when a user password
is past the maximum password age, the tick box “User must change password at next logon”
will be ticked. If you wish to prevent a password on a user account from expiring, you will
need to tick the tickbox “Password never expires”. Settings configured in here will
overwrite the settings configured at the Domain level.
The next setting you can configure is, “Minimum password age”. This setting determines how
long a user must have a password before they can change it. If you use the Enforce Password
History it is important to also set this option. By default the user can only change their
password once per day. Given that the default password history is 24, this would mean that
in order for a user to reuse the same password they would need to change their password once
per day for 25 days. If this setting was not configured, a user could potentially change
their password 25 times in a row to get back to their original password. Believe me,
if this settings is not configured, there are users that would change their password
25 times to get back to their original password if you allowed them.
The next setting, “Minimum password length” determines how long the password needs to
be. The default is 7 characters. The next setting, “Password must meet complexity
requirements”, means that the password is checked when it is changed to ensure that
is meets a number of requirements, otherwise it will not be changed. These requirements
are that the password must have at least 6 or more characters and contain 3 out of the
4 of the following: Contain upper case, lower case, digits and non-alphanumeric characters.
Since only 3 of the 4 are requirements, you could for example have a password with lower
case letters, a number and a non-alphanumeric symbol like @, # and *. You could also have
a password with upper and lower case letters and a number, which would also be valid. The
last requirement for the password is that it does not contain parts of the user name
or Full name. This requirement only exists for names that are over 2 characters. If this
requirement was enforced for very small usernames, like username with only 2 characters, this
would make it difficult to change the password as many potential password could contain those
2 characters. By default, this setting is enabled. It should be noted that this setting
only takes effect when the user attempts to change their password. If you use the admin
tools to change the password or the password is already set, the password can be a non-complex
password. The last option, “Store password using reversible
encryption” stores the password in a format that can be decrypted by applications. This
is not very secure and should be avoided when possible. It should be noted here that if
this option is switched on, the password will not be stored in revisable encryption until
it is changed. This is because Active Directory uses a one way function to store the password.
It is not physically possible to reverse this process to obtain the password.
This covers the Password Policy settings. The next group of settings is the Account
Lockout Policy. These settings determine what happens when a user attempts to login and
they provide the wrong password. A common form of password attack is what is referred
to as a brute force attack. This is when a hacker attempts to try a number of passwords
in sequence in an attempt to guess the password. For example, if a brute force attack was attempted
to find out a pin number, the brute force attack would generally start from 0 and continue
upwards until the pin number is worked out. If to many attempts are tried with the same
user and the wrong password in a row, Active Directory can lock the account out requiring
an administrator to unlock the account or a time period to expire before the account
can be used again. If I open Active Directory User and Computers
and open the user properties, notice that on the account tab there is a tick box “unlock
account”. If this tick box is ticked the account is locked. An administrator can clear
this tick box to unlock the account or if configured to do so will clear itself after
a period of time has expired. An account can become locked if a user is
attempting to login to a computer, but it can also become locked if the user attempts
to access a resource on the network and is prompted for a password and enters in an incorrect
password to many times. If this were to occur, this can cause their user account to become
locked. In Windows Server 2003 and above, Domain Controllers
will check the password given with the password used before the last password change. If there
is a match, the user account will not be locked. This prevents the user account being locked
out due to an application or service still using the old password.
Also the built-in administrator account cannot be locked out. This is because a hacker could
lock out the administrator account on purpose to prevent it from being used. If multiple
authentication requests for the administrator are received in a row, Windows will start
using a delay before answering authentication requests for the administrator account. This
will help prevent the administrator account from being comprised from a brute force attack
as it limits how many password attempts can be tried over time.
The first setting the can be configured for lock out is “Account lockout duration”.
This setting determines how long a user account after it is locked out will automatically
be unlocked. This is a useful setting for companies that run 24 hours a day but do not
have 24 hours IT support. If a user account were to be locked out during the middle of
the night, the user would simply need to wait until the user account automatically unlocks
itself rather than calling the IT department in the middle of the night to have the user
account unlocked. If this setting is not configured, once a user account is locked it will remain
locked until an administrator unlocks it. The next setting is “Account lockout threshold”.
This setting determines how many wrong logon attempts have to be made before the user account
is locked out. By default this value is 0 which means that the user account will never
be locked out. The next setting, “Reset account lockout
counter after” determines how many minutes need to expire before the failed login counter
is reset. For example, if the Account Lockout Threshold was set to 5, the user could attempt
to login 5 times before the account was lockout. If the user however, attempted to login 4
times this would be recorded. If Reset account lockout counter was configured to 10 minutes,
the user would need to wait 10 minutes before the failed counter would be reset. After 10
minutes they would be able to attempt to login again up to 5 times.
If you do decide to configure “Reset account lockout counter after” and “Account lockout
threshold together you must also configure Account lockout duration to the same value
or greater. This covers account lock out. The last section
is Kerberos Policy. On most networks you will leave these settings on the default and will
never need to change them as the defaults work quite well. It is unlikely that Microsoft
will ask you a question on the exam about these settings so I will go through them only
to help your understanding of how Kerberos works.
The first option, “Enforce user logon restriction”, will check if the user has the required rights
before granting a Kerberos ticket. For example, if a user was attempting to access a computer
from remote, they would need the “Access this computer from the network” right. If
they did not have this right, creating the ticket would be a waste of time as they would
be denied access anyway. By default this setting is enabled. On a slow
network it may be worth considering switching this option off due to the delay of the server
having to travel the network to check the local policy before creating the ticket. On
modern networks this should not be an issue. The next two settings, “Maximum lifetime
for service ticket” and “Maximum lifetime for a user ticket” determine how long a
Kerberos ticket can be used. The default is 10 hours. After the ticket expires it will
need to be renewed or a new one created. The next setting, “Maximum lifetime for
user ticket renewal”, determines how long a user ticket can be renewed until it has
to be recreated. The default is 7 days. The last setting is “Maximum tolerance for
computer clock synchronization”. Kerberos puts a time stamp in the tickets that it creates.
A time stamp helps prevent replay attacks. A replay attack is when data is captured by
a 3rd party and then resent to a server at a later date. The hope is the server will
think the data is from the original user and allow it. To prevent this, time stamps are
used so the data cannot be used later on. To allow a system like this to occur, the
time on the client and the Domain Controllers must be in sync. By default, Kerberos allows
a time difference of up to 5 minutes. The settings I have looked at here I would
recommend leaving them on the default rather than changing them. For example, if you are
having problems with clock synchronization I would look at ways to keep your time on
your computer in sync rather than change the settings in here.
The last thing to consider when modify the security policy is which settings to configure.
Before you change anything, check the security policy of your company. A lot of companies
have requirements that they use. For example, how long a user password needs to be. Also,
a large enough company will have auditors come in who will check security settings on
the network. You should make sure that your settings meet the minimum requirements for
the auditors; otherwise this can be an embarrassing configuration setting for an auditor to find
and report to your employer. Next perform a cost vs security comparison.
There are many different ideas about what security settings should be set to. Configuring
the password settings so that users are forced to use longer passwords is considered better
security but may cost you more in support calls for password resets.
Also consider the real security value of the settings you choose. There have been a number
of studies done that have found that forcing the users to change their password too often
results in poor security. This is because a user it is more likely the user will write
their passwords down. Users will also tend to put a number at the end of the password
and change the number each time the password needs to be changed. For example, the password
will end with the number of the current month. Extra password changes also generally create
more calls to the helpdesk for password resets. Thanks for watching this video on Password
Policy for Active Directory. Traditionally only one password policy can be configured
per domain and this is stored in the Default Domain Policy. In the next video I will look
at how multiple password polices can be configured in the single domain allowing you to tailor
password settings to particular users. For more free videos in this course and others,
please visit our YouTube Channel or subscribe. See you in the next video.