festus94
Goto Top

DC via JEA-Rolle promoten

Hallo zusammen,

ich habe mich in der letzten Zeit mit dem Thema Just Enough Administration unter Windows Server 2016 beschäftigt. Wir haben im Unternehmen ein paar Anwendungsfällt, bei denen wir das Feature nutzen möchten. Das klappt soweit auch wunderbar – bis auf eine Ausnahme.

Einer dieser Anwendungsfälle ist das Promoten von Servern zu Domänen-Controllern. Das ist meines Wissens nach die einzige Aktion, die man im AD verständlicherweise nicht einfach delegieren kann. Wir haben aber den Bedarf, diese Aktion an Administratoren zu delegieren, die keine Domänen-Admin-Rechte besitzen (sollen).

Ich habe in unserer Testumgebung jetzt eine neue JEA-Rolle auf einem Domänen-Controller angelegt.

Session Configuration
@{

# Version number of the schema used for this document
SchemaVersion = '2.0.0.0'  

# ID used to uniquely identify this document
GUID = '4fa7e5d9-0fa7-49f2-959c-751551e1858e'  

# Author of this document
Author = ''  

# Description of the functionality provided by these settings
# Description = '' 

# Session type defaults to apply for this session configuration. Can be 'RestrictedRemoteServer' (recommended), 'Empty', or 'Default' 
SessionType = 'RestrictedRemoteServer'  

# Directory to place session transcripts for this session configuration
TranscriptDirectory = 'C:\ProgramData\JEAConfiguration\Transcripts'  

# Whether to run this session configuration as the machine's (virtual) administrator account 
RunAsVirtualAccount = $true

# Scripts to run when applied to a session
# ScriptsToProcess = 'C:\ConfigData\InitScript1.ps1', 'C:\ConfigData\InitScript2.ps1' 

# User roles (security groups), and the role capabilities that should be applied to them when applied to a session
RoleDefinitions = @{
    'DOMAIN\Gruppe' = @{  
        'RoleCapabilities' = 'ADDCActions' } }  

}

Wenn die Variable "RunAsVirtualAccount" auf $true gesetzt wird und die Rolle auf einem Domänen-Controller genutzt wird, dann wird der virtuelle Account, unter dem gearbeitet wird, Mitglied der Gruppe Domänen-Admins. Das habe ich mit

whoami  /groups

geprüft, und es funktioniert einwandfrei. Nun zur eigentlichen Aktion:

