JEA-sessieconfiguraties

  • Artikel
  • 9 minuten om te lezen

Een JEA-eindpunt wordt geregistreerd op een systeem door een PowerShell-sessieconfiguratiebestand te maken en te registreren. Sessieconfiguraties definiëren wie het JEA-eindpunt kan gebruiken en tot welke rollen ze toegang hebben. Ze definiëren ook globale instellingen die van toepassing zijn op alle gebruikers van de JEA-sessie.

Een sessieconfiguratiebestand maken

Als u een JEA-eindpunt wilt registreren, moet u opgeven hoe dat eindpunt is geconfigureerd. Er zijn veel opties om rekening mee te houden. De belangrijkste opties zijn:

  • Wie heeft toegang tot het JEA-eindpunt
  • Aan welke rollen ze worden toegewezen
  • Welke identiteit JEA gebruikt onder de dekking
  • De naam van het JEA-eindpunt

Deze opties worden gedefinieerd in een PowerShell-gegevensbestand met een .pssc extensie die bekend staat als een PowerShell-sessieconfiguratiebestand. Het sessieconfiguratiebestand kan worden bewerkt met elke teksteditor.

Voer de volgende opdracht uit om een leeg sjabloonconfiguratiebestand te maken.

New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer -Path .\MyJEAEndpoint.pssc

Tip

Alleen de meest voorkomende configuratieopties zijn standaard opgenomen in het sjabloonbestand. Gebruik de -Full schakeloptie om alle toepasselijke instellingen op te nemen in de gegenereerde PSSC.

Het -SessionType RestrictedRemoteServer veld geeft aan dat de sessieconfiguratie wordt gebruikt door JEA voor veilig beheer. Sessies van dit type werken in de NoLanguage-modus en hebben alleen toegang tot de volgende standaardopdrachten (en aliassen):

  • Clear-Host (cls, clear)
  • Exit-PSSession (exsn, exit)
  • Get-Command (gcm)
  • Get-FormatData
  • Get-Help
  • Measure-Object (meting)
  • Out-Default
  • Select-Object (selecteren)

Er zijn geen PowerShell-providers beschikbaar en er zijn geen externe programma's (uitvoerbare bestanden of scripts).

Zie about_Language_modes voor meer informatie over taalmodi.

Kies de JEA-identiteit

Achter de schermen heeft JEA een identiteit (account) nodig die moet worden gebruikt bij het uitvoeren van opdrachten van een verbonden gebruiker. U definieert welke identiteit JEA gebruikt in het sessieconfiguratiebestand.

Lokaal virtueel account

Lokale virtuele accounts zijn handig wanneer alle rollen die zijn gedefinieerd voor het JEA-eindpunt worden gebruikt om de lokale computer te beheren en een lokaal beheerdersaccount voldoende is om de opdrachten met succes uit te voeren. Virtuele accounts zijn tijdelijke accounts die uniek zijn voor een specifieke gebruiker en alleen voor de duur van hun PowerShell-sessie. Op een lidserver of werkstation behoren virtuele accounts tot de groep Administrators van de lokale computer. Op een Active Directory-domein Controller behoren virtuele accounts tot de groep Domeinadministrators van het domein.

# Setting the session to use a virtual account
RunAsVirtualAccount = $true

Als voor de rollen die zijn gedefinieerd door de sessieconfiguratie geen volledige beheerdersbevoegdheden zijn vereist, kunt u de beveiligingsgroepen opgeven waartoe het virtuele account behoort. Op een lidserver of werkstation moeten de opgegeven beveiligingsgroepen lokale groepen zijn, niet groepen uit een domein.

Wanneer een of meer beveiligingsgroepen zijn opgegeven, wordt het virtuele account niet toegewezen aan de lokale groep of domeinbeheerdersgroep.

# Setting the session to use a virtual account that only belongs to the NetworkOperator and NetworkAuditor local groups
RunAsVirtualAccount = $true
RunAsVirtualAccountGroups = 'NetworkOperator', 'NetworkAuditor'

Notitie

