Aktivér remoting med flere hop i Windows PowerShell

  • 15 minutter

En anden udfordring med at fjerne data er relateret til delegering af legitimationsoplysninger på tværs af flere fjernforbindelser. Legitimationsoplysninger kan som standard kun delegeres på tværs af én forbindelse eller hop. Denne delegering af begrænsninger forhindrer fjerncomputeren i yderligere at delegere dine legitimationsoplysninger, da dette kan medføre en ekstra sikkerhedsrisiko.

Generelt er dette det scenarie, vi vil tage fat på:

  1. Du er logget på ServerA-.
  2. Fra ServerAstarter du en PowerShell-fjernsession for at oprette forbindelse til ServerB.
  3. En kommando, du kører på ServerB- via din PowerShell Remoting-session, forsøger at få adgang til en ressource på ServerC-.
  4. Adgang til ressourcen på ServerC- blev nægtet, fordi de legitimationsoplysninger, du brugte til at oprette PowerShell Remoting-sessionen, ikke overføres fra ServerB- til ServerC-.

Behovet for at udføre flere hop (eller delegering af flere hop) kan ofte forekomme i produktionsmiljøer. I nogle organisationer har administratorer f.eks. ikke tilladelse til at oprette forbindelse direkte fra deres klientcomputere til en server i datacenteret. De skal i stedet oprette forbindelse til en mellemliggende gateway eller hoppeserver og derefter derfra oprette forbindelse til den server, de vil administrere. I sin standardkonfiguration tillader fjernkørsel ikke denne fremgangsmåde. Når du har oprettet forbindelse til en fjerncomputer, kan dine legitimationsoplysninger ikke gå længere end fjerncomputeren. Forsøg på at få adgang til alle ressourcer, der ikke er placeret på den pågældende computer, resulterer typisk i en fejl, fordi din adgang ikke ledsages af legitimationsoplysninger. Løsningen er at aktivere CredSSP (Credential Security Support Provider).

Aktivering af CredSSP

CredSSP cachelagrer legitimationsoplysninger på fjernserveren (ServerBfra det forrige eksempel). Derfor skal du være opmærksom på, at hvis du bruger CredSSP, åbnes der potentielle angreb mod tyveri af legitimationsoplysninger. Hvis fjerncomputeren er kompromitteret, har hackeren adgang til brugerens legitimationsoplysninger. CredSSP er som standard deaktiveret på både klient- og servercomputere. Du bør kun aktivere CredSSP i de miljøer, der er mest tillid til. En domæneadministrator, der opretter forbindelse til en domænecontroller, kan f.eks. have Aktiveret CredSSP, fordi der er stor tillid til domænecontrolleren.

Du skal aktivere CredSSP-protokollen både på startcomputeren, der kaldes -klientens, og på den modtagende computer, der kaldes -serveren. Dette gør det muligt for den modtagende computer at delegere dine legitimationsoplysninger én ekstra hop.

Hvis du vil konfigurere klienten, skal du køre følgende kommando og erstatte servernavn med navnet på den server, der kan delegere dine legitimationsoplysninger igen:

Enable-WsManCredSSP –Role Client –Delegate servername

Servernavnet kan indeholde jokertegn. Det er dog for tilladt at bruge jokertegnet stjerne (*) i sig selv, fordi du gør det muligt for en hvilken som helst computer at slette dine legitimationsoplysninger igen, selv en uautoriseret bruger. Overvej i stedet et begrænset jokertegnmønster, f.eks. *.ADATUM.com, som begrænser delegering til computere i det pågældende domæne.

Hvis du vil konfigurere serveren, skal du køre Enable-WsManCredSSP – rolleserver. Der kræves ingen delegeret computerliste på serveren. Du kan også konfigurere disse indstillinger via Gruppepolitik, som giver en mere centraliseret og ensartet konfiguration på tværs af en virksomhed.

Seddel

Der har været mange sikkerhedsbrud dokumenteret, mens du bruger CredSSP, og derfor er det ikke længere en foretrukket mulighed. Du bør i stedet bruge begrænset delegering.

Ressourcebaseret Kerberos-begrænset delegering

Fra og med Windows Server 2012 kan du gå fra ved hjælp af CredSSP og i stedet bruge begrænset delegering. begrænset delegering implementerer delegering af tjenesteanmodninger ved hjælp af sikkerhedsbeskrivelser i stedet for en liste over tilladte servernavne. Dette gør det muligt for ressourcen at bestemme, hvilke sikkerhedsprincipaler der kan anmode om anmodninger på vegne af en anden bruger. Ressourcebaseret begrænset delegering fungerer korrekt, uanset domænefunktionsniveau.

Begrænset delegering kræver:

  • Adgang til en domænecontroller i det samme domæne som værtscomputeren, hvorfra Windows PowerShell-fjernkommandoerne køres.
  • Adgang til en domænecontroller i det domæne, der hoster den fjernserver, du forsøger at få adgang til fra den mellemliggende fjernserver.