Role Capabilities
@{

# ID used to uniquely identify this document
GUID = '828f39b1-7db3-418c-8fac-38dd429d86c4'  

# Author of this document
Author = ''  

# Description of the functionality provided by these settings
Description = ''  

# Company associated with this document
CompanyName = ''  

# Copyright statement for this document
Copyright = ''  

# Modules to import when applied to a session
# ModulesToImport = 'MyCustomModule', @{ ModuleName = 'MyCustomModule'; ModuleVersion = '1.0.0.0'; GUID = '4d30d5f0-cb16-4898-812d-f20a6c596bdf' } 

# Aliases to make visible when applied to a session
# VisibleAliases = 'Item1', 'Item2' 

# Cmdlets to make visible when applied to a session
# VisibleCmdlets = 'Invoke-Cmdlet1', @{ Name = 'Invoke-Cmdlet2'; Parameters = @{ Name = 'Parameter1'; ValidateSet = 'Item1', 'Item2' }, @{ Name = 'Parameter2'; ValidatePattern = 'L*' } } 

# Functions to make visible when applied to a session
# VisibleFunctions = 'Promote-Server' 

# External commands (scripts and applications) to make visible when applied to a session
VisibleExternalCommands = 'C:\Windows\system32\whoami.exe'  

# Providers to make visible when applied to a session
# VisibleProviders = 'Item1', 'Item2' 

# Scripts to run when applied to a session
# ScriptsToProcess = 'C:\ConfigData\InitScript1.ps1', 'C:\ConfigData\InitScript2.ps1' 

# Aliases to be defined when applied to a session
# AliasDefinitions = @{ Name = 'Alias1'; Value = 'Invoke-Alias1'}, @{ Name = 'Alias2'; Value = 'Invoke-Alias2'} 

# Functions to define when applied to a session
FunctionDefinitions = @{ Name = 'Promote-Server'; ScriptBlock = {  
        $SecureString = ConvertTo-SecureString -String "LocalAdminPassword" -AsPlainText -Force  
        $LocalAdmin = New-Object System.Management.Automation.PSCredential("SERVER\Administrator", $SecureString)  
        
        Invoke-Command -ComputerName "SERVER" -ScriptBlock {  
                Install-ADDSDomainController -DomainName "Domain.tld" -SafeModeAdministratorPassword ("SMAPWD" | ConvertTo-SecureString -AsPlainText -Force) -Force  
        } -Credential $LocalAdmin
} }

# Variables to define when applied to a session
# VariableDefinitions = @{ Name = 'Variable1'; Value = { 'Dynamic' + 'InitialValue' } }, @{ Name = 'Variable2'; Value = 'StaticInitialValue' } 

# Environment variables to define when applied to a session
# EnvironmentVariables = @{ Variable1 = 'Value1'; Variable2 = 'Value2' } 

# Type files (.ps1xml) to load when applied to a session
# TypesToProcess = 'C:\ConfigData\MyTypes.ps1xml', 'C:\ConfigData\OtherTypes.ps1xml' 

# Format files (.ps1xml) to load when applied to a session
# FormatsToProcess = 'C:\ConfigData\MyFormats.ps1xml', 'C:\ConfigData\OtherFormats.ps1xml' 

# Assemblies to load when applied to a session
# AssembliesToLoad = 'System.Web', 'System.OtherAssembly, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' 

}

Die eigentliche Logik funktioniert auch wunderbar. Ich öffne eine PowerShell-Sitzung auf dem Domänen-Controller mit der Session Configuration und führe die Funktion

Promote-Server

aus. Das Problem ist jetzt, dass der virtuelle Account mit Domänen-Admin-Rechten, der nur zur Laufzeit au dem DC existiert, auf dem dem zu promotenden Server nicht bekannt ist. Dementsprechend funktioniert das Promoten nicht. Zumindest ist das meiner Meinung nach das Problem.

Fehler
fehler

Habt ihr eine Idee, wie ich das Ganze anders bauen könnte, oder habt ihr das ggf. selbst schon mal gemacht? Danke für euren Input. face-smile

Viele Grüße

Festus94

Content-Key: 1508006852

Url: https://administrator.de/contentid/1508006852

Printed on: April 19, 2024 at 13:04 o'clock

Member: Th0mKa
Th0mKa Nov 16, 2021 at 10:15:17 (UTC)
Goto Top
Moin,

der virtuelle Account ist wie du schon festgestellt hast auf genau diesen Domain Controller beschränkt. Du könntest gucken ob du das ganze stattdessen mit einem gMSA-Konto umsetzen kannst, das ist auf beliebigen Domain Computern verfügbar. Problem dabei ist die Nachverfolgbarkeit, du kannst dann nur im Transcript sehen wer wann was gemacht hat.

/Thomas
Member: Festus94
Festus94 Nov 16, 2021 at 13:44:46 (UTC)
Goto Top
Hi @Th0mKa,

danke für deine Rückmeldung. Den Gedanken hatte ich auch, aber dieser Account müsste dann dauerhaft Domänen-Admin-Rechte haben, was ich nicht möchte. Und den Account auf allen Servern verfügbar machen, möchte ich auch nicht. Wir sind gerade dabei, von so Superadmins wegzukommen, die einfach überall alles dürfen. Und ich möchte generell keine Service Accounts mehr haben, die Domänen-Admin sind.

