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
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
geprüft, und es funktioniert einwandfrei. Nun zur eigentlichen Aktion:
Role Capabilities
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
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
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.
Viele Grüße
Festus94
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
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.
Viele Grüße
Festus94
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1508006852
Url: https://administrator.de/contentid/1508006852
Ausgedruckt am: 21.11.2024 um 22:11 Uhr
5 Kommentare
Neuester Kommentar
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
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
Falls es noch aktuell ist mit Deinem Problem:
Ja, die ist allerdings mit etwas Aufwand verbunden aber ähnlich gelagert
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/