ADMIN
Nuts and Bolts Active Directory Security Lead image: Lead Image © Mykola Velychko, Fotolia.com
Lead Image © Mykola Velychko, Fotolia.com
 

Focusing on security in Active Directory

Externally Sealed Off

To prevent an intruder attack in Active Directory, Windows Server's security features along with freeware monitoring can save the day. By Thomas Joos

Active Directory (AD) environments are often the focus of attackers. As soon as malware can access credentials on a domain member PC, the entire AD is at risk of being taken over. In particular, privileged user and administrator accounts are under fire. In this article, I apply best practices to demonstrate how you can increase security in the Microsoft directory service.

For optimal AD security, small and medium-sized companies should position themselves as enterprise environments, which, in most cases, have access to significantly more resources for securing their IT infrastructure. Microsoft itself provides detailed instructions for securing its directory service [1].

Inquisitive Intruders

An attacker usually enters a network through a single endpoint, such as an insecure PC, server, router, or other network device. Once this endpoint has been taken over, the criminal must familiarize himself with the network, because only with sufficient information can the intruder efficiently spy on the rest of the network or carry out further attacks. This spying is also called reconnaissance, or recon.

Locating administrator accounts in the network is an important step in this process. By using a pass-the-hash (PtH) attack, for example, an attacker can access the network and privileged user accounts with the rights of the transferred account and do damage to the network almost completely unobserved.

Dangerous PtH Attacks

Pass-the-hash attacks are targeted directly at AD user accounts; those with privileged rights are particularly interesting, of course, and can be administrator or user accounts that have the right to change user passwords, for example. With changes to the user account, attackers gain access rights other than PtH. PtH attacks are based not only on user passwords, but also on the hashes that are assigned to a user account after authentication. Simply put, they are tickets into AD.

As soon as an attacker detects a user account in AD or the user administration of a server, they can try to gain access to a hash of the account with PtH attacks, even without knowing the password. The process does not aim to hack passwords or decrypt the hash. Attackers want to take over the original hash and use the rights of the corresponding account. If this succeeds, an attacker can easily act with admin rights in the network, even without knowing the account password.

This is particularly serious in single sign-on (SSO) environments. If configured appropriately, an attacker can not only use the hash to cause damage to the local network but can also access other services, such as the cloud. Hybrid environments with Microsoft Azure or Office 365 are particularly at risk.

Allocating Rights Sensibly

Administrator accounts should be used very carefully in AD environments. In doing so, administrators and those responsible in the company should take various things into account. Much is already possible with the standard options in AD. First of all, different administrator accounts should be used for the different server applications in the company. SQL Server administrator accounts should not be used for Exchange or AD management. If such an account is compromised, all other server services are also in danger.

But it also makes sense to work with different accounts within the Windows Server standard services. Windows Server offers different user groups that are available by default. These standard groups are important in the root domain, especially in overall structures:

The groups DnsUpdateProxy, Enterprise Admins, Schema Admins, and DnsAdmins are defined in the first domain set up in an AD forest and is also the topmost domain of the first structure of the forest. You can add users and user groups from different domains of the forest to a group.

Cautious Use of Administrator Account

For secure AD environments, it makes sense to limit the use of accounts with increased privileges as much as possible. You should only log in with the administrator account that is set up for the respective server service. If a workstation is suspected of being compromised or insecure, it is highly advisable not to 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. In other words, the administrator workstations tasked with managing the environment should not be connected to the Internet.

In general, it is better to work with normal user accounts rather than administrator accounts by default anyway. The administration of the environment should be done at special workstations that are exclusively for administration purposes. The Log on as … rights are not recommended in secure environments, because the logon data is stored temporarily on the computer. Particularly secure administrator workstations should therefore only be used for administrative work. Administrator's should use a different workstation for nonadministrative work.

An added advantage of this division is that only the programs required for administration are installed on the administration workstations, which can be protected by group policies. For example, Microsoft previously offered the Security Compliance Manager [2] to create templates for group policies (Figure 1).

Tools such as Security Compliance Manager (now retired [3]) made it possible to operate AD environments more securely.
Figure 1: Tools such as Security Compliance Manager (now retired [3]) made it possible to operate AD environments more securely.

In principle, it makes sense to use multifactor authentication for the administrator accounts. Moreover, it is advisable to use temporary administrator accounts. In such an infrastructure, administrator accounts only have the right to perform a specific management task for a limited period of time. Once the task has been completed or the time has elapsed, the rights are removed.

Read-Only DCs

In locations where DCs are not located in protected server rooms, read-only domain controllers (RODCs) should be used. RODCs receive the replicated information from the normal DCs and do not accept changes from administrators. Thus, an RODC only receives information and cannot write any information into AD. This feature allows you to run DCs in smaller branch offices, where the DCs are not protected, without compromising a company's security.

An RODC protects AD from password spying. It knows all objects in AD, but only stores the user passwords that you explicitly specify. If such an RODC is stolen and an attacker attempts to read passwords from the controller's database, the accounts of the remaining domain are protected. Writable DCs do not set up a replication connection to RODCs, because a replication can only take place from normal DCs to RODCs. RODCs set up replication connections to the writable DCs that you specify when upgrading.

In the Active Directory Users and Computers snap-in, you right-click the Domain Controllers organizational unit (OU) and select Pre-create Read-only Domain Controller account from the context menu. Then, run the wizard to create a new DC in the data center and assign it a computer account. An administrator can then install this server in the branch office. The server is automatically assigned the function of the RODC.