Virtuele accounts krijgen tijdelijk het aanmeldings-as-a-servicerecht in het beveiligingsbeleid van de lokale server. Als een van de opgegeven VirtualAccountGroups al dit recht in het beleid heeft gekregen, wordt het afzonderlijke virtuele account niet meer toegevoegd en verwijderd uit het beleid. Dit kan handig zijn in scenario's zoals domeincontrollers waarbij revisies van het beveiligingsbeleid voor domeincontrollers nauw worden gecontroleerd. Dit is alleen beschikbaar in Windows Server 2016 met het samenvouwen van november 2018 of hoger en Windows Server 2019 met het samenvouwen van januari 2019 of hoger.

Door groepen beheerd serviceaccount

Een door groepen beheerd serviceaccount (GMSA) is de juiste identiteit die moet worden gebruikt wanneer JEA-gebruikers toegang nodig hebben tot netwerkbronnen, zoals bestandsshares en webservices. GMSA's geven u een domeinidentiteit die wordt gebruikt voor verificatie met resources op elke computer binnen het domein. De rechten die een GMSA biedt, worden bepaald door de resources die u gebruikt. U hebt geen beheerdersrechten op computers of services, tenzij de computer- of servicebeheerder deze rechten expliciet aan de GMSA heeft verleend.

# Configure JEA sessions to use the GMSA in the local computer's domain
# with the sAMAccountName of 'MyJEAGMSA'
GroupManagedServiceAccount = 'Domain\MyJEAGMSA'

GMSA's mogen alleen worden gebruikt wanneer dat nodig is:

  • Het is moeilijk om acties te traceren naar een gebruiker wanneer u een GMSA gebruikt. Elke gebruiker deelt dezelfde run-as-identiteit. U moet transcripties en logboeken van PowerShell-sessies controleren om afzonderlijke gebruikers te correleren met hun acties.

  • De GMSA heeft mogelijk toegang tot veel netwerkbronnen waartoe de verbindingsgebruiker geen toegang nodig heeft. Probeer altijd effectieve machtigingen in een JEA-sessie te beperken om het principe van minimale bevoegdheden te volgen.

Notitie

Beheerde serviceaccounts voor groepen zijn alleen beschikbaar op computers die lid zijn van een domein met PowerShell 5.1 of hoger.

Zie het artikel over beveiligingsoverwegingen voor meer informatie over het beveiligen van een JEA-sessie.

Sessietranscripties

Het is raadzaam om een JEA-eindpunt zo te configureren dat transcripties van sessies van gebruikers automatisch worden vastgelegd. Transcripties van PowerShell-sessies bevatten informatie over de verbinding makende gebruiker, de uitvoering als identiteit die eraan is toegewezen en de opdrachten die door de gebruiker worden uitgevoerd. Ze kunnen nuttig zijn voor een controleteam dat moet begrijpen wie een specifieke wijziging heeft aangebracht in een systeem.

Als u automatische transcriptie in het sessieconfiguratiebestand wilt configureren, geeft u een pad op naar een map waarin de transcripties moeten worden opgeslagen.

TranscriptDirectory = 'C:\ProgramData\JEAConfiguration\Transcripts'

Transcripties worden naar de map geschreven door het lokale systeemaccount , waarvoor lees- en schrijftoegang tot de map is vereist. Standaardgebruikers mogen geen toegang hebben tot de map. Beperk het aantal beveiligingsbeheerders dat toegang heeft om de transcripties te controleren.

Gebruikersstation

Als uw gebruikers die verbinding maken, bestanden moeten kopiëren naar of van het JEA-eindpunt, kunt u het gebruikersstation inschakelen in het sessieconfiguratiebestand. Het gebruikersstation is een PSDrive die is toegewezen aan een unieke map voor elke verbindende gebruiker. Met deze map kunnen gebruikers bestanden van of naar het systeem kopiëren zonder hen toegang te geven tot het volledige bestandssysteem of de bestandssysteemprovider weer te geven. De inhoud van het gebruikersstation blijft behouden in sessies om situaties te voorkomen waarin de netwerkverbinding kan worden onderbroken.

MountUserDrive = $true

