In Part 1 of this article series measures have already been presented to improve the security of the Active Directory. The next articles are now dedicated to the implementation of these measures within an existing Active Directory using an example environment. This article first deals with the Admin Host.
Introduction
The fictitious company "FrankysWebLab" can serve as an example here. Let's assume that this fictitious company has an administrator who takes care of the operation of its own IT infrastructure. The fictitious company therefore has a few servers and clients. Typically, the company "FrankysWebLab" has the following IT systems:
- Domain Controller
- FileServer
- Database server
- Exchange Server
- Windows clients (PC and notebooks)
Perhaps also a few more servers/services and clients.
I had originally planned to start with the Admin Tier model, but I think it makes more sense to start with the Admin Host first. The Admin Tier model will be covered in the next article.
Installation Admin Host
An admin host should be installed from a "clean medium", i.e. no ready-made image or similar should be used. Installing from a clean medium is important because, for example, settings have already been applied in templates for virtual machines and other software may also have been installed. If you install the Admin Hosts from scratch, you know exactly which software will be installed and which settings will be applied.
After installing the operating system (I am using Windows Server 2019 in this case, Windows 10 is of course also OK), the remote desktop protocol is first activated and remote administration is deactivated. The admin host is not added to the Active Directory:
Two new user accounts can then be created, an administrative user (AHAdmin) and a user that is used to connect to the Admin Host via RDP (AHUser). Secure passwords must be used for both users:
The user AHAdmin receives local administrator authorizations:
The user AHUser remains a normal user, but receives RDP rights:
You can now log in with the "AHAdmin" account and deactivate the "Administrator" account:
With the user AHAdmin, the "Microsoft Security Baseline" can now be applied, which sets some basic settings for the security of the operating system. To apply the Security Baseline, the Security Compliance Toolkit (depending on the operating system) and the LGPO tool are required. Both can be downloaded here:
Note: The downloads are of course not carried out on the admin host.
The ZIP archive with the security baseline is transferred to the admin host and unpacked. The "Local_Script" folder can then be found in the folder in which the archive was unpacked:
In this folder you will find the "Tools" folder. The LGPO archive is now unpacked here:
The baseline can now be applied in the PowerShell. In my case with the parameter "WS2019NonDomainJoined", if Windows 10 is used as the operating system, the parameter "Win10NonDomainJoined" can be used:
The Windows firewall can now be adjusted. To do this, the local security policy is first adjusted so that outgoing connections are also blocked, so you can easily control which network traffic is allowed:
The firewall rules can now be configured. I have initially removed all incoming and outgoing rules here. This means that no connections to the admin host are possible for the time being, so the rules must be deleted via the console or VM console.
Only two rules are actually required for incoming connections, Ping and Remote Desktop. These two rules can be additionally restricted so that connections to the admin host are only possible from certain subnets or IPs:
More rules may be required for outgoing connections as shown here. However, at least DNS, RDP and Ping should be allowed. If additional tools are installed on the admin host, the outgoing rules must be extended accordingly. These rules can also be adapted to specific target networks or IPs:
If management websites need to be accessed, an additional rule can be created for HTTP traffic. However, this should always be restricted to the internal network:
The Windows firewall is now used to control which computer (or which network) can connect to the admin host and where the admin host can connect to.
Note: Rules such as Any-Any-Any are strictly forbidden here. Just like surfing the Internet, only what is required for administration is permitted here. No AD membership, no centrally managed virus scanner, no centrally managed backup software, etc. Rules for Windows updates can be prepared and only activated if the system is also updated.
Once the Windows firewall has been configured, unnecessary Windows services can be switched off. There are usually numerous services here that are not used on an admin host. It is therefore advisable to go through all Windows services once and stop and deactivate unnecessary services:
In addition to the measures mentioned, other settings are useful, such as disconnecting and logging off the RDP connections after XX minutes of idle time. Saving passwords should also be prohibited. Everyone should decide for themselves to what extent these settings make sense.
Once the Admin Host has been configured, it is easy to use. An RDP connection is established from your own workstation to the Admin Host with the user AHUser. A privileged RDP connection to the target system is now established within the RDP session to the Admin Host. The admin host therefore serves as a secure jump system to the actual target:
The normal workstation may no longer be used for administrative purposes. It also makes sense to install different admin hosts for the different admin tiers.