Autorisatieregels en beveiligingsfuncties van Windows PowerShell-internettoegangAuthorization Rules and Security Features of Windows PowerShell Web Access

Bijgewerkte: 24 juni 2013Updated: June 24, 2013

Van toepassing op: Windows Server 2012 R2, WindowsServer 2012Applies To: Windows Server 2012 R2, Windows Server 2012

Windows PowerShell Web Access in Windows Server 2012 R2 en Windows Server 2012 heeft een beperkend beveiligingsmodel.Windows PowerShell Web Access in Windows Server 2012 R2 and Windows Server 2012 has a restrictive security model. Gebruikers moeten expliciet toegang worden verleend voordat ze kunnen zich bij de Windows PowerShell Web Access-gateway aanmelden en de Windows PowerShell webgebaseerde console gebruiken.Users must explicitly be granted access before they can sign in to the Windows PowerShell Web Access gateway and use the web-based Windows PowerShell console.

Autorisatieregels en sitebeveiliging configurerenConfiguring authorization rules and site security

Nadat Windows PowerShell-webtoegang is geïnstalleerd en de gateway is geconfigureerd, kunnen gebruikers de aanmeldingspagina openen in een browser, maar ze zich niet aanmelden totdat de Windows PowerShell Web Access-beheerder gebruikers toegang expliciet verleent.After Windows PowerShell Web Access is installed and the gateway is configured, users can open the sign-in page in a browser, but they cannot sign in until the Windows PowerShell Web Access administrator grants users access explicitly. 'Windows PowerShell Web Access' toegangsbeheer wordt beheerd met behulp van de set Windows PowerShell-cmdlets in de volgende tabel beschreven.'Windows PowerShell Web Access' access control is managed by using the set of Windows PowerShell cmdlets described in the following table. Er is geen vergelijkbare grafische gebruikersinterface voor het toevoegen of beheren van autorisatieregels.There is no comparable GUI for adding or managing authorization rules. Zie Windows PowerShell Web Access Cmdlets.See Windows PowerShell Web Access Cmdlets.

Beheerders kunnen definiëren 0 - n verificatieregels voor Windows PowerShell Web Access.Administrators can define 0-n authentication rules for Windows PowerShell Web Access. De standaardbeveiliging is beperkend, niet toelatend. Als er geen verificatieregels zijn, heeft geen enkele gebruiker toegang tot iets.The default security is restrictive rather than permissive; zero authentication rules means no users have access to anything.

Add-PswaAuthorizationRule en Test-PswaAuthorizationRule in Windows Server 2012 R2 bevatten de parameter Credential waarmee u toevoegen en testen van Windows PowerShell-webtoegang autorisatieregels van een externe computer, of uit binnen een actieve sessie voor Windows PowerShell Web Access.Add-PswaAuthorizationRule and Test-PswaAuthorizationRule in Windows Server 2012 R2 include a Credential parameter that allows you to add and test Windows PowerShell Web Access authorization rules from a remote computer, or from within an active Windows PowerShell Web Access session. Als kunt andere Windows PowerShell-cmdlets die u een referentieparameter hebt u een PSCredential-object opgeven als de waarde van de parameter.As with other Windows PowerShell cmdlets that have a Credential parameter, you can specify a PSCredential object as the value of the parameter. U maakt een PSCredential-object met de referenties die u wilt doorgeven aan een externe computer, voeren de Get-Credential cmdlet.To create a PSCredential object that contains credentials you want to pass to a remote computer, run the Get-Credential cmdlet.

Windows PowerShell-webtoegang verificatieregels zijn regels van de goedgekeurde IP-adressen.Windows PowerShell Web Access authentication rules are whitelist rules. Elke regel is een definitie van een toegestane verbinding tussen gebruikers, doelcomputers en bepaalde Windows-PowerShell sessieconfiguraties (ook wel eindpunten of runspaces) op opgegeven doelcomputers.Each rule is a definition of an allowed connection between users, target computers, and particular Windows PowerShell session configurations (also referred to as endpoints or runspaces) on specified target computers. Voor een uitleg op runspaces Zie begin gebruik van PowerShell RunspacesFor an explanation on runspaces see Beginning Use of PowerShell Runspaces

Opmerking over beveiligingSecurity Note

Voor een gebruiker hoeft slechts één regel waar te zijn om ervoor te zorgen dat hij of zij toegang krijgt.A user needs only one rule to be true to get access. Als een gebruiker toegang tot een computer met volledige taaltoegang of alleen toegang tot Windows PowerShell cmdlets voor extern beheer van de webconsole krijgt, kunt de gebruiker aanmelden (of springen) naar andere computers die zijn verbonden met de eerste doelcomputer.If a user is given access to one computer with either full language access or access only to Windows PowerShell remote management cmdlets, from the web-based console, the user can log on (or hop) to other computers that are connected to the first target computer. De veiligste manier voor het configureren van Windows PowerShell-webtoegang is dat gebruikers alleen toegang tot beperkte sessieconfiguraties waarmee ze specifieke taken die ze normaal op afstand moeten uitvoeren.The most secure way to configure Windows PowerShell Web Access is to allow users access only to constrained session configurations that allow them to accomplish specific tasks that they normally need to perform remotely.

