Security Observation Windows domain Password Policy

If you are the administrator of a Windows domain, you will be very aware of the restrictions related to the password policy of the domain user account. But with the advent of Windows Server, some of these restrictions will no longer exist. Let's take a look at how the new operating system solves this problem: multiple password policies cannot be implemented.

If you are running any version of the current Windows domain (Windows NT, Windows 2000 ActiveDirectory, or Windows Server 2003 ActiveDirectory), you will be limited by a single password policy for each domain. In fact, you are limited by not only password policies, but also a wider range of settings covered by account policies. Figure 1 shows these policies and settings.

Figure 1 Account policies

Password Policy

Force password history

Maximum Password Validity Period

Minimum Password Validity Period

Minimum Password Length

The password must meet the complexity requirements.

Use reversible encrypted storage Password

Account lock Policy

Account lock time

Domain locked by account

The time before resetting the account to lock the counter...

Kerberos Policy

Force user logon Restriction

Maximum Service Ticket life

Maximum Lifetime of user tickets

The longest life cycle of User Ticket Renewal

Maximum Computer Clock Synchronization tolerance

By default, these policy settings apply to all domain accounts and user accounts associated with the domain. This is because the Group Policy is inherited down the ActiveDirectory structure. To better understand how these policies affect domain accounts and local user accounts, it is important to know the location where these policies are set and how the Inheritance Method of group policies affects all different user accounts. (Note that Kerberos policy settings only apply to domain user accounts, because only domain user accounts use Kerberos for authentication. The Local User Account uses NTLMv2, NTLM, or LM for authentication .)

Set Account Policies

Within Active Directory, group policies establish and control account policies for the entire domain. This occurs when the ActiveDirectory domain is installed for the first time and is completed by obtaining the default group policy object (GPO) linked to the domain node in Active Directory. This GPO name is the default domain policy and has the default configuration of all three parts of the Account Policy. Figure 2 shows the complete list of initial settings of password policy items in the Windows Server2003 domain.

Figure 2 Default password policies for Windows Server 2003 domain (click the image to get a large view)

The settings in this GPO control all domain user accounts and account policies for each domain computer. Remember that all domain computers (desktops and servers) have local security account managers (SAM), which is important. The default setting in GPO controls this SAM. Of course, the local SAM also contains the local user account of each computer.

By using GPO, the normal inheritance is performed along the Active Directory structure. The settings in the default domain policy can affect all domain computers. Since this GPO is linked to a domain node, it affects all computer accounts in this domain.

Operation that cannot be performed on the current password policy

There are still many misunderstandings about the current implementation of Active Directory (in Windows Server2003), despite years of rigorous testing, no evidence is found to prove that those misunderstandings are correct. Obviously (or should be said), policies cannot work in other ways than design.

