AD Security Optimization and Hardening White Paper-03

Chapter 3: Technical-Strategic Level Optimization Outline

The overall architecture design of the domain must be scientific. Otherwise, if there are problems with the foundation, no matter how much it is patched at the upper level, the risk remains. Just like if the foundation is not solid, no matter how much the house is reinforced, it will be of no avail.

From a global perspective, there are mainly the following points:

3.1 Optimize Domain Architecture

From a security perspective, this measure is to reduce the attack surface.

The best recommendation is a single forest, single domain architecture, without subdomains, for the following reasons:

1. The most important reason is the consideration of security.

A subdomain is essentially an independent domain. If the subdomain is attacked, it is very likely that a lateral attack will occur from the subdomain into the parent domain. In the absence of effective guarantees for the security of the subdomain, setting up a subdomain will put the parent domain at risk. In other words, adding a subdomain does not improve security, but instead doubles the amount of management and doubles the security risk.

2. From a management perspective.

Administrators of a subdomain can fully manage their subdomain and have high privileges. If they do not manage it well, it will lead to chaos in the management of the subdomain. It is better to have one domain where all management can be "one size fits all", which is more centralized and simpler.

From the perspective of the difficulty of management, managing one domain is much simpler and easier than managing multiple domains. For example, if there is frequent internal personnel movement, moving between OUs (organizational units) in one domain is easy, but moving between domains is much more complicated.

From the perspective of management costs, managing multiple domains will have more security configurations, and even more hardware and software resource consumption.

3. From the perspective of combining security and management.

For the subdomain part, an appropriate organizational unit can be created in the single domain and reasonable authorization can be given to this organizational unit to achieve authorized management, which is convenient for managers and effectively controls permissions, achieving a "win-win" situation for management and security.

3.2 Minimize the Number of Sites

The essence of this measure is also to reduce the attack surface.

It is not necessary for every branch to deploy an AD site.

If the branch has few users (e.g. less than 100) and the bandwidth from the branch to the headquarters is sufficient (10M or more), then it is generally not necessary to add a new site. This branch can directly log in to the headquarters for verification. Even in the event of occasional dedicated line interruption, since the client has login cache, it does not affect the user's login to the desktop to use the computer.

3.3 Do Not Deploy Too Many Domain Controllers

The essence of this measure is also to reduce the attack surface.

Because one more domain controller is one more exposure point.

Of course, it's not to say that there should only be one domain controller for the whole domain. Considering redundancy, the headquarters should have at least two domain controllers, which can be increased to 3 to 4 according to the load situation. Other branches are recommended to deploy one domain controller.

3.4 Try to Deploy Read-Only Domain Controllers at All Branches

Except for the deployment of two to three read-write domain controllers at the headquarters, all branches that can deploy read-only domain controllers should deploy read-only domain controllers.

Note: If the Exchange server is deployed at a branch site, there must be a read-write domain controller at the site.

The read-only domain controller will greatly improve the controllability of domain security, reduce the defense surface, mainly reflected in the following points:

1. Each read-only domain controller can authorize a common user to manage (mainly manage scenarios such as patching, restarting, shutting down, etc., object management (such as user management) and group policy management do not need to log into this server, of course, can also log into this server). In this way, even if this server is attacked by hackers, it cannot carry out lateral attacks to the read-write domain control, and because the read-only domain control is a read-only copy and cannot be modified, hackers cannot attack by modifying AD data synchronization to other domain controls.

2. By default, read-only domain controllers do not even cache user and computer password information. In order to speed up local user and computer login, policies are usually configured to copy the user and computer password information of this site, i.e., at most the account password information of this site is in the AD database, greatly reducing the risk.

3. Read-only domain controllers can also configure replication filtering, for example, some sensitive information can not be copied to the branch read-only domain controller (such as PKI information).

4. From the replication perspective, all properties are replicated from the read-write domain control to the read-only domain control in one direction, and no information is copied from the read-only domain control to the read-write domain control.

In a sense, deploying a read-only domain controller is equivalent to reducing the number of domain controllers, i.e., reducing the attack surface.

3.5 Use Physical Machines for Read-Write Domain Controllers As Much As Possible

Although virtual machines bring great convenience, physical machines are better from a security perspective, mainly for the following reasons:

1. If the physical machine where the virtual machine is located is compromised, the virtual machine is also equivalent to being compromised. In other words, to protect the virtual machine, the relevant physical machine must be protected first, and now there are often news about vulnerabilities in certain virtualization platforms, which further exacerbates this insecurity.

2. Virtual machines can be copied by hackers or insiders, leading to serious information leakage and security risks.

3. It reduces the impact of some administrators' misoperations. Some administrators are used to making a snapshot before patching, and even use this snapshot to restore the domain controller, which will bring about replication problems of the domain controller, affecting the domain function.

