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.
Hi Franky,
warum sollte eigentlich der Admin-Host kein Domänen-Mitglied sein?
Das ist eine gute Frage. Laut PAW Konzept von Microsoft muss er sogar in die Domäne, da hier GPOs verteilt werden und Windows Updates vom WSUS kommen. Woher bekommt also der Admin Host seine Windows Updates, wenn er doch nie ein Internet sieht!? Und was ein ungepatchtes System bedeutet, ist jedem klar.
Es gibt z.B. eine GPO die es verbietet auf dem Admin Host / PAW die lokale Firewall zu bearbeiten. Also selbst mit dem „AHAdmin“ wäre das nicht möglich. Das wäre ohne Domäne gar nicht möglich.
Ein PAW nach Microsoft ist jedoch eine echt umfangreiche Geschichte und da ist dieser hier gezeigte Admin Host immer noch tausendmal besser, als die Tiering Kennwörter auf der Workstation einzugeben, die sowieso den ganzen Tag vom Admin für Mails, Surfing etc hergenommen wird ;-)
Hallo Frank,
Vielen Dank für die schnelle Antwort. Lokales gpedit gefolgt von gpupdate und Neustart hatte ich als erstes versucht. Leider ohne Erfolg.
LG Roland
Hallo Frank,
danke für die vielen interessanten Themen.
Ich habe versucht der Anteilung zu folgen. So weit ist alles gut und umsetzbar.
Probleme bereitet die Security Compliance auf Windows 10 1909. Wird die angewendet lässt sich der ausgehende Datenverkehr in der Firewall nicht mehr blockieren. Der Schalter steht auf Zulassen und lässt sich weder mit der GUI, netsh, regdit oder powershell ändern.
Hast Du eine Empfehlung?
LG Roland
Hallo Roland,
du kannst Gruppenrichtlinien verwenden um die Einstellungen zu ändern. Alternativ kannst du auch die lokalen Einstellungen via gpedit.msc“ überschreiben.
Gruß,
Frank
Wenn es nur darum geht auf keinem der Tier 1 oder 2 Systemen ein T0-Admin-Kennwort einzugeben könnte man da nicht auch ein günstiges Raspi-System nehmen, sich dort per RDP oder ähnlichem zu verbinden und von dort dann per RDP-Client auf den Server anzumelden? Der Vorteil wäre neben dem sehr günstigen Preis, geringem Stromverbrauch auch noch dass man ein minimales Linux-System verwenden könnte, sicherheitstechnisch vielleicht besser als Windows 10.
Hallo Frank,
sehr interessanter Artikel, den ich auch umsetzen möchte.
Doch dazu habe ich noch eine Frage: Habe das Security Compliance Toolkit fuer Win 2016 Server downgeloadet,
doch leider finde ich in dem Verzeichnis „Local_Scripts“ nicht das BaselineLocalInstall.ps1 Script.
Bei mir sehe ich nur drei Shell-Scripts:
– Client_Install.cmd
– Domain_Controller_Install.cmd
– Member_Server_Install.cmd
Wo finde ich das Powershellscript?
Gruss, Erwin
Moin,
schön das dieses Thema und die Umsetzung in den Artikelserie gezeigt wird.
Ich möchte hier anmerken das ein Sprungsystem „Jump host“ des sicheren Quellen-prinzips „clean source“ widerspricht. Diese Admin Workstation ist auch keine PAW. In diesem hier gezeigten Aufbau wird immer noch das T0 Admin Passwort auf einer T3 Workstation Tastatur (physisch) eingegeben. (Was leicht abgefangen werden kann)
Anderes herum wäre es „richtig/besser“ (laut dem Tier und PAW Konzept): T0 (oder T1…) Admin Workstation: an dieser wird sich mit dem T0 Admin Benutzer angemeldet und von hier aus werden T0 Systeme verwaltet. In z.B. einer virtuellen Maschine auf der T0 Workstation läuft eine T3 Workstation an der man sich mit seinem T3 Benutzer anmeldet um z.B. Mails abzurufen.
Warum wird auf diese Anmerkung nicht eingegangen? Soll man es wie hier beschrieben lieber nicht machen? Es stellt sich mir noch die Frage wieviele Admin Host ich nun wirklich benötige. Bei z.B. 2 Admins wären das 6 Hosts.
Hi,
ich wäre auch entweder bei der Lösung T0 Workstation mit T3 VM, oder zwei Clients und klassisch mit KVM-Switch am Arbeitsplatz umschaltbar. In Anbetracht der aktuellen Situation mit Corona ist das allerdings mit mehreren physischen Geräten so eine Herausforderung, ein virtueller KVM Switch wäre wieder ein Angriffspunkt.
T3 auf T0 hätte man bei Exploits von dem Hypervisor / Guest VM allerdings auch wieder Probleme.
Ich pers. würde deshalb auf 2 Hardware-Clients setzen und diese virtuell im Netzwerk segmentiert zur Administration nutzen. Ebenfalls T0 Clients dem AD joinen und strenge Regeln in Hinblick auf Sicherheit und schnelles OS patchen etablieren.
Deinen Gedankengang kann ich nur allzu gut nachvollziehen.
Es ist ein leichtes, RDP-Credentials mit Tools wie Mimikatz etc. aufzudecken (https://pentestlab.blog/2021/05/24/dumping-rdp-credentials/)
Hallo Frank,
mit interesse verfolge ich die Artikel der Reihe.
Könntest Du eventuell kurz etwas zu den Firewall-Regeln hinzufügen, die Adressbereiche kann ich nirgends finden im Zusammenhang mit der zu Verwaltenden Umgebung.
Du verwendet ja 192.168.200.xxx in dem Beispiel
Gruss,
Michael
Hallo,
wenn ich mir das so alles durchlese fällt mir auf, dass ich dann auf den AdminHosts noch einmal alle T0-, T1- bzw. T2-Admins anlegen muss. Sonst können sie ja nicht Remote darauf bzw. darüber arbeiten.
Oder habe ich da etwas falsch verstanden??
Hallo Cordula,
auf dem Admin Host braucht du keine Tier Konten anlegen. Der Admin Host ist ja nicht Mitglied des ADs. Die Verbindung zum AdminHost via RDP wird mit dem Benutzer AHUser hergestellt. Es macht aber Sinn, mehrere AdminHosts zu installieren, wie viele hängt von der Umgebung ab. Beispielsweise könnte man für jedes Tier einen AdminHost installieren, oder auch für jeden Admin, oder für Jedes Tier und jeden Admin.
Gruß,
Frank
Hi
sehr spannendes Thema und sehr gut erklärt!
Jedoch ergibt sich mir noch nicht ganz, wie ich „Daten“ z.b. die Installationsdateien für vSphere bzw. die Security Baseline auf den Admin Host bekomme. Tatsächlich via USB oder über SMB Freigabe?
Gruß
Heiko
Hallo Heiko,
du kannst in einer RDP-Sitzung auf dem RDP-Server Laufwerke des RDP-Clientrechners verwenden, wenn du diese im RDP-Client zuvor als „Lokale Ressourchen“ aktiviert hast.
VG
Buster
Ich war bisher immer stiller Leser hier. Das Thema ist aber besonders spannend und ich freue mich schon auf die weiteren Artikel. Top Arbeit!
Ein sehr spannendes Thema, nicht nur in Bezug zum gerade aktuellen Emotet Fall bei Heise. Freue mich schon auf den nächsten Teil.
Zum Artikel: Nutzt man den Admin-Host also nicht direkt für die Administration der Server via RSAT oder Admin- Weboberflächen wie Exchange Admin Center, sondern springt auf ein weiteres System, das dann hierfür benutzt wird?
Hi Stefan,
doch der Admin Host kann genau dafür genutzt werden. Wichtig ist in der Firewall dann nur die Admin Oberflächen freizugeben die auch benötigt werden.
Gruß,
Frank
Hallo Frank, Hallo Stefan!
Ich habe drei Admin-Hosts unter Windows 10 2004 eingerichtet und möchte nun auf dem T0-Host die RSAT-Tools verwenden. Der Start eines RSAT-Tools (z.B. DHCP) ist erwartungsgemäß unter dem lokalen User AHUser nicht sinnvoll, da mir dann die Berechtigungen fehlen, um auf den DHCP-Server zuzugreifen. Wenn ich das Tool als anderer Benutzer starten will und hier die Zugangsdaten meines T0-Admins eingebe, erhalte ich immer die Fehlermeldung „Benutzername oder Kennwort ist falsch“.
Können die RSAT-Tools ausschließlich auf den Servern gestartet werden oder wo liegt mein Denkfehler?