Standaard kunt u met het gebruikersstation maximaal 50 MB aan gegevens per gebruiker opslaan. U kunt de hoeveelheid gegevens beperken die een gebruiker kan gebruiken met het veld UserDriveMaximumSize .

# Enables the user drive with a per-user limit of 500MB (524288000 bytes)
MountUserDrive = $true
UserDriveMaximumSize = 524288000

Als u niet wilt dat gegevens in het gebruikersstation persistent zijn, kunt u een geplande taak op het systeem zo configureren dat de map elke nacht automatisch wordt opgeschoond.

Notitie

Het gebruikersstation is alleen beschikbaar in PowerShell 5.1 of hoger.

Zie PowerShell-stations beheren voor meer informatie over PSDrives.

Roldefinities

Roldefinities in een sessieconfiguratiebestand definiëren de toewijzing van gebruikers aan rollen. Elke gebruiker of groep die in dit veld is opgenomen, krijgt toestemming voor het JEA-eindpunt wanneer het is geregistreerd. Elke gebruiker of groep kan slechts één keer als sleutel in de hashtabel worden opgenomen, maar kan meerdere rollen worden toegewezen. De naam van de functiemogelijkheid moet de naam zijn van het functiebestand, zonder de .psrc extensie.

RoleDefinitions = @{
    'CONTOSO\JEA_DNS_ADMINS'    = @{ RoleCapabilities = 'DnsAdmin', 'DnsOperator', 'DnsAuditor' }
    'CONTOSO\JEA_DNS_OPERATORS' = @{ RoleCapabilities = 'DnsOperator', 'DnsAuditor' }
    'CONTOSO\JEA_DNS_AUDITORS'  = @{ RoleCapabilities = 'DnsAuditor' }
}

Als een gebruiker deel uitmaakt van meer dan één groep in de roldefinitie, krijgt deze toegang tot de rollen van elke groep. Wanneer twee rollen toegang verlenen tot dezelfde cmdlets, wordt de meest machtigingsparameterset aan de gebruiker verleend.

Wanneer u lokale gebruikers of groepen opgeeft in het veld roldefinities, moet u de computernaam gebruiken, niet localhost of jokertekens. U kunt de computernaam controleren door de $env:COMPUTERNAME variabele te inspecteren.

RoleDefinitions = @{
    'MyComputerName\MyLocalGroup' = @{ RoleCapabilities = 'DnsAuditor' }
}

Zoekvolgorde voor functiemogelijkheden

Zoals in het bovenstaande voorbeeld wordt weergegeven, worden er naar de functiemogelijkheden verwezen door de basisnaam van het functiebestand. De basisnaam van een bestand is de bestandsnaam zonder de extensie. Als er meerdere functiemogelijkheden beschikbaar zijn op het systeem met dezelfde naam, gebruikt PowerShell de impliciete zoekvolgorde om het effectieve functiemogelijkheidsbestand te selecteren. JEA geeft geen toegang tot alle functiemogelijkheidsbestanden met dezelfde naam.

JEA gebruikt de $env:PSModulePath omgevingsvariabele om te bepalen welke paden moeten worden gescand op functiemogelijkheidsbestanden. Binnen elk van deze paden zoekt JEA naar geldige PowerShell-modules die een submap 'RoleCapabilities' bevatten. Net als bij het importeren van modules geeft JEA de voorkeur aan functiemogelijkheden die worden geleverd met Windows naar aangepaste rolmogelijkheden met dezelfde naam.

Voor alle andere naamconflicten wordt prioriteit bepaald door de volgorde waarin Windows de bestanden in de map opsommen. De volgorde is niet gegarandeerd alfabetisch. Het eerste functiebestand dat overeenkomt met de opgegeven naam, wordt gebruikt voor de verbinding makende gebruiker. Omdat de zoekvolgorde voor functiemogelijkheden niet deterministisch is, wordt het ten zeerste aanbevolen dat rolmogelijkheden unieke bestandsnamen hebben.

Regels voor voorwaardelijke toegang

