JEA-sessieconfiguraties
Een JEA-eindpunt is geregistreerd op een systeem door een PowerShell-sessieconfiguratiebestand te maken en te registreren. Sessieconfiguraties bepalen 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 toegang heeft tot het JEA-eindpunt
- Aan welke rollen ze kunnen 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 ook wel een PowerShell-sessieconfiguratiebestand wordt genoemd. 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-FormatDataGet-HelpMeasure-Object(measure)Out-DefaultSelect-Object(select)
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 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 Beheer istrators van de lokale computer. Op een Active Directory-domein Controller behoren virtuele accounts tot de groep Domain Beheer s 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 nodig zijn, 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 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
Aan virtuele accounts wordt tijdelijk de aanmelding als een service verleend in het beveiligingsbeleid van de lokale server. Als aan een van de opgegeven VirtualAccountGroups al dit recht in het beleid is verleend, 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 waartoe u toegang hebt. 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 terug 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 verbindende gebruiker geen toegang nodig heeft. Probeer altijd effectieve machtigingen in een JEA-sessie te beperken om het principe van minimale bevoegdheden te volgen.
Notitie
Door groepen beheerde serviceaccounts 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 te configureren om automatisch transcripties van sessies van gebruikers vast te leggen. Transcripties van PowerShell-sessies bevatten informatie over de verbinding makende gebruiker, de uitvoering als identiteit die aan hen 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 vereist is. Standaardgebruikers mogen geen toegang hebben tot de map. Beperk het aantal beveiligingsbeheerders dat toegang heeft om de transcripties te controleren.
Gebruikersstation
Als uw verbindende gebruikers bestanden naar of van het JEA-eindpunt moeten kopiëren, 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 kopiëren van of naar het systeem zonder dat ze toegang hebben tot het volledige bestandssysteem of de bestandssysteemprovider beschikbaar maken. De inhoud van het gebruikersstation blijft in verschillende sessies staan 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 permanent 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 worden opgenomen als een sleutel in de hashtabel, maar kan meerdere rollen worden toegewezen. De naam van de functiemogelijkheid moet de naam zijn van het functiemogelijkheidsbestand, 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 missieve parameterset 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 controleren.
RoleDefinitions = @{
'MyComputerName\MyLocalGroup' = @{ RoleCapabilities = 'DnsAuditor' }
}
Zoekvolgorde voor functiemogelijkheden
Zoals in het bovenstaande voorbeeld wordt weergegeven, worden er naar rolmogelijkheden 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 biedt geen toegang tot alle functiemogelijkheidsbestanden met dezelfde naam.
JEA gebruikt de $env:PSModulePath omgevingsvariabele om te bepalen welke paden moeten worden gescand op rolmogelijkheidsbestanden. 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 rolmogelijkheden die met Windows worden verzonden naar aangepaste rolmogelijkheden met dezelfde naam.
Voor alle andere naamgevingsconflicten wordt prioriteit bepaald door de volgorde waarin Windows de bestanden in de map opsommen. De volgorde is niet gegarandeerd alfabetisch. Het eerste functiemogelijkheidsbestand dat overeenkomt met de opgegeven naam, wordt gebruikt voor de verbinding makende gebruiker. Omdat de zoekvolgorde voor functiemogelijkheden niet deterministisch is, wordt het sterk 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 behoren tot 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 de sleutels 'And' en 'Or' om uw regels samen te stellen. 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, alleen 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 -Fullvoor een volledige lijst met ondersteunde eigenschappen in het sessieconfiguratiebestand uit.
Een sessieconfiguratiebestand testen
U kunt een sessieconfiguratie testen met behulp van de cmdlet Test-PSSessionConfigurationFile . Het is raadzaam om 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 een 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' }
}
$parameters = @{
SessionType = 'RestrictedRemoteServer'
Path = '.\JEAConfig.pssc'
RunAsVirtualAccount = $true
TranscriptDirectory = 'C:\ProgramData\JEAConfiguration\Transcripts'
RoleDefinitions = $roles
RequiredGroups = @{ Or = '2FA-logon', 'smartcard-logon' }
}
New-PSSessionConfigurationFile @parameters
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.