An RODC offers a complete AD, but without storable passwords, because the associated folder is write protected. When using RODCs, the following procedures apply:

1. A user logs on to the RODC location.

2. The RODC checks whether the user's password has been replicated to the server. If so, the user is logged on.

3. If the password is not available on the RODC, the login request is forwarded to a fully fledged DC.

4. If the registration is successful, a Kerberos ticket is assigned to the RODC.

5. The RODC now issues the user their own Kerberos ticket, with which this user works. Group memberships and group policies are not sent wirelessly. This information remains on the RODC.

6. Next, the RODC tries to replicate this user's password into its database from a DC. Whether or not this succeeds depends on the respective group membership.

7. The process starts again from step 2 the next time the user logs on.

The administrator account passwords in AD are never stored on an RODC. Because of their importance, these passwords are excluded from possibly being replicated to the write-protected DC. If the wireless connection between the branch office with the RODC and a normal DC is lost, no logon takes place at the domain. The RODC then behaves like a normal member server, and only a local logon to the server is possible.

If you install the DNS service on an RODC, the server becomes a read-only DNS server. The same restrictions apply here as for an RODC. A read-only DNS server only accepts changes from normal DNS servers and does not accept any changes itself. A read-only DNS server is available to users as a normal DNS server for queries, but does not support dynamic DNS registration. If a client tries to register, the DNS server will tell it that the update is not accepted. In the background, the client can try to register on a normal DNS server, which then replicates the changes back to the read-only DNS server.

In the event of the theft of an RODC, the administrator must remove the computer account of the stolen DC. A selection window is displayed, which resets the passwords of users and computers replicated on the RODC.

Even if a thief is able to read the data from the RODC, it is worthless, because a reset has been carried out in the meantime. During this process, AD does not delete the user and computer accounts – just the passwords. Additionally, the data not only can be reset, but the wizard has an option to export the accounts.

Securing the DNS System

Microsoft has already introduced Domain Name System Security Extensions (DNSSEC) with Windows Server 2008 R2. Zones can be signed digitally online in Windows Server 2016. DNSSEC can be fully integrated into AD, including the ability to enable dynamic updates for protected zones. Windows Server 2016 supports official standards such as NSEC3 and RSA/SHA-2 for digital signing of DNS zones and also supports DNSSEC on RODCs. If an RODC with Windows Server 2016 finds a signed DNS zone, it automatically creates a secondary copy of the zone and transfers the data from the DNSSEC-protected zone.

Advantageously, branch offices can also resolve data backed up with RODCs without endangering the zone's signature and data. DNSSEC can be created from the zone's context menu, and the zone is signed by an assistant. The wizard allows manual signing, an update of the signing, and a signature according to automatic settings. With Windows Server 2016, signed zones can also be replicated to other DNS servers in the network.

Using Managed Service Accounts

Managed service accounts (MSAs) have been on board since Windows Server 2008 R2 and were significantly improved in Windows Server 2012 R2. In Windows Server 2016, MSAs still work like those in Server 2012 R2; you can use one MSA for multiple servers. To this end, Microsoft has developed Group Managed Service Accounts (gMSAs) for MSAs. You can administrate the MSAs in PowerShell. However, with the Managed Service Accounts GUI [4] freeware, it is much easier to create MSAs in Server 2016 (Figure 2).

The Managed Service Account GUI makes MSA management much easier.
Figure 2: The Managed Service Account GUI makes MSA management much easier.

Group Managed Service Accounts focus on server applications like Exchange and SQL Server. These applications are not only critical for operations, but also for security, because the user accounts that start these services often have extensive rights. In particular, the Local Service, Network Service, and Local System services are often used for server applications, and sometimes even administrator accounts. The disadvantage of local services is the lack of being able to make settings at the domain level. If administrators use AD user accounts instead of these accounts, passwords always must be managed manually. To view the Managed Service Accounts OU and the service accounts created therein, you might have to enable Advanced Features from the View menu in the Active Directory Users and Computers snap-in.

MSAs are user accounts in AD that are used for local services. The passwords of these accounts are not changed manually, but automatically by AD under certain conditions. Administrators can trigger such changes manually. The advantage of this setup is that the system services that use these user accounts do not have to be configured by the administrator when changing passwords; rather, they automatically apply the change of passwords.

The administration of such service accounts can also be delegated to non-administrators (e.g., the database system programmers).

Constantly Checking AD

Changes to AD settings by administrators are rarely noticed. You should therefore subject AD administration tasks to regular monitoring. In addition to professional solutions, free tools can be used in small and medium-sized environments. With the free Netwrix Change Notifier [5] tool, all changes are logged and, if desired, sent by email. In this way, those responsible in the company always have an overview of the changes made, which can be reversed in the event of problems. The advantage of the tool is its very easy setup. You can integrate the freeware into your environment in a few minutes and make all the necessary settings in a GUI.

The free SolarWinds Admin Bundle for Active Directory [6] provides various additional tools to help you display and delete inactive user and computer accounts in AD (Figure 3)and lets you use a CSV file to create multiple users at the same time.

Additional tools find inactive and no longer needed accounts in AD.
Figure 3: Additional tools find inactive and no longer needed accounts in AD.

Conclusions

To improve security in Active Directory, admins have no need for additional expensive tools that are complicated to operate. Microsoft already offers enough security features with the standard tools in Windows Server. Freeware monitoring can also be used in small and medium-sized environments to detect changes. Generally speaking, administrator accounts should always be especially secure.