> 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 Configurez l'authentification et l'autorisation basée sur les rôles dans PowerShell Universal, couvrant le mappage des revendications, les scripts de stratégie et les jetons d'application. ## Authentification Par défaut, PowerShell Universal fournit [l'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 pourriez 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 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 assignant le rôle directement à l'identité. {% hint style="info" %} Par défaut, les utilisateurs ne reçoivent aucun rôle. Les attributions de plusieurs rôles sont valides dans PowerShell Universal. {% endhint %} ### Mappage de rôle à revendication Vous pouvez mapper des rôles à une revendication (comme l'appartenance à un groupe) en utilisant les paramètres `-ClaimType` et `-ClaimValue` de `New-PSURole`. Des paramètres sont aussi disponibles dans le dialogue des propriétés du rôle, dans Secure > Roles. Par exemple, avec l'authentification Windows, si vous souhaitiez mapper un groupe à un rôle, vous pourriez le configurer de manière à ce que le SID du groupe soit mappé au rôle d'administrateur. {% 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 %} Mapper des rôles à des revendications de cette manière est plus rapide que les scripts de stratégie, car cela n'exige 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 nommé Dashboard Administrators. Ce groupe a 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 le Claim Value sera `61849bf2-e44b-4057-b589-6cd1812d7545`. Une fois la revendication mappée, les utilisateurs du groupe Dashboard Administrators feront partie du groupe Administrators de PowerShell Universal. Le fichier `roles.ps1` résultant ressemblera à ceci. Tous les autres rôles sont désactivés. {% 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 %} ### Attribution par 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 visitant la page 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. {% code collapsedlinecount="10" %} ```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(); } ``` {% endcode %} ### 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 Identities. Par défaut, les identités reçoivent un rôle par le mappage des revendications ou par une stratégie. ### Rôles intégrés #### Administrator Accès complet à l'ensemble de la plateforme PowerShell Universal et à ses paramètres. #### 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 des 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 selon le rôle Vous pouvez modifier la page que l'utilisateur voit lors de sa 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 éprouver 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, avec une valeur par défaut de 32kb. {% code collapsedlinecount="10" %} ``` { "Kestrel": { "Endpoints": { "HTTP": { "Url": "http://*:5000" } }, "Limits": { "MaxRequestHeadersTotalSize": 132768 }, "RedirectToHttps": "false" }, ``` {% endcode %} ### 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 pourriez recevoir des erreurs lorsque vous activez des revendications qui incluent de nombreux groupes. Elles 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. *Bad Request - Request Too Long* *HTTP Error 400. The size of the request headers is too long.* Si vous avez activé HTTPS, 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. {% code collapsedlinecount="10" %} ``` HKLM:\System\CurrentControlSet\Services\Http\Parameters MaxFieldLength: DWORD HKLM:\System\CurrentControlSet\Services\Http\Parameters MaxRequestBytes: DWORD ``` {% endcode %} 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). Comme solution de rechange à l'augmentation de la taille de requête, vous pouvez aussi réduire le nombre de groupes envoyés. Dans Azure Active Directory, vous pouvez restreindre l'envoi aux seuls groupes attribués à l'application afin d'empêcher que tous les groupes soient envoyés. 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 : ceci peut aussi servir de limite de sécurité si vous réglez « 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. Les administrateurs peuvent créer des jetons pour des identités à partir de Secure > Application Tokens. Pour créer un jeton pour votre propre compte, ouvrez User Settings dans le menu utilisateur et sélectionnez 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 l'autorisation Bearer. ## Environnement Par défaut, les scripts d'authentification par formulaire et d'attribution par stratégie s'exécutent dans le processus de 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`. {% code collapsedlinecount="10" %} ```powershell Set-PSUSetting -SecurityEnvironment '5.1' ``` {% endcode %} ## 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. Ceci peut être combiné à une vérification d'appartenance à un groupe AD dans les stratégies des rôles 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. {% 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 %} ## Exemple : stratégie basée sur l'appartenance à un groupe Active Directory (authentification Windows) {% hint style="info" %} Cet exemple exige une méthode d'authentification qui fournira des informations sur les groupes 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 souhaitez attribuer le rôle. {% 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 %} ## 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 le protocole LDAP afin de récupérer les membres d'un groupe Active Directory. Ici, nous avons créé un groupe nommé « PowerShell Universal Admins » dont les membres devraient obtenir un accès Administrator dans PowerShell Universal. Ici, nous effectuons 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 du SID, du DN ou de l'ObjectGUID serait plus appropriée. {% 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 %} ## 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-azure-entra-id-azure-active-directory). Une fois PowerShell Universal et Azure Active Directory configurés, vous pouvez configurer des scripts de rôles pour vérifier si les utilisateurs sont membres de groupes présents dans Azure AD. Vous pouvez tirer parti des mappages de revendications pour mapper l'ID de groupe Azure AD à un rôle PowerShell Universal. Premièrement, assurez-vous que les revendications d'appartenance aux 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. {% code collapsedlinecount="10" %} ``` "groupMembershipClaims": "All", ``` {% endcode %} Une fois la configuration terminé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. {% code collapsedlinecount="10" %} ```powershell New-PSURole -Name 'Administrators' -ClaimType 'groups' -ClaimValue '4acabc67-56cc-4590-9de6-164f3c4faf10' ``` {% endcode %} Lorsque les utilisateurs se connectent, leur appartenance aux groupes sera validée par rapport à leurs revendications et un rôle 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, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/powershell-universal/fr/securite/security.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.