Autorisation

Autorisation dans PowerShell Universal.

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

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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

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.

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.

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