Informazioni

Autenticazione

Per impostazione predefinita, PowerShell Universal fornisce l'autenticazione utente locale. I nomi utente e le password crittografate sono archiviati nel database di PowerShell Universal. Per gli ambienti aziendali, potrebbe voler valutare l'utilizzo dei metodi di autenticazione supportati dalla sua organizzazione.

• Windows SSO
• OpenID Connect
• SAML2
• WS-Federation

Autorizzazione

L'autorizzazione degli utenti viene realizzata tramite i ruoli. I ruoli possono essere assegnati tramite la mappatura delle attestazioni, uno script dei criteri oppure assegnando il ruolo direttamente all'identità.

Per impostazione predefinita, gli utenti non ricevono alcun ruolo. In PowerShell Universal sono valide più assegnazioni di ruolo.

Mappatura da ruolo ad attestazione

È possibile mappare i ruoli a un'attestazione (ad esempio l'appartenenza a un gruppo) utilizzando i parametri -ClaimType e -ClaimValue di New-PSURole. Le impostazioni sono disponibili anche nella finestra di dialogo delle proprietà del ruolo in Security \ Roles.

Mappatura del tipo e del valore dell'attestazione

Ad esempio, con l'autenticazione Windows, se volesse mappare un gruppo a un ruolo, potrebbe configurarla in modo che il SID del gruppo venga mappato al ruolo di amministratore.

New-PSURole -Name Administrator -ClaimType 'http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid' -ClaimValue 'S-123-123-123'

Mappare i ruoli alle attestazioni in questo modo è più veloce rispetto agli script dei criteri, perché non richiede l'esecuzione di PowerShell quando l'utente effettua l'accesso.

Visualizzare le informazioni sulle attestazioni

Per agevolare lo sviluppo degli script dei criteri o l'assegnazione dei ruoli alle attestazioni, è possibile visualizzare le informazioni sulle attestazioni facendo clic su View Claim Information in Security \ Roles.

Pulsante View Claim Information

Esempio: Azure Active Directory

È possibile mappare un gruppo di Azure Active Directory a un ruolo cercando l'ID oggetto del gruppo in Azure. Ad esempio, all'interno del dominio Ironman Software abbiamo un gruppo chiamato Dashboard Administrators. Questo gruppo ha un ID oggetto 61849bf2-e44b-4057-b589-6cd1812d7545.

All'interno di PowerShell Universal, posso assegnare gli utenti di questo gruppo al gruppo Administrator configurando la mappatura delle attestazioni. Il Claim Type sarà groups e il Claim Value sarà 61849bf2-e44b-4057-b589-6cd1812d7545. Una volta mappata l'attestazione, gli utenti del gruppo Dashboard Administrators faranno parte del gruppo Administrators di PowerShell Universal. Il file roles.ps1 risultante avrà questo aspetto.

Tutti gli altri ruoli sono disabilitati.

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

Assegnazione tramite criteri

Per impostazione predefinita, i ruoli vengono assegnati tramite criteri. I criteri vengono eseguiti quando l'utente effettua l'accesso. È possibile modificare gli script dei criteri visitando la pagina Security / Roles. Faccia clic sul pulsante Edit Code per configurare lo script del criterio.

Gli script dei criteri ricevono un oggetto ClaimsPrincipal come parametro e devono restituire true o false. I criteri che generano errori verranno considerati false. L'oggetto ClaimsPrincipal contiene l'identità dell'utente e le attestazioni che l'utente ha ricevuto. Queste possono includere le assegnazioni di gruppo o altre funzionalità dell'account di un utente.

Può aspettarsi un oggetto con questa struttura.

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>();
}

Assegnazione dei ruoli

Per assegnare un ruolo a un utente, è possibile creare la sua identità all'interno di Universal e quindi selezionare il ruolo nel menu a discesa nella pagina Identities.

Tabella delle identità

Per impostazione predefinita, le identità ricevono un ruolo tramite la mappatura delle attestazioni o un criterio.

Modifica del ruolo dell'identità

Ruoli predefiniti

