> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/da/sikkerhed/security.md).

# Om

Konfigurer godkendelse og rollebaseret autorisation i PowerShell Universal, herunder claim-tilknytning, politikscripts og app-tokens.

## Godkendelse

Som standard tilbyder PowerShell Universal [lokal brugergodkendelse](/powershell-universal/da/sikkerhed/local-accounts.md). Brugernavne og krypterede adgangskoder gemmes i PowerShell Universal-databasen. I virksomhedsmiljøer kan De overveje at anvende godkendelsesmetoder, som Deres organisation understøtter.

* [Windows-enkeltlogon](/powershell-universal/da/sikkerhed/enterprise-security/windows-sso.md)
* [OpenID Connect](/powershell-universal/da/sikkerhed/enterprise-security/openid-connect.md)
* [SAML2](/powershell-universal/da/sikkerhed/enterprise-security/saml2.md)
* [WS-Federation](/powershell-universal/da/sikkerhed/enterprise-security/ws-federation.md)

## Autorisation

Brugerautorisation udføres med roller. Roller kan enten tildeles via tilknytning af claims, et politikscript eller ved at tildele rollen direkte til identiteten.

{% hint style="info" %}
Som standard modtager brugere ingen roller. Flere rolletildelinger er gyldige i PowerShell Universal.
{% endhint %}

### Tilknytning af rolle til claim

De kan knytte roller til et claim (f.eks. et gruppemedlemskab) ved hjælp af parametrene `-ClaimType` og `-ClaimValue` for `New-PSURole`. Indstillinger er også tilgængelige i dialogboksen for rollegenskaber under Secure > Roles.

Hvis De for eksempel med Windows-godkendelse vil knytte en gruppe til en rolle, kan De konfigurere det, så gruppens SID knyttes til administratorrollen.

{% code collapsedlinecount="10" %}

```powershell
New-PSURole -Name Administrator -ClaimType 'http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid' -ClaimValue 'S-123-123-123'
```

{% endcode %}

Tilknytning af roller til claims på denne måde er hurtigere end politikscripts, fordi det ikke kræver, at PowerShell køres, når brugeren logger på.

### Vis claimoplysninger

For at hjælpe med at udvikle politikscripts eller tildele roller til claims kan De se claimoplysninger ved at klikke på View Claim Information i Secure > Roles.

### Eksempel: Azure Active Directory

De kan knytte en Azure Active Directory-gruppe til en rolle ved at slå gruppens Object ID op i Azure. I Ironman Software-domænet har vi for eksempel en gruppe, der hedder Dashboard Administrators. Denne gruppe har object ID'et `61849bf2-e44b-4057-b589-6cd1812d7545`.

I PowerShell Universal kan jeg tildele brugere i denne gruppe til gruppen Administrator ved at konfigurere claimtilknytningen. Claim Type bliver `groups`, og Claim Value bliver `61849bf2-e44b-4057-b589-6cd1812d7545`. Når jeg har tilknyttet claimet, bliver brugere i gruppen Dashboard Administrators en del af gruppen PowerShell Universal Administrators. Den resulterende `roles.ps1` ser sådan ud.

Alle andre roller er deaktiveret.

{% code collapsedlinecount="10" %}

```powershell
New-PSURole -Name Administrator -ClaimType 'groups' -ClaimValue '61849bf2-e44b-4057-b589-6cd1812d7545'
New-PSURole -Name "Operator" -Description "Operators have access to manage and execute scripts, create other entities within PowerShell Universal but cannot manage PowerShell Universal itself." -Policy {} -Disabled
New-PSURole -Name "Reader" -Description "Readers have read-only access to PowerShell Universal. They cannot make changes to any entity within the system." -Policy { } -Disabled 
New-PSURole -Name "Execute" -Description "Execute scripts within PowerShell Universal." -Policy { } -Disabled
New-PSURole -Name "User" -Description "Does not have access to the admin console but can be assigned resources like APIs, scripts, dashboards and pages." -Policy { } -Disabled
```

{% endcode %}

### Tildeling af politik

Som standard tildeles roller af politikker. Politikker køres, når brugeren logger på. De kan ændre politikscriptene ved at gå til siden Secure > Roles. Klik på knappen Edit Code for at konfigurere Policy-scriptet.

