AD Security Optimization and Hardening White Paper-02

2.2 Building a Hierarchical Classification Model for Systems

Building a hierarchical classification model for systems is mainly to lay the foundation for the next section on account hierarchical classification, different levels of systems have different levels of accounts. At the same time, system hierarchical classification can also be referred to in patch policy.

The systems added to the domain can be divided into two major categories, servers and clients. As shown in the above diagram, the server systems are divided into 6 levels, with the importance decreasing from top to bottom.

The first level is the domain base system, such as domain controllers, which are the most important systems for the domain.

The second level is the core application system added to the domain or Microsoft series applications, such as ERP servers added to the domain, and Microsoft series Exchange servers, LYNC servers. These Microsoft series servers have a very high degree of integration with AD and have a wide user base. They are often the targets of hackers. Many hackers use them as stepping stones to ultimately take down the domain control. Therefore, from the perspective of domain security, they are very important and are also listed as the second level.

The third level systems may not have been added to the domain, but their user login has integrated with AD through LDAP. If simple authentication is chosen for LDAP authentication, user passwords are transmitted in plaintext. When these systems are attacked, user passwords can be easily sniffed and used by hackers as a stepping stone to further attack the domain control.

The fourth level is other important business systems added to the domain, such as OA, which is generally an application used by many people.

The fifth level is the edge business applications added to the domain, which are generally used by fewer people and are non-core applications.

The sixth level is business applications with outdated operating systems. Since the vendors of these systems generally no longer provide security patches, these systems pose a high security risk.

Of course, the above division is just a reference, each enterprise can make minor adjustments according to its own situation.

2.3 Building a Hierarchical Classification Model for Accounts

We have classified the accounts in the domain, including four levels:

Level A: Domain-level administrator accounts, mainly accounts located in the domain DA group / EA group / DC local administrator group.

Level B: Local administrator group accounts of the operating system, including accounts in the local administrator group of the server and accounts in the local administrator group of the client.

Level C: Administrator accounts of the application program itself.

Level D: Ordinary accounts for client login.

These different levels of accounts are located in the administrator groups of different levels of systems, for example, level A accounts are in level 1 systems. In general, these accounts must have strict scopes of use, corresponding accounts log into corresponding systems, and higher-level accounts cannot be used to log into lower-level systems. If they really need to log in, it is best to use a one-time password, i.e., change the password after logging out, to prevent cached credentials from being used.

One special point is that when a system has passed the manufacturer's support cycle and vulnerabilities cannot be repaired, it is necessary to consider creating a dedicated administrator account to log in, and the original administrator account can no longer be used to log in, to prevent its credentials from being stolen.

For a specific administrator, he will have multiple accounts, each account is suitable for different systems or scenarios. To make it easier to understand, we now give an example to explain this account system. For example, for IT manager Zhang San, he should have multiple accounts, not just one account used in various level systems.

Firstly, Zhang San as a user, like other employees, has a domain account (level D), for example, called zhangsan, used to log into his own computer;

Then Zhang San is also a desktop operation and maintenance personnel, he needs to maintain other employees' computers, for example, installing software, at this time he needs a client's level B account such as pc-zhangsan;

If Zhang San is also an Exchange system administrator, then he needs a server level B account such as adm-zhangsan. If Zhang San is an Exchange recipient administrator, then he has a level C account, but this account can generally be shared with level D account zhangsan, because it does not need to log into the system, it is only used in the application.

If Zhang San is also a domain control administrator, he also needs a level A account dc-zhangsan (for specific suggestions on domain administrators refer to the specific description of Section 4.1 Domain Control Reinforcement, this is a general example).

The above level A and level B accounts have two design ideas, still using Zhang San as an example, if his level B account is adm-zhangsan, he manages mail, OA system, usually needs to add this account to the local administrator group of the mail, OA system, then if the OA system is infected, it is very likely to spread laterally to the mail server (credential transfer). So this level B account created with the user as the dimension is suitable for each administrator to manage a set of systems. If a user needs to manage multiple sets of systems, a level B account can also be created with the system dimension, for example, a mail system administrator mailadmin, an OA system administrator oaadmin, in this way, any system infection, the infection is only limited to this system, will not spread laterally.