Ist zwar ambitioniert, aber wir sind schon fast da. face-smile Trotzdem danke für deine Antwort.

Viele Grüße
Member: Festus94
Festus94 Dec 03, 2021 at 11:44:53 (UTC)
Goto Top
Hat sonst niemand eine Idee? face-smile
Member: noob73
noob73 Feb 11, 2022 updated at 13:30:58 (UTC)
Goto Top
Zitat von @Festus94:

Hat sonst niemand eine Idee? face-smile

Falls es noch aktuell ist mit Deinem Problem:

Ja, die ist allerdings mit etwas Aufwand verbunden aber ähnlich gelagertface-wink

Stehe auch vor der Aufgabe diverse SuperAdmins Ihre überprivilegierten Rechte zu entziehen. Ist zwar noch nicht vollständig umgesetzt sieht aber in etwa so aus:

Ich bau mir einen JEA-Endpoint in dem ich nur Proxy-Funktionen implementiere.
Über diesen JEA-Endpoint den nur ausgewählte AD-User einer bestimmten Gruppe Invoken dürfen füge ich ebenfalls vordefinierten Gruppen (unsere Server-Admins, Server-RDP-User, wenn nötig Domänen-, Enterprise- und Schema-Admins") darüber die notwendigen User zu.

Mit einer Besonderheit. Die User müssen ja nicht 24/7 Mitglieder dieser Gruppe sein. Deshalb hab ich die Möglichkeit der Time-Based-Groups in Betracht gezogen. Erfordert lediglich einen FFL/DFL 2016 und die Aktivierung des optionalen AD Features "Privilege Access Management". Ab da besteht die Möglichkeit User Gruppen auf Zeit zuzuordnen. Die Mitgliedschaft innerhalb der Gruppe wird über einen TTL-Wert gesteuert und die Service-Tickets dieser User werden dann vom KDC nur noch über die Dauer des definierten TTL ausgestellt.
Läuft die TTL ab, verschwindet der User automatisch aus der Gruppe =)

Geiler geht´s nicht, muss nur selbst gebaut werden. Microsoft stellt halt nur die Mittel via Powershell zu Verfügung.

Endziel soll sein, dass via GUI zu unterstützen. Somit kann dann ein unprivilegiertes Konto über den JEA-Endpoint die User auf Zeit zuordnen. Und die Proxyfunktionen benötigt man halt deshalb, weil man mit der eigentlichen Funktion Add-ADGroupmember die User ja auch prinzipiell ohne Zeitfaktor hinzufügen könnte.

Für Deinen Zweck bedeutet dies, der GMSA den du zum Promoten des DCs benötigst wäre tatsächlich nur über den definierten Zeitraum Mitglied der Gruppe "Domänen-Admins"

Ist nur eine Idee =)

Guggst Du:
https://secureidentity.se/time-based-groups/
Member: Festus94
Festus94 Feb 12, 2022 at 10:46:23 (UTC)
Goto Top
Hi @noob73,

das Thema ist tatsächlich noch offen, allerdings ist es in der Prio etwas nach hinten gerückt. Ich kenne die Funktion, die du beschreibst. Das zielt ja alles auf das Thema JIT ab.

Das Problem bei der Methode ist aber, dass ich dann für z. B. eine Stunde einen Domänen-Admin habe, mit dem ja auf allen möglichen anderen Servern beliebige Aktionen ausgeführt werden können. Auch bei der Verwendung eines GMSAs, denn Domänen-Controller können diese Konten pauschal nutzen, und der Mechanismus, über den ich die zu promotenden Server zur Nutzung des Accounts berechtigen müsste, könnte ja auch von anderen einfach missbraucht werden. Genau deshalb möchte ich die Gruppenmitgliedschaft vermeiden und eher delegieren.

Trotzdem vielen Dank und ein schönes Wochenende. face-smile