That is to say, many administrators believe that they can set multiple password policies for multiple users in the same domain. They think you can create a GPO and link it to an organizational unit (OU ). This idea is to move the user account to OU so that GPO affects these objects. In GPO, modify the account policy to create a safer Password Policy (probably by setting the maximum password length to 14 ). However, for some reason, this configuration will never meet the expected results. First, password policy settings are based on computers rather than users. With the prerequisites for this setting, the setting will never affect the user account. Second, there is only one way to modify the account policy settings for the domain user account, that is, to modify the account policy within the GPO linked to the domain. The GPO linked to the OU and configured to change the account policy settings will modify the local SAM that resides in the OU (or in the sub-OU of the connected OU.

Another misunderstanding is that the account policy settings established in the root domain (the initial domain of the ActiveDirectory forest) flow down or inherit to the subdomains in the forest. This is also not the case. In this way, settings cannot work. The GPO linked to the domain and the OU in a domain does not affect the objects in other domains, even if the GPO is linked to the root domain. The only way to make GPO settings affect objects in other domains is to link GPO to the Active Directory site.

Password Policy Change

You can see that the current version of Windows processes the user account password in a simple and intuitive way. This includes a set of password rules applicable to all domain accounts, as well as managing account policies by linking to the Group Policy objects of Domain Nodes in Active Directory. With the advent of Windows Server 2008, all of this was ruled out.

Windows Server 2008 and the released Active Directory infrastructure use another method. Placing Account Policies in GPO allows only one policy for all domain user accounts, which has now been moved to a deeper part of ActiveDirectory. In addition, account policies are no longer based on computer accounts. Now, you can allow individual users and user groups to control their password restrictions. For Windows administrators, this is a completely new concept. After all, we have been processing the Account Policies for computer accounts for a long time.

Account Policy in Windows Server 2008

In Windows Server 2008, you do not need to use the default domain policy to create an account policy. In fact, you do not use GPO to create Account Policies for domain user accounts. In Windows Server 2008, you are taken to the ActiveDirectory database for modification. Specifically, you will use a tool similar to ADSIEdit to modify the ActiveDirectory object and its associated attributes.

The reason for this change is that the Group Policy is not designed for multiple passwords in the same domain. In Windows Server2008, the function of implementing multiple passwords in each domain is very good, but not everyone thinks this function is very convenient to use. However, over time, the interface for configuration settings will become more and more accessible. Now, you need to use the ActiveDirectory database setup tool to change the system.

If you prefer to use other methods to modify account policy settings, you do not need to use ADSIEdit. You can use any other LDAP editing tool that can access the ActiveDirectory database, or even scripts. After implementing the password policy in Windows Server2008, you need to use a different method from the past. Using the new feature means you need to consider which users and groups need to accept which password settings.

You should not only consider the password length, but also consider other restrictions attached to the password policy settings, including the shortest, longest use period, and history. Other considerations include how to control user lock policy settings and Kerberos settings. The current account policy settings have one-to-one relationship with the account policy settings configured in the ActiveDirectory database in Windows Server 2008. However, note that since these policy settings are already ActiveDirectory objects and attributes, the names of each policy setting will also be different from the previous ones, which is very important.

To set a new password, you must create a password setting object (PSO) named msDS-PasswordSettings under the password setting container. The LDAP path of the container is "cn = PasswordSettings, cn = System, dc = domainname, dc = com ". Note that the function level of the domain used must be set to WindowsServer 2008. Under this new object, you need to fill in several attributes, as shown in 3.

Figure 3 Password attributes in Active Directory

Active Directory attribute name attribute description

MsDS-PasswordSettingsPrecedence establishes a priority when the same user has membership in multiple groups using different password policies.

MsDS-PasswordReversibleEncryptionEnabled: whether to enable reversible encryption.

MsDS-PasswordHistoryLength determines the number of unique passwords in the middle before a password can be reused.

MsDS-PasswordComplexityEnabled determines the number and type of characters required by the password.

MsDS-MinimumPasswordLength determines the minimum password length.

MsDS-MinimumPasswordAge determines how long the password can be changed.

MsDS-MaximumPasswordAge determines how long the password will be used before the user needs to change the password.

MsDS-LockoutThreshold determines the number of failed password attempts allowed before the user account is locked.

MsDS-LockoutObservationWindow determines how long the password counter will be reset after an error occurs.

MsDS-LockoutDuration determines the lock duration of the account after the account is locked due to the number of failed password attempts.

As you can see, all group policy settings related to account policy settings are copied as attributes. Note that there is also a priority setting. This is critical for implementing multiple passwords in the same domain, because there must be some conflicts and a mechanism to handle these conflicts is required.

Target account policy settings

For each created object, all attributes must be filled in to create an account policy for each user. Here we have a new msDS-PSOAppliesTo attribute to determine which objects will receive this set of policy settings. This is a key attribute that can be used to allocate specific settings to specific users. The list under this attribute can be a user or a group, but it is best to use a group instead of a user to create an access control list. Because the group is more stable, easier to locate, and easier to process.

Stand up and cheer

Over the years, we have been hoping to use multiple passwords in the same ActiveDirectory domain. From the password perspective, the situation that every user in the entire domain is at the same security level is gone forever. For example, you can set an 8-character password for a common user and a 14-character complex password for IT professionals (which may have administrator privileges.

It takes some time to create or modify Account Policy Settings Using the ActiveDirectory database. Fortunately, the new settings follow the settings you are familiar. When you start using WindowsServer2008, be sure to study these new settings immediately, because these must be your first configuration.