Administrator

Accesso completo all'intera piattaforma PowerShell Universal e alle impostazioni.

Operator

Gli operatori possono aggiungere e rimuovere risorse come API, Script e Dashboard. Gli operatori non possono modificare impostazioni come ambienti, ruoli o impostazioni generali.

Execute

Il ruolo Execute concede la possibilità di eseguire script e l'accesso in lettura a tutto il resto.

Reader

Il ruolo Reader fornisce l'accesso in sola lettura a PowerShell Universal.

Route predefinita per ruolo

È possibile modificare la pagina che l'utente vede al momento dell'accesso impostando la proprietà Default Route per il ruolo. Ad esempio, potrebbe voler indirizzare gli utenti delle risorse umane alla dashboard Human Resources e gli utenti IT alla dashboard IT.

Utenti con molti gruppi

Se i suoi utenti sono membri di più di circa 40 gruppi, potrebbe riscontrare problemi di accesso. Ciò è dovuto ai limiti di dimensione delle intestazioni HTTP in IIS e Kestrel. Più gruppi comprendono un utente, più attestazioni di autorizzazione ha e maggiore è l'intestazione.

È possibile aumentare il limite delle intestazioni per Kestrel utilizzando la configurazione dei limiti nel file appsettings.json. Sarà necessario aumentare la dimensione dell'intestazione. È un valore in byte e il valore predefinito è 32 kb.