De cmdlets waarnaar wordt verwezen in Windows PowerShell Web Access Cmdlets toestaan voor het maken van een reeks toegangsregels die worden gebruikt voor het autoriseren van een gebruiker op de Windows PowerShell Web Access-gateway.The cmdlets referenced in Windows PowerShell Web Access Cmdlets allow to create a set of access rules which are used to authorize a user on the Windows PowerShell Web Access gateway. De regels verschillen van de toegangsbeheerlijsten (ACL’s) op de doelcomputer en bieden een extra beveiligingslaag voor internettoegang.The rules are different from the access control lists (ACLs) on the destination computer, and provide an additional layer of security for web access. Meer informatie over beveiliging vindt u in het volgende gedeelte.More details about security are described in the following section.

Als gebruikers niet een van de voorgaande beveiligingslagen doorgeven, ontvangen ze een algemeen 'toegang geweigerd'-bericht in hun browservensters.If users cannot pass any of the preceding security layers, they receive a generic 'access denied' message in their browser windows. Hoewel beveiligingsgegevens worden geregistreerd op de gatewayserver, zien eindgebruikers geen informatie over hoeveel beveiligingslagen ze zijn gepasseerd of op welke laag de aanmeldings- of verificatiefout is opgetreden.Although security details are logged on the gateway server, end users are not shown information about how many security layers they passed, or at which layer the sign-in or authentication failure occurred.

Zie voor meer informatie over het configureren van autorisatieregels autorisatieregels configureren in dit onderwerp.For more information about configuring authorization rules, see configuring authorization rules in this topic.

BeveiligingSecurity

Het beveiligingsmodel van Windows PowerShell-internettoegang heeft vier lagen tussen een eindgebruiker van de webconsole en een doelcomputer.The Windows PowerShell Web Access security model has four layers between an end user of the web-based console, and a target computer. Windows PowerShell Web Access-beheerders kunnen beveiligingslagen toevoegen via aanvullende configuratie in de console IIS-beheer.Windows PowerShell Web Access administrators can add security layers through additional configuration in the IIS Manager console. Zie voor meer informatie over het beveiligen van websites in IIS-beheerconsole, Configure Web Server Security (IIS 7).For more information about securing websites in the IIS Manager console, see Configure Web Server Security (IIS 7). Voor meer informatie over IIS best practices en het voorkomen van denial of service-aanvallen, Zie Best Practices voor voorkomen van DoS/tot Denial Service-aanvallen.For more information about IIS best practices and preventing denial-of-service attacks, see Best Practices for Preventing DoS/Denial of Service Attacks. Een beheerder kan ook kopen en installeren van extra retail verificatiesoftware.An administrator can also buy and install additional retail authentication software.

In de volgende tabel worden de vier beveiligingslagen tussen eindgebruikers en doelcomputers beschreven.The following table describes the four layers of security between end users and target computers.

NiveauLevel LaagLayer
11 beveiligingsfuncties voor IIS-webserversiis web server security features
22 Windows powershell web access op formulieren gebaseerde gatewayverificatiewindows powershell web access forms-based gateway authentication
33 Windows powershell web access-autorisatieregelswindows powershell web access authorization rules
44 doel-verificatie en autorisatie-regelstarget authentication and authorization rules

Onder de volgende rubrieken vindt u gedetailleerde informatie over elke laag:Detailed information about each layer can be found under the following headings:

Beveiligingsfuncties van IIS-webserverIIS Web Server security features

Gebruikers van Windows PowerShell-webtoegang moeten altijd een gebruikersnaam en wachtwoord voor hun account op de gateway verificatie opgeven.Windows PowerShell Web Access users must always provide a user name and password to authenticate their accounts on the gateway. Echter dat Windows PowerShell-webtoegang beheerders ook verificatie van clientcertificaten desgewenst kunnen inschakelen of uitschakelen, Zie installeren en gebruiken van windows powershell-webtoegang een testcertificaat inschakelen en hoger, het configureren van een legitiem certificaat).However, Windows PowerShell Web Access administrators can also turn optional client certificate authentication on or off, see install and use windows powershell web access to enable a test certificate and, later, how to configure a genuine certificate).

De optionele functie voor clientcertificaten vereist dat eindgebruikers beschikken over een geldig clientcertificaat naast hun gebruikersnaam en wachtwoord en maakt deel uit van de webserverconfiguratie (IIS).The optional client certificate feature requires end users to have a valid client certificate, in addition to their user names and passwords, and is part of Web Server (IIS) configuration. Als de clientcertificaatlaag is ingeschakeld, vraagt de aanmeldingspagina van Windows PowerShell-webtoegang gebruikers een geldig certificaat voordat hun aanmeldingsreferenties worden geëvalueerd.When the client certificate layer is enabled, the Windows PowerShell Web Access sign-in page prompts users to provide valid certificates before their sign-in credentials are evaluated. Bij verificatie van clientcertificaten wordt het clientcertificaat automatisch gecontroleerd.Client certificate authentication automatically checks for the client certificate. Als een geldig certificaat niet wordt gevonden, informeert Windows PowerShell-webtoegang gebruikers, zodat ze voor het certificaat leveren kunnen.If a valid certificate is not found, Windows PowerShell Web Access informs users, so they can provide the certificate. Als een geldig clientcertificaat wordt gevonden, wordt de aanmeldingspagina voor gebruikers om toegang te bieden hun gebruikersnamen en wachtwoorden in Windows PowerShell Web Access geopend.If a valid client certificate is found, Windows PowerShell Web Access opens the sign-in page for users to provide their user names and passwords.