Politikscripts modtager et `ClaimsPrincipal`-objekt som parameter og skal returnere true eller false. Politikker, der udløser fejl, antages at være false. Objektet `ClaimsPrincipal` indeholder brugerens identitet og de krav, som brugeren har modtaget. Disse kan omfatte gruppetildelinger eller andre funktioner på en brugers konto.

De kan forvente et objekt med denne struktur.

{% code collapsedlinecount="10" %}

```csharp
public class ClaimsPrincipal
{
    public List<Claim> Claims { get; set; } = new List<Claim>();
    public Identity Identity { get; set; } = new Identity();
}

public class Identity 
{
    public string Name { get ;set; }
}

public class Claim 
{
    public string Type { get; set; }  
    public string Value { get; set; }
    public string ValueType { get; set; } 
    public string Issuer { get; set; }
    public Dictionary<string, string> Properties { get; set; } = new Dictionary<string, string>();
}
```

{% endcode %}

### Rolletildeling

For at tildele en rolle til en bruger kan De oprette brugerens identitet i Universal og derefter vælge rollen i rullelisten på siden Identities.

Som standard modtager identiteter en rolle via claimtilknytning eller politik.

### Indbyggede roller

#### Administrator

Fuld adgang til hele PowerShell Universal-platformen og indstillingerne.

#### Operator

Operatører har adgang til at tilføje og fjerne ressourcer såsom API'er, Scripts og Dashboards. Operatører kan ikke ændre indstillinger som miljøer, roller eller generelle indstillinger.

#### Execute

Rollen Execute giver mulighed for at køre scripts og læseadgang til alt andet.

#### Reader

Rollen Reader giver skrivebeskyttet adgang til PowerShell Universal.

### Standardrute pr. rolle

De kan ændre, hvilken side brugeren ser ved logon, ved at angive egenskaben `Default Route` for rollen. De kan f.eks. ønske, at HR-brugere går til dashboardet Human Resources, mens De ønsker, at IT-brugere går til IT Dashboard.

### Brugere med mange grupper

Hvis Deres brugere er medlemmer af mere end ca. 40 grupper, kan De opleve problemer med at logge på. Det skyldes størrelsesbegrænsninger for HTTP-headerne i IIS og Kestrel. Jo flere grupper en bruger er medlem af, jo flere autorisationsclaims har de, og jo større er headeren.

De kan øge headergrænsen for Kestrel ved hjælp af limits-konfigurationen i filen `appsettings.json`. De skal øge headerstørrelsen. Det er en værdi i byte og er som standard 32kb.

{% code collapsedlinecount="10" %}

```
{
  "Kestrel": {
    "Endpoints": {
      "HTTP": {
        "Url": "http://*:5000"
      }
    },
    "Limits": {
      "MaxRequestHeadersTotalSize": 132768
    },
    "RedirectToHttps": "false"
  },
```

{% endcode %}

### IIS-autorisation

Autorisation i IIS fungerer som med enhver anden metode, men De skal være opmærksom på størrelsesgrænsen for anmodningsheaderen. De kan modtage fejl, når De aktiverer krav, der omfatter mange grupper. Kravene kan overskride størrelsesgrænsen for headeren, og IIS returnerer fejl. Vi har konstateret, at ca. 40 Azure Active Directory-grupper forårsager dette problem på en standardinstallation af IIS.

Den fejl, De vil modtage, vil enten være en 400-fejl om, at anmodningen er for lang.

*Bad Request - Request Too Long* *HTTP Error 400. The size of the request headers is too long.*

Hvis De har HTTPS aktiveret, vil De modtage en fejl om en HTTP2-protokolfejl.

De kan øge IIS-anmodningsstørrelsen ved at angive følgende nøgler i registreringsdatabasen. De skal genstarte Deres computer, for at de træder i kraft.

{% code collapsedlinecount="10" %}

```
HKLM:\System\CurrentControlSet\Services\Http\Parameters
    MaxFieldLength: DWORD

HKLM:\System\CurrentControlSet\Services\Http\Parameters
    MaxRequestBytes: DWORD
```

{% endcode %}

Yderligere oplysninger findes i [Microsofts dokumentation](https://docs.microsoft.com/en-us/troubleshoot/iis/http-bad-request-response-kerberos#workaround-2-set-maxfieldlength-and-maxrequestbytes-registry-entries).

Som alternativ til at øge anmodningsstørrelsen kan De også reducere antallet af grupper, der sendes. I Azure Active Directory kan De angive, at kun de grupper, der er tildelt programmet, sendes, for at forhindre, at alle grupper sendes.

I Azure skal De gå til **App registrations** > (Vælg appen) > **Token Configuration** og angive de grupper, der er tildelt programmet.

Gå nu til **Enterprise Application** > (Vælg programmet) > **Users and groups**. Tildel den eller de grupper, De er interesseret i at medtage i claims. (Bemærk: dette kan også bruges som en sikkerhedsgrænse, hvis De sætter “User Assignment Required” til Yes i afsnittet ‘Properties’ i programmet)

## App Tokens

App-tokens kan tildeles tjenester, der ikke kan logge på interaktivt. Administratorer kan oprette tokens til identiteter fra Secure > Application Tokens. For at oprette et token til Deres egen konto skal De åbne User Settings fra brugermenuen og vælge Tokens.

Tokenet vil have en udløbstid på et år og have de gyldige roller for Deres konto. For at kopiere App Token til Deres konto skal De klikke på handlingen Copy. For at tilbagekalde et App Token skal De klikke på handlingen Revoke.

De kan bruge App Tokens med Universal-cmdletterne eller ved at bruge webanmodninger direkte med Bearer-autorisation.

## Miljø

Som standard kører scripts til formulargodkendelse og politiktildeling i PowerShell Universal-processen. De kan valgfrit konfigurere et eksternt [miljø ](/powershell-universal/da/config/environments.md)til at køre Deres godkendelses- og autorisationsscripts. Når De konfigurerer et sikkerhedsmiljø, startes en ekstern PowerShell-proces, som konfigureres til at bruge Deres miljøs indstillinger.

For at justere det miljø, der bruges af sikkerhedsprocessen, skal De angive `-SecurityEnvironment` i `settings.ps1`.

{% code collapsedlinecount="10" %}

```powershell
Set-PSUSetting -SecurityEnvironment '5.1'
```

{% endcode %}

## Eksempel: formulargodkendelse med Active Directory

Følgende eksempel viser udførelse af et simpelt "LDAP BIND" for at validere en brugers legitimationsoplysninger til Active Directory. Hvis en bruger, der forsøger at få adgang til PowerShell Universal, ikke er standardadministratorbrugeren, skal vedkommende godkende sine legitimationsoplysninger over for Active Directory via et simpelt LDAP-bind. Dette kan kombineres med en kontrol af medlemskab af en AD-gruppe i rollepolitikkerne Admin, Operator og Reader for effektivt at bruge godkendelse med Active Directory OG medlemskab af Active Directory-gruppe til at give rollebaseret adgang til PowerShell Universal.

{% code collapsedlinecount="10" %}

```powershell
param(
    [PSCredential]$Credential
)

#
#   You can call whatever cmdlets you like to conduct authentication here.
#   Just make sure to return the $Result with the Success property set to $true
#

$Result = [Security.AuthenticationResult]::new()
if ($Credential.UserName -eq 'Admin') 
{
    #Maintain the out of box admin user
    $Result.UserName = 'Default Admin'
    $Result.Success = $true 
}
else
{
    # Get current domain using logged-on user's credentials - this validates their credential
    $CurrentDomain = "LDAP://DC=mydemodomain,DC=com"  # Insert Your Domain Here
    $domain = New-Object System.DirectoryServices.DirectoryEntry($CurrentDomain,($Credential.UserName),$Credential.GetNetworkCredential().password)

    if ($domain.name -eq $null)
    {
        "Authentication failed for $($Credential.UserName)!" | Out-File "C:\test\adlogin.txt"
        write-host "Authentication failed - please verify your username and password."
        $Result.UserName = ($Credential.UserName)
        $Result.Success = $false 
    }
    else
    {
        write-host "Successfully authenticated with domain $($domain.name)"
        "Authentication success for $($Credential.UserName)!" | Out-File "C:\test\adlogin.txt"
        $Result.UserName = ($Credential.UserName)
        $Result.Success = $true 
    }
}

$Result
```

{% endcode %}

## Eksempel: politik baseret på Active Directory-gruppemedlemskab (Windows-godkendelse)

{% hint style="info" %}
Dette eksempel kræver en godkendelsesmetode, der leverer gruppeoplysninger under godkendelsesprocessen. Metoder som Windows-godkendelse og WS-Federation kan levere disse oplysninger. Forms-godkendelse fungerer ikke med denne type politik.
{% endhint %}

Dette eksempel gør brug af de claims, der leveres under godkendelse. De kan kontrollere, om brugeren har et groupsid (gruppemedlemskab), ved hjælp af claimtilknytninger. Knyt claimtypen groupid til den værdi, De vil tildele rollen til.

{% code collapsedlinecount="10" %}

```powershell
$Parameters = @{
    Name = "Administrators"
    ClaimType = 'http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid'
    ClaimValue = 'S-1-5-21-22222222-111111-3333333-153'
}

New-PSURole @Parameters
```

{% endcode %}

## Eksempel: politik baseret på medlemskab af en Active Directory-gruppe

I dette eksempel konfigurerer vi vores script til administratorpolitik, så det bruger LDAP til at hente medlemskabet af en Active Directory-gruppe. Her har vi oprettet en gruppe kaldet "PowerShell Universal Admins", hvor medlemmer af gruppen skal tildeles administratoradgang i PowerShell Universal. Her udfører vi en simpel kontrol af samaccountname for brugeren for at sikre, at vedkommende er medlem af gruppen. I mere robuste miljøer ville en kontrol af SID/DN/ObjectGUID være mere passende.

{% code collapsedlinecount="10" %}

```powershell
param(
$User
)

$UserName = ($User.Identity.Name)
$UserName = $UserName.Substring($UserName.IndexOf('\')+1,($UserName.Length -($UserName.IndexOf('\')+1)))

$IsMember = $false;

# Perform LDAP Group Member Lookup
$Searcher = New-Object DirectoryServices.DirectorySearcher
$Searcher.SearchRoot = 'LDAP://CN=Users,DC=berg,DC=com' # INSERT ROOT LDAP HERE
$Searcher.Filter = "(&(objectCategory=person)(memberOf=CN=PowerShell Universal Admins,OU=Information Technology,DC=berg,DC=com))" #GROUP INSERT DN TO CHECK HERE
$Users = $Searcher.FindAll()
$Users | ForEach-Object{
    If($_.Properties.samaccountname -eq $UserName)
    {
        $IsMember = $true;
        "$UserName is a member of admin group!" | Out-File "C:\test\adgroup.txt"
    }
    else {
        "$UserName is NOT member of admin group!" | Out-File "C:\test\adgroup.txt"
    }
}

return $IsMember
```

{% endcode %}

## Eksempel: gruppemedlemskab baseret på Azure Active Directory

Dette eksempel benytter sig af [OpenID Connect and Azure Active Directory](/powershell-universal/da/sikkerhed/enterprise-security/openid-connect.md#configuring-azure-entra-id-azure-active-directory).

Når De har konfigureret PowerShell Universal og Azure Active Directory, kan De konfigurere rollescripts til at kontrollere, om brugere er medlemmer af grupper, der findes i Azure AD. De kan udnytte claimstilknytninger til at knytte fra Azure AD Group ID til en PowerShell Universal-rolle.

Sørg først for, at claims for gruppemedlemskab er aktiveret i manifestet for Deres programregistrering. Dette vil medtage alt gruppemedlemskab, så det er tilgængeligt i PowerShell Universal.

{% code collapsedlinecount="10" %}

```
"groupMembershipClaims": "All",
```

{% endcode %}

Når det er konfigureret, kan De opdatere Deres rollescript, så det kontrollerer et gruppemedlemskab. Notér først objekt-id'et for den gruppe, De vil kontrollere i Azure AD.

Dernæst kan De i Deres script `roles.ps1` validere, at en bruger har en bestemt rolle, ved hjælp af tilknytning af claims.

{% code collapsedlinecount="10" %}

```powershell
New-PSURole -Name 'Administrators' -ClaimType 'groups' -ClaimValue '4acabc67-56cc-4590-9de6-164f3c4faf10'
```

{% endcode %}

Når brugere logger på, valideres deres gruppemedlemskab mod deres claims, og en rolle tildeles.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.devolutions.net/powershell-universal/da/sikkerhed/security.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.