Scroll Top

SmartCard-Logon – Teil 3 – Bastion Forest

Martin Handel

SmartCard-Logon with YubiKey 5 NFC + AMA + Bastion Forest

Smart Card Logon in Verbindung mit AMA (Authentication Mechanism Assurance) ist, wie bereits gesehen, deutlich sicherer als Smart Card Logon alleine.

AMA-Grenzen: Beispiel 1 – Exchange On-Premises

AMA kommt meist bei Produkten mit einem eigenen RBAC (role based access control) rasch an seine Grenze. Als Beispiel sei hier der On-Premises Exchange 2019 CU12 genannt.

Der Exchange 2019 verfügt über eine interne Rolle mit dem Namen “Organization Management”:

Members of this management role group have permissions to manage Exchange objects and their properties in the Exchange organization. Members can also delegate role groups and management roles in the organization. […

Sowas wie die “Enterprise Admins” im Active Directory.

Ein Exchange-Admin mit Smart Card-AMA würde jetzt wie folgt aufgebaut sein:

User (CH\mhandl-ExAdm) ⇒ Smart Card (YubiKey 5 NFC) ⇒ Zertifikat mit Issuing Policy (V4.SmartcardExAdm) ⇒ AMA-Gruppe (AMA_Ex_OrgAdms) ⇒ “Organization Management”

Das Blöde: die Exchange-Organisation schaut nach, ob der User (hier: CH\mhandl-ExAdm) in der AMA-Gruppe Mitglied ist.

Ist er nicht. Ist er nie!

Dann sagt der Exchange “no”.

AMA-Grenzen: Beispiel 2 – “Domain Admins”

Eine weitere Grenze für AMA ist an die AMA-Gruppe gekoppelt; diese muss immer eine leere, universale Gruppe sein. Die Gruppenarten domänenlokal und global sind für AMA nicht geeignet.

Universale Gruppen (universal groups) wurde mit Active Directory 2000 vorgestellt und waren zu beginn ein Werk des Teufels. Diese Annahme war darin begründet, dass universale Gruppen inkl. deren Mitglieder im globalen Katalog gehalten werden. Der globale Katalog wiederum wird im ganzen Wald (forest) repliziert. Änderte man jetzt nur eine Mitgliedschaft einer universalen Gruppen (zum Beispiel ein User rein oder ein Computer raus), dann wurde die ganze Gruppe inklusive der vollständigen Liste der aktuellen Mitglieder im gesamten Wald repliziert. Jedes aber wohlgemerkt zu Zeiten von Analog-Modem-Verbindungen (56 kbit/Sekunde), ISDN-Strecken (128 kbit/Sekunde – bei Kanalbündelung) und sehr, sehr teuren Breitband-Verdingungen wie T1 (1,554 Mbit/Sekunde).

Das ist aber hier nicht der Punkt. Der Punkt ist: in welche Gruppen kann eine universelle Gruppe aufgenommen werden?

  1. andere universelle Gruppen des gleichen Waldes
  2. andere domänenlokale (domain local) Gruppen des gleichen Waldes oder einer vertrauenden Struktur

Ende.

Es gibt nicht die Möglichkeit, eine universelle Gruppe einer globalen Gruppe des gleichen Waldes / der gleichen Domäne hinzuzufügen.

So haben wir, beispielsweise, eine Gruppe mit dem Namen AMA_DomainAdmins (leere, universelle Gruppe) und möchten via AMA die Aufgaben der Domänen-Administration übernehmen:

  1. AMA_DomainAdmins ⇒ “Administrators (Built-in)” / “Administratoren (Build-in)”: geht (die Mitgliedschaft in den Built-in domain local groups wird bei “whoami.exe /groups” nicht angezeigt)
  2. AMA_DomainAdmins ⇒ “Enterprise Admins” / “Organisations-Administratoren”: geht
  3. AMA_DomainAdmins ⇒ “Schema Admins” / “Schema-Administratoren”: geht
  4. AMA_DomainAdmins ⇒ “Domain Admins” / “Domänen-Administratoren”: geht nicht!
  5. AMA_DomainAdmins ⇒ “Group Policy Creator Owner” / “Gruppenrichtlinien Ersteller-Besitzer”: geht nicht!

Na und? Mir doch egal!

Nein, ist es nicht! So kann ein AMA_DomainAdmin keinen DC hochstufen!

Die Setup-Routine beim Hochstufen prüft, ob man in der Gruppe -512 (Domain Admins) Mitglied ist.

Bin ich nicht, werde ich auch nie sein. Demzufolge geht das Hochstufen nicht.

Der Computer sagt “no”.

Bastion Forest oder auch Red Forest genannt

In beiden Szenarien hilft, obwohl beide Szenarien unterschiedliche technische Ursachen haben, ein sogenannter Bastion- oder auch Red Forest. Das Konzept eines Bastion Forest (kurz BF) wurde im Jahr 2015 begründet und galt damals als eine Antwort auf die Problematik mit Golden Ticket / Silver Ticket / Pass-the-Hash / Pass-the-Ticket.

Kurz umrissen: bei einem BF werden die ganzen sensiblen Konten (T0 und T1, manchmal auch T2) in einen extra Wald, eben dem Bastion Forest, ausgelagert. Die produktive AD-Struktur, hier kurz Golden Forest (GF) genannt, vertraut diesem neuen Bastion Forest.

Einseitig, ausgehend als Forest trust.

Der Vater des Gedanken war somit: neuer Wald = nicht kompromittiert. Dieser neue Wald wird mit Produktaktualisierungen (vulgo Patches) versorgt und nach Standard-ESAE gehärtet. Dann wird ein, aus Sicht des BF, eingehender Forest-Trust von dem GF erstellt. Dieser Trust wird auf der Seite des GF als “PIM-Trust” konfiguriert und der BF aktiviert noch die AES-Verschlüsselung für die Vertrauensstellung.

Ganz nebenbei: ESAE, Red Forest und das was gleich kommt ist schon länger seitens Microsoft “retired”.

Lesenswert ist das “Kleingedruckte”:

…] While Microsoft no longer recommends an isolated hardened forest model for most scenarios at most organizations, Microsoft still operates a similar architecture internally (and associated support processes and personnel) because of the extreme security requirements for providing trusted cloud services to organizations around the globe. […

Ah, ja. “Ihr: nein, wir: ja!”

Das Exchange-Problem (in der Theorie)

Das Exchange-Problem wird durch sogenannte “linked role groups” gelöst. Diese benötigen zwar keinen PIM-Trust, jedoch einen extra Wald. Somit ist es naheliegend das administrative Problem bei Exchange über den Bastion Forest in Verbindung mit AMA zu lösen.

Die Vorgehensweise:

  1. Es wird im BF eine (leere), universelle Gruppe angelegt.
  2. Die gewünschte Rollenmodellierung wird erstellt (in der Regel werden die Rollen der vordefinierten Rollengruppe “Organization Management” einfach kopiert)
  3. Im GF wird dann einen neue Rollengruppe auf Basis der Rollenmodellierung erstellt und mit der SID der (leeren), universellen Gruppe aus dem BF konnotiert.

Weil wir es jetzt auf der Seite des BF mit einer leeren, universellen Gruppe zu tun haben, liegt die Vermutung sehr nahe, dass man hier AMA einsetzen kann.

Das “Domain Admins”-Problem (in der Theorie)

Das “Domain Admins”-Problem wird durch sogenannte “ShadowPrincipals” gelöst. ShadowPrincipals benötigen nicht nur einen neuen Wald, sondern die Vertrauensstellung muss in der Qualität eines “PIM-Trust” vorliegen. Ein ShadowPrincipal ist ein eigenes Objekt, welches in der Configuration des BF gespeichert wird. Dieses Objekt verfügt, unter anderem, über ein Attribut mit dem Namen “msDS-ShadowPrincipalSID”. In dieses Attribut wird einfach die vollständige SID einer Referenzgruppe aus dem GF geschrieben, beispielsweise die ObjectSID der Gruppe der “Domain Admins”.

Weiterführend verfügt ein ShadowPrincipal über das Attribut “Member”, welches genauso arbeitet wie bei einer Gruppe. Bedeutet also: ich erstelle einen solchen ShadowPrincipal, schreibe die vollständige SID einer Referenzgruppe in das Attribut “msDS-ShadowPrincipalSID” und füge Mitglieder zu diesem ShadowPrincipal hinzu. Ein geeignetes Mitglied wäre zum Beispiel eine leere, universelle Gruppe.

Die Vorgehensweise:

  1. Ein ShadowPrincipal wird im BF generiert
  2. Diesem ShadowPrincipal wird eine leere, universelle Gruppe als Mitglied hinzugefügt.

Bei dieser leeren, universellen Gruppe, welche Mitglied im ShadowPrincipal ist, handelt es sich natürlich um eine AMA-Gruppe.

PIM-Trust, ShadowPrincipal und linked role group

Das Erstellen des Bastion Forest unterscheidet sich nicht der Erstellung eines ganz normalen Forests. Direkt nach der Erstellung des Waldes durchläuft der BF die üblichen Härtungsmaßnahmen für Active Directory und zwischen dem Golden Forest und dem Bastion Forest wird die Namensauflösung via DNS etabliert. Sobald die Namensauflösung steht kann die Vertrauensstellung (einseitiger Forest-Trust, wobei GF dem BF vertraut) erstellt werden.

Diese Schritte dokumentiere ich an dieser Stelle nicht.

Wir steigen daher ein beim

PIM-Trust

Der sogenannte PIM-Trust setzt bei einer gesamstrukturübergreifenden Vertrauensstellung (Forest Trust) im Attribut “trustAttributes” die Bitwertigkeit 1024. Das Flag “PIM-Trust” aktiviert eigentlich einen PAM-Trust.

PAM is based on new capabilities in AD DS, particularly for domain account authentication and authorization, and new capabilities in Microsoft Identity Manager. PAM separates privileged accounts from an existing Active Directory environment. When a privileged account needs to be used, it first needs to be requested, and then approved. After approval, the privileged account is given permission via a foreign principal group in a new bastion forest rather than in the current forest of the user or application. The use of a bastion forest gives the organization greater control, such as when a user can be a member of a privileged group, and how the user needs to authenticate.

Ob das jetzt PIM-Trust oder PAM-Trust heißt, sei dahingestellt.

Wenn die Vertrauensstellung vorhanden ist, müssen auf der GF-Seite (hier: cloud-hybrid.de) drei Befehle abgesetzt werden:

  • netdom.exe trust cloud-hybrid.de /domain:red-cloud-hybrid.de /enablepimtrust:yes /userd:Administrator /passwordd:*
  • netdom.exe trust cloud-hybrid.de /domain:red-cloud-hybrid.de /quarantine:no /userd:Administrator /passwordd:*
  • netdom.exe trust cloud-hybrid.de /domain:red-cloud-hybrid.de /enablesidHistory:yes /userd:Administrator /passwordd:*

PAM-Feature, ShadowPrincipals und AMA-Gruppe

Das PAM-Feature und die ShadowPrincipals sind “nur” für den Zugriff durch Domain Admins notwendig (siehe Problem-Beispiel 2). Damit der User in den Genuß des ShadowPrincipals kommt muss hierzu eine AMA-Gruppe erstellt werden und in die Member des ShadowPrincipals aufgenommen werden.

  1. PAM-Feature aktivieren: im BF Enable-ADOptionalFeature ‘Privileged Access Management Feature’ -Target red-cloud-hybrid.de -Scope ForestOrConfigurationSet -Confirm:$false
  2. ShadowPrincipal erstellen: im BF $SID = (Get-ADGroup -Identity “Domain Admins” -Server de-vdc01.cloud-hybrid.de).sid.value; New-ADObject -Name CH_DomAdmins -Path “CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=RED-CLOUD-HYBRID,DC=DE” -Type ‘msDS-ShadowPrincipal’ -OtherAttributes @{ ‘msDS-ShadowPrincipalSID’=$SID }
  3. die Gruppe AMA_DomAdmins in den ShadowPrincipal als Member aufnehmen.

linked role group erstellen

Das Erstellen einer linked role group führt uns zu einer leeren, universellen Gruppe (aka AMA-Gruppe), die vorab im BF erstellt wird.

Die nachfolgenden Schritte erfolgen auf der Seite des Golden Forest (hier: cloud-hybrid.de) innerhalt der Exchange PowerShell.

$RCHCred = Get-Credential -Credential RCH\Administrator
$OrgMgmt = Get-RoleGroup -Identity "Organization Management"
New-RoleGroup -Name "RCH-RG" -LinkedForeignGroup "AMA_ExOrgAdmin" -LinkedDomainController rch-vdc01.red-cloud-hybrid.de -LinkedCredential $RCHCred -Roles $OrgMgmt.Roles

Das letzte Bild der Gallerie zeigt die AMA-Gruppe im BF mit der Verknüpfung zu Issuance Policy

RootCA und NTAuth

Jetzt kommt leider ein kleines strukturelles Problem auf uns zu: das Vertrauen zur RootCA und NTAuth.

Die Struktur cloud-hybrid.de muss noch den Zertifikate aus red-cloud-hybrid.de vertrauen; das löst man am einfachsten mit certutil.exe, in dem man das Root-Zertifikat in den Enterprise Root-Store importiert.  Die Default Domain Policy (!) sorgt dafür, dass das Vertrauen auf die djd (domain joined devices, im Vergleich zu hjd (hybrid joined device) und ejd (entra joined device)) kommt.

Was ist aber NTAuth?

NTAuth ist der Enterprise NT Authentication Store. Bedeutet hier liegt das Vertrauen zu CAs, welche Authentifizierungszertifikate ausstellen. Die RCH-SUBCA (red-cloud-hybrid-subca) fehlt hier. Der Import erfolgt unspektaktulär über certutil.exe.

Die nachfolgenden Schritte erfolgen im GF:

  1. certutil.exe -dspublish -f c:\rch-rootca.cer RootCA
  2. certutil.exe -dspublish -f c:\rch-subca.cer NTAuthCA

Smart Card-Zertifikat mit AMA austellen

Es fehlt der Schlussstein: das Smart Card-Zertifikat mit AMA für den jeweiligen User, der sich als “Domain Admin” und “Exchange OrgAdmin” verdingt.

Zwei AMA-Gruppen in einem Zertifikat?

Ja, zwei AMA-Gruppen in einem Zertifikat!

Wie?

Das ist einfach: zwei Issuance Policies in der Zertifikatsvorlage.

Proof of Concept

Der User RCH\CHT0-mhandl verfügt nun über ein Smart Card-Logon-Zertifikat auf seinem YubiKey 5 NFC.

Das Smart Card-Logon-Zertifikat enthält zwei Issuance Policies:

  1. CHExOrgAdminIP: dieses Issuance Policy ist mit der linked role group (AMA_ExOrgAdmin) verbunden, welche zugleich als AMA-Gruppe fungiert.
  2. CHDomAdminIP: dieses Issuance Policy ist mit einer AMA-Gruppe verbunden (AMA_DomAdmins). Diese AMA-Gruppe ist wiederum Mitglied in dem ShadowPrincipal CH_DomAdmins. Der ShadowPrincipal CH_DomAdmins ist eine Referenz der “CH\Domain Admins”

Langer Rede kurzer Sinn: wenn sich RCH\CHT0-mhandl mit der Smart Card anmeldet und über den Forest Trust hinweg sich mit den CLOUD-HYBRID.DE-Ressourcen (Active Directory und Exchange) verbindet, ist RCH\CHT0-mhandl “CH\Domain Admin” und “RCH-OrgAdmin” (RCH-OrgAdmin ist eine Kopie der “Organizational Admins” im Exchange).

Wie arbeite ich eigentlich vom Bastion Forest aus?

Da gibt es mehrere Ansätze, alle haben so ihr für und wider.

Remote Procedure Calls (RPC)

Das Arbeiten mit den meisten RSAT (Remote Server Administration Tools) erfolgt per RPC. RPC verlangt eine “recht ordentliches Loch” in der Firewall:

  • TCP 135 (end point mapper)
  • TCP 49152 – 65535 (RPC range)

Das mag nicht immer auf Gegenliebe seites der Netzwerker stoßen.

PowerShell-Remoting & Windows-Remoting

Windows- und PowerShell-Remoting können vieles, aber nicht alles, abwickeln. Die Portzuweisung ist “etwas” kleiner als bei RPC:

  • TCP 5985 (nativ ohne Zertifikat)
  • TCP 5986 (mit Zertifikat)
Active Directory Web Services (ADWS)

ADWS ist die SOAP-Schnittstelle für die Windows PowerShell mit ihrem Modul ActiveDirectory. Die Postzuweisung ist einfach:

  • TCP 9389
Remote Desktop Protocoll (RDP)

RDP ist vermutlich die gängiste Variante um auf Serversysteme administrativ zuzugreifen (wobei ich diese absolut nicht präferiere).

  • TCP 3389
  • UDP 3389

Aber nun zurück zu unserem RCH\CHT0-mhandl:

Beispiel 1: Exchange per RDP

Bei Exchange sollte die ECP-Seite noch auf SSO umgestellt werden, analog zur OWA. OWA und ECP sollten ohnehin nicht mehr zum Internet exponiert werden.

Set-OwaVirtualDirectory -Identity "de-vex01\OWA (Default Web Site)" -FormsAuthentication $false -WindowsAuthentication $true
Set-EcpVirtualDirectory -Identity "de-vex01\OWA (Default Web Site)" -FormsAuthentication $false -WindowsAuthentication $true

Beispiel 2: Active Directory Users and Computers per RPC

Schlussworte

Bei einem Golden Forest wird der Aufwand für den Betrieb Bastion Forest etwas zu groß sein. Hier stimmt das Verhältnis nicht mehr, zwischen Sicherheitszugewinn und notwendigem Mehraufwand.

Die Stärke des Bastion Forest liegt in seiner Skalierfähigkeit. Wenn ich beispielsweise einen Resource Forest (Exchange, SharePoint, etc) habe, einen oder mehrere Golden Forests (User, Computer, basische IT Services wie File und Print) zu verwalten habe, dann kommt der BF zum Tragen.

Der BF schöpft seine Stärke aus dem Smart Card Logon im Zusammenspiel mit AMA. Zusätzlich kommt hinzu, dass durch linked role groups und ShadowPrincipals aus Sicht des Golden Forests ein Aufklären für einen Angreifer sehr schwer ist. Selbst wenn erfolgreich aufgeklärt wurde, macht AMA im Kombination mit der physischen Smart Card eine Kompromittierung sehr, sehr schwer.

Related Posts