5 Steps to Secure Active Directory
5 Steps to Secure Active Directory
The Active Directory is used in many companies as a central element for authentication. Therefore, the domain controllers are also the focus of attackers. If these systems are compromised, the entire network is often at risk. Safety can be significantly increased with on-board equipment that you already have, making a more secure active directory environment with virtually no cost.
Accounts with elevated rights and administrator accounts are often the focus of the attackers. In order to optimally secure Active Directory, small and medium-sized companies should learn from enterprise environments, which in most cases are looking for a significantly more secure Active Directory environment.
Active Directory Security Vulnerabilities
When an attacker enters a network, it usually happens through a single endpoint. This takes places by using some default methods for hacking a password such as a Brute-Force Attack . As soon as this endpoint, for example an insecure PC, server, router or other network device, has been taken over, it is important to collect information about the network. Because only with sufficient information can an attacker efficiently spy on the rest of the network or carry out further attacks. This spying out, also called reconnaissance, or “recon” for short, spies on the network. Pass the hash Attacks are aimed directly at user accounts in Active Directory. Pass the hash attacks are a form of computer access with the LAN Manager’s hashed equivalent value of a password. This hash is normally generated from a plain text password and stored as a variable which hackers can sniff out. Of course, user accounts with privileged rights are of particular interest here. These can be administrator accounts, but also user accounts that have been given the right to change user passwords, for example. Attackers come with user changes in addition to PtH to other accesses. PtH attacks rely not only on the passwords of the users, but on the hashes that are assigned to a user account after authentication. Simply put, these are tickets in Active Directory. Next we will look at some tools that hackers use to attack less secure active directory environments.
Active Directory Attacks and Hacking Tools
As the previously mentioned pas the hash form of attack is most common in active directory, there are some other tools that hackers use to do what they need. The reconnaissance phase takes place by sniffing out information after the hacker has gained access to one node in the network. Then they will use some mainstream tools that are available to recon and get information. After they know which users are best to get the information from, they use the pass the hash method to steal the Lan Manager Hash or the Kerberos keys from the LSASS memory on the compromised windows machine. Other than this they use some tools to facilitate quicker attacks:
Mimikatz: a tool used for grabbing the said hash from Kerberos tickets or the Lan Manger Hash.
PowerSploit: a power-shell based tool for most elementary cases of atacks.
Bloodhound : a tool to find the best candidates for attacking and finding the Active Directory relationships between the users.
How to Secure Your Active Directory
After finding out about the potential secure active directory problems, we are going to take a look at 5 steps that you can take to harden active directory and let attackers tries be futile. These steps should be taken with consideration of your environment and it’s needs, if you are working in smaller scales maybe some steps might be taken first and then other steps be done if you have got the time or budget to do them.
Step 1: Use administrator account carefully and divide up rights
Administrator accounts should be used very carefully in Active Directory environments. First, different administrator accounts should be used for the different server applications in the company. Administrator accounts for SQL servers should not also be used for Exchange or to manage Active Directory. If such an account is compromised, all other server services are also at risk. Windows servers offer various user groups that are available by default and should also be used. These standard groups are particularly important in the root domain, especially in forests.
Step 2: No unnecessary logins with administrator accounts
In secure AD environments, it makes sense to work with accounts with elevated rights as little as possible. The login should only ever be made with the administrator account that is set up for the respective server service.
If a workstation is suspected of being compromised or unsafe, administrators should never log on to the system with the administrator account. In general, it makes sense to avoid logging on to computers that are connected to the Internet. Therefore, the administrators' workstations used to manage the environment should not be connected to the Internet.
Step 3: Use multi-factor registration and use administrator-time accounts
In principle, it may be necessary for administrator accounts to use multi factor authentication ( MFA ). In addition, you should also put administrator accounts on time. In such an infrastructure, administrator accounts are only given the right to carry out a certain administrative task for a certain period of time. If the task is completed or the time has expired, the rights are removed again. Resulting in a more secure active directory enviroment.
Step 4: Use read-only domain controllers in unsafe locations
Read-only domain controllers should be used in locations where the domain controllers are not positioned in protected server rooms. One possibility to secure domain controllers in branches is the read-only domain controller (RODC). These domain controllers receive the replicated information from the normal domain controllers and do not accept any changes from administrators themselves.
An RODC offers a complete and secure Active Directory, however without saved passwords. This folder on the RODC is read-only. An RODC can save passwords, but only those that an administrator specifies. When using RODCs, the following processes are carried out when a user logs on:
- A user logs on to the RODC location.
- The RODC checks whether the user's password has been replicated to the server. If so, the user is logged on.
- If the password is not available on the RODC, the login request is forwarded to a full DC.
- If registration is successful, a Kerberos ticket is assigned to the RODC.
- The RODC now issues the user with its own Kerberos ticket with which this user works. By the way, group memberships and group policies are not sent over the WAN line. This information is stored on the RODC.
- Next, the RODC tries to replicate this user's password to its database from a full DC. Whether or not it works depends on the group membership.
- The next time this user logs on, the process described begins again.
Step 5: Use Managed Service Accounts
The managed service accounts are an innovation since Windows Server 2008 R2 and have been significantly improved in Windows Server 2012 R2. A service account is a user account that is created to run a particular service or software. In Windows Server 2016, the managed service accounts still work somewhat like in Windows Server 2012 R2. Administrators can use a managed service account for multiple servers. To this end, Microsoft has developed the grouped managed service accounts (gMSA) for the already managed service accounts (MSA). Administrators can manage the managed service accounts in Power Shell. The Freeware Managed Service Accounts GUI creates much easier managed service accounts in Windows Server 2016.