If you missed the other parts in this article series please read:
Introduction
Like any network operating system, at the heart of the security is a username and password. There are default users created (Administrator and Guest are a few), which will all have a password associated with them. When any user attempts to authenticate or access any resource, the password for their user account is required. Now, thank goodness, a Windows Server 2003 (and later) domain requires a password by default. This password needs to be protected at all angles due to the potential of it being captured, guessed, hacked, or in some other way determined. There are many ways to protect a Windows password, this series of articles will discuss what you can do to increase security for your passwords. First, we must understand how a password is established and controlled, then how it can be attacked, so we can then take measures to protect against the common attacks.
Windows Default Passwords
When you are trying to logon to an Active Directory domain, you will need to input three key entries: username, password, domain name.
When this information is received by the domain controller, it is analyzed against the current password for the username that is listed in the Active Directory database. If the password is a match, then the domain controller will authenticate the user, providing the user with an authentication token to gain access to other resources on the network/domain.
When the user attempts to change the password for their account, this information is also sent to the domain controller. When the new password is entered by the user and sent to the domain controller, policies are in place to ensure the password meets minimum security requirements. A few notes about the password policy for the domain (as well as for all local user accounts by default):
- There is a minimum of 7 characters required for a Windows password (Windows Server 2003 domains and later)
- Passwords must contain 3 of the following 4 types of characters: upper case alpha, lower case alpha, numeric, special ($!@*…)
- A new password must be generated before 42 days to keep the account active
- A password can not be reused until 24 unique passwords have been created
All of these settings are established under the Computer Configuration portion of a GPO, listed under Password Policy. Figure 1 illustrates what the settings are for these password policy configurations.
Figure 1: Password Policy settings in a GPO are located under Computer Configuration, not User Configuration
What Controls Domain Password Policy?
As a long time Windows security educator, I have been working with Active Directory since 1999 and have taught thousands of IT professionals the finer points of Windows security, including the details around the Windows Password Policy. I find it very interesting that now, over 9 years after Microsoft first released Active Directory, that some IT professionals are still confused as to how the password policy is controlled and what options you have to modify them. So, here is the reality of Windows Password Policy and the capabilities.
First, the Default Domain Policy GPO controls the Password Policy for all computers in the entire domain. Yes, this includes the domain controllers, servers, and desktops (which have joined the domain) for the entire Active Directory domain. The Default Domain Policy is linked to the domain node, which of course includes all computers in the domain as a target.
Second, any GPO linked to the domain can be used to establish and control the password policy settings. The GPO just has to have the highest priority at the domain level, which will make it “win” in any conflicting settings regarding the password policy settings.
Third, if a GPO is linked to an organizational unit (OU), it will NOT control the password for user accounts that are located in the OU. This is by far the most common mistake that IT professionals make. The password policy settings are NOT user based, they rather are computer based, as shown in Figure 1 above.
Fourth, if a GPO is linked to an OU, the password policy settings created in the GPO will effect the local SAM on any computer that is located under the OU. This will “trump” the password policy settings configured in the GPO linked to the domain, but only for the local user accounts stored in the local SAMs of these computers.
Fifth, if a GPO is linked to the Default Domain Controllers OU, it will NOT control the Active Directory database of users stored on the DCs. The only way to modify the password policy settings for domain user accounts is within a GPO linked to the domain (unless you are using Windows Server 2008 domains, which you can use fine-grained password policies, which are described in full detail here).
Sixth, LanManager (LM) is fully supported on most existing Windows Active Directory enterprises. LM is a very old authentication protocol that is very weak with protecting the password and the password hash generated to support authentication with this protocol. There are two GPO settings (which are actually Registry settings) that control if LM will be supported and if the LM hash will be stored. We will be going into both of these settings in the next installment of this article series, making sure you know how to configure these settings correctly and exactly where to make the settings within a GPO.
Summary
The default password policy settings for an Active Directory domain are not horrible, but can be improved. The default settings are originally configured and stored in the Default Domain Policy GPO, which is linked to the domain node. For Windows 2000 and Server 2003 domains, there can only be one password policy for a Windows 2000/2003 domain! This means that all users (IT staff, developers, executives, HR, etc) have the same password policy restrictions. If those are weak for one set of users, then they are weak for all users. Modifications can be made to the local SAM on servers and desktops (not DCs) from GPOs that are linked to the OUs where these computer accounts reside in AD. These GPO settings will only control local user accounts, not domain user accounts. LM is a old, insecure, and poor choice for an authentication protocol, which should be investigated and disabled if possible. In the next installment we will not only talk about protecting against LM, but other ways that Windows passwords are attacked.
If you missed the other parts in this article series please read:
