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 attribuant le rôle directement à l'identité.

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.

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.

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.

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.

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

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="https://218893503-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAje1UFQFSPx2kH2ueeCf%2Fuploads%2Fgit-blob-d2492c5fb69b57572019e3d793148c0e0c53370c%2Fimage%20(224).png?alt=media" 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.

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.

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)

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.

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.

$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.

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.

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