Windows Domain Password Policy

Windows Domain Password Policy

Derek Melber

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 2008, 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 Windows^{Any current version of the domain (Windows NTWindows 2000 Active DirectoryOr Windows Server2003 Active Directory), it will be limited by each domain can have only one password policy. 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.}

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 Active Directory 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 Active Directory 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 2Displays the complete list of initial settings of password policy items in the Windows Server 2003 domain.

Figure 2 Default password policies for Windows Server 2003 domain (click the image to get a small view)
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 Server 2003), 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 Active Directory 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 only allows you to set one policy for all domain user accounts, which has now been moved to a deeper part of Active Directory. 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 Active Directory database for modification. Specifically, you will use a tool similar to adsiedit to modify the Active Directory 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 Server 2008, 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 Active Directory 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 Active Directory database, or even scripts. After implementing the password policy in Windows Server 2008, you need to use a different method than in 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 Active Directory database in Windows Server 2008. However, note that since these policy settings are already active directory 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 = password settings, CN = system, Dc = domainname, Dc = com ". Note that the function level of the domain used must be set to Windows Server 2008. Under this new object, you need to fill in several attributes, as shown in 3.

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 Active Directory 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 an account policy using the active directory database. Fortunately, the new settings follow the settings you are familiar. When you start to use Windows Server 2008, be sure to study these new settings immediately, because these must be your first configuration.

Derek MelberBoth MCSE, cism and MVP are independent consultants and trainers. He teaches and promotes Microsoft technologies, focusing on Active Directory, group policies, security, and desktop management. Derek has published many IT books including the Microsoft Windows Group Policy Guide (Microsoft Press, 2005 ). You can contact him via derekm@braincore.net.
From December 2007 journal technet magazine.
You are welcome to give your comments. You are welcome to send us feedback.