Acerca de

Autenticación

De forma predeterminada, PowerShell Universal proporciona autenticación de usuarios locales. Los nombres de usuario y las contraseñas cifradas se almacenan en la base de datos de PowerShell Universal. Para entornos empresariales, puede que desee considerar el uso de métodos de autenticación admitidos por su organización.

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

Autorización

La autorización de usuarios se realiza mediante roles. Los roles se pueden asignar mediante la asignación de reclamaciones, un script de directiva o asignando el rol directamente a la identidad.

De forma predeterminada, los usuarios no reciben ningún rol. En PowerShell Universal se admiten varias asignaciones de roles.

Asignación de rol a reclamación

Puede asignar roles a una reclamación (como la pertenencia a un grupo) mediante los parámetros -ClaimType y -ClaimValue de New-PSURole. También hay opciones de configuración disponibles en el cuadro de diálogo de propiedades del rol dentro de Security \ Roles.

Asignación de tipo y valor de reclamación

Por ejemplo, con la autenticación de Windows, si desea asignar un grupo a un rol, puede configurarlo de modo que el SID del grupo se asigne al rol de administrador.

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

Asignar roles a reclamaciones de esta manera es más rápido que los scripts de directivas, ya que no requiere que se ejecute PowerShell cuando el usuario inicia sesión.

Ver información de reclamaciones

Para ayudar a desarrollar scripts de directivas o asignar roles a reclamaciones, puede ver la información de reclamaciones haciendo clic en View Claim Information en Security \ Roles.

Botón View Claim Information

Ejemplo: Azure Active Directory

Puede asignar un grupo de Azure Active Directory a un rol buscando el Object ID del grupo en Azure. Por ejemplo, dentro del dominio de Ironman Software, tenemos un grupo llamado Dashboard Administrators. Este grupo tiene un ID de objeto 61849bf2-e44b-4057-b589-6cd1812d7545.

Dentro de PowerShell Universal, puedo asignar los usuarios de este grupo al grupo Administrator configurando la asignación de reclamaciones. El Claim Type será groups y el Claim Value será 61849bf2-e44b-4057-b589-6cd1812d7545. Una vez asignada la reclamación, los usuarios del grupo Dashboard Administrators formarán parte del grupo Administrators de PowerShell Universal. El archivo roles.ps1 resultante tendrá este aspecto.

Todos los demás roles están deshabilitados.

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

Asignación por directivas

De forma predeterminada, los roles se asignan mediante directivas. Las directivas se ejecutan cuando el usuario inicia sesión. Puede cambiar los scripts de directivas visitando la página Security / Roles. Haga clic en el botón Edit Code para configurar el script de directiva.

Los scripts de directivas recibirán un objeto ClaimsPrincipal como parámetro y deben devolver true o false. Se asumirá que las directivas que generen errores devuelven false. El objeto ClaimsPrincipal contiene la identidad del usuario y las reclamaciones que ha recibido. Estas pueden incluir asignaciones de grupos u otras características de la cuenta de un usuario.

Puede esperar un objeto con esta estructura.

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

Asignación de roles

Para asignar un rol a un usuario, puede crear su identidad dentro de Universal y, a continuación, seleccionar el rol en la lista desplegable de la página Identities.

Tabla de identidades

De forma predeterminada, las identidades reciben un rol mediante la asignación de reclamaciones o una directiva.

Editar el rol de la identidad

Roles integrados

Administrator

Acceso completo a toda la plataforma y la configuración de PowerShell Universal.

Operator

Los operadores tienen acceso para añadir y eliminar recursos como APIs, Scripts y Dashboards. Los operadores no pueden cambiar opciones de configuración como entornos, roles o configuración general.

Execute

El rol Execute otorga la capacidad de ejecutar scripts y acceso de lectura para todo lo demás.

Reader

El rol Reader proporciona acceso de solo lectura a PowerShell Universal.

Ruta predeterminada por rol

Puede cambiar la página que ve el usuario al iniciar sesión estableciendo la propiedad Default Route del rol. Por ejemplo, puede que desee que los usuarios de RR. HH. vayan al panel de Recursos Humanos mientras que los usuarios de TI vayan al panel de TI.

Usuarios con muchos grupos

Si sus usuarios son miembros de más de unos 40 grupos, es posible que experimente problemas al iniciar sesión. Esto se debe a los límites de tamaño de las cabeceras HTTP en IIS y Kestrel. Cuantos más grupos tenga un usuario, más reclamaciones de autorización tendrá y mayor será la cabecera.

Puede aumentar el límite de cabeceras de Kestrel utilizando la configuración de límites en el archivo appsettings.json. Deberá aumentar el tamaño de la cabecera. Es un valor en bytes y su valor predeterminado es 32 kb.

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

Autorización en IIS

La autorización en IIS funciona igual que con cualquier otro método, pero debe tener en cuenta el límite de tamaño de la cabecera de la solicitud. Es posible que reciba errores al habilitar reclamaciones que incluyan muchos grupos. Pueden superar el límite de tamaño de la cabecera e IIS devolverá errores. Hemos comprobado que unos 40 grupos de Azure Active Directory provocan este problema en una instalación predeterminada de IIS.

El error que recibirá será un error 400 indicando que la solicitud es demasiado larga.

Si tiene HTTPS habilitado, recibirá un error sobre un error de protocolo HTTP2.

Puede aumentar el tamaño de solicitud de IIS estableciendo las siguientes claves del registro. Deberá reiniciar el equipo para que surtan efecto.

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

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

Puede encontrar más información en la documentación de Microsoft.

Como alternativa a aumentar el tamaño de la solicitud, también puede reducir el número de grupos enviados. En Azure Active Directory, puede establecer que solo se envíen los grupos asignados a la aplicación para evitar que se envíen todos los grupos.

En Azure, vaya a App registrations > (seleccione la aplicación) > Token Configuration y especifique los grupos asignados a la aplicación.

Ahora vaya a Enterprise Application > (seleccione la aplicación) > Users and groups. Asigne el grupo o los grupos que desee incluir en las reclamaciones. (Nota: esto también se puede utilizar como límite de seguridad si establece “User Assignment Required” en Yes en la sección ‘Properties’ de la aplicación)

Tokens de aplicación

Los tokens de aplicación se pueden asignar a servicios que no pueden iniciar sesión de forma interactiva. Puede conceder un nuevo token de aplicación a su cuenta haciendo clic en el botón Grant App Token dentro de la pestaña Security / App Tokens.

El token tendrá una caducidad de un año y contará con los roles válidos de su cuenta. Para copiar el token de aplicación en su cuenta, haga clic en la acción Copy. Para revocar un token de aplicación, haga clic en la acción Revoke.

Puede utilizar los tokens de aplicación con los cmdlets de Universal o mediante solicitudes web directamente utilizando la autorización Bearer.

Página de tokens de aplicación

Entorno

De forma predeterminada, los scripts de autenticación de formularios y de asignación de directivas se ejecutan dentro del proceso de PowerShell Universal. Opcionalmente, puede configurar un entorno externo para ejecutar sus scripts de autenticación y autorización. Cuando configura un entorno de seguridad, se iniciará un proceso externo de PowerShell y se configurará para usar la configuración de su entorno.

Para ajustar el entorno utilizado por el proceso de seguridad, establezca -SecurityEnvironment en settings.ps1.

Set-PSUSetting -SecurityEnvironment '5.1'

Ejemplo: autenticación de formularios con Active Directory

El siguiente ejemplo muestra cómo realizar un sencillo "LDAP BIND" para validar las credenciales de Active Directory de un usuario. Si un usuario que intenta acceder a PowerShell Universal no es el usuario administrador predeterminado, deberá autenticar correctamente sus credenciales con Active Directory mediante un simple enlace LDAP. Esto se puede combinar con una comprobación de pertenencia a grupos de AD en las directivas de los roles Admin, Operator y Reader para utilizar de forma eficaz la autenticación de Active Directory Y la pertenencia a grupos de Active Directory con el fin de proporcionar acceso basado en roles 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

Ejemplo: directiva basada en la pertenencia a grupos de Active Directory (autenticación de Windows)

Este ejemplo requiere un método de autenticación que proporcione información de grupos durante el proceso de autenticación. Métodos como la autenticación de Windows y WS-Federation pueden proporcionar esta información. La autenticación de formularios no funcionará con este tipo de directiva.

Este ejemplo aprovecha las reclamaciones que se proporcionan durante la autenticación. Puede comprobar si el usuario tiene un groupsid (pertenencia a un grupo) mediante asignaciones de reclamaciones. Asigne el tipo de reclamación groupid al valor al que desea asignar el rol.

$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

Ejemplo: directiva basada en la pertenencia a grupos de Active Directory

En este ejemplo configuraremos nuestro script de directiva de Administrator para que utilice LDAP con el fin de recuperar la pertenencia a un grupo de Active Directory. Aquí hemos creado un grupo llamado "PowerShell Universal Admins" en el que a los miembros del grupo se les debe conceder acceso de administrador en PowerShell Universal. Aquí realizamos una simple comprobación de samaccountname del usuario para asegurarnos de que es miembro del grupo. Para entornos más robustos, sería más apropiada una comprobación de 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

Ejemplo: pertenencia a grupos basada en Azure Active Directory

Este ejemplo aprovecha OpenID Connect y Azure Active Directory.

Una vez que haya configurado PowerShell Universal y Azure Active Directory, puede configurar scripts de roles para verificar si los usuarios son miembros de grupos existentes en Azure AD. Puede aprovechar las asignaciones de reclamaciones para asignar el ID de grupo de Azure AD a un rol de PowerShell Universal.

En primer lugar, asegúrese de tener habilitadas las reclamaciones de pertenencia a grupos en el manifiesto de su registro de aplicación. Esto incluirá toda la pertenencia a grupos, de modo que sea accesible en PowerShell Universal.

"groupMembershipClaims": "All",

Una vez configurado, puede actualizar su script de roles para comprobar la pertenencia a un grupo. Primero anote el ID de objeto del grupo que desea comprobar dentro de Azure AD.

A continuación, dentro de su script roles.ps1, puede validar que un usuario tiene un rol determinado mediante la asignación de reclamaciones.

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

A medida que los usuarios inicien sesión, se validará su pertenencia a grupos con respecto a sus reclamaciones y se les asignará un rol.