Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Uppdaterad: 24 juni 2013
Gäller för: Windows Server 2012 R2, Windows Server 2012
Windows PowerShell Web Access i Windows Server 2012 R2 och Windows Server 2012 har en restriktiv säkerhetsmodell. Användare måste uttryckligen beviljas åtkomst innan de kan logga in på Windows PowerShell Web Access-gatewayen och använda den webbaserade Windows PowerShell-konsolen.
Konfigurera behörighetsregler och platssäkerhet
Efter att Windows PowerShell Web Access har installerats och gatewayen är konfigurerad kan användare öppna inloggningssidan i en webbläsare, men de kan inte logga in förrän Windows PowerShell Web Access-administratören uttryckligen ger användarna åtkomst. 'Windows PowerShell Web Access'-åtkomstkontrollen hanteras genom att använda uppsättningen av Windows PowerShell-cmdlets som beskrivs i följande tabell. Det finns inget jämförbart grafiskt gränssnitt för att lägga till eller hantera auktorisationsregler. Se Windows PowerShell Web Access Cmdlets.
Administratörer kan definiera {0-n} autentiseringsregler för Windows PowerShell Web Access. Standardsäkerheten är restriktiv snarare än tillåtande; Inga autentiseringsregler betyder att inga användare har tillgång till någonting.
Add-PswaAuthorizationRule och Test-PswaAuthorizationRule i Windows Server 2012 R2 inkluderar en Credential-parameter som låter dig lägga till och testa Windows PowerShell Web Access-auktoriseringsregler från en fjärrdator eller från en aktiv Windows PowerShell Web Access-session. Precis som med andra Windows PowerShell-cmdlets som har en Credential-parameter kan du ange ett PSCredential-objekt som värdet på parametern. För att skapa ett PSCredential-objekt som innehåller inloggningsuppgifter du vill skicka till en fjärrdator, kör Get-Credential-cmdleten .
Windows PowerShell Web Access-autentiseringsregler är tillåtna regler. Varje regel är en definition av en tillåten anslutning mellan användare, måldatorer och särskilda Windows PowerShell-sessionskonfigurationer (även kallade endpoints eller runspaces) på angivna måldatorer. För en förklaring om runspaces , se Beginning Use of PowerShell Runspaces
Viktigt!
En användare behöver bara en regel för att vara sann för att få åtkomst. Om en användare får tillgång till en dator med antingen full språkåtkomst eller endast tillgång till Windows PowerShell fjärrhanteringscmdlets, kan användaren från webkonsolen logga in (eller hoppa) till andra datorer som är anslutna till den första måldatorn. Det säkraste sättet att konfigurera Windows PowerShell Web Access är att tillåta användare att endast få tillgång till begränsade sessionskonfigurationer som gör det möjligt för dem att utföra specifika uppgifter som de normalt behöver utföra på distans.
De cmdlets som refereras till i Windows PowerShell Web Access Cmdlets tillåter att skapa en uppsättning åtkomstregler som används för att auktorisera en användare på Windows PowerShell Web Access-gatewayen. Reglerna skiljer sig från åtkomstkontrolllistorna (ACL) på destinationsdatorn och ger ett extra säkerhetslager för webbåtkomst. Mer information om säkerhet beskrivs i följande avsnitt.
Om användare inte kan passera något av de föregående säkerhetslagren får de ett generiskt meddelande om att 'åtkomst nekas' i sina webbläsarfönster. Även om säkerhetsdetaljer loggas på gateway-servern visas slutanvändarna inte information om hur många säkerhetslager de passerade, eller på vilket lager inloggnings- eller autentiseringsmisslyckandet inträffade.
För mer information om att konfigurera auktorisationsregler, se konfigurera auktorisationsregler i detta ämne.
Security
Windows PowerShell Web Access-säkerhetsmodellen har fyra lager mellan en slutanvändare av den webbaserade konsolen och en måldator. Windows PowerShell Web Access-administratörer kan lägga till säkerhetslager genom ytterligare konfiguration i IIS Manager-konsolen. För mer information om hur du säkrar webbplatser i IIS Manager-konsolen, se Konfigurera webbserversäkerhet (IIS7).
För mer information om IIS bästa praxis och förebyggande av överkörningsattacker, se Bästa praxis för att förebygga DoS/Denial of Service-attacker. En administratör kan också köpa och installera ytterligare programvara för autentisering i butiker.
Följande tabell beskriver de fyra säkerhetsnivåerna mellan slutanvändare och måldatorer.
Detaljerad information om varje lager finns under följande rubriker:
IIS webbserversäkerhetsfunktioner
Windows PowerShell Web Access-användare måste alltid ange användarnamn och lösenord för att autentisera sina konton på gatewayen. Dock kan administratörer för Windows PowerShell Web Access också slå på eller av valfri autentisering av klientcertifikat, se installera och använda Windows PowerShell Web Access för att aktivera ett testcertifikat och senare hur man konfigurerar ett äkta certifikat.
Den valfria funktionen för klientcertifikat kräver att slutanvändare har ett giltigt klientcertifikat, utöver sina användarnamn och lösenord, och är en del av Web Server (IIS)-konfigurationen. När klientcertifikatslaget är aktiverat uppmanar inloggningssidan för Windows PowerShell Web Access användare att tillhandahålla giltiga certifikat innan deras inloggningsuppgifter utvärderas. Autentisering av klientcertifikat kontrollerar automatiskt klientcertifikatet. Om ett giltigt certifikat inte hittas informerar Windows PowerShell Web Access användarna, så att de kan tillhandahålla certifikatet. Om ett giltigt klientcertifikat hittas öppnar Windows PowerShell Web Access inloggningssidan för användare att ange sina användarnamn och lösenord.
Detta är ett exempel på ytterligare säkerhetsinställningar som erbjuds av IIS Web Server. För mer information om andra IIS-säkerhetsfunktioner, se Konfigurera webbserversäkerhet (IIS 7).
Windows PowerShell Web Access-formulärbaserad gateway-autentisering
Windows PowerShell Web Access-inloggningssidan kräver en uppsättning inloggningsuppgifter (användarnamn och lösenord) och erbjuder användarna möjlighet att ange olika inloggningsuppgifter för måldatorn. Om användaren inte tillhandahåller alternativa uppgifter används även det primära användarnamnet och lösenordet som används för att ansluta till gatewayen för att ansluta till måldatorn.
De nödvändiga inloggningsuppgifterna autentiseras på Windows PowerShell Web Access-gateway. Dessa inloggningsuppgifter måste vara giltiga användarkonton på antingen den lokala Windows PowerShell Web Access-gatewayservern eller i Active Directory.
Windows PowerShell Web Access-behörighetsregler
Efter att en användare har autentiserats vid gatewayen kontrollerar Windows PowerShell Web Access auktorisationsregler för att verifiera om användaren har tillgång till den begärda måldatorn. Efter framgångsrik auktorisation skickas användarens inloggningsuppgifter vidare till måldatorn.
Dessa regler utvärderas först efter att en användare har autentiserats av gatewayen, och innan en användare kan autentiseras på en måldator.
Regler för mål-autentisering och auktorisering
Det sista säkerhetslagret för Windows PowerShell Web Access är måldatorns egen säkerhetskonfiguration. Användare måste ha rätt åtkomsträttigheter konfigurerade på måldatorn, och även enligt Windows PowerShell Web Access-behörighetsreglerna, för att köra en Windows PowerShell webbaserad konsol som påverkar måldatorn via Windows PowerShell Web Access.
Detta lager erbjuder samma säkerhetsmekanismer som skulle utvärdera anslutningsförsök om användare försökte skapa en fjärrsession med Windows PowerShell till en måldator från Windows PowerShell genom att köra Enter-PSSession eller New-PSSession cmdlets.
Som standard använder Windows PowerShell Web Access primäranvändarnamnet och lösenordet för autentisering både på gatewayen och måldatorn. Den webbaserade inloggningssidan, i en sektion med titeln Valfria anslutningsinställningar, erbjuder användare möjlighet att ange olika inloggningsuppgifter för måldatorn om det behövs. Om användaren inte tillhandahåller alternativa uppgifter används även det primära användarnamnet och lösenordet som används för att ansluta till gatewayen för att ansluta till måldatorn.
Auktorisationsregler kan användas för att ge användare tillgång till en viss sessionskonfiguration. Du kan skapa begränsade runspaces eller sessionskonfigurationer för Windows PowerShell Web Access och låta specifika användare ansluta endast till specifika sessionskonfigurationer när de loggar in på Windows PowerShell Web Access. Du kan använda åtkomstkontrolllistor (ACL) för att avgöra vilka användare som har tillgång till specifika endpoints, och ytterligare begränsa åtkomsten till endpointen för en specifik uppsättning användare genom att använda auktoriseringsregler som beskrivs i detta avsnitt. För mer information om begränsade runspaces, se Skapa ett begränsat runspace.
Konfigurera auktorisationsregler
Administratörer vill troligen ha samma auktorisationsregel för Windows PowerShell Web Access-användare som redan är definierad i deras miljö för Windows PowerShell fjärrhantering. Den första proceduren i detta avsnitt beskriver hur man lägger till en säker auktorisationsregel som ger åtkomst till en användare, inloggning för att hantera en dator och inom en enda sessionskonfiguration. Den andra proceduren beskriver hur man tar bort en auktorisationsregel som inte längre behövs.
Om du planerar att använda anpassade sessionskonfigurationer för att tillåta specifika användare att arbeta endast inom begränsade runspaces i Windows PowerShell Web Access, skapa dina egna sessionskonfigurationer innan du lägger till auktorisationsregler som refererar till dem. Du kan inte använda Windows PowerShell Web Access-cmdlets för att skapa anpassade sessionskonfigurationer. För mer information om hur du skapar anpassade sessionskonfigurationer, se about_Session_Configuration_Files.
Windows PowerShell Web Access-cmdlets stöder ett wildcard-tecken, en asterisk ( * ). Jokerkaraktärer inom strängar stöds inte; Använd en enda asterisk per egenskap (användare, datorer eller sessionskonfigurationer).
Anmärkning
För fler sätt du kan använda auktorisationsregler för att ge åtkomst till användare och hjälpa till att säkra Windows PowerShell Web Access-miljön, se andra exempel på auktorisationsregelscenarion i detta ämne.
För att lägga till en restriktiv auktorisationsregel
Gör något av följande för att öppna en Windows PowerShell-session med utökade användarrättigheter.
Högerklicka på Windows PowerShell i aktivitetsfältet på Windows-skrivbordet och klicka sedan på Kör som administratör.
På Windows Start-skärmen , högerklicka på Windows PowerShell och klicka sedan på Kör som administratör.
Valfritt steg För att begränsa användaråtkomst genom att använda sessionskonfigurationer:
Kontrollera att de sessionskonfigurationer du vill använda redan finns i dina regler.
Om de ännu inte har skapats, använd instruktioner för att skapa sessionskonfigurationer i about_Session_Configuration_Files.
Denna auktorisationsregel ger en specifik användare tillgång till en dator i nätverket som de vanligtvis har tillgång till, med åtkomst till en specifik sessionskonfiguration som är anpassad till användarens typiska skript- och cmdlet-behov. Skriv följande och tryck sedan på Retur.
Add-PswaAuthorizationRule -UserName <domain\user | computer\user> ` -ComputerName <computer_name> -ConfigurationName <session_configuration_name>- I följande exempel beviljas en användare vid namn JSmith i Contoso-domänen tillgång att hantera datorns Contoso_214 och använda en sessionskonfiguration som heter NewAdminsOnly.
Add-PswaAuthorizationRule -UserName 'Contoso\JSmith' ` -ComputerName Contoso_214 -ConfigurationName NewAdminsOnlyVerifiera att regeln har skapats genom att köra antingen Get-PswaAuthorizationRule-cmdlet , eller
Test-PswaAuthorizationRule -UserName <domain\user | computer\user> -ComputerName** <computer_name>. Till exempelTest-PswaAuthorizationRule -UserName Contoso\\JSmith -ComputerName Contoso_214.
För att ta bort en auktorisationsregel
Om en Windows PowerShell-session inte redan är öppen, se steg 1 för att lägga till en restriktiv auktorisationsregel i detta avsnitt.
Skriv följande och tryck sedan på Enter, där regel-ID representerar det unika ID-numret för regeln du vill ta bort.
Remove-PswaAuthorizationRule -ID <rule ID>Alternativt, om du inte känner till ID-numret, men vet det vänliga namnet på regeln du vill ta bort, kan du få regelns namn och skicka det till cmdleten
Remove-PswaAuthorizationRuleför att ta bort regeln, som visas i följande exempel:Get-PswaAuthorizationRule ` -RuleName <rule-name> | Remove-PswaAuthorizationRule
Anmärkning
Du blir inte ombedd att bekräfta om du vill ta bort den angivna auktorisationsregeln; regeln raderas när du trycker på Enter. Se till att du vill ta bort auktorisationsregeln innan du kör Remove-PswaAuthorizationRule cmdleten.
Andra exempel på scenarion med auktorisationsregler
Varje Windows PowerShell-session använder en sessionskonfiguration; om en sådan inte specificeras för en session använder Windows PowerShell den standardmässiga, inbyggda Windows PowerShell-sessionskonfigurationen, kallad Microsoft.PowerShell. Standardkonfigurationen för sessioner inkluderar alla cmdlets som finns tillgängliga på en dator. Administratörer kan begränsa åtkomsten till alla datorer genom att definiera en sessionskonfiguration med ett begränsat runspace (ett begränsat antal cmdlets och uppgifter som deras slutanvändare kan utföra). En användare som har tillgång till en dator med antingen full språkåtkomst eller endast Windows PowerShell fjärrhanterings-cmdlets kan ansluta till andra datorer som är anslutna till den första datorn. Att definiera ett begränsat runspace kan förhindra att användare får tillgång till andra datorer från deras tillåtna Windows PowerShell-runspace och förbättrar säkerheten i din Windows PowerShell Web Access-miljö. Sessionskonfigurationen kan distribueras (genom att använda Group Policy) till alla datorer som administratörer vill göra tillgängliga via Windows PowerShell Web Access. Mer information om sessionskonfigurationer finns i about_Session_Configurations. Följande är några exempel på detta scenario.
En administratör skapar en endpoint, kallad PswaEndpoint, med ett begränsat runspace. Därefter skapar administratören en regel,
*,*,PswaEndpoint, och distribuerar slutpunkten till andra datorer. Regeln tillåter alla användare att komma åt alla datorer med endpointen PswaEndpoint. Om detta är den enda auktorisationsregeln som definieras i regeluppsättningen, skulle datorer utan den ändpunkten inte vara tillgängliga.Administratören skapade en endpoint med ett begränsat runspace kallat PswaEndpoint och vill begränsa åtkomsten till specifika användare. Administratören skapar en användargrupp kallad Level1Support och definierar följande regel: Level1Support,*,PswaEndpoint. Regeln ger alla användare i gruppen Level1Support tillgång till alla datorer med PswaEndpoint-konfigurationen . På samma sätt kan åtkomst begränsas till en specifik uppsättning datorer.
Vissa administratörer ger vissa användare mer tillgång än andra. Till exempel skapar en administratör två användargrupper, Admins och BasicSupport. Administratören skapar också en endpoint med ett begränsat runspace som kallas PswaEndpoint, och definierar följande två regler: Admins,*,* och BasicSupport,*,PswaEndpoint. Den första regeln ger alla användare i Admin-gruppen tillgång till alla datorer, och den andra regeln ger alla användare i BasicSupport-gruppen endast tillgång till de datorer med PswaEndpoint.
En administratör har satt upp en privat testmiljö och vill ge alla auktoriserade nätverksanvändare tillgång till alla datorer i nätverket som de vanligtvis har tillgång till, samt alla sessionskonfigurationer som de vanligtvis har tillgång till. Eftersom detta är en privat testmiljö skapar administratören en auktorisationsregel som inte är säker. - Administratören kör cmdleten
Add-PswaAuthorizationRule * * *, som använder jokertecken * för att representera alla användare, alla datorer och alla konfigurationer. - Denna regel motsvarar följande:Add-PswaAuthorizationRule -UserName * -ComputerName * -ConfigurationName *.Anmärkning
Denna regel rekommenderas inte i en säker miljö och kringgår det säkerhetslager av auktorisationsregler som tillhandahålls av Windows PowerShell Web Access.
En administratör måste tillåta användare att ansluta till måldatorer i en miljö som inkluderar både arbetsgrupper och domäner, där arbetsgruppsdatorer ibland används för att ansluta till måldatorer inom domäner, och datorer i domäner ibland används för att ansluta till måldatorer i arbetsgrupper. Administratören har en gateway-server, PswaServer, i en arbetsgrupp; och måldatorn srv1.contoso.com befinner sig i en domän. Användaren Chris är en auktoriserad lokal användare både på arbetsgruppens gatewayserver och måldatorn. Hans användarnamn på arbetsgruppsservern är chrisLocal; Och hans användarnamn på måldatorn är Contoso\chris. För att ge Chris åtkomst till srv1.contoso.com lägger administratören till följande regel.
Add-PswaAuthorizationRule -userName PswaServer\chrisLocal `
-computerName srv1.contoso.com -configurationName Microsoft.PowerShell
Förestående regelexempel autentiserar Chris på gateway-servern och auktoriserar sedan hans åtkomst till srv1. På inloggningssidan måste Chris ange en andra uppsättning uppgifter i området för valfria anslutningsinställningar (contoso\chris). Gateway-servern använder den extra uppsättningen av inloggningsuppgifter för att autentisera honom på måldatorn, srv1.contoso.com.
I det föregående scenariot upprättar Windows PowerShell Web Access en lyckad anslutning till måldatorn först efter att följande har lyckats och tillåtits av minst en auktorisationsregel.
Autentisering på arbetsgruppens gateway-server genom att lägga till ett användarnamn i formatet server_name user_name\ till auktorisationsregeln
Autentisering på måldatorn genom att använda alternativa inloggningsuppgifter som finns på inloggningssidan, i området Valfria anslutningsinställningar
Anmärkning
Om gateway- och måldatorer tillhör olika arbetsgrupper eller domäner måste en förtroenderelation upprättas mellan de två arbetsgruppsdatorerna, de två domänerna eller mellan arbetsgruppen och domänen. Denna relation kan inte konfigureras med Windows PowerShell Web Access auktoriseringsregel-cmdlets. Auktorisationsregler definierar inte en förtroenderelation mellan datorer; De kan endast ge användare behörighet att ansluta till specifika måldatorer och sessionskonfigurationer. För mer information om hur man konfigurerar en förtroenderelation mellan olika domäner, se Skapa domäner och skogsförtroenden. För mer information om hur man lägger till arbetsgruppsdatorer i en lista över betrodda värdar, se Remote Management with Server Manager.
Att använda en enda uppsättning auktorisationsregler för flera platser
Auktoriseringsregler lagras i en XML-fil. Som standard är $env:windir\Web\PowershellWebAccess\data\AuthorizationRules.xmlsökvägsnamnet för XML-filen .
Sökvägen till XML-filen för auktorisationsregler lagras i filenpowwa.config , som finns i $env:windir\Web\PowershellWebAccess\data. Administratören har flexibilitet att ändra referensen till standardsökvägen i powwa.config för att passa preferenser eller krav. Att låta administratören ändra filens plats låter flera Windows PowerShell Web Access-gateways använda samma auktoriseringsregler, om en sådan konfiguration önskas.
Sessionshantering
Som standard begränsar Windows PowerShell Web Access en användare till tre sessioner åt gången. Du kan redigera webbapplikationens web.config-fil i IIS Manager för att stödja ett annat antal sessioner per användare. Vägen till web.config filen är $env:windir\Web\PowerShellWebAccess\wwwroot\Web.config.
Som standard är IIS Web Server konfigurerad att starta om applikationspoolen om några inställningar ändras. Till exempel startas applikationspoolen om om ändringar görs i web.config-filen . >Eftersom Windows PowerShell Web Access använder sessionstillstånd i minnet, >förlorar användare som är inloggade på Windows PowerShell Web Access-sessioner sina sessioner när applikationspoolen startas om.
Inställning av standardparametrar på inloggningssidan
Om din Windows PowerShell Web Access-gateway körs på Windows Server 2012 R2 kan du konfigurera standardvärden för de inställningar som visas på inloggningssidan för Windows PowerShell Web Access. Du kan konfigurera värden i denweb.config fil som beskrivs i föregående stycke. Standardvärden för inloggningssidans inställningar finns i appSettings-sektionen i web.config-filen; Följande är ett exempel på avsnittet appSettings. Giltiga värden för många av dessa inställningar är desamma som för motsvarande parametrar i New-PSSession-cmdleten i Windows PowerShell.
Till exempel är nyckeln defaultApplicationName , som visas i följande kodblock, värdet på den $PSSessionApplicationName preferensvariabeln på måldatorn.
<appSettings>
<add key="maxSessionsAllowedPerUser" value="3"/>
<add key="defaultPortNumber" value="5985"/>
<add key="defaultSSLPortNumber" value="5986"/>
<add key="defaultApplicationName" value="WSMAN"/>
<add key="defaultUseSslSelection" value="0"/>
<add key="defaultAuthenticationType" value="0"/>
<add key="defaultAllowRedirection" value="0"/>
<add key="defaultConfigurationName" value="Microsoft.PowerShell"/>
</appSettings>
Time-outs och oplanerade frånkopplingar
Windows PowerShell Web Access-sessioner går ut i timeout. I Windows PowerShell Web Access som körs på Windows Server 2012 visas ett time-out-meddelande för inloggade användare efter 15 minuters sessionsinaktivitet. Om användaren inte svarar inom fem minuter efter att timeout-meddelandet visats avslutas sessionen och användaren loggas ut. Du kan ändra timeout-perioder för sessioner i webbplatsinställningarna i IIS Manager.
I Windows PowerShell Web Access som körs på Windows Server 2012 R2, upphör sessionerna som standard efter 20 minuters inaktivitet. Om användare kopplas bort från sessioner i webbkonsolen på grund av nätverksfel eller andra oplanerade avstängningar eller fel, och inte för att de själva har stängt sessionerna, fortsätter Windows PowerShell Web Access-sessionerna att köras, anslutna till måldatorer, tills timeout-perioden på klientsidan löper ut. Sessionen kopplas bort efter antingen standardtiden på 20 minuter eller efter den tidsavslutning som gatewayadministratören angett, beroende på vilket som är kortast.
Om gateway-servern kör Windows Server 2012 R2 låter Windows PowerShell Web Access användare återansluta till sparade sessioner vid ett senare tillfälle, men när nätverksfel, oplanerade avstängningar eller andra fel kopplar bort sessionerna, kan användare inte se eller återansluta till sparade sessioner förrän efter att den tidsavslutning som gatewayadministratören angett har löpt ut.