Externe communicatie met meerdere hops inschakelen in Windows PowerShell

Voltooid

Een andere uitdaging met externe communicatie is gerelateerd aan het delegeren van referenties voor meerdere externe verbindingen. Standaard kunnen referenties worden gedelegeerd via slechts één verbinding of hop. Met deze beperkingsdelegering voorkomt u dat de externe computer uw referenties verder delegeert, omdat dit een extra beveiligingsrisico kan veroorzaken.

Over het algemeen is dit het scenario dat we willen aanpakken:

1. U bent aangemeld bij ServerA.
2. Vanuit ServerA start u een externe PowerShell-sessie om verbinding te maken met ServerB.
3. Een opdracht die u uitvoert op ServerB via uw externe PowerShell-sessie probeert toegang te krijgen tot een resource op ServerC.
4. De toegang tot de resource op ServerC wordt geweigerd omdat de referenties die u hebt gebruikt om de externe PowerShell-sessie te maken, niet worden doorgegeven van ServerB naar ServerC.

De noodzaak om meerdere hops (of multi-hop) delegering uit te voeren, kan vaak optreden in productieomgevingen. In sommige organisaties mogen beheerders bijvoorbeeld niet rechtstreeks vanaf hun clientcomputers verbinding maken met een server in het datacenter. In plaats daarvan moeten ze verbinding maken met een tussenliggende gateway of jumpserver en vervolgens verbinding maken met de server die ze willen beheren. In de standaardconfiguratie staat externe communicatie deze benadering niet toe. Nadat u verbinding hebt gemaakt met een externe computer, kan uw referentie niet verder gaan dan de externe computer. Als u toegang probeert te krijgen tot een resource die zich niet op die computer bevindt, treedt er meestal een fout op omdat uw toegang niet wordt vergezeld van een referentie. De oplossing is om Credential Security Support Provider (CredSSP) in te schakelen.

CredSSP inschakelen

CredSSP slaat referenties op de externe server (ServerB, uit het vorige voorbeeld) in de cache op. Daarom moet u er rekening mee houden dat u met CredSSP potentiële diefstalaanvallen kunt openen. Als de externe computer is aangetast, heeft de aanvaller toegang tot de referenties van de gebruiker. CredSSP is standaard uitgeschakeld op zowel client- als servercomputers. Schakel CredSSP alleen in de meest vertrouwde omgevingen in. Een domeinbeheerder die verbinding maakt met een domeincontroller kan bijvoorbeeld CredSSP hebben ingeschakeld omdat de domeincontroller zeer vertrouwd is.

U moet het CredSSP-protocol inschakelen op de initiërende computer, aangeduid als de client en op de ontvangende computer, aangeduid als de server. Hierdoor kan de ontvangende computer uw referenties één extra hop delegeren.

Als u de client wilt configureren, voert u de volgende opdracht uit, waarbij u de servernaam vervangt door de naam van de server die uw referenties opnieuw kan verwijderen:

Enable-WsManCredSSP –Role Client –Delegate servername

De servernaam kan jokertekens bevatten. Het gebruik van het jokerteken sterretje (*) zelf is echter te permissief omdat u elke computer in staat stelt om uw referenties opnieuw te verzenden, zelfs een onbevoegde gebruiker. Overweeg in plaats daarvan een beperkt jokertekenpatroon, zoals *.ADATUM.com, waardoor herdelegatie wordt beperkt tot computers in dat domein.

Voer Enable-WsManCredSSP –Role Server uit om de server te configureren. Er is geen lijst met gedelegeerde computers vereist op de server. U kunt deze instellingen ook configureren via Groepsbeleid, dat een gecentraliseerde en consistentere configuratie biedt voor een onderneming.

Notitie

Er zijn talloze beveiligingsschendingen gedocumenteerd tijdens het gebruik van CredSSP en daarom is het geen voorkeursoptie meer. Gebruik in plaats daarvan beperkte delegering.

Op resources gebaseerde, beperkte Kerberos-delegering

Vanaf Windows Server 2012 kunt u credSSP gebruiken en in plaats daarvan beperkte delegatie gebruiken. Beperkte delegering implementeert delegering van servicetickets met behulp van beveiligingsdescriptors in plaats van een acceptatielijst met servernamen. Hierdoor kan de resource bepalen welke beveiligingsprinciplen tickets namens een andere gebruiker kunnen aanvragen. Beperkte delegering op basis van resources werkt correct, ongeacht het functionele domeinniveau.

Beperkte delegering vereist:

• Toegang tot een domeincontroller in hetzelfde domein als de hostcomputer van waaruit de externe windows PowerShell-opdrachten worden uitgevoerd.
• Toegang tot een domeincontroller in het domein dat als host fungeert voor de externe server die u probeert te openen vanaf de tussenliggende externe server.

De code voor het instellen van de machtigingen vereist een computer met Windows Server met de Active Directory PowerShell Remote Server Administration Tools (RSAT). U kunt RSAT toevoegen als windows-functie door de volgende twee opdrachten uit te voeren:

Add-WindowsFeature RSAT-AD-PowerShell
Import-Module ActiveDirectory

Voer de volgende opdracht uit om op resources gebaseerde Kerberos-beperkte delegatie van LON-SVR1 via LON-SVR2 te verlenen aan LON-SVR3:

Set-ADComputer -Identity LON-SVR2 -PrincipalsAllowedToDelegateToAccount LON-SVR3

Een probleem kan ertoe leiden dat deze opdracht mislukt. Het KDC (Key Distribution Center) heeft een negatieve SPN-cache van 15 minuten. Als LON-SVR2 al heeft geprobeerd te communiceren met LON-SVR3, is er een negatieve cachevermelding. U moet de cache op LON-SVR2 wissen met behulp van een van de volgende technieken:

• Voer de opdracht klist purge -li 0x3e7 uit. Dit is de voorkeurs- en snelste methode.
• Wacht 15 minuten totdat de cache automatisch is gewist.
• Start LON-SVR2 opnieuw.

Voer het volgende codevoorbeeld uit om beperkte delegering te testen:

$cred = Get-Credential Adatum\TestUser                
Invoke-Command -ComputerName LON-SVR1.Name -Credential $cred -ScriptBlock {Test-Path \\$($using:ServerC.Name)\C$            `
Get-Process lsass -ComputerName $($using:LON-SVR2.Name)
Get-EventLog -LogName System -Newest 3 -ComputerName $using:LON-SVR3.Name            
}

Net genoeg administratie

Just Enough Administration (JEA) is een beveiligingstechnologie waarmee gedelegeerd beheer mogelijk is voor alles wat wordt beheerd door PowerShell. Met JEA kunt u het volgende doen:

• Verminder het aantal beheerders op uw machines met behulp van virtuele accounts of door groepen beheerde serviceaccounts om bevoegde acties uit te voeren namens gewone gebruikers.
• Beperk wat gebruikers kunnen doen door op te geven welke cmdlets, functies en externe opdrachten ze kunnen uitvoeren.
• Begrijp beter wat uw gebruikers doen door transcripties en logboeken te bekijken die precies weergeven welke opdrachten een gebruiker heeft uitgevoerd tijdens hun sessie.

Accounts met hoge bevoegdheden die worden gebruikt om uw servers te beheren, vormen een ernstig beveiligingsrisico. Als een aanvaller inbreuk kan maken op een van deze accounts, kunnen ze laterale aanvallen binnen uw organisatie starten. Elk gecompromitteerd account biedt een aanvaller toegang tot nog meer accounts en resources en zet ze één stap dichter bij het stelen van bedrijfsgeheimen, het starten van een DOS-aanval (Denial-of-Service) en meer.

Het is ook niet altijd eenvoudig om beheerdersbevoegdheden te verwijderen. Houd rekening met het veelvoorkomende scenario waarin de DNS-rol is geïnstalleerd op dezelfde computer als uw Active Directory-domeincontroller. Uw DNS-beheerders hebben lokale beheerdersbevoegdheden nodig om problemen met de DNS-server op te lossen. Maar hiervoor moet u hen lid maken van de beveiligingsgroep Beheerders met hoge bevoegdheden. Deze aanpak biedt DNS-beheerders de mogelijkheid om controle te krijgen over uw hele domein en toegang tot alle resources op die computer.

JEA lost dit probleem op via het principe van minimale bevoegdheden. Met JEA kunt u een beheereindpunt configureren voor DNS-beheerders die hen alleen toegang geven tot de PowerShell-opdrachten die ze nodig hebben om hun werk te doen. Dit betekent dat u de juiste toegang kunt bieden om een vergiftigde DNS-cache te herstellen of de DNS-server opnieuw op te starten zonder ze onbedoeld rechten te geven voor Active Directory, of om door het bestandssysteem te bladeren of mogelijk gevaarlijke scripts uit te voeren. Nog beter, wanneer de JEA-sessie is geconfigureerd voor het gebruik van tijdelijke, bevoegde virtuele accounts, kunnen uw DNS-beheerders verbinding maken met de server met behulp van niet-beheerdersreferenties en nog steeds opdrachten uitvoeren waarvoor doorgaans beheerdersbevoegdheden zijn vereist. MET JEA kunt u gebruikers verwijderen uit algemeen bevoegde lokale of domeinbeheerdersrollen en zorgvuldig bepalen wat ze op elke computer kunnen doen.

JEA is een functie die is opgenomen in PowerShell 5.0 en hoger. Voor volledige functionaliteit moet u de nieuwste versie van PowerShell installeren die beschikbaar is voor uw systeem. Externe communicatie van PowerShell biedt de basis waarop JEA is gebouwd. Het is noodzakelijk om ervoor te zorgen dat externe communicatie van PowerShell is ingeschakeld en goed is beveiligd voordat u JEA kunt gebruiken.

Wanneer u een JEA-eindpunt maakt, moet u een of meer rolmogelijkheden definiëren die beschrijven wat iemand in een JEA-sessie kan doen. Een functiemogelijkheid is een PowerShell-gegevensbestand met de extensie .psrc, waarin alle cmdlets, functies, providers en externe programma's worden vermeld die beschikbaar worden gesteld om gebruikers te verbinden.

U kunt een nieuw PowerShell-functiemogelijkheidsbestand maken met de cmdlet New-PSRoleCapabilityFile . Bewerk vervolgens het resulterende functiemogelijkheidsbestand om de opdrachten toe te staan die vereist zijn voor de rol. De Help-documentatie van PowerShell bevat verschillende voorbeelden van hoe u het bestand kunt configureren.