{
  "Kestrel": {
    "Endpoints": {
      "HTTP": {
        "Url": "http://*:5000"
      }
    },
    "Limits": {
      "MaxRequestHeadersTotalSize": 132768
    },
    "RedirectToHttps": "false"
  },

Autorizzazione IIS

L'autorizzazione in IIS funziona come con qualsiasi altro metodo, ma occorre tenere presente il limite di dimensione dell'intestazione della richiesta. Potrebbe ricevere errori quando abilita attestazioni che includono molti gruppi. Possono superare il limite di dimensione dell'intestazione e IIS restituirà degli errori. Abbiamo riscontrato che circa 40 gruppi di Azure Active Directory causano questo problema in un'installazione IIS predefinita.

L'errore che riceverà sarà un errore 400 con l'indicazione che la richiesta è troppo lunga.

Se ha abilitato HTTPS, riceverà un errore relativo a un errore di protocollo HTTP2.

È possibile aumentare la dimensione della richiesta di IIS impostando le seguenti chiavi di registro. Sarà necessario riavviare la macchina affinché diventino effettive.

HKLM:\System\CurrentControlSet\Services\Http\Parameters
    MaxFieldLength: DWORD

HKLM:\System\CurrentControlSet\Services\Http\Parameters
    MaxRequestBytes: DWORD

Maggiori informazioni sono disponibili nella documentazione di Microsoft.

In alternativa all'aumento della dimensione della richiesta, è possibile anche ridurre il numero di gruppi inviati. In Azure Active Directory è possibile impostare solo i gruppi assegnati all'applicazione per impedire l'invio di tutti i gruppi.

In Azure vada su App registrations > (selezioni l'app) > Token Configuration e specifichi i gruppi assegnati all'applicazione.

Ora vada su Enterprise Application > (selezioni l'app) > Users and groups. Assegni il gruppo o i gruppi che desidera includere nelle attestazioni. (Nota: questo può essere utilizzato anche come limite di sicurezza se imposta “User Assignment Required” su Yes nella sezione ‘Properties’ dell'app)

Token app

I token app possono essere assegnati a servizi che non possono effettuare l'accesso in modo interattivo. È possibile concedere un nuovo token app al suo account facendo clic sul pulsante Grant App Token nella scheda Security / App Tokens.

Il token avrà una scadenza di un anno e i ruoli validi per il suo account. Per copiare il token app nel suo account, faccia clic sull'azione Copy. Per revocare un token app, faccia clic sull'azione Revoke.

È possibile utilizzare i token app con i cmdlet di Universal oppure tramite richieste web dirette utilizzando l'autorizzazione Bearer.

Pagina dei token app

Ambiente

Per impostazione predefinita, gli script di autenticazione con moduli e di assegnazione dei criteri vengono eseguiti all'interno del processo di PowerShell Universal. Facoltativamente, è possibile configurare un Environment esterno per eseguire gli script di autenticazione e autorizzazione. Quando configura un ambiente di sicurezza, verrà avviato un processo PowerShell esterno configurato in base alle impostazioni del suo ambiente.

Per modificare l'ambiente utilizzato dal processo di sicurezza, imposti -SecurityEnvironment in settings.ps1.

Set-PSUSetting -SecurityEnvironment '5.1'

Esempio: autenticazione con moduli con Active Directory

L'esempio seguente mostra come eseguire un semplice "LDAP BIND" per convalidare le credenziali Active Directory di un utente. Se un utente che tenta di accedere a PowerShell Universal non è il Default Admin User, dovrà autenticare correttamente le proprie credenziali con Active Directory tramite un semplice bind LDAP. Questo può essere combinato con un controllo di appartenenza a un gruppo AD nei criteri dei ruoli Admin, Operator e Reader per utilizzare efficacemente l'autenticazione Active Directory E l'appartenenza ai gruppi di Active Directory al fine di fornire un accesso basato sui ruoli a 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

Esempio: criterio basato sull'appartenenza ai gruppi di Active Directory (autenticazione Windows)

Questo esempio richiede un metodo di autenticazione che fornisca le informazioni sui gruppi durante il processo di autenticazione. Metodi come l'autenticazione Windows e WS-Federation possono fornire queste informazioni. L'autenticazione con moduli non funzionerà con questo tipo di criterio.

Questo esempio sfrutta le attestazioni fornite durante l'autenticazione. È possibile verificare se l'utente dispone di un groupsid (appartenenza a un gruppo) utilizzando le mappature delle attestazioni. Mappi il tipo di attestazione groupid al valore a cui desidera assegnare il ruolo.

$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

Esempio: criterio basato sull'appartenenza ai gruppi di Active Directory

In questo esempio configureremo il nostro script del criterio Administrator per utilizzare LDAP al fine di recuperare l'appartenenza a un gruppo di Active Directory. Qui abbiamo creato un gruppo chiamato "PowerShell Universal Admins", i cui membri devono ottenere l'accesso Administrator in PowerShell Universal. In questo caso eseguiamo un semplice controllo del samaccountname dell'utente per verificare che sia membro del gruppo. Per ambienti più robusti sarebbe più appropriato un controllo su SID/DN/ObjectGUID.

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

Esempio: appartenenza ai gruppi basata su Azure Active Directory

Questo esempio sfrutta OpenID Connect e Azure Active Directory.

Dopo aver configurato PowerShell Universal e Azure Active Directory, è possibile configurare gli script dei ruoli per verificare se gli utenti sono membri dei gruppi presenti in Azure AD. È possibile sfruttare le mappature delle attestazioni per mappare l'ID del gruppo di Azure AD a un ruolo di PowerShell Universal.

Innanzitutto, si assicuri di aver abilitato le attestazioni di appartenenza ai gruppi nel manifest per la registrazione dell'applicazione. Questo includerà tutte le appartenenze ai gruppi, in modo che siano accessibili in PowerShell Universal.

"groupMembershipClaims": "All",

Una volta configurato, è possibile aggiornare lo script del ruolo per verificare l'appartenenza a un gruppo. Prima di tutto, prenda nota dell'ID oggetto del gruppo che desidera verificare all'interno di Azure AD.

Successivamente, all'interno dello script roles.ps1, è possibile convalidare che un utente disponga di un determinato ruolo utilizzando la mappatura delle attestazioni.

New-PSURole -Name 'Administrators' -ClaimType 'groups' -ClaimValue '4acabc67-56cc-4590-9de6-164f3c4faf10'

Quando gli utenti effettuano l'accesso, la loro appartenenza ai gruppi verrà convalidata rispetto alle loro attestazioni e verrà assegnato un ruolo.