Of course, you can also plan B-level accounts by combining user and system dimensions, such as mail-zhangsan,oa-zhangsan, but in this way, the administrator has a lot of accounts, too many things can easily cause management vulnerabilities. Therefore, how to plan depends on the specific situation, you can also refer to the description of the next section 2.4, how to prevent this kind of lateral attack in the choice of operation and maintenance management methods is also very important.

For B-level client administrator accounts, such as pc-zhangsan in the above example, you need to join the domain's site client administrator group, and add this group to the client's local administrators group, and prohibit its network access rights, to prevent the infected computer from spreading laterally.

For B-level local administrator administrator, the server is renamed to srvadmin, the client is renamed to pcadmin, use the LAPS solution, to achieve password randomization and can be checked. Of course, the password of LAPS is saved in AD in plaintext, so this is also a potential vulnerability point. For the client, you can consider the following solution: pcadmin can have a unified password, but disable its network access rights, so when the credentials of this account are obtained, it can only log in interactively, and cannot extend to other computers through the network, the impact range is very small. Even if you use the LAPS solution, you should also disable the network access rights of pcadmin.

2.4 Constructing an Operation and Maintenance Management Model

For the daily operation and maintenance of domain control, it is recommended not to log into the domain control itself, but to do it through a management machine.

The daily operation and maintenance path is: Management Account > Bastion Machine > Management Machine > Domain Control.

From "Management Machine > Domain Control", use remote management. There are many kinds of remote management methods provided by the system now. Different remote management methods are suitable for different scenes. Which remote management method to choose not only relates to the convenience of operation and maintenance but also relates to the safety of domain control. Here are some related suggestions:

From the above summary, daily operation and maintenance and user management, etc., can be operated on the management machine running AD users and computer tools. These operating accounts can be authorized site administrators, and do not have to be BA group administrators.

Other maintenance operations that require BA group administrators can log into the domain control in restricted mode RDP. The restricted mode has a benefit that the credentials submitted by the administrator will not be saved on the target server, and this session runs as the system identity of the target server, which eliminates the possibility of lateral attacks. Based on this, it is also recommended to manage other servers' RDP in this way. In this way, for an administrator like adm-zhangsan who needs to manage multiple systems, since this method eliminates the possibility of lateral attacks, this account model can be used safely.

But the restricted mode must limit the IP that can connect to RDP, otherwise the target server will have a high-risk risk of being connected to RDP by PTH, which is also one of the reasons why it was suggested earlier to use a dedicated management machine for remote domain control.

For non-headquarters sites, if it is a read-only DC, refer to the suggestions for RODC later. For read-write domain control, it is recommended that each one set up a dedicated domain account (non-domain administrators group), and can only log into this DC, authorize this user to be able to turn on and off the machine maintenance.

In an emergency or in a situation where access through the management machine is not possible, domain administrators can access the system via the console (physical machine connected to mouse, keyboard and display, virtual machine accessed via virtualization management platform).

Regarding the management machine, you can deploy two or more dedicated management machines for domain-related management, all relevant administrators can log into this management machine for corresponding management operations.

If you want multiple people to log in concurrently (more than 2), you need to deploy windows server system and deploy a session desktop mode, sessions that have not moved for 2 hours will be automatically logged out.

If up to 2 people are logging in, you can deploy windows 10 enterprise edition, which has better security features.

The basic configuration and reinforcement of the management machine are as follows:

Disable password caching

Prohibit caching of network credentials

Update to the latest patch immediately

Turn on the system firewall

Install antivirus software, set exit and uninstall password, add exclusion.

Disable server service

Disable WINRM service.

Run the remote desktop client in restricted mode

Disable client disk mapping for remote desktop services, enable clipboard text paste

Remote desktop automatically logs out after 2 hours of inactivity.

Remote desktop automatically logs out after 2 hours of disconnect.

Prohibit reading from USB drives and other mobile media

Turn off autoplay (all drives)

Prohibit access to the internet

Disable browser password saving (recommend up to IE/EDGE/Chrome three browsers)

Do not disable UAC

Do not install unnecessary software, one more software is one more vulnerability point

Administrators: Members only administrator, clean up domain admins

Remote desktop users: Only administrator work accounts are members