Dit is een voorbeeld van aanvullende beveiligingsinstellingen die worden aangeboden via IIS-webserver.This is one example of additional security settings that are offered by IIS Web Server. Zie voor meer informatie over andere IIS-beveiligingsfuncties Configure Web Server Security (IIS 7)For more information about other IIS security features, see Configure Web Server Security (IIS 7)

Verificatie van Windows PowerShell Web Access-gateway op basis van formulierenWindows PowerShell Web Access forms-based gateway authentication

De aanmeldingspagina van Windows PowerShell-webtoegang vereist een set referenties (gebruikersnaam en wachtwoord) en biedt gebruikers de mogelijkheid om andere referenties te bieden voor de doelcomputer.The Windows PowerShell Web Access sign-in page requires a set of credentials (user name and password) and offers users the option of providing different credentials for the target computer. Als de gebruiker geen alternatieve referenties opgeeft, worden de primaire gebruikersnaam en het primaire wachtwoord die worden gebruikt om verbinding te maken met de gateway, ook gebruikt om verbinding te maken met de doelcomputer.If the user does not provide alternate credentials, the primary user name and password that are used to connect to the gateway are also used to connect to the target computer.

De vereiste referenties worden geverifieerd op de Windows PowerShell Web Access-gateway.The required credentials are authenticated on the Windows PowerShell Web Access gateway. Deze referenties moeten geldige gebruikersaccounts op de lokale Windows PowerShell Web Access-gatewayserver of in Active Directory zijn.These credentials must be valid user accounts on either the local Windows PowerShell Web Access gateway server, or in Active Directory.

Autorisatieregels voor Windows PowerShell-webtoegangWindows PowerShell Web Access authorization rules

Nadat een gebruiker is geverifieerd op de gateway, controleert Windows PowerShell-webtoegang autorisatieregels om te controleren of de gebruiker toegang tot de gevraagde doelcomputer heeft.After a user is authenticated at the gateway, Windows PowerShell Web Access checks authorization rules to verify if the user has access to the requested target computer. Na een geslaagde autorisatie worden referenties van de gebruiker doorgegeven aan de doelcomputer.After successful authorization, the user's credentials are passed along to the target computer.

Deze regels worden pas geëvalueerd nadat een gebruiker is geverifieerd door de gateway en voordat een gebruiker kan worden geverifieerd op een doelcomputer.These rules are evaluated only after a user has been authenticated by the gateway, and before a user can be authenticated on a target computer.

Verificatie- en autorisatieregels van de doelcomputerTarget authentication and authorization rules

De laatste beveiligingslaag voor Windows PowerShell-internettoegang is de beveiligingsconfiguratie voor doel van het computer.The final layer of security for Windows PowerShell Web Access is the target computer's own security configuration. Gebruikers moeten de juiste toegangsrechten op de doelcomputer en ook in de Windows PowerShell Web Access-autorisatieregels geconfigureerd om uit te voeren van een Windows PowerShell-webconsole die van invloed op een doelcomputer via Windows PowerShell-webtoegang hebben.Users must have the appropriate access rights configured on the target computer, and also in the Windows PowerShell Web Access authorization rules, to run a Windows PowerShell web-based console that affects a target computer through Windows PowerShell Web Access.

Deze laag biedt dezelfde beveiligingsmechanismen die evalueren verbindingspogingen als gebruikers proberen een externe Windows PowerShell-sessie met een doelcomputer van Windows PowerShell maken door het uitvoeren van de Enter-PSSession of New-PSSession cmdlets.This layer offers the same security mechanisms that would evaluate connection attempts if users tried to create a remote Windows PowerShell session to a target computer from within Windows PowerShell by running the Enter-PSSession or New-PSSession cmdlets.

Standaard gebruikt Windows PowerShell Web Access de primaire gebruikersnaam en het wachtwoord voor verificatie op de gateway en de doelcomputer.By default, Windows PowerShell Web Access uses the primary user name and password for authentication on both the gateway and the target computer. Het web gebaseerde aanmeldingspagina, in de sectie optionele verbindingsinstellingen, biedt gebruikers de mogelijkheid om andere referenties te bieden voor de doelcomputer maken als ze vereist zijn.The web-based sign-in page , in a section titled Optional connection settings, offers users the option of providing different credentials for the target computer , if they are required. Als de gebruiker geen alternatieve referenties opgeeft, worden ook de primaire gebruikersnaam en het wachtwoord die worden gebruikt voor het verbinding maken met de gateway gebruikt voor het verbinding maken met de doelcomputer.If the user does not provide alternate credentials , the primary user name and password that are used to connect to the gateway are also used to connect to the target computer.

