> 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/authorization.md).
# Autorisation
L'autorisation des utilisateurs est réalisée à l'aide de rôles. Les rôles peuvent être attribués par mappage de revendications, par un script de stratégie ou en assignant directement le rôle à l'identité.
{% hint style="info" %}
Aucun rôle n'est automatiquement attribué par défaut. Un compte administrateur local est créé lors de la configuration initiale et est utilisé pour configurer les attributions de rôles.
{% endhint %}
### Mappage de rôle à revendication
Vous pouvez mapper des rôles à une revendication (telle qu'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 de rôle sous Sécurité \ Rôles.
Mappage de rôle à revendication
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 corresponde 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 de rôles à des revendications de cette manière est plus rapide que les scripts de stratégie, car il ne nécessite pas l'exécution de PowerShell lors de la connexion de l'utilisateur.
### Afficher les informations de revendication
Pour faciliter le développement de scripts de stratégie ou l'attribution de rôles à des revendications, vous pouvez afficher les informations de revendication en cliquant sur Afficher les informations de revendication dans Sécurité \ Rôles.
Afficher les informations de revendication
### 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, il existe un groupe appelé Dashboard Administrators. Ce groupe possède un ID d'objet de `61849bf2-e44b-4057-b589-6cd1812d7545`.
Dans PowerShell Universal, vous pouvez affecter les utilisateurs de ce groupe au groupe Administrateurs en configurant le mappage de revendications. Le type de revendication sera `groups` et la valeur de revendication sera `61849bf2-e44b-4057-b589-6cd1812d7545`. Une fois le mappage configuré, 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 stratégie
Par défaut, les rôles sont attribués par des stratégies. Les stratégies sont exécutées lors de la connexion de l'utilisateur. Vous pouvez modifier les scripts de stratégie en accédant à la page Sécurité / Rôles. Cliquez sur le bouton Modifier le code pour configurer le script de stratégie.
Bouton Modifier le code de stratégie
Les scripts de stratégie reçoivent un objet `ClaimsPrincipal` comme paramètre et doivent retourner vrai ou faux. Les stratégies qui génèrent des erreurs sont considérées comme fausses. L'objet `ClaimsPrincipal` contient l'identité de l'utilisateur ainsi que les revendications qu'il a reçues. Celles-ci peuvent inclure des appartenances à des groupes ou d'autres caractéristiques du compte d'un utilisateur.
Vous pouvez vous attendre à un objet ayant cette structure.
```csharp
public class ClaimsPrincipal
{
public List Claims { get; set; } = new List();
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 Properties { get; set; } = new Dictionary();
}
```
### 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.
Par défaut, les identités reçoivent un rôle par mappage de revendications ou par stratégie.
Attribution de rôle
### Importer des rôles
Lorsque l'authentification Windows est activée, vous pouvez cliquer sur le bouton Importer les groupes Windows pour sélectionner les groupes que vous souhaitez importer dans PowerShell Universal. Après avoir sélectionné ces groupes, des rôles seront créés avec le mappage de rôle à revendication, sans avoir à le configurer manuellement.
Bouton Importer les groupes Windows
### 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écuter
Le rôle Exécuter accorde la possibilité 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 ressources humaines accèdent au tableau de bord des ressources humaines tandis que les utilisateurs informatiques accèdent au tableau de bord informatique.
### Utilisateurs avec de nombreux groupes
Si vos utilisateurs sont membres de plus d'environ 40 groupes, 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 qui incluent de nombreux groupes. Ceux-ci peuvent dépasser la limite de taille de l'en-tête et IIS retournera des erreurs. Nous avons constaté qu'environ 40 groupes Azure Active Directory peuvent causer 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.
Si vous avez HTTPS activé, vous recevrez une erreur concernant une erreur de protocole HTTP2.
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 que les modifications prennent effet.
```
HKLM:\System\CurrentControlSet\Services\Http\Parameters
MaxFieldLength: DWORD
HKLM:\System\CurrentControlSet\Services\Http\Parameters
MaxRequestBytes: DWORD
```
Plus d'informations 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).
En 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 définir uniquement les groupes assignés à l'application pour éviter que tous les groupes soient envoyés.
Dans Azure, accédez à **Inscriptions d'applications** > (Sélectionnez l'application) > **Configuration des jetons**, et spécifiez les groupes assignés à l'application. 
Accédez ensuite à **Application d'entreprise** > (Sélectionnez l'application) > **Utilisateurs et groupes**. Assignez 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'utilisateurs requise » sur Oui dans la section « Propriétés » de l'application.)
## 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 disposera des 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.
Page des jetons d'application
## Environnement
Par défaut, les scripts d'authentification par formulaire et d'attribution de stratégie s'exécutent dans le processus PowerShell Universal. Vous pouvez éventuellement configurer un [Environnement](https://github.com/Devolutions/doc-gitbook/blob/master/translations/fr/powershell-universal/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 un simple « LDAP BIND » 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 avec Active Directory via un simple lien LDAP. Cela peut être combiné avec une vérification d'appartenance à un groupe AD dans les stratégies de rôles Administrateur, Opérateur et Lecteur pour utiliser efficacement l'authentification Active Directory ET l'appartenance à un groupe 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 : Stratégie 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 de groupe lors du processus d'authentification. Des méthodes telles que l'authentification Windows et WS-Federation peuvent fournir ces informations. L'authentification par formulaire ne fonctionnera pas avec ce type de stratégie.
{% 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 : Stratégie basée sur l'appartenance à un groupe Active Directory
Dans cet exemple, nous allons configurer notre script de stratégie Administrateur pour utiliser LDAP afin de récupérer l'appartenance d'un groupe Active Directory. Nous avons créé un groupe appelé « PowerShell Universal Admins » dont les membres doivent se voir accorder l'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.
```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 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 trouvés 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 les revendications d'appartenance à un groupe sont activées dans le manifeste de l'inscription de votre application. Cela inclura toutes les appartenances aux groupes, de sorte qu'elles soient accessibles dans PowerShell Universal.
```
"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.
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'
```
Lors de la connexion des utilisateurs, leur appartenance aux groupes sera validée par rapport à leurs revendications et un rôle leur sera 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/authorization.md?ask=
```
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.