Koden til konfiguration af tilladelserne kræver en computer, der kører Windows Server med RSAT (Active Directory PowerShell Remote Server Administration Tools). Du kan tilføje RSAT som en Windows-funktion ved at køre følgende to kommandoer:

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

Hvis du vil tildele ressourcebaseret Kerberos-begrænset delegering fra LON-SVR1- via LON-SVR2- til LON-SVR3-, skal du køre følgende kommando:

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

Et problem kan medføre, at denne kommando mislykkes. KDC (Key Distribution Center) har en negativ SPN-cache på 15 minutter. Hvis LON-SVR2- allerede har forsøgt at kommunikere med LON-SVR3-, er der en negativ cachepost. Du skal rydde cachen på LON-SVR2- ved hjælp af en af følgende teknikker:

  • Kør kommandoen klist purge -li 0x3e7. Dette er den foretrukne og hurtigste metode.
  • Vent 15 minutter på, at cachen ryddes automatisk.
  • Genstart LON-SVR2.

Hvis du vil teste begrænset delegering, skal du køre følgende kodeeksempel:

$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            
}

Lige nok administration

Just Enough Administration (JEA) er en sikkerhedsteknologi, der gør det muligt at delegere administration for alt, der administreres af PowerShell. Med JEA kan du:

  • Reducer antallet af administratorer på dine computere ved hjælp af virtuelle konti eller gruppeadministrerede tjenestekonti til at udføre privilegerede handlinger på vegne af almindelige brugere.
  • Begræns, hvad brugerne kan gøre, ved at angive, hvilke cmdlet'er, funktioner og eksterne kommandoer de kan køre.
  • Du kan bedre forstå, hvad dine brugere foretager sig, ved at gennemse transskriptioner og logge, der viser præcis, hvilke kommandoer en bruger kørte under sin session.

Konti med mange rettigheder, der bruges til at administrere dine servere, udgør en alvorlig sikkerhedsrisiko. Hvis en hacker kompromitterer en af disse konti, kan vedkommende starte tværgående angreb på tværs af din organisation. Hver kompromitteret konto giver en hacker adgang til endnu flere konti og ressourcer og bringer dem et skridt tættere på at stjæle virksomhedens hemmeligheder, starte et Denial-of-Service-angreb (DOS) og meget mere.

Det er heller ikke altid nemt at fjerne administrative rettigheder. Overvej det almindelige scenarie, hvor DNS-rollen er installeret på samme computer som din Active Directory-domænecontroller. Dine DNS-administratorer kræver lokale administratorrettigheder for at løse problemer med DNS-serveren. Men hvis du vil gøre det, skal du gøre dem til medlemmer af sikkerhedsgruppen Administratorer med mange rettigheder. Denne fremgangsmåde giver effektivt DNS-administratorer mulighed for at få kontrol over hele domænet og få adgang til alle ressourcerne på den pågældende computer.

JEA løser dette problem ved hjælp af princippet om mindste rettigheder. Med JEA kan du konfigurere et administrationsslutpunkt for DNS-administratorer, der kun giver dem adgang til de PowerShell-kommandoer, de skal bruge for at få deres job udført. Det betyder, at du kan give den nødvendige adgang til at reparere en forgiftet DNS-cache eller genstarte DNS-serveren uden utilsigtet at give dem rettigheder til Active Directory eller til at gennemse filsystemet eller køre potentielt farlige scripts. Det er endnu bedre, at når JEA-sessionen er konfigureret til at bruge midlertidige, privilegerede virtuelle konti, kan DNS-administratorer oprette forbindelse til serveren ved hjælp af legitimationsoplysninger, der ikke er administrator, og stadig køre kommandoer, der typisk kræver administratorrettigheder. JEA giver dig mulighed for at fjerne brugere fra vidt privilegerede lokale roller eller domæneadministratorroller og nøje styre, hvad de kan gøre på hver computer.

JEA er en funktion, der er inkluderet i PowerShell 5.0 og nyere. Hvis du vil have fuld funktionalitet, skal du installere den nyeste version af PowerShell, der er tilgængelig for dit system. PowerShell Remoting giver det fundament, som JEA er bygget på. Det er nødvendigt at sikre, at PowerShell Remoting er aktiveret og sikret korrekt, før du kan bruge JEA.

Når du opretter et JEA-slutpunkt, skal du definere en eller flere rollefunktioner, der beskriver, hvad en person kan gøre i en JEA-session. En rollefunktion er en PowerShell-datafil med filtypenavnet .psrc, der viser alle de cmdlet'er, funktioner, providere og eksterne programmer, der er gjort tilgængelige for at oprette forbindelse til brugere.

Du kan oprette en ny PowerShell-rollefunktionsfil med New-PSRoleCapabilityFile cmdlet. Du skal derefter redigere den resulterende rollefunktionsfil for at tillade de kommandoer, der kræves til rollen. Dokumentationen til PowerShell Hjælp indeholder flere eksempler på, hvordan du kan konfigurere filen.