> 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 Configurez l'autorisation basée sur les rôles dans PowerShell Universal à l'aide du mappage de revendications, de scripts de stratégie et de rôles intégrés pour contrôler l'accès à la plateforme. L'autorisation des utilisateurs s'effectue au moyen de rôles. Les rôles peuvent être attribués par le mappage des revendications, par un script de stratégie ou en attribuant le rôle directement à l'identité. {% hint style="info" %} Aucun rôle n'est attribué automatiquement par défaut. Un compte d'administrateur local est créé lors de la configuration initiale et utilisé pour configurer les attributions de rôles. {% endhint %} ### Mappage des rôles aux revendications Vous pouvez mapper des rôles à une revendication (comme une appartenance à un groupe) à l'aide des paramètres `-ClaimType` et `-ClaimValue` de `New-PSURole`. Des paramètres sont également disponibles dans la boîte de dialogue des propriétés du rôle, sous **Secure > Roles**. Par exemple, avec l'authentification Windows, si vous vouliez mapper un groupe à un rôle, vous pourriez 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 stratégie, car il ne nécessite pas l'exécution de PowerShell lorsque l'utilisateur se connecte. ### Afficher les informations de revendication Pour vous aider à développer des scripts de stratégie ou à attribuer des rôles à des revendications, vous pouvez afficher les informations de revendication en cliquant sur View Claim Information dans **Secure > Roles**. ### 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 possède l'ID d'objet `61849bf2-e44b-4057-b589-6cd1812d7545`. Dans PowerShell Universal, je peux attribuer les utilisateurs de ce groupe au groupe Administrator en configurant le mappage des revendications. Le Claim Type sera `groups` et la Claim Value sera `61849bf2-e44b-4057-b589-6cd1812d7545`. Une fois la revendication mappée, les utilisateurs du groupe Dashboard Administrators feront partie du groupe PowerShell Universal Administrators. 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 de stratégie Par défaut, les rôles sont attribués par des stratégies. Les stratégies sont exécutées lorsque l'utilisateur se connecte. Vous pouvez modifier les scripts de stratégie en accédant à **Secure > Roles**. Cliquez sur le bouton Edit Code pour configurer le script de stratégie. Les scripts de stratégie reçoivent un objet `ClaimsPrincipal` comme paramètre et doivent retourner true ou false. Les stratégies qui génèrent des erreurs seront considérées comme false. L'objet `ClaimsPrincipal` contient l'identité de l'utilisateur et les revendications que l'utilisateur a reçues. Celles-ci peuvent inclure des attributions de 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 sous **Secure > Identities**. Par défaut, les identités reçoivent un rôle par le mappage des revendications ou par une stratégie. ### Importer des rôles Lorsque l'authentification Windows est activée, vous pouvez cliquer sur le bouton Import Windows Groups 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 des rôles aux revendications, sans avoir à le configurer manuellement. ### Rôles intégrés #### Administrator Accès complet à l'ensemble de la plateforme et des paramètres de PowerShell Universal. #### Operator 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 comme les environnements, les rôles ou les paramètres généraux. #### Execute Le rôle Execute accorde la capacité d'exécuter des scripts et un accès en lecture pour tout le reste. #### Reader Le rôle Reader 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 la connexion en définissant la propriété `Default Route` du rôle. Par exemple, vous pourriez vouloir que les utilisateurs des RH accèdent au tableau de bord des ressources humaines tandis que les utilisateurs des TI accèdent au tableau de bord des TI. ### Utilisateurs appartenant à de nombreux groupes Si vos utilisateurs sont membres de plus d'environ 40 groupes, vous pourriez 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 à l'aide de 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 tenir compte de la limite de taille des en-têtes de requête. Vous pourriez recevoir des erreurs lorsque vous activez des revendications qui incluent de nombreux groupes. Elles 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 causeront 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. *Bad Request - Request Too Long* *HTTP Error 400. The size of the request headers is too long.* Si HTTPS est activé, vous recevrez une erreur concernant une erreur de protocole HTTP2. Vous pouvez augmenter la taille de requête d'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 ``` Vous trouverez plus d'informations 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). Au lieu d'augmenter la taille de la requête, vous pouvez aussi réduire le nombre de groupes envoyés. Dans Azure Active Directory, vous pouvez définir uniquement les groupes attribués à l'application afin d'empêcher l'envoi de tous les groupes. Dans Azure, allez à **App registrations** > (sélectionnez l'appli) > **Token Configuration**, et spécifiez les groupes attribués à l'application. Allez maintenant à **Enterprise Application** > (sélectionnez l'appli) > **Users and groups**. Attribuez le ou les groupes que vous souhaitez inclure dans les revendications. (Remarque : cela peut aussi servir de limite de sécurité si vous définissez « User Assignment Required » à Yes dans la section « Properties » de l'appli) ## 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 Grant App Token dans **User menu > User Settings > Tokens**. 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 Copy. Pour révoquer un jeton d'application, cliquez sur l'action Revoke. Vous pouvez utiliser les jetons d'application avec les applets de commande Universal ou en utilisant directement des requêtes web avec \*\*\*\*\*\* src="" alt=""> 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. Lorsque vous configurez un environnement de sécurité, un processus PowerShell externe sera 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 » afin de valider les identifiants Active Directory d'un utilisateur. Si un utilisateur qui tente d'accéder à PowerShell Universal n'est pas l'utilisateur administrateur par défaut, il devra authentifier avec succès ses identifiants auprès d'Active Directory au moyen d'un simple bind LDAP. Cela peut être combiné à une vérification de l'appartenance à un groupe AD dans les stratégies de rôle Admin, Operator et Reader afin d'utiliser efficacement l'authentification Active Directory ET l'appartenance aux groupes Active Directory pour 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 fournira les informations de groupe pendant le 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 stratégie. {% endhint %} Cet exemple tire parti des revendications fournies pendant l'authentification. Vous pouvez vérifier si l'utilisateur possède un groupsid (appartenance à un groupe) en utilisant les mappages de revendications. Mappez le type de revendication groupid à la valeur à laquelle vous voulez 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 Administrator pour utiliser LDAP afin de récupérer les membres d'un groupe Active Directory. Nous avons créé ici un groupe appelé « PowerShell Universal Admins » dont les membres devraient obtenir un accès Administrator dans PowerShell Universal. Nous effectuons ici une simple vérification du samaccountname de l'utilisateur pour nous assurer qu'il est membre du groupe. Pour des environnements plus robustes, une vérification 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 d'Azure Active Directory. Une fois PowerShell Universal et Azure Active Directory configurés, 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. D'abord, assurez-vous que les revendications d'appartenance à des groupes sont activées dans le manifeste de votre enregistrement d'application. Cela inclura toutes les appartenances aux groupes, afin qu'elles soient accessibles dans PowerShell Universal. ``` "groupMembershipClaims": "All", ``` Une fois la configuration effectuée, 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 des revendications. ```powershell New-PSURole -Name 'Administrators' -ClaimType 'groups' -ClaimValue '4acabc67-56cc-4590-9de6-164f3c4faf10' ``` À mesure que les utilisateurs se connectent, leur appartenance aux groupes sera validée par rapport à leurs revendications et un rôle sera attribué. ### Voir aussi * [Devolutions Academy – Authentification](https://academy.devolutions.net/student/path/3465905/activity/5612255) --- # 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, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/powershell-universal/fr/securite/authorization.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.