How to implement password granular management in Windows Server2012

With the maturity of IT technology, the security management of accounts in enterprises is becoming more and more strict. The management of account passwords is especially important. The method of ensuring account password security is to uniformly configure account and password groups at the domain level. Strategy to achieve the unification of enterprise passwords. But in fact, the importance of passwords for different user accounts in the enterprise is different. For example, the account password of the IT administrator is more important than the password of the ordinary user. In addition, the password is too complicated for the special operation. For Uyghur personnel, it may not be difficult to remember, but for ordinary users, it is not an easy task to remember. Therefore, the need to configure a password policy for the administrator account and the general domain user account is It came into being. So how do you implement granular management of different user password policies? Many administrators who don't know much about cryptographic group policies do this: put administrator accounts and common domain user accounts in different planned OUs, then mount different group policies under different OUs and configure them separately. Different password policies are used to manage different types of user password policies. This approach seems to be perfect for the granular management of passwords, but can we achieve the results we expected? To be sure, this is not enough to meet our expectations. If the failure to achieve the desired results, then what is the impact of the password policy configured under different OUs? Next we will explore through experiments. Experimental environment: The servers DC1 and SVR1 of the windows server2012R2 system are installed, in which DC1 is the domain controller and SVR1 is the computer in the domain. The other configurations are as follows: Server name account type account membership group belongs to OU DC1 domain user admin Domain Admins Domain Users Administrator user Domain Users Common user domain computer SVR1 //SVR1 Local Account Tom //
Next, the experimental configuration process: Step 1: Create a Group Policy object and implement the group policy link on DC1, open the group through Server Manager - Tools - Group Policy Management Policy Management Console, then create an administrator GPO and a normal user GPO in the Group Policy object, respectively, and link them to the administrator and normal user OU, as shown in the figure: Step 2: Edit the domain, administrator OU Three levels of password policy for common user OU 1. Select Default Domain Policy, right-click to edit, and then expand in the group policy management editor that opens: Computer Configuration - Policies - Windows Settings - Security Settings - Account Policies - Password Policies, and According to the following parameter settings: Here we focus on the minimum length of the password under the default domain policy is 10 bits. 2, the same method, select the administrator GPO-edit, configure the password policy under the administrator OU as follows: Here we focus on the minimum password length of 8 bits. 3. Continue to use the same method, select the normal user GPO-edit, configure the password policy under the administrator OU as follows: Here we focus on the minimum password length of 6 digits. Step 3: Verify the final valid password policy. 1. On DC1, open a command prompt and run the gpupdate /force command to update the configured group policy: 2. Open the AD user and computer, open the administrator's OU, and try to reset the administrator group user admin password to 8 digits. 1qaz@WSX, the following prompt pops up: 3, open the OU of the ordinary user, try to reset the password of the ordinary domain user user1 to 6q 1qaz@W, the following prompt pops up: 4, re-open the administrator OU to reset the admin password 10 digit 1qaz@WSX#E, reset the user's password to 10 digits of 1qaz@WSX#E, and found that the password has been changed, indicating that the change was successful. That is to say, the password policies of the administrator GPO and the common user GPO configured in the administrator OU and the common user OU are not effective. Only the password policy configured at the domain level takes effect. Only one password policy can be set in the entire domain. Granular management of password policies is implemented by configuring password policies for different OUs. So the question is, where does the password policy we configured under different OUs take effect? Continue to verify down. 5. Switch to SVR1, log in with the domain administrator account, open a command prompt, and run the gpupdate /force command to update the group policy. Then open the local users and groups. At this time, we try to reset the local user Tom created on SVR1 with the password of 4q 1qaz. At this time, an error message is displayed: the password does not meet the password policy requirements, but we are not configured in the local policy. Any password policy, and the local password policy is undefined by default, continue to verify. At this point, try to reset Tom's password to 6-digit 1qaz@W. Finally, the password is set. The 6-digit new password satisfies the requirements of the password policy, and the password policy is not from the local. Reviewing the configuration of our experimental environment, the configuration of the password policy associated with SVR1 is only under the ordinary user of the OU to which the SVR1 computer account belongs. The password policy, that is, although the password policy under the OU cannot be valid for the domain user account in the OU, it is effective for the local user of the computer in the OU. In summary, there can only be one password policy in a domain, and only the domain-level password policy takes effect, and the password policy under the OU only takes effect on the local account of the computer in the OU. This seems to be contrary to the application order and validity principle of the group strategy we are learning, but it is reasonable to think about it carefully. The password security of the account is very important, and it is necessary to realize unified management. However, this does not help us to achieve granular management of passwords for different users, so how to achieve it? Please refer to Windows
Server2012 to implement a diversified password strategy (2) to learn.

In the previous section of Windows Server 2012 to implement password granular management (1), only one password policy can be set in a domain, and only the password policy configured at the domain level is valid, but this does not help us. Solve the password policy of implementing user passwords for different types of users in a domain to achieve granular management of user passwords. Then in this section, we will focus on how to implement granular granulating management in the Windows environment. Before Windows Server 2008, there were no other ways to implement two password policies in a domain. You can only configure a password policy at the new domain level by adding a new domain and then placing the administrator account in the newly added domain. However, in the existing domain, a unified password policy is configured for ordinary domain users. Although this method can also fulfill our requirements, the actual operation requires both a new domain and a cross-domain management access problem, which is very troublesome. In the Windows Server 2008 version, a diversified password policy that can set different password configurations for different users in one domain appears. To configure a diversified password policy in the Windows Server 2008 version, you need to open the domain partition in the ADSI editor, find the System container, expand to find the Password Settings Container, and then create a new object, follow the wizard to implement the diversified password policy step by step, and After configuration, you also need to specify which security principals to apply the password policy to (as shown in the following figure). Although Windows Server 2008 provides granular management of passwords, we can see that it is very cumbersome to implement, and the possibility of error is relatively large. In Windows Server 2012, this function has been greatly improved in terms of operation. We do not need to open the ADSI editor to easily set up a diversified password policy directly through the Active Directory Management Center in Windows Server 2012. Before you can set up a diversified password policy, you need some prerequisites: 1. Permissions: Members in the domain admins group 2. Functional level of the domain: windows server 2008 or higher 3. Managed console: Windows server2012 version Active Directory Management Center
Experimental Environment: The computer DC1 with the windows server2012R2 system installed and configured as a domain controller with the domain name contoso.com. Then, based on the current experimental environment, we will demonstrate the deployment process of the diversified password policy: Step 1: Upgrade the functional level of the domain Log in to DC1 with the default administrator account in the domain. The upgrade of the domain function level can open the console of the AD user and the computer or the AD management center or the AD domain and the trust relationship. Right-click on the domain level to implement it. Here, only the functional level of the domain in the AD management center can be enhanced: you can see The current functional level is windows server2012R2, so the prerequisites for the domain functional level are met. Step 2: Prepare the test account in the AD user and computer management console, create a new organizational unit test, then under test, create a common domain account Aaron and White, and then add Aaron to the domain admins group as an administrator account.