PowerShell Remoting (PSRemoting) is een van de meest gebruikte functies in alle PowerShell. Waarom? Omdat het zo ontzettend handig is! Met één enkel commando kunt u naadloos verbinding maken met één of duizenden externe computers en opdrachten uitvoeren.
In deze Ultieme Gids gaat u diep in op PSRemoting. U leert wat het is, hoe het werkt en alle verschillende technologieën die PSRemoting laten werken. Deze gids zal niet behandelen hoe PSRemoting te gebruiken. U zult verwijzingen zien naar veel van onze how-to gidsen gedurende het hele proces.
Hoe PSRemoting werkt
In een notendop stelt PSRemoting u in staat om opdrachten uit te voeren op externe computers alsof u ervoor zat. PSRemoting biedt een reeks functies die een gebruiker verbinden en authenticeren, externe opdrachten uitvoeren en eventuele uitvoer van die opdracht teruggeven naar de lokale computer.
Denk aan PSRemoting als telnet of SSH of zelfs psexec. Het is gewoon een manier om opdrachten uit te voeren op computers binnen PowerShell.
PSRemoting vertrouwt sterk op een concept genaamd een sessie. Een sessie is een term die wordt gebruikt om een externe shell te beschrijven die opdrachten uitvoert. Het proces om een van deze sessies te maken verloopt via vele stappen op de achtergrond.
Wanneer u een PSRemoting-sessie start, worden de volgende ruwe stappen uitgevoerd:
- De klant probeert verbinding te maken met de doelserver op een WinRM-ontvanger (meer over WinRm-ontvangers hieronder). Een WinRM-ontvanger is een kleine webservice die op de doelserver wordt uitgevoerd. WinRM is de implementatie van Microsoft van een standaard genaamd WSMan. WSMan is een open standaard die destijds is gemaakt met vele andere grote technologiebedrijven zoals Dell, Intel en Sun Microsystems.
- Wanneer de klant verbinding maakt met de ontvanger via het HTTP- of HTTPS-protocol, begint het authenticatieproces. Alle details van elke methode van authenticatie worden later behandeld, maar voor nu moet u weten dat de klant in enige vorm referenties aan de server moet doorgeven.
- Nadat de klant verbinding heeft gemaakt en geauthenticeerd is bij de server, maakt PSRemoting een sessie aan.
- Zodra PSRemoting de sessie heeft aangemaakt, is deze klaar voor gebruik. Op dit punt kan de klant informatie naar de server sturen, waarbij de server eventuele noodzakelijke output retourneert, bekend als seriëlisatie. Deze communicatie is meestal versleuteld.
WinRM-ontvangers: Beschikbaar voor verbinding
A client needs somewhere to connect to when coming in from over the network. The client needs to “talk” to something that’s “listening” on the other side; that “listening” is the role of the WinRM listener.
U kunt alle WinRm-ontvangers die op een willekeurige Windows-computer actief zijn ontdekken met behulp van onderstaand winrm-commando.
WinRm-ontvangers hebben een paar belangrijke componenten. Ze hebben:
- A listening address – The listening address is the IP address that they bind to. This is the IP address that a client connects to.
- Het type transport – Elke WinRM-listener heeft een manier nodig om te communiceren met de client; ze doen dit via een transport met behulp van HTTP of HTTPS.
- Een optionele certificaat-Thumbprint – Wanneer een WinRM-listener HTTPS gebruikt voor het transport, moet het weten welke privésleutel moet worden gebruikt om de client te authenticeren; deze sleutel wordt gevonden met behulp van een certificaat-Thumbprint.
Gebruik indien mogelijk een HTTPS-listener. Het instellen van HTTPS-transport verhoogt de beveiliging door de geldigheid van de server te waarborgen en zowel de authenticatie- als het transportverkeer te versleutelen. Gebruik bij het uitgeven van een certificaat bij voorkeur een vertrouwd certificaat van een certificeringsinstantie in plaats van een zelfondertekend certificaat.
Vertrouwde hosts: Valideren van een server
Hoe PSRemoting-authenticatie via WinRM werkt
Zoals hierboven vermeld, is een van de eerste stappen die PSRemoting onderneemt, authenticatie. Authenticatie is een van de meest gecompliceerde maar essentiële onderdelen van PSRemoting.
Toen PSRemoting voor het eerst werd geïntroduceerd, had het slechts één authenticatiemechanisme, Windows Remote Management (WinRM), maar tegenwoordig kunt u ook authenticeren met SSH, zoals u later zult zien.
WinRM ondersteunt twee verschillende soorten authenticatie: een gebruikersnaam en wachtwoord of een certificaat met verschillende soorten authenticatie voor een gebruikersnaam/wachtwoordcombinatie.
Basisauthenticatie
Het starten met het makkelijkste, maar tegelijkertijd meest onveilige type authenticatie is Basis authenticatie. Dit type authenticatie is een standaard ingebouwd in het HTTP-protocol. Basis authenticatie stuurt een base64 gecodeerde kopie van de gebruikersnaam en wachtwoord in de HTTP-header van de client naar de luisteraar.
Omdat Basis authenticatie alleen de gebruikersnaam en wachtwoord codeert en het niet versleutelt, is het triviaal om de referenties te onderscheppen over het netwerk.
Gebruik geen Basis authenticatie tenzij het absoluut noodzakelijk is. Er zijn veel andere, veiligere methoden waarop WinRM kan authenticeren!
Kerberos Authenticatie
Zijn zowel uw client als server in een Active Directory omgeving? Zo ja, dan gebruikt u al Kerberos authenticatie over veel van uw netwerkdiensten.
Wanneer de WinRM-client probeert verbinding te maken met een WinRM-luisteraar via Kerberos:
- De server probeert eerst een sessiesleutel of ticket-verlenend-ticket voor de client op te halen bij een domeincontroller.
- De domeincontroller zoekt de client en de server op en als beide geldig en vertrouwd zijn, geeft het de token uit.
- De server valideert vervolgens de verbinding van de client met behulp van de vertrouwde token in plaats van de gebruikersnaam en het wachtwoord.
Tijdens de Kerberos-authenticatie controleert de domeincontroller zowel de client als de server tijdens de stappen voor het ophalen van het ticket, waardoor het voor kwaadwillenden moeilijk wordt om de server te imiteren.
Kerberos is een volwassen en veilige authenticatiemethode en is het standaard authenticatietype wanneer een client en server beide lid zijn van een Active Directory-domein. Het vereist echter wel dat zowel de client als de server zijn aangesloten bij hetzelfde Active Directory-forest of dat er een vertrouwen is opgezet tussen forests.
Onderhandelingsauthenticatie
WinRm kan ook proberen Kerberos te gebruiken en als dat niet beschikbaar is, terugschakelen naar een authenticatieprotocol genaamd NT Lan Manager (NTLM).
Bij het gebruik van NTLM:
- De server stuurt de client een string.
- De client versleutelt vervolgens de string met een hash van het wachtwoord van de gebruiker.
- De versleutelde string wordt vervolgens teruggestuurd naar de server die de gebruikersnaam, de oorspronkelijke string en de versleutelde string naar een domeincontroller stuurt.
- De domeincontroller zoekt vervolgens de wachtwoord-hash voor die gebruiker op en herhaalt hetzelfde versleutelingsproces op de string om te controleren of deze overeenkomt.
NTLM is goed voor het valideren van de client, maar in tegenstelling tot Kerberos valideert het de server niet. Dit opent meerdere aanvalsmogelijkheden waarbij de server geïmpersonaliseerd kan worden door een aanvaller.
U kunt de beveiliging van NTLM verbeteren door ook de server te valideren met een serververificatiecertificaat en dit toe te wijzen aan een HTTPS WinRM-listener. In deze configuratie wordt de client geauthenticeerd met NTLM tegen de domeincontroller, en de server wordt geauthenticeerd met een vertrouwd certificaat. Hoewel deze configuratie zowel client- als serverauthenticatie biedt, maakt het gebruik van het verouderde NTLM-protocol gebruik van een ouder versleutelingsalgoritme met een verouderde sleutelgrootte.
Om deze redenen is NTLM alleen bruikbaar als u de server aan de vertrouwde hostlijst toevoegt of een HTTPS-listener gebruikt.
Digest Authenticatie
Een van de meest ongebruikelijke authenticatiemethoden in WinRM is Digest Authenticatie. NTLM en Digest zijn vergelijkbare authenticatiemethoden. Net als NTLM genereert Digest een unieke string die wordt versleuteld met de hash van het wachtwoord van de gebruiker. Het wachtwoord hoeft vervolgens niet naar de server te worden verzonden.
Digest gebruikt het MD5-hashingsalgoritme om het wachtwoord te versleutelen. Vanwege deze keuze voor het algoritme wordt Digest over het algemeen beschouwd als verouderd en zou het niet moeten worden gebruikt. MD5 heeft verschillende bekende kwetsbaarheden die het ongeschikt maken voor cryptografisch gebruik.
Credential Security Support Provider (CredSSP)
Hoewel we diepgaand kunnen ingaan op CredSSP, is dat niet nodig. Waarom? Omdat als het gaat om PSRemoting en WinRM, CredSSP typisch geïmplementeerd is om één reden, het “tweede hop probleem”, waarover je hieronder meer zult leren.
Wanneer geconfigureerd voor CredSSP-authenticatie, gebruiken zowel de WinRM-client als de server beide Negotiate-authenticatie om zowel de gebruiker als de client te authenticeren. Maar eenmaal voltooid, wordt het wachtwoord van de gebruiker naar de server verzonden.
Omdat het wachtwoord wordt verzonden nadat het authenticatieproces is voltooid, is het nu versleuteld. CredSSP versleutelt ook het wachtwoord met de TLS-sessiesleutels zodat de versleutelde string uniek zal zijn tussen sessies.
CredSSP is handig omdat de server na authenticatie vervolgens namens u verbinding kan maken met iets anders. Echter, wanneer dit gebeurt, vertrouwt u volledig op de server waarmee u bent verbonden met het gebruikerswachtwoord.
Certificaatgebaseerde authenticatie
Misschien wel de meest veilige methode van authenticatie om te gebruiken met PSRemoting is certificaatgebaseerde authenticatie. Bij deze methode van authenticatie vindt een typische sleuteluitwisseling plaats met een privé- en openbare sleutel op de client en valideert een server het certificaat.
WinRM authenticeert de gebruiker door een gebruiker op de server te mappen binnen WinRm. Het enige dat tijdens het authenticatieproces wordt doorgegeven, is de openbare sleutel, dus het is een zeer veilige manier van authenticatie
Hoewel het de meest veilige is, is op certificaat gebaseerde authenticatie niet al te gebruikelijk. Waarom? Simpelweg vanwege het werk dat nodig is om het in te stellen. Je moet:
- Een certificaatautoriteit opzetten
- Een gebruikersauthenticatiecertificaat
- Delen van de openbare sleutel
- Een lokaal gebruikersaccount gebruiken met de juiste rechten (waarschijnlijk de groep Beheerders)
- Configureren van een HTTPS- luisteraar
- …en andere stappen
Je kunt geen domeingebruiker gebruiken om te authenticeren met certificaten, zelfs als de client en server beide deel uitmaken van Active Directory.
Standaardwaarden voor Windows OS-authenticatie
Nu je hebt gezien dat er veel verschillende authenticatieopties beschikbaar zijn, hoe weet je welke standaard beschikbaar zijn? Hieronder zie je een tabel met twee kolommen die aangeven of de WinRM-client standaard is ingeschakeld en of dat specifieke authenticatietype standaard is ingeschakeld.
Alle eerder genoemde authenticatietypen zijn configureerbaar, maar met behulp van de tabel hieronder krijg je een goed idee van wat je zelf moet configureren.
| Method | Client | Service |
| Basic | Enabled | Disabled |
| Kerberos | Enabled | Enabled |
| Negotiate | Enabled | Enabled |
| CredSSP | Disabled | Disabled |
| Digest | Enabled | Disabled |
| Certificate | Enabled | Disabled |
Het Probleem van de Tweede Hop of Dubbele Hop
Een van de grootste problemen met PSRemoting staat bekend als het “tweede hop probleem” of een “dubbele hop”. Deze situatie doet zich voor wanneer u verbinding maakt met een extern systeem via PSRemoting en vervolgens verbinding moet maken met een ander extern systeem.
Deze situatie is problematisch omdat wanneer de WinRm-client zich authenticeert bij het eerste externe systeem, de server alleen de identiteit van de oorspronkelijke client valideert zonder het wachtwoord naar de server te sturen. Wanneer u probeert verbinding te maken met de tweede computer vanaf de server van de eerste verbinding, heeft de uiteindelijke server geen manier om de identiteit van de gebruiker te valideren.
U kunt het dubbele hop probleem oplossen op verschillende manieren, bijvoorbeeld door CredSSP of Kerberos Delegatie te gebruiken.
Gebruik van CredSSP
De meest voorkomende manier om het dubbele hop probleem te omzeilen, is door CredSSP te gebruiken. CredSSP-authenticatie omzeilt deze situatie door gebruikersreferenties op te slaan op de eerste externe server, die vervolgens door de server-omgekeerde client naar de tweede externe server kunnen worden doorgegeven.
Er is echter één addertje onder het gras bij het gebruik van CredSSP. De opgeslagen gebruikersreferentie op de eerste externe server kan in platte tekst worden opgeslagen, wat een duidelijke beveiligingszorg met zich meebrengt. In nieuwere besturingssystemen wordt een hash van het wachtwoord en het Kerberos Ticket Granting Ticket (TGT) opgeslagen. Deze kunnen samen worden gebruikt om overal in het netwerk te authenticeren, net als een wachtwoord in platte tekst, maar het verlaagt het risico enigszins.
Met Onderhandelen wisselen de client en de server informatie uit om te valideren wie ze zeggen te zijn, maar het wachtwoord van de gebruiker is nooit toegankelijk. Dankzij deze beveiligingsfunctie is er geen manier waarop de eerste server je kan authenticeren wanneer je verbinding maakt met de tweede server.
Gebruik van Kerberos Delegatie
Kerberos, zoals eerder vermeld, is een gangbare manier om PSRemoting in te stellen. Omdat het deel uitmaakt van het alomtegenwoordige Active Directory en al standaard is ingesteld, is het extreem gebruikelijk. Hoewel Kerberos op zichzelf een prima manier is om WinRM te authenticeren, lost het het double-hop probleem niet op.
Om het double-hop scenario te omzeilen, kun je een tweede type authenticatie gebruiken dat bekend staat als Kerberos Delegatie. Hoewel er veel varianten van Kerberos Delegatie zijn, is de enige variant die in staat is (en veilig genoeg) om als alternatief voor CredSSP te dienen, genaamd Kerberos Beperkte Delegatie, meer specifiek op resource gebaseerde Kerberos Beperkte Delegatie.
Resource-based Kerberos Beperkte Delegatie is een vorm van het delegeren van Kerberos authenticatietokens op basis van domeinresources, zoals computers, in dit geval, beperkt tot een specifieke lijst van Kerberos (Active Directory) objecten.
Om deze Kerberos-delegatie te configureren, moet u het ADComputer-object van de derde computer in de keten bewerken. Als u bijvoorbeeld van ClientA naar ServerB naar ServerC gaat, moet u het ADComputer-object voor ServerC bewerken, maar u moet ook weten wat ServerB zal zijn. Voer voor dit voorbeeld de onderstaande opdracht uit in PowerShell:
Het gebruik van op bronnen gebaseerde Kerberos-delegatie werkt voor externe verbindingen zoals …, maar werkt niet met PSRemoting. U zult geen verbinding kunnen maken met een derde computer wanneer u verbonden bent met een computer via WinRM met behulp van PSRemoting.
Het instellen van op bronnen gebaseerde Kerberos Beperkte Delegatie is een eenregelige PowerShell-opdracht met behulp van de Set-ADComputer cmdlet. Als u bijvoorbeeld verbonden bent met ServerB vanaf ClientA via PSRemoting en verbinding wilt maken met ServerC met …, kunt u dit doen door de onderstaande PowerShell-opdracht uit te voeren.
WinRm cacheert mislukte verbindingen gedurende 15 minuten. Vanwege deze functie kunt u mogelijk geen verbinding maken met de derde computer, zelfs nadat u op bronnen gebaseerde Kerberos Beperkte Delegatie heeft ingesteld. Om te herstellen, wacht u of voert u de opdracht
klist purge -LI 0x3e7uit op de derde computer om de mislukte Kerberos-tokens te wissen.
Hoe PSRemoting Authenticatie via SSH werkt
Hoewel WinRm-authenticatie de meest voorkomende methode van authenticatie is voor PSRemoting, heb je vanaf PowerShell v6 een andere manier; SSH. Het gebruik van SSH als authenticatiemethode stelt je in staat om PSRemoting te gebruiken met Linux.
SSH vereist, in tegenstelling tot WinRm, enige aanvullende configuratie zowel op de client als op de server, zoals het instellen van een SSH-client op de Windows-client en …
Het gebruik van SSH voor de authenticatie betekent dat je beperkt bent tot de soorten authenticatie die SSH ondersteunt. Dit beperkt de lijst tot de twee belangrijkste, namelijk op wachtwoord gebaseerde en op sleutel gebaseerde authenticatie.
Er zijn andere soorten authenticatie die door SSH worden ondersteund, maar deze worden meestal als minder veilig beschouwd dan de op wachtwoord en sleutel gebaseerde opties, dus we zullen ons hier alleen op deze twee concentreren.
Wachtwoordauthenticatie
De gemakkelijkste manier om SSH-authenticatie met PSRemoting in te stellen is met op wachtwoord gebaseerde authenticatie. Op wachtwoord gebaseerde authenticatie stelt je in staat om een wachtwoord te verstrekken om jezelf te valideren.
In het SSH-authenticatieproces wordt het wachtwoord uitgewisseld nadat de SSH-verbinding tot stand is gebracht en het wachtwoord wordt versleuteld tijdens de transmissie. In tegenstelling tot sommige authenticatiemethoden die worden gebruikt door WinRM, zoals Kerberos, stuurt deze authenticatiemethode het volledige wachtwoord niet naar de server.
Je kunt SSH-wachtwoordauthenticatie min of meer vergelijken met de WinRM-authenticatiemethode Basic die een HTTPS-ontvanger gebruikt. Het wachtwoord zelf is niet op een zinvolle manier beschermd, maar de volledige verbinding, inclusief het wachtwoord, is versleuteld en de server wordt gevalideerd op basis van een certificaat.
Certificaatgebaseerde Authenticatie
Hoewel op wachtwoorden gebaseerde authenticatie eenvoudig in te stellen is en gemakkelijk te gebruiken, heeft het twee problemen.
- Ten eerste is er geen manier om op een veilige manier in een onbeheerd formaat te authenticeren.
- Wachtwoordauthenticatie stuurt nog steeds een wachtwoord over het netwerk. Hoewel het wachtwoord binnen de SSH-verbinding is versleuteld, ontvangt de server het volledige wachtwoord. Als de server op de een of andere manier gecompromitteerd is, kan dit een beveiligingsprobleem worden.
Certificaatgebaseerde authenticatie stuurt daarentegen geen gevoelige gegevens over het netwerk, zoals het wachtwoord. In plaats daarvan heeft de server een kopie van een openbare sleutel, heeft de client een kopie van de privésleutel en vinden de onderhandelingen plaats op de server.
A rough workflow goes as follows:
- Wanneer de client probeert te authenticeren, stuurt het de ID of thumbprint van de openbare sleutel naar de server.
- Als de server de openbare sleutel als geautoriseerd heeft, antwoordt deze met een met de openbare sleutel versleutelde string.
- Vervolgens decodeert de client de string met de privésleutel.
- De privésleutel wordt vervolgens gehasht met een sessie-ID.
- De sessie-ID wordt teruggestuurd naar de server, die het vervolgens vergelijkt met de gehashte waarde die is gegenereerd met behulp van de oorspronkelijke string en de sessie-ID.
- Als de sessie-ID-hash van de client overeenkomt met de sessie-ID op de server, authenticeert de client en mag deze verbinding maken.
Alles wat is versleuteld met de openbare sleutel kan alleen worden ontcijferd met een bijbehorende privésleutel. Alles wat is versleuteld met de privésleutel kan alleen worden ontcijferd met de openbare sleutel. De sessie-ID wordt ook toegevoegd om te zorgen voor wat wordt genoemd Perfecte Voorwaartse Geheimhouding (PFS).
PFS biedt beveiliging als de privésleutel wordt gecompromitteerd, de aanvaller zou niet in staat zijn om alle berichten die heen en weer zijn gegaan te ontcijferen. Een unieke sessie-ID betekent dat het gedeelde geheim dat wordt gebruikt om de communicatie te versleutelen, voor elke sessie anders is.
Certificaatgebaseerde authenticatie met SSH, zoals WinRm, vereist wel extra inspanning om in te stellen, zoals het genereren van de privé-/publieke sleutel en het autoriseren van de publieke sleutel op de externe server.
Gebruikersrechten vereist om verbinding te maken
Standaard kunnen twee lokale gebruikersgroepen verbinding maken met een server op afstand met behulp van PSRemoting; Beheerders en Gebruikers voor externe beheer.
Hoewel je gewoon gebruikersaccounts kunt toevoegen aan de lokale beheerdersgroep op een externe server, moet je altijd de minste hoeveelheid toegang verlenen. Als een gebruiker alleen maar verbinding moet maken met PSRemoting naar een externe computer, kun je het gebruikersaccount toevoegen aan de groep Remote Management Users; niet aan Beheerders.
Om PSRemoting-toegang verder te beheren, kun je ook gebruikmaken van een functie genaamd Just Enough Administration (JEA). JEA stelt niet-beheerdersgebruikers in staat om alleen specifieke commando’s uit te voeren als beheerders in PowerShell’s beperkte taalmodus.
Impliciet vs. “Expliciet” Remote beheer
Als je eerder PSRemoting hebt gebruikt, ben je waarschijnlijk bekend met commando’s zoals Invoke-Command, New-PSSession, Enter-PSSession, enz. Wanneer je deze commando’s uitvoert, is het duidelijk dat je op de een of andere manier verbinding maakt met een externe computer. Je gebruikt PSRemoting expliciet.
Als je PSRemoting-specifieke commando’s uitvoert, voer je die commando’s expliciet uit, maar wist je dat er nog een andere manier is? In plaats van rechtstreeks Invoke-Command en andere cmdlets aan te roepen, kun je PSRemoting benutten door impliciete PSRemoting te gebruiken.
Impliciete PSRemoting kan lijken alsof je de opdrachten lokaal uitvoert binnen je PowerShell-sessie, maar ze worden feitelijk uitgevoerd op een externe machine. Een goed voorbeeld hiervan is het gebruik van een module die niet is geïnstalleerd op jouw systeem. In plaats van deze lokaal te installeren, kun je opdrachten exporteren uit een PSSession, waardoor je ze kunt uitvoeren alsof ze lokaal zijn geïnstalleerd.
In de onderstaande schermafbeelding zie je dat ik het Test-PendingReboot-commando niet heb. Vervolgens verbond ik met een externe machine en exporteerde dat commando.
Vervolgens, als die module is geïmporteerd, kan ik het Test-PendingReboot-commando uitvoeren. Dit wordt hieronder getoond, maar je zult opmerken dat het de computernaam in de uitvoer toont als de naam van het apparaat waarop PowerShell wordt uitgevoerd, niet het apparaat waarvan het commando is geïmporteerd.
