Active Directory domain infrastructure configuration 3

Subsequent articlesActive Directory domainAfter infrastructure configuration 2, the Active Directory domain infrastructure configuration in this article is described as follows:

Account lock Policy

The account lock policy is an Active Directory security feature that locks user accounts when multiple logon attempts fail within a specified period of time. The allowed attempts and time periods are based on the configured values for Security Policy locking. You cannot log on to the locked account. The domain controller tracks logon attempts, and the server software can be configured to respond to such potential attacks by disabling accounts during a preset period of time.

When configuring an account lock policy in the Active Directory domain, the administrator can set any value for the attempt and time period variables. However, if the value set by "Reset Account lock counter" is greater than the value set by "account lock time, the domain controller automatically adjusts the value of "account lock time" to the same value as the "Reset Account lock counter.

In addition, if the value set for "account lock time" is lower than that set for "Reset Account lock counter, the domain controller automatically adjusts the "Reset Account lock counter" value to the same value as the "account lock time" value. Therefore, if the value of "account lock time" is defined, the value of "Reset Account lock counter" must be less than or equal to the value configured for "account lock time.

The domain controller performs this operation to avoid conflict with the setting value in the security policy. If the administrator configures the value set for "Reset Account lock counter" to be greater than the value set for "account lock time, the implementation of the configured value for "account lock time" will expire first, so you can log on to the network. However, the Reset Account lock counter setting Continues counting. Therefore, the "account lock threshold" setting will retain up to three Invalid Logins), and users will not be able to log on.

To avoid this situation, the domain controller automatically resets the value set for "Reset Account lock counter" to be equal to the value set for "account lock time. These security policy settings help prevent attackers from guessing user passwords and reduce the possibility of successful attacks on the network environment. You canGroup PolicyConfigure the values in the following table in the domain group policy at the following position in the object Editor: the following table lists the account locking policies for the two security environments defined in this Guide.

Account lock time

Table 2.8: settings 　

The "account lock time" setting determines the length of time required before the account is locked and the user can try to log on again. This operation is performed by specifying the number of minutes in which the locked account remains unavailable. If the value set for "account lock time" is 0, the locked accounts remain locked until the administrator unlocks them. The default value of Windows XP in this setting is "not defined ".

To reduce the number of calls supported by the help station and provide a secure infrastructure, for the two environments defined in this Guide, set "account lock time" to "30 minutes ".

Setting the value of this setting to never unlock automatically seems to be a good idea, but this will increase the number of calls received by the Help Desk in the organization to unlock the account that is accidentally locked. For each lock level, setting this value to 30 minutes can reduce the chance of DoS attacks. This setting value also gives the user the opportunity to log on again within 30 minutes when the account is locked. This is the most acceptable time period for the user without turning to the help desk.

Account lock threshold

Table 2.9: settings 　

The "account lock threshold" is used to determine the number of attempts a user can log on to the account before the account is locked.

The reasons for authorizing a user to lock himself out of the account may be: Wrong Password or wrong password, or changing the password on the computer and logging on to another computer. The computer with the wrong password continuously tries to authenticate the user. Because the password used for authentication is incorrect, the user account is eventually locked. This issue does not exist for organizations that only use Domain Controllers Running Windows Server 2003 or earlier. To avoid locking authorized users, set the account lock threshold to a high value. The default value of this setting is "0 Invalid Logins ".

For the two environments defined in this Guide, set the "account lock threshold" value to "50 Invalid Logins ". Because a vulnerability exists regardless of whether the value of this setting is configured, unique measures are defined for each of these possibilities. Your organization should strike a balance between identified threats and risks that are being reduced.

Two options are available for this setting. Setting the "account lock threshold" value to "0" ensures that the account is not locked. This setting prevents DoS attacks intended to lock accounts in an organization. It can also reduce the number of calls to the help station because the user will not accidentally lock himself out of the account. Because this setting cannot avoid strong attacks, the password policy is set to a value greater than 0 only when it explicitly meets the following two conditions to force all users to use a complex password consisting of eight or more characters. A strong audit mechanism is in place to remind administrators when a series of account locks occur in the organizational environment. For example, audit solution should monitor security event 539. This event is a logon failure ). This event means that the account is locked when you try to log on.

