> 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/fr/securite/security.md).

# À propos

## Authentification

Par défaut, PowerShell Universal fournit une [authentification des utilisateurs locaux](/powershell-universal/fr/securite/local-accounts.md). Les noms d'utilisateur et les mots de passe chiffrés sont stockés dans la base de données de PowerShell Universal. Pour les environnements d'entreprise, vous pouvez envisager d'utiliser les méthodes d'authentification prises en charge par votre organisation.

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

## Autorisation

L'autorisation des utilisateurs est gérée par des rôles. Les rôles peuvent être attribués par mappage de revendications, par un script de politique ou en affectant directement le rôle à l'identité.

{% hint style="info" %}
Par défaut, les utilisateurs ne reçoivent aucun rôle. Des attributions de rôles multiples sont valides dans PowerShell Universal.
{% endhint %}

### Mappage de rôle à revendication

Vous pouvez mapper des rôles à une revendication (comme une appartenance à un groupe) en utilisant les paramètres `-ClaimType` et `-ClaimValue` de `New-PSURole`. Les paramètres sont également disponibles dans la boîte de dialogue des propriétés du rôle dans Sécurité \ Rôles.

<figure><img src="/files/mtN4hoxm2QsODItKZS6B" alt=""><figcaption><p>Mappage du type et de la valeur de la revendication</p></figcaption></figure>

Par exemple, avec l'authentification Windows, si vous souhaitez mapper un groupe à un rôle, vous pouvez le configurer de sorte que le SID du groupe soit mappé au rôle d'administrateur.

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

Le mappage des rôles aux revendications de cette manière est plus rapide que les scripts de politique, car il n'est pas nécessaire d'exécuter PowerShell lors de la connexion de l'utilisateur.

### Afficher les informations de revendication

Pour vous aider à développer des scripts de politique ou à attribuer des rôles à des revendications, vous pouvez afficher les informations de revendication en cliquant sur Afficher les informations de revendication dans Sécurité \ Rôles.

<figure><img src="/files/swT5MsJqMJvIuIwSE1T8" alt=""><figcaption><p>Bouton Afficher les informations de revendication</p></figcaption></figure>

### Exemple : Azure Active Directory

Vous pouvez mapper un groupe Azure Active Directory à un rôle en recherchant l'ID d'objet du groupe dans Azure. Par exemple, dans le domaine Ironman Software, nous avons un groupe appelé Dashboard Administrators. Ce groupe a un ID d'objet `61849bf2-e44b-4057-b589-6cd1812d7545`.

Dans PowerShell Universal, vous pouvez affecter les utilisateurs de ce groupe au groupe Administrateurs en configurant le mappage de revendication. Le type de revendication sera `groups` et la valeur de revendication sera `61849bf2-e44b-4057-b589-6cd1812d7545`. Une fois la revendication mappée, les utilisateurs du groupe Dashboard Administrators feront partie du groupe Administrateurs de PowerShell Universal. Le fichier `roles.ps1` résultant ressemblera à ceci.

Tous les autres rôles sont désactivés.

```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
```

### Attribution par politique

Par défaut, les rôles sont attribués par des politiques. Les politiques sont exécutées lors de la connexion de l'utilisateur. Vous pouvez modifier les scripts de politique en accédant à la page Sécurité / Rôles. Cliquez sur le bouton Modifier le code pour configurer le script de politique.

Les scripts de politique reçoivent un objet `ClaimsPrincipal` en paramètre et doivent retourner vrai ou faux. Les politiques qui génèrent des erreurs sont considérées comme fausses. L'objet `ClaimsPrincipal` contient l'identité de l'utilisateur et les revendications qu'il a reçues. Celles-ci peuvent inclure des appartenances à des groupes ou d'autres caractéristiques du compte utilisateur.

Vous pouvez vous attendre à un objet avec cette structure.

```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>();
}
```

### Attribution de rôle

Pour attribuer un rôle à un utilisateur, vous pouvez créer son identité dans Universal, puis sélectionner le rôle dans la liste déroulante de la page Identités.

<figure><img src="/files/Z441WEO8xyWh5GtfRPpz" alt=""><figcaption><p>Tableau des identités</p></figcaption></figure>

Par défaut, les identités reçoivent un rôle par mappage de revendication ou par politique.

<figure><img src="/files/cNuEpP5XKslMNG80OpNQ" alt=""><figcaption><p>Modifier le rôle de l'identité</p></figcaption></figure>

### Rôles intégrés

#### Administrateur

Accès complet à l'ensemble de la plateforme et des paramètres de PowerShell Universal.

#### Opérateur

Les opérateurs ont accès à l'ajout et à la suppression de ressources telles que les API, les scripts et les tableaux de bord. Les opérateurs ne peuvent pas modifier les paramètres tels que les environnements, les rôles ou les paramètres généraux.