Autorisatieregels kunnen worden gebruikt om gebruikers toegang te verlenen tot een bepaalde sessieconfiguratie.Authorization rules can be used to allow users access to a particular session configuration. U kunt maken beperkte runspaces of sessieconfiguraties voor Windows PowerShell-webtoegang en bepaalde gebruikers verbinding maken met alleen specifieke sessieconfiguraties wanneer ze zich bij Windows PowerShell-internettoegang aanmelden toestaan.You can create restricted runspaces or session configurations for Windows PowerShell Web Access , and allow specific users to connect only to specific session configurations when they sign in to Windows PowerShell Web Access. U kunt toegangsbeheerlijsten (ACL's) gebruiken om te bepalen welke gebruikers toegang hebben tot specifieke eindpunten en toegang tot het eindpunt voor een specifieke groep gebruikers verder beperken via autorisatieregels die in deze sectie beschreven.You can use access control lists (ACLs) to determine which users have access to specific endpoints , and further restrict access to the endpoint for a specific set of users by using authorization rules described in this section. Zie voor meer informatie over beperkte runspaces maken van een beperkte runspace.For more information about restricted runspaces, see Creating a constrained runspace.

Autorisatieregels configurerenConfiguring authorization rules

Beheerders willen waarschijnlijk dezelfde autorisatieregel voor Windows PowerShell Web Access-gebruikers die al is gedefinieerd in hun omgeving voor extern beheer van Windows PowerShell.Administrators likely want the same authorization rule for Windows PowerShell Web Access users that is already defined in their environment for Windows PowerShell remote management. De eerste procedure in deze sectie wordt beschreven hoe een veilige autorisatieregel waarmee toegang wordt verleend aan één gebruiker, aanmelding bij één computer beheren en binnen één sessieconfiguratie toevoegen.The first procedure in this section describes how to add a secure authorization rule that grants access to one user , signing in to manage one computer , and within a single session configuration. In de tweede procedure wordt beschreven hoe u een autorisatieregel verwijdert die niet meer nodig is.The second procedure describes how to remove an authorization rule that is no longer needed.

Als u van plan bent aangepaste sessieconfiguraties gebruiken om specifieke gebruikers werken binnen beperkte runspaces in Windows PowerShell Web Access in staat, maakt u uw aangepaste sessieconfiguraties voordat u autorisatieregels die naar deze verwijzen toevoegt.If you plan to use custom session configurations to allow specific users to work only within restricted runspaces in Windows PowerShell Web Access , create your custom session configurations before you add authorization rules that refer to them. U kunt de Windows PowerShell Web Access cmdlets niet gebruiken aangepaste sessieconfiguraties maken.You cannot use the Windows PowerShell Web Access cmdlets to create custom session configurations. Zie voor meer informatie over het maken van aangepaste sessieconfiguraties about_Session_Configuration_Files.For more information about creating custom session configurations , see about_Session_Configuration_Files.

Windows PowerShell Web Access cmdlets ondersteunen één jokerteken, een sterretje ( * ).Windows PowerShell Web Access cmdlets support one wildcard character , an asterisk ( * ). Jokertekens binnen tekenreeksen worden niet ondersteund. Gebruik één sterretje per eigenschap (gebruikers, computers of sessieconfiguraties).Wildcard characters within strings are not supported; use a single asterisk per property (users, computers, or session configurations).

OpmerkingNote

Voor Zie voor meer manieren kunt u autorisatieregels toegang te verlenen aan gebruikers en de Windows PowerShell Web Access-omgeving te beveiligen andere voorbeeldscenario's met autorisatieregels in dit onderwerp.For more ways you can use authorization rules to grant access to users and help secure the Windows PowerShell Web Access environment , see other authorization rule scenario examples in this topic.

Een beperkende autorisatieregel toevoegenTo add a restrictive authorization rule

  1. Doe het volgende om een Windows PowerShell-sessie met verhoogde gebruikersrechten te openen.Do one of the following to open a Windows PowerShell session with elevated user rights.

    • Het Windows-bureaublad met de rechtermuisknop op Windows PowerShell op de taakbalk en klik vervolgens op als Administrator uitvoeren.On the Windows desktop, right-click Windows PowerShell on the taskbar , and then click Run as Administrator.

    • Windows Start scherm, met de rechtermuisknop op Windows PowerShell , en klik vervolgens op als Administrator uitvoeren.On the Windows Start screen, right-click Windows PowerShell , and then click Run as Administrator.

  2. Optionele stap voor het beperken van gebruikerstoegang met behulp van sessieconfiguraties:Optional step For restricting user access by using session configurations:

    Controleren of de sessieconfiguraties die u wilt gebruiken, al in uw regels bestaan.Verify that the session configurations that you want to use , already exist in your rules . Als ze nog geen hebt is gemaakt, gebruikt u instructies voor het maken van sessieconfiguraties in about_Session_Configuration_Files.If they have not yet been created , use instructions for creating session configurations in about_Session_Configuration_Files.

  3. Deze autorisatieregel verleent een bepaalde gebruikerstoegang tot een computer op het netwerk waartoe ze gewoonlijk toegang hebben, met toegang tot een bepaalde sessieconfiguratie die is afgestemd op de gebruiker '™ s typische scripting- en cmdlet-behoeften.This authorization rule allows a specific user access to one computer on the network to which they typically have access, with access to a specific session configuration that is scoped to the user'™s typical scripting and cmdlet needs. Typ het volgende en druk vervolgens op Enter.Type the following, and then press Enter.

Add-PswaAuthorizationRule -UserName <domain\user | computer\user> -ComputerName <computer_name> -ConfigurationName <session_configuration_name>
  • In het volgende voorbeeld wordt een gebruiker met de naam JSmith in de Contoso domein krijgt toegangsrechten voor het beheren van de computer Contoso_214, en een sessieconfiguratie genaamd gebruiken NewAdminsOnly.In the following example, a user named JSmith in the Contoso domain is granted access to manage the computer Contoso_214, and use a session configuration named NewAdminsOnly.
Add-PswaAuthorizationRule -UserName 'Contoso\JSmith' -ComputerName Contoso_214 -ConfigurationName NewAdminsOnly
  1. Controleer of dat de regel is gemaakt door de Get-PswaAuthorizationRule -cmdlet of Test-PswaAuthorizationRule - UserName <domein\gebruiker | computer\ gebruiker> - ComputerName <computer_name>.Verify that the rule has been created by running either the Get-PswaAuthorizationRule cmdlet, or Test-PswaAuthorizationRule -UserName <domain\user | computer\user> -ComputerName <computer_name>. Bijvoorbeeld: Test-PswaAuthorizationRule - UserName Contoso\JSmith - ComputerName Contoso_214.For example, Test-PswaAuthorizationRule -UserName Contoso\JSmith -ComputerName Contoso_214.

Een autorisatieregel verwijderenTo remove an authorization rule

  1. Als een Windows PowerShell-sessie nog niet is geopend, raadpleegt u stap 1 van een beperkende autorisatieregel toevoegen in deze sectie.If a Windows PowerShell session is not already open, see step 1 of to add a restrictive authorization rule in this section.

  2. Typ het volgende en druk vervolgens op Enter, waarbij regel-ID vertegenwoordigt de unieke id van de regel die u wilt verwijderen.Type the following, and then press Enter, where rule ID represents the unique ID number of the rule that you want to remove.

Remove-PswaAuthorizationRule -ID <rule ID>

U kunt ook als u de ID-nummer niet kent maar wel de beschrijvende naam van de regel die u wilt verwijderen, u kunt de naam van de regel en doorgeven aan de Remove-PswaAuthorizationRule cmdlet om te verwijderen van de regel, zoals wordt weergegeven in het volgende voorbeeld: Get-PswaAuthorizationRule -RuleName <rule-name> | Remove-PswaAuthorizationRule.Alternatively, if you do not know the ID number, but know the friendly name of the rule you want to remove, you can get the name of the rule, and pipe it to the Remove-PswaAuthorizationRule cmdlet to remove the rule, as shown in the following example: Get-PswaAuthorizationRule -RuleName <rule-name> | Remove-PswaAuthorizationRule.

Opmerking:Note:

U wordt niet gevraagd te bevestigen of u wilt verwijderen van de opgegeven autorisatieregel; de regel wordt verwijderd wanneer u op Enter.You are not prompted to confirm whether you want to delete the specified authorization rule; the rule is deleted when you press Enter. Wees er zeker van dat u de autorisatieregel wilt verwijderen voordat u de cmdlet Remove-PswaAuthorizationRule uitvoert.Be sure that you want to remove the authorization rule before running the Remove-PswaAuthorizationRule cmdlet.

Andere voorbeeldscenario’s met autorisatieregelsOther authorization rule scenario examples

Elke Windows PowerShell-sessie gebruikt een sessieconfiguratie; Als er een is niet opgegeven voor een sessie, Windows PowerShell gebruikt het standaard ingebouwde Windows PowerShell, sessieconfiguratie genaamd Microsoft.PowerShell.Every Windows PowerShell session uses a session configuration; if one is not specified for a session, Windows PowerShell uses the default, built-in Windows PowerShell session configuration, called Microsoft.PowerShell. De standaardsessieconfiguratie bevat alle cmdlets die beschikbaar zijn op een computer.The default session configuration includes all cmdlets that are available on a computer. Beheerders kunnen de toegang tot alle computers beperken door een sessieconfiguratie met een beperkte runspace (een beperkt aantal cmdlets en taken die eindgebruikers kunnen uitvoeren) te definiëren.Administrators can restrict access to all computers by defining a session configuration with a restricted runspace (a limited range of cmdlets and tasks that their end users could perform). Een gebruiker die toegang tot een computer met volledige taaltoegang of alleen de Windows PowerShell extern beheer-cmdlets kunt verbinden met andere computers die zijn verbonden met de eerste computer.A user who is granted access to one computer with either full language access or only the Windows PowerShell remote management cmdlets can connect to other computers that are connected to the first computer. Een beperkte runspace definiëren kunnen voorkomen dat gebruikers toegang krijgen tot andere computers vanuit hun toegestane Windows PowerShell-runspace en verbetert de beveiliging van uw Windows PowerShell Web Access-omgeving.Defining a restricted runspace can prevent users from accessing other computers from their allowed Windows PowerShell runspace, and improves the security of your Windows PowerShell Web Access environment. De sessieconfiguratie kan (via Groepsbeleid) worden gedistribueerd naar alle computers die beheerders toegankelijk willen maken via Windows PowerShell-webtoegang.The session configuration can be distributed (by using Group Policy) to all computers that administrators want to make accessible through Windows PowerShell Web Access. Zie voor meer informatie over sessieconfiguraties about_Session_Configurations.For more information about session configurations, see about_Session_Configurations. Hier volgen enkele voorbeelden van dit scenario.The following are some examples of this scenario.

  • Een beheerder maakt een eindpunt met de naam Pswaeindpunt, met een beperkte runspace.An administrator creates an endpoint, called PswaEndpoint, with a restricted runspace. En vervolgens de beheerder een regel maakt *,*, Pswaeindpunt, en distribueert het eindpunt naar andere computers.Then, the administrator creates a rule, *,*,PswaEndpoint, and distributes the endpoint to other computers. De regel verleent alle gebruikers toegang tot alle computers met het eindpunt Pswaeindpunt.The rule allows all users to access all computers with the endpoint PswaEndpoint. Als dit de enige autorisatieregel is die is gedefinieerd in de regelset, zijn computers zonder dat eindpunt niet toegankelijk.If this is the only authorization rule defined in the rule set, computers without that endpoint would not be accessible.

  • De beheerder een eindpunt worden gemaakt met een beperkte runspace genaamd Pswaeindpunt, en wil de toegang beperken tot specifieke gebruikers.The administrator created an endpoint with a restricted runspace called PswaEndpoint,and wants to restrict access to specific users. De beheerder maakt een groep gebruikers genaamd Level1Support, en definieert de volgende regel: Level1Support,*, Pswaeindpunt.The administrator creates a group of users called Level1Support, and defines the following rule: Level1Support,*,PswaEndpoint. De regel verleent alle gebruikers in de groep Level1Support toegang tot alle computers met de Pswaeindpunt configuratie.The rule grants any users in the group Level1Support access to all computers with the PswaEndpoint configuration. Op vergelijkbare wijze kan de toegang worden beperkt tot een specifieke set computers.Similarly, access can be restricted to a specific set of computers.

  • Sommige beheerders bieden bepaalde gebruikers uitgebreidere toegang dan andere.Some administrators provide certain users more access than others. Een beheerder maakt bijvoorbeeld twee gebruikersgroepen, Admins en basisondersteuning.For example, an administrator creates two user groups, Admins and BasicSupport. De beheerder maakt ook een eindpunt met een beperkte runspace genaamd Pswaeindpunt, en definieert de volgende twee regels: beheerders,*,\* en Basisondersteuning,*, Pswaeindpunt.The administrator also creates an endpoint with a restricted runspace called PswaEndpoint, and defines the following two rules: Admins,*,\* and BasicSupport,*,PswaEndpoint. De eerste regel biedt alle gebruikers in de Admin groepstoegang tot alle computers en de tweede regel biedt alle gebruikers in de basisondersteuning groep alleen toegang tot computers met Pswaeindpunt.The first rule provides all users in the Admin group access to all computers, and the second rule provides all users in the BasicSupport group access only to those computers with PswaEndpoint.

  • Een beheerder heeft een besloten testomgeving ingesteld en wil alle geautoriseerde netwerkgebruikers toegang geven tot alle computers in het netwerk waartoe ze gewoonlijk toegang hebben, met toegang tot alle sessieconfiguraties waartoe ze gewoonlijk toegang hebben.An administrator has set up a private test environment, and wants to allow all authorized network users access to all computers on the network to which they typically have access, with access to all session configurations to which they typically have access. Omdat dit een besloten testomgeving is, maakt de beheerder een autorisatieregel die niet veilig is.Because this is a private test environment, the administrator creates an authorization rule that is not secure.

    • De beheerder voert de cmdlet Add-PswaAuthorizationRule * * *, waarin het jokerteken \* voor alle gebruikers alle computers en alle configuraties.The administrator runs the cmdlet Add-PswaAuthorizationRule * * *, which uses the wildcard character \* to represent all users, all computers, and all configurations.
    • Deze regel komt overeen met het volgende: Add-PswaAuthorizationRule -UserName * -ComputerName * -ConfigurationName *.This rule is the equivalent of the following: Add-PswaAuthorizationRule -UserName * -ComputerName * -ConfigurationName *.

    Opmerking:Note:

    Deze regel wordt niet aanbevolen in een beveiligde omgeving en omzeilt de beveiligingslaag autorisatie beveiliging van Windows PowerShell Web Access.This rule is not recommended in a secure environment, and bypasses the authorization rule layer of security provided by Windows PowerShell Web Access.

  • Een beheerder moet gebruikers toestaan verbinding te maken met doelcomputers in een omgeving met zowel werkgroepen als domeinen, waarbij werkgroepcomputers af en toe worden gebruikt om verbinding te maken met doelcomputers in domeinen en computers in domeinen af en toe worden gebruikt om verbinding te maken met doelcomputers in werkgroepen.An administrator must allow users to connect to target computers in an environment that includes both workgroups and domains, where workgroup computers are occasionally used to connect to target computers in domains, and computers in domains are occasionally used to connect to target computers in workgroups. De beheerder heeft een gatewayserver PswaServer, in een werkgroep en de doelcomputer srv1.contoso.com zich in een domein.The administrator has a gateway server, PswaServer, in a workgroup; and target computer srv1.contoso.com is in a domain. Gebruiker Chris is een geautoriseerde lokale gebruiker op zowel de gatewayserver werkgroep als de doelcomputer.User Chris is an authorized local user on both the workgroup gateway server and the target computer. Zijn gebruikersnaam op de werkgroepserver is chrisLocal; en zijn gebruikersnaam op de doelcomputer is contoso\chris.His user name on the workgroup server is chrisLocal; and his user name on the target computer is contoso\chris. De beheerder verleent Chris toegang tot srv1.contoso.com door de volgende regel toe te voegen.To authorize access to srv1.contoso.com for Chris, the administrator adds the following rule.

Add-PswaAuthorizationRule -userName PswaServer\chrisLocal -computerName srv1.contoso.com -configurationName Microsoft.PowerShell

Het vorige Regelvoorbeeld wordt voor Chris verificatie op de gatewayserver en dan toelaat zijn toegang tot srv1.The preceding rule example authenticates Chris on the gateway server, and then authorizes his access to srv1. Op de aanmeldingspagina moet Chris een tweede set referenties in opgeven. de optionele verbindingsinstellingen gebied (contoso\chris).On the sign-in page, Chris must provide a second set of credentials in the Optional connection settings area (contoso\chris). De gatewayserver gebruikt de aanvullende set referenties om hem te verifiëren op de doelcomputer srv1.contoso.com.The gateway server uses the additional set of credentials to authenticate him on the target computer, srv1.contoso.com.

Windows PowerShell-webtoegang stelt u een verbinding met de doelcomputer nadat het volgende geslaagd en is toegestaan door ten minste één autorisatieregel is in het voorgaande scenario.In the preceding scenario, Windows PowerShell Web Access establishes a successful connection to the target computer only after the following have been successful, and allowed by at least one authorization rule.

  1. Verificatie op de gatewayserver werkgroep door de naam van een gebruiker toe te voegen in de notatie servernaam\gebruikersnaam aan de autorisatieregelAuthentication on the workgroup gateway server by adding a user name in the format server_name\user_name to the authorization rule

  2. Verificatie op de doelcomputer met behulp van alternatieve referenties op de aanmeldingspagina in de optionele verbindingsinstellingen gebiedAuthentication on the target computer by using alternate credentials provided on the sign-in page, in the Optional connection settings area

    Opmerking:Note:

    Als de gateway en de doelcomputer zich in verschillende werkgroepen of domeinen bevinden, moet een vertrouwensrelatie tussen de twee werkgroepcomputers, de twee domeinen of de werkgroep en het domein worden ingesteld.If gateway and target computers are in different workgroups or domains, a trust relationship must be established between the two workgroup computers, the two domains, or between the workgroup and the domain. Deze relatie kan niet worden geconfigureerd met behulp van Windows PowerShell Web Access cmdlets voor autorisatieregels.This relationship cannot be configured by using Windows PowerShell Web Access authorization rule cmdlets. Autorisatieregels definiëren geen vertrouwensrelatie tussen computers. Ze kunnen enkel gebruikers toestaan verbinding te maken met specifieke doelcomputers en sessieconfiguraties.Authorization rules do not define a trust relationship between computers; they can only authorize users to connect to specific target computers and session configurations. Zie voor meer informatie over het configureren van een vertrouwensrelatie tussen verschillende domeinen Creating Domain and Forest Trusts.For more information about how to configure a trust relationship between different domains, see Creating Domain and Forest Trusts. Zie voor meer informatie over hoe u werkgroepcomputers toevoegt aan een lijst met vertrouwde hosts, extern beheer met ServerbeheerFor more information about how to add workgroup computers to a trusted hosts list, see Remote Management with Server Manager

Eén set autorisatieregels gebruiken voor meerdere sitesUsing a single set of authorization rules for multiple sites

Autorisatieregels worden opgeslagen in een XML-bestand.Authorization rules are stored in an XML file. De naam van het pad van het XML-bestand is standaard % windir %\Web\PowershellWebAccess\gegevens\AuthorizationRules.xml.By default, the path name of the XML file is %windir%\Web\PowershellWebAccess\data\AuthorizationRules.xml.

Het pad naar het XML-bestand met autorisatieregels wordt opgeslagen in de powwa.config bestand, dat is gevonden in % windir %\Web\PowershellWebAccess\gegevens.The path to the authorization rules XML file is stored in the powwa.config file, which is found in %windir%\Web\PowershellWebAccess\data. De beheerder heeft de flexibiliteit de verwijzing naar het standaardpad in wijzigen powwa.config op basis van voorkeuren of vereisten.The administrator has the flexibility to change the reference to the default path in powwa.config to suit preferences or requirements. De beheerder om de locatie van het bestand te wijzigen zodat kiest, kunnen meerdere Windows PowerShell-webtoegang gateways dezelfde autorisatieregels gebruiken indien zo'n configuratie gewenst is.Allowing the administrator to change the location of the file lets multiple Windows PowerShell Web Access gateways use the same authorization rules, if such a configuration is desired.

SessiebeheerSession management

Standaard beperkt de Windows PowerShell-webtoegang een gebruiker tot drie sessies tegelijk.By default, Windows PowerShell Web Access limits a user to three sessions at one time. U kunt de webtoepassing bewerken web.config bestand in IIS-beheer voor de ondersteuning van een verschillend aantal sessies per gebruiker.You can edit the web application's web.config file in IIS Manager to support a different number of sessions per user. Het pad naar de web.config bestand is $Env: Windir\Web\PowerShellWebAccess\wwwroot\Web.config.The path to the web.config file is $Env:Windir\Web\PowerShellWebAccess\wwwroot\Web.config.

IIS-webserver is standaard geconfigureerd om opnieuw te starten van de groep van toepassingen als u alle instellingen worden bewerkt.By default, IIS Web Server is configured to restart the application pool if any settings are edited. Bijvoorbeeld, de groep van toepassingen opnieuw wordt gestart als er wijzigingen zijn aangebracht aan de web.config bestand.For example, the application pool is restarted if changes are made to the web.config file.

Omdat Windows PowerShell-webtoegang de sessiestatus uit het geheugen gebruikt, raken gebruikers aangemeld bij Windows PowerShell-webtoegang sessies hun sessie wanneer de groep van toepassingen opnieuw wordt opgestart kwijt.Because Windows PowerShell Web Access uses in-memory session states, users signed in to Windows PowerShell Web Access sessions lose their sessions when the application pool is restarted.

Standaardparameters instellen op de aanmeldingspaginaSetting default parameters on the sign-in page

Als uw Windows PowerShell Web Access-gateway op Windows Server 2012 R2 wordt uitgevoerd, kunt u de standaardwaarden voor de instellingen die worden weergegeven op de aanmeldingspagina van Windows PowerShell-webtoegang configureren.If your Windows PowerShell Web Access gateway is running on Windows Server 2012 R2, you can configure default values for the settings that are displayed on the Windows PowerShell Web Access sign-in page. U kunt waarden configureren in de web.config -bestand dat wordt beschreven in de vorige alinea.You can configure values in the web.config file that is described in the preceding paragraph. Standaardwaarden voor de instellingen van de aanmeldingspagina zijn gevonden in de appSettings sectie van het bestand web.config; Hieronder volgt een voorbeeld van de appSettings sectie.Default values for the sign-in page settings are found in the appSettings section of the web.config file; the following is an example of the appSettings section. Geldige waarden voor veel van deze instellingen zijn hetzelfde als die voor de overeenkomstige parameters van de New-PSSession cmdlet in Windows PowerShell.Valid values for many of these settings are the same as those for the corresponding parameters of the New-PSSession cmdlet in Windows PowerShell. Bijvoorbeeld, de defaultApplicationName sleutel, zoals wordt weergegeven in het volgende codeblok, is de waarde van de $PSSessionApplicationName voorkeursvariabele op de doelcomputer.For example, the defaultApplicationName key, as shown in the following code block, is the value of the $PSSessionApplicationName preference variable on the target computer.

    <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 en niet-geplande afgebroken sessiesTime-outs and unplanned disconnections

Er is een time-out opgetreden voor de Windows PowerShell Web Access-sessies. In Windows PowerShell-webtoegang op Windows Server 2012 wordt uitgevoerd, een time-outbericht weergegeven aan gebruikers aangemeld na 15 minuten van inactiviteit in de sessie.Windows PowerShell Web Access sessions time out. In Windows PowerShell Web Access running on Windows Server 2012, A time-out message is displayed to signed-in users after 15 minutes of session inactivity. Als de gebruiker niet reageert binnen vijf minuten nadat het time-outbericht wordt weergegeven, wordt de sessie beëindigd en wordt de gebruiker afgemeld. U kunt de time-outperiode voor sessies wijzigen in de website-instellingen in IIS-beheer.If the user does not respond within five minutes after the time-out message is displayed, the session is ended, and the user is signed out. You can change time-out periods for sessions in the website settings in IIS Manager.

In Windows PowerShell Web Access uitgevoerd op Windows Server 2012 R2, time-outwaarde voor sessies, standaard na 20 minuten van inactiviteit.In Windows PowerShell Web Access running on Windows Server 2012 R2, sessions time out, by default, after 20 minutes of inactivity. Als gebruikers verbinding met sessies in de webconsole wordt verbroken vanwege netwerkfouten of andere niet-gepland afsluiten of fouten, en niet omdat ze de sessie zelf hebt gesloten, blijven de Windows PowerShell Web Access-sessies actief, verbonden met doelcomputers, totdat de time-outperiode op de client is verstreken.If users are disconnected from sessions in the web-based console because of network errors or other unplanned shutdowns or failures, and not because they have closed the sessions themselves, the Windows PowerShell Web Access sessions continue to run, connected to target computers, until the time-out period on the client side lapses. De sessie wordt beëindigd na de standaardperiode van 20 minuten of na de time-outperiode die is opgegeven door de beheerder van de gateway, afhankelijk van welke periode korter is.The session is disconnected after either the default 20 minutes, or after the time-out period specified by the gateway administrator, whichever is shorter.

Als de gateway-server wordt uitgevoerd van Windows Server 2012 R2, Windows PowerShell Web Access kunnen gebruikers opnieuw verbinding met maken opgeslagen sessies op een later tijdstip, maar wanneer netwerkfouten, niet-gepland afsluiten of andere fouten sessies loskoppelt, gebruikers niet zien of opnieuw verbinding maken met opgeslagen sessies pas na de time-outperiode die is opgegeven door de beheerder.If the gateway server is running Windows Server 2012 R2, Windows PowerShell Web Access lets users reconnect to saved sessions at a later time, but when network errors, unplanned shutdowns, or other failures disconnect sessions, users cannot see or reconnect to saved sessions until after the time-out period specified by the gateway administrator has lapsed.

Zie ookSee Also