If the preceding conditions are not met, the second option is: Set the "account lock threshold" to a high enough value, this allows the user to accidentally lose the wrong password several times without locking himself out of the account, and ensure that the Account will still be locked due to strong password attacks. In this case, if you set the value to a certain number of times, for example, 3 to 5 times), invalid logon ensures proper security and acceptable availability. This setting will avoid unexpected account locking and reduce the number of help station calls, but it cannot avoid DoS attacks as described above.

Reset Account lock counter

Table 2.10: settings 　

"Reset Account lock counter" sets the length of time before "account lock threshold" is reset to zero. The default value is "not defined ". If the "account lock threshold" is defined, the reset time must be less than or equal to the value set for "account lock time. For the two environments defined in this Guide, set "Reset Account lock counter" to "30 minutes later ".

Keeping this setting as its default value or configuring this value at a long interval will cause DoS attacks to the environment. Attackers maliciously perform a large number of failed logins to all users in the organization, locking their accounts as described above. If no policy is specified to reset the account lock, the Administrator must manually unlock all accounts.

In turn, if a reasonable time value is configured for this purpose, the user will lock only a set period of time before all accounts are automatically unlocked. Therefore, the recommended setting value is 30 minutes, which defines the time period that the user is most likely to accept without turning to the help desk.

User permission allocation

Module 3 "Windows XP Client Security Settings" details user permission assignment. However, the "add workstation in the domain" user permission should be set for all domain controllers. The reason is discussed in this module. Module 3 and 4 of "Windows 2003 Server Security Guide" describes other information about Member Server and Domain Controller settings.

Add workstation in domain

Table 2.11: settings 　

The "add workstation in a domain" user permission allows users to add computers to a specific domain. For this permission to take effect, you must assign it to the user as part of the default Domain Controller Policy of the domain. Users with this permission can add up to 10 workstations to the domain. Users who have granted the "Create computer object" permission to the OU or computer container in Active Directory can also add the computer to the domain. Users with this permission can add an unlimited number of computers to the domain, whether or not they have been assigned the "add workstation in the domain" user permission.

By default, all Users in the Authenticated Users Group can add up to 10 computer accounts to the Active Directory domain. These new computer accounts are created in the computer container. In the Active Directory domain, each computer account is a complete security entity that can authenticate and access domain resources. Some organizations want to limit the number of computers in the Active Directory environment so that they can always track, generate, and manage them.

Adding a workstation to a domain may impede this effort. It also provides users with a way to execute activities that are more difficult to track because they can create other unauthorized domain computers. For these reasons, in the two environments defined in this Guide, the "add workstation in domain" user permission is granted only to the "Administrators" group.

Security Settings

The account policy must be defined in the default domain policy and must be enforced by the domain controller of the domain. The domain controller always obtains the account policy from the default domain policy GPO, even if there are other account policies applied to the OU containing the domain controller.

There are two policies in the security options, which also play the same role as the account policy to be considered at the domain level. You can configure the domain group policy values in the following table in the Group Policy object Editor: Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options Microsoft Network Server: the user is automatically logged out when the logon time is used up.

Table 2.12: settings 　

"Microsoft network server: automatically deregister the user when the logon time is used up" sets whether to disconnect the user connected to the local computer after the valid logon time of the user account is exceeded. This setting affects the Server Message Block (SMB) component. After this policy is enabled, the session between the client and the SMB service is forcibly disconnected after the client Logon Time is exceeded. If this policy is disabled, the created Client Session is allowed to continue after the client Logon Time is exceeded. Enable this setting to ensure that the "Network Security: Force logout after the logon time is exceeded" setting is also enabled.

If the Organization has configured a logon time for the user, it is necessary to enable this policy. Otherwise, it is assumed that you cannot access network resources after the logon time is exceeded. In fact, you can continue to use these resources by setting up sessions within the permitted time. If no logon time is used in the organization, Enabling this setting does not affect. If the logon time is used, the existing user session is forcibly terminated after the logon time of the existing user is exceeded.

We hope this series of Active Directory domain infrastructure configurations will be helpful to readers.