If it is a physical domain controller, TPM chips and BitLocker drive encryption should be configured for all server volumes.

If it is a virtual machine, the relevant virtual machine encryption technology should be enabled on the virtual machine platform.

3.6 Domain Controllers Should Use the Latest Operating System As Much As Possible

The latest operating system has better security and functionality, so it is recommended to prioritize the use of domain controllers.

Avoid using an operating system that is out of support cycle and does not have new patches for DC.

3.7 Reasonable Planning and Authorization of Organizational Units

Organizational units should be reasonably planned, and authorization should be carried out according to the principle of minimum permission, and do not arbitrarily expand the authorized personnel and permissions, such as giving everyone full control permissions.

Organizational Units (OU) are containers for various Active Directory objects, and their design will be based on the following principles:

 First principle: Facilitate the delegation of authorization;

 Facilitate refined terminal management through group policy.

The following suggestions are made:

 Authorization is granted on a site-by-site basis. A site administrator group and a site client administrator group are created for each site, and the site administrator group is authorized to perform operations such as creation, modification, disabling, and deletion of users, computers, security groups, etc. within this site. The site client administrator group is added to the local administrator group of this site's computer through group policy for daily maintenance that requires administrator privileges.

 Authorization is based on security groups, and individual users are not granted, which is convenient for adjustment.

 If there are user and computer objects to be moved between sites, they should be moved to an intermediate "transfer station" organizational unit first, and the target site should go to pick them up.

 The user OU is initially designed independently, which is convenient for future applications to synchronize AD users.

 There is an independent global resource OU, where global computer, server, security group and other objects are placed. This global resource OU is managed by the domain administrator/enterprise administrator.

The aforementioned site administrator group and site client administrator group are recommended to be placed under this OU, i.e., the changes in the members of these groups are the responsibility of the group, to avoid branches not adding accounts according to specifications.

 The management machine is an independent OU, which is convenient for implementing special group policies.

3.8 Group Policy Can Only Be Added, Deleted, and Changed by the Domain Admins Group

Since group policies may be used to distribute malicious settings or programs, it is recommended to control the permissions for adding, deleting, and changing GPOs, and to monitor whether the delegated permissions of GPOs have changed, and whether GPOs have changed, especially the default Default domain Policy and Default Domain Controller Policy.

By default, users in the Domain Admins and Group Policy Creator Owners groups have the permission to create new GPOs. It is recommended to clear the Group Policy Creator Owners security group and use a restricted group policy to ensure that its members are empty. Subsequent sections will also discuss that the members of Domain Admins will also be empty by default, and members will be added only when necessary, and group policies will be edited in a "run as" manner.

3.9 User Account Automatic Synchronization

The main purpose of this recommendation in terms of security is also to reduce the attack surface, because the more expired accounts there are, the larger the attack surface.

It is recommended to deploy an AD user synchronization program to synchronize user information from other authoritative sources (such as HR, OA), including user creation, information changes, user department transfers, user disabling, user deletion, etc., which has at least the following advantages:

1. It greatly reduces the time spent by administrators on AD daily operations and maintenance. Administrators no longer need to waste time on the management of the entire life cycle of user accounts, such as account creation and changes, disabling, deletion, etc., these operations can be automated.

2. It reduces the security risks caused by untimely processing in the management process, such as the timely disabling of a user account after an employee leaves the company. Manual processing often results in delays or even neglect, while automatic synchronization does not.

In general, automatic synchronization can more effectively ensure the timeliness, accuracy, and completeness of user data.

3.10 Implement Appropriate Password and Lockout Policies

Different levels of accounts should have different password and lockout policies.

Implement password and lockout policies for general users (D-level) at the domain level.

For A-level and B-level accounts, more stringent password and lockout policies should be in place, which are implemented through PSO.

The suggestion here is to be appropriate, not strict.

Appropriate means feasible. For example, some companies have implemented strict password policies, requiring complexity and password length, and requiring changes every 60 days, as well as multiple password histories. As a result, some users can't remember their passwords and directly write their passwords on paper and stick them on their computers, which actually reduces security. Therefore, the password policy for users must be considered comprehensively. Generally speaking, if the password length of users is 8 or more, the strong password (four choose 3) is required, the password is changed once every six months, and one password history is acceptable.

If possible, it is best to develop a password blacklist function, because the default password policy can only simply check the length and complexity requirements of the password. The password set by this default password policy is still a classic weak password that is easy to crack in most cases, such as using multiple consecutive numbers or letters when setting a password, using the weak password P@ssw0rd, using English with the company's letter abbreviation, etc.

But for administrators, there should be stricter password policies, with passwords of at least 13 characters or more.

For the implementation of the lockout policy, it is usually recommended to have a supporting user self-unlock system. Otherwise, if the administrator is asked to handle the unlock, the workload may be large and it is necessary to find the reason for the lockout, which is not feasible.