Alle gebruikers en groepen in het veld RoleDefinitions krijgen automatisch toegang tot JEA-eindpunten. Met regels voor voorwaardelijke toegang kunt u deze toegang verfijnen en vereisen dat gebruikers deel uitmaken van aanvullende beveiligingsgroepen die geen invloed hebben op de rollen waaraan ze zijn toegewezen. Dit is handig als u een Just-In-Time Privileged Access Management-oplossing, smartcardverificatie of een andere meervoudige verificatieoplossing wilt integreren met JEA.

Regels voor voorwaardelijke toegang worden gedefinieerd in het veld RequiredGroups in een sessieconfiguratiebestand. Daar kunt u een hashtabel (optioneel genest) opgeven die gebruikmaakt van 'And' en 'Or'-sleutels om uw regels te maken. Hier volgen enkele voorbeelden van het gebruik van dit veld:

# Example 1: Connecting users must belong to a security group called "elevated-jea"
RequiredGroups = @{ And = 'elevated-jea' }

# Example 2: Connecting users must have signed on with 2 factor authentication or a smart card
# The 2 factor authentication group name is "2FA-logon" and the smart card group name is "smartcard-logon"
RequiredGroups = @{ Or = '2FA-logon', 'smartcard-logon' }

# Example 3: Connecting users must elevate into "elevated-jea" with their JIT system and have logged on with 2FA or a smart card
RequiredGroups = @{ And = 'elevated-jea', @{ Or = '2FA-logon', 'smartcard-logon' }}

Notitie

Regels voor voorwaardelijke toegang zijn alleen beschikbaar in PowerShell 5.1 of hoger.

Andere eigenschappen

Sessieconfiguratiebestanden kunnen ook alles doen wat een functiebestand kan doen, zonder de mogelijkheid om gebruikers toegang te geven tot verschillende opdrachten. Als u alle gebruikers toegang wilt geven tot specifieke cmdlets, functies of providers, kunt u dit rechtstreeks in het sessieconfiguratiebestand doen. Voer Get-Help New-PSSessionConfigurationFile -Fulluit voor een volledige lijst met ondersteunde eigenschappen in het sessieconfiguratiebestand.

Een sessieconfiguratiebestand testen

U kunt een sessieconfiguratie testen met behulp van de cmdlet Test-PSSessionConfigurationFile . Het is raadzaam uw sessieconfiguratiebestand te testen als u het .pssc bestand handmatig hebt bewerkt. Testen zorgt ervoor dat de syntaxis juist is. Als een sessieconfiguratiebestand deze test mislukt, kan het niet worden geregistreerd op het systeem.

Voorbeeld van sessieconfiguratiebestand

In het volgende voorbeeld ziet u hoe u een sessieconfiguratie voor JEA maakt en valideert. De roldefinities worden gemaakt en opgeslagen in de $roles variabele voor gemak en leesbaarheid. Het is geen vereiste om dit te doen.

$roles = @{
    'CONTOSO\JEA_DNS_ADMINS'    = @{ RoleCapabilities = 'DnsAdmin', 'DnsOperator', 'DnsAuditor' }
    'CONTOSO\JEA_DNS_OPERATORS' = @{ RoleCapabilities = 'DnsOperator', 'DnsAuditor' }
    'CONTOSO\JEA_DNS_AUDITORS'  = @{ RoleCapabilities = 'DnsAuditor' }
}

New-PSSessionConfigurationFile -SessionType RestrictedRemoteServer -Path .\JEAConfig.pssc -RunAsVirtualAccount -TranscriptDirectory 'C:\ProgramData\JEAConfiguration\Transcripts' -RoleDefinitions $roles -RequiredGroups @{ Or = '2FA-logon', 'smartcard-logon' }
Test-PSSessionConfigurationFile -Path .\JEAConfig.pssc # should yield True

Sessieconfiguratiebestanden bijwerken

Als u de eigenschappen van een JEA-sessieconfiguratie wilt wijzigen, inclusief de toewijzing van gebruikers aan rollen, moet u de registratie ongedaan maken. Registreer vervolgens de JEA-sessieconfiguratie opnieuw met behulp van een bijgewerkt sessieconfiguratiebestand.

Volgende stappen