#### Exécution

Le rôle Exécution accorde la capacité d'exécuter des scripts et un accès en lecture seule pour tout le reste.

#### Lecteur

Le rôle Lecteur fournit un accès en lecture seule à PowerShell Universal.

### Route par défaut par rôle

Vous pouvez modifier la page que l'utilisateur voit lors de sa connexion en définissant la propriété `Route par défaut` pour le rôle. Par exemple, vous pouvez souhaiter que les utilisateurs des RH accèdent au tableau de bord Ressources humaines tandis que les utilisateurs informatiques accèdent au tableau de bord informatique.

### Utilisateurs appartenant à de nombreux groupes

Si vos utilisateurs sont membres de plus d'une quarantaine de groupes environ, vous pouvez rencontrer des problèmes de connexion. Cela est dû aux limites de taille des en-têtes HTTP dans IIS et Kestrel. Plus un utilisateur est membre de groupes, plus il possède de revendications d'autorisation et plus l'en-tête est volumineux.

Vous pouvez augmenter la limite d'en-tête pour Kestrel en utilisant la configuration des limites dans le fichier `appsettings.json`. Vous devrez augmenter la taille de l'en-tête. Il s'agit d'une valeur en octets dont la valeur par défaut est 32 Ko.

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

### Autorisation IIS

L'autorisation dans IIS fonctionne comme avec toute autre méthode, mais vous devez être conscient de la limite de taille des en-têtes de requête. Vous pouvez recevoir des erreurs lorsque vous activez des revendications incluant de nombreux groupes. Celles-ci peuvent dépasser la limite de taille des en-têtes et IIS retournera des erreurs. Nous avons constaté qu'environ 40 groupes Azure Active Directory provoquent ce problème sur une installation IIS par défaut.

L'erreur que vous recevrez sera soit une erreur 400 indiquant que la requête est trop longue.

![](/files/N3Th8aZahgywghDCPpBi)

Si vous avez activé HTTPS, vous recevrez une erreur concernant un protocole HTTP2.

![](/files/UgNd0k2A5jAdPu5QA71e)

Vous pouvez augmenter la taille des requêtes IIS en définissant les clés de registre suivantes. Vous devrez redémarrer votre machine pour qu'elles prennent effet.

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

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

Des informations supplémentaires sont disponibles dans la [documentation de Microsoft](https://docs.microsoft.com/en-us/troubleshoot/iis/http-bad-request-response-kerberos#workaround-2-set-maxfieldlength-and-maxrequestbytes-registry-entries).

Comme alternative à l'augmentation de la taille des requêtes, vous pouvez également réduire le nombre de groupes envoyés. Dans Azure Active Directory, vous pouvez configurer l'envoi uniquement des groupes attribués à l'application afin d'éviter que tous les groupes soient transmis.

Dans Azure, accédez à **Inscriptions d'applications** > (Sélectionnez l'application) > **Configuration des jetons**, et spécifiez les groupes affectés à l'application. ![](https://support.ironmansoftware.com/api/v1/threads/548223000001702109/inlineImages/edbsndabe757f382adbd6bf97fb8f980f999a0299e9db01c2972b353b3c8c4ffe29e6ae82d11d75341af2d224cd8f4103b9b009cb9d18e2809c18ece1c19c88900fe13e6b2866bb6604db1b7c9360f4da552d?et=17798841e64\&ha=5d1aea069a1f58d946c8dad4e93abec12ca48d705aad7500a321b0c311d7e581\&f=1.png)

Accédez ensuite à **Application d'entreprise** > (Sélectionnez l'application) > **Utilisateurs et groupes**. Attribuez le ou les groupes que vous souhaitez inclure dans les revendications. (Remarque : cela peut également être utilisé comme limite de sécurité si vous définissez « Affectation d'utilisateur requise » sur Oui dans la section « Propriétés » de l'application)

![](https://support.ironmansoftware.com/api/v1/threads/548223000001702109/inlineImages/edbsndabe757f382adbd6bf97fb8f980f999a0299e9db01c2972b353b3c8c4ffe29e6ae82d11d75341af2d224cd8f4103b9b0ba101ed249f6cf46a1cf05c5cfe5650d84cedc32ef9ab20a4535665ec422da7b?et=17798841e64\&ha=0397e6316da5e7ab913c1ec8c932ba854c1a88d27c54044ea299ca2dac438aef\&f=2.png)

## Jetons d'application

Les jetons d'application peuvent être attribués à des services qui ne peuvent pas se connecter de manière interactive. Vous pouvez accorder un nouveau jeton d'application à votre compte en cliquant sur le bouton Accorder un jeton d'application dans l'onglet Sécurité / Jetons d'application.

Le jeton aura une expiration d'un an et possédera les rôles valides pour votre compte. Pour copier le jeton d'application dans votre compte, cliquez sur l'action Copier. Pour révoquer un jeton d'application, cliquez sur l'action Révoquer.

Vous pouvez utiliser les jetons d'application avec les cmdlets Universal ou en effectuant des requêtes web directement à l'aide de l'autorisation Bearer.

<figure><img src="/files/fUYdRcxSdnRT1SZINvSt" alt=""><figcaption><p>Page des jetons d'application</p></figcaption></figure>

## Environnement

Par défaut, les scripts d'authentification par formulaire et d'attribution de politique s'exécutent dans le processus PowerShell Universal. Vous pouvez éventuellement configurer un [Environnement](/powershell-universal/fr/config/environments.md) externe pour exécuter vos scripts d'authentification et d'autorisation. Lorsque vous configurez un environnement de sécurité, un processus PowerShell externe est démarré et configuré pour utiliser les paramètres de votre environnement.

Pour ajuster l'environnement utilisé par le processus de sécurité, définissez `-SecurityEnvironment` dans `settings.ps1`.

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

## Exemple : authentification par formulaire avec Active Directory

L'exemple suivant montre comment effectuer une simple « liaison LDAP » pour valider les informations d'identification Active Directory d'un utilisateur. Si un utilisateur tentant d'accéder à PowerShell Universal n'est pas l'utilisateur administrateur par défaut, il devra authentifier ses informations d'identification auprès d'Active Directory via une simple liaison LDAP. Cela peut être combiné avec une vérification d'appartenance à un groupe AD dans les politiques de rôles Administrateur, Opérateur et Lecteur pour utiliser efficacement l'authentification Active Directory ET l'appartenance à des groupes Active Directory afin de fournir un accès basé sur les rôles à PowerShell Universal.

```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
```

## Exemple : politique basée sur l'appartenance à un groupe Active Directory (authentification Windows)

{% hint style="info" %}
Cet exemple nécessite une méthode d'authentification qui fournit des informations sur les groupes lors du processus d'authentification. Des méthodes comme l'authentification Windows et WS-Federation peuvent fournir ces informations. L'authentification par formulaire ne fonctionnera pas avec ce type de politique.
{% endhint %}

Cet exemple tire parti des revendications fournies lors de l'authentification. Vous pouvez vérifier si l'utilisateur possède un groupsid (appartenance à un groupe) en utilisant des mappages de revendications. Mappez le type de revendication groupid à la valeur à laquelle vous souhaitez attribuer le rôle.

```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
```

## Exemple : politique basée sur l'appartenance à un groupe Active Directory

Dans cet exemple, nous allons configurer notre script de politique Administrateur pour utiliser LDAP afin de récupérer l'appartenance d'un groupe Active Directory. Ici, nous avons créé un groupe appelé « PowerShell Universal Admins » dont les membres doivent se voir accorder un accès Administrateur dans PowerShell Universal. Nous effectuons ici une simple vérification du samaccountname de l'utilisateur pour s'assurer qu'il est membre du groupe. Pour des environnements plus robustes, une vérification par SID/DN/ObjectGUID serait plus appropriée.

![](/files/eq446yEfMu2Gu86Z7qvL)

```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
```

## Exemple : appartenance à un groupe basée sur Azure Active Directory

Cet exemple tire parti d'[OpenID Connect et d'Azure Active Directory](/powershell-universal/fr/securite/enterprise-security/openid-connect.md#configuring-azuread).

Une fois que vous avez configuré PowerShell Universal et Azure Active Directory, vous pouvez configurer des scripts de rôle pour vérifier si les utilisateurs sont membres de groupes dans Azure AD. Vous pouvez tirer parti des mappages de revendications pour mapper l'ID de groupe Azure AD à un rôle PowerShell Universal.

Tout d'abord, assurez-vous que vous avez activé les revendications d'appartenance à des groupes dans le manifeste de votre inscription d'application. Cela inclura toutes les appartenances aux groupes, afin qu'elles soient accessibles dans PowerShell Universal.

![](/files/8pBsJCtozxLBkS8EYd76)

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

Une fois configuré, vous pouvez mettre à jour votre script de rôle pour vérifier l'appartenance à un groupe. Notez d'abord l'ID d'objet du groupe que vous souhaitez vérifier dans Azure AD.

![](/files/OueYIRFG3Zn1uUQKCy82)

Ensuite, dans votre script `roles.ps1`, vous pouvez valider qu'un utilisateur possède un rôle particulier en utilisant le mappage de revendications.

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

Lorsque les utilisateurs se connectent, leur appartenance aux groupes est validée par rapport à leurs revendications et un rôle leur est attribué.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.devolutions.net/powershell-universal/fr/securite/security.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.
