Hoe het Double-Hop Probleem van PowerShell op te lossen: Een Complete Gids – techsyncer

Heb je ooit geprobeerd toegang te krijgen tot een externe bron binnen een PowerShell Remoting-sessie, alleen om een frustrerende toegang geweigerd blokkade tegen te komen? Dit veelvoorkomende probleem, bekend als het “double-hop” probleem, voorkomt dat je toegang krijgt tot een tweede externe machine vanuit je huidige sessie.

Goed nieuws? Er zijn manieren om het double-hop probleem op te lossen zonder al te complexe configuraties. In deze tutorial bouw je een aangepaste sessie die naadloos omgaat met authenticatie, waardoor je tijd en moeite bespaart terwijl je de beveiliging behoudt.

Overwin double-hops met sessieconfiguraties en stroomlijn je workflow!

PowerShell uitvoeren als een andere gebruiker

Als je werkt met scripts die verbinding maken met externe bronnen, kun je het double-hop probleem tegenkomen. Dit probleem doet zich voor wanneer je inloggegevens niet verder authentiseren dan de eerste hop in een externe verbinding.

Neem bijvoorbeeld een script dat submappen op een externe computer telt met behulp van een UNC-pad:

(Get-ChildItem -Path \\SRV2\c$ -Directory).Count

Als je bent ingelogd als een gebruiker die geen toestemming heeft om toegang te krijgen tot een bron, kun je PowerShell onder een ander gebruikersaccount uitvoeren:

Zoek naar PowerShell in het Startmenu.
Klik met de rechtermuisknop op de PowerShell-snelkoppeling en selecteer Bestandslocatie openen.
In Verkenner, houd Shift ingedrukt, klik met de rechtermuisknop op de snelkoppeling en selecteer Uitvoeren als een andere gebruiker.
Voer de inloggegevens in van een gebruiker met de benodigde bevoegdheden.

Na het starten van PowerShell als een andere gebruiker, zou de opdracht nu succesvol moeten zijn:

(Get-ChildItem -Path \\SRV2\c$ -Directory).Count

TIP: Als je vaak opdrachten uitvoert met verschillende referenties, overweeg dan om de Start-Process cmdlet te gebruiken met de -Credential parameter. Op deze manier kun je nieuwe PowerShell-sessies direct vanuit de console openen met alternatieve referenties.

Testen van Externe Verbindingen

Je kunt met succes toegang hebben tot een externe bron lokaal, zoals een gedeelde map, wanneer je werkt met meerdere externe systemen. Maar dan ontdek je dat dezelfde opdracht een “toegang geweigerd” foutmelding geeft wanneer deze wordt uitgevoerd (vanaf een tweede externe computer).

Deze inconsistentie kan verwarrend zijn, vooral wanneer je ervan overtuigd bent dat je referenties voldoende machtigingen hebben.

Om je externe verbindingen te testen, maak een sessie met een andere computer:

Enter-PSSession -ComputerName SRV3

Zodra verbonden, probeer dezelfde opdracht uit te voeren op de tweede machine:

(Get-ChildItem -Path \\SRV2\c$ -Directory).Count

Deze test resulteert vaak in een “toegang geweigerd” foutmelding, zelfs als je een account met machtigingen gebruikt.

Bevestig je huidige gebruiker met het volgende:

whoami

Deze situatie (dubbele hop) treedt op omdat PowerShell je referenties niet doorgeeft naar de volgende hop. Dit mechanisme is een beveiligingsfunctie ingebouwd in Kerberos-authenticatie, maar het kan een groot hoofdpijndossier zijn bij het beheren van meerdere systemen.

Oplossen van het Dubbele-Hop Probleem met Sessieconfiguraties

Een oplossing voor het dubbele-hop probleem is om een sessieconfiguratie te maken op de tussenliggende machine.

Begin met het registreren van een sessieconfiguratie op de computer waarmee je verbinding maakt, in dit geval, SRV3.

De volgende opdracht:

Wijs een Naam toe aan de sessieconfiguratie (bijv., Admin).
Geeft de account (RunAsCredential) aan waar sessies onder zullen worden uitgevoerd.
Zorgt ervoor (Force) dat de configuratie wordt toegepast en de WinRM-service wordt herstart.

Invoke-Command -ComputerName SRV3 -ScriptBlock {
    Register-PSSessionConfiguration -Name Admin -RunAsCredential 'psforsysadmins.local\adam' -Force
}

PowerShell vraagt je om het wachtwoord voor de RunAsCredential account, dat veilig wordt opgeslagen op de externe machine. Zodra de configuratie is geregistreerd, wordt de WinRM-service herstart en wordt de sessie gesloten.

Met de configuratie op zijn plaats, kun je nu verbinding maken met de ConfigurationName parameter:

Invoke-Command -ComputerName SRV3 -ScriptBlock {
    (Get-ChildItem -Path \\SRV2\c$ -Directory).Count
} -ConfigurationName Admin

Deze opdracht voert dezelfde handeling uit als eerder. Het specificeert echter de Admin sessieconfiguratie, die wordt uitgevoerd onder de opgegeven beheerdersaccount.

Tip: Beperk de toegang tot de sessieconfiguratie door gebruikers- of groepsspecifieke toegangsrechten te definiëren met behulp van de Set-PSSessionConfiguration cmdlet. Op deze manier zorg je ervoor dat alleen geautoriseerde gebruikers gebruik kunnen maken van de configuratie.

Conclusie

In deze gids heb je het probleem van de dubbele hop in PowerShell Remoting gezien en opgelost. Het instellen van een sessieconfiguratie kan het probleem van de dubbele hop oplossen en ervoor zorgen dat referenties veilig worden doorgegeven.

Deze oplossing is persistent, dus je kunt de configuratie hergebruiken zelfs na herstarts, wat het een robuuste aanpak maakt voor het beheren van externe PowerShell-sessies. Nu kun je met vertrouwen multi-hop externe bewerkingen beheren en werkstromen stroomlijnen zonder de beveiliging in gevaar te brengen.

Van hieruit kunt u overwegen geavanceerde beveiligingsopties te verkennen, zoals het beperken van sessietoegang of het implementeren van op certificaten gebaseerde authenticatie. Deze verbeteringen kunnen uw remote-instellingen verder versterken terwijl u flexibel omgaat met complexe omgevingen.