> 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/es/seguridad/authorization.md). # Autorización Configure la autorización basada en roles en PowerShell Universal mediante asignación de reclamaciones, scripts de políticas y roles integrados para controlar el acceso a la plataforma. La autorización de usuarios se realiza mediante roles. Los roles se pueden asignar a través de la asignación de reclamaciones, de un script de políticas o asignando el rol directamente a la identidad. {% hint style="info" %} De forma predeterminada, no se asigna ningún rol automáticamente. Durante la configuración inicial se crea una cuenta de administrador local que se utiliza para configurar las asignaciones de roles. {% endhint %} ### Asignación de roles a reclamaciones 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 disponibles en el diálogo de propiedades del rol, en **Secure > Roles**. Por ejemplo, con la autenticación de Windows, si quisiera asignar un grupo a un rol, podría configurarlo de modo que el SID del grupo se asigne al rol de administrador. ```powershell 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 políticas, porque no requiere ejecutar PowerShell cuando el usuario inicia sesión. ### Ver información de reclamaciones Para ayudarle a desarrollar scripts de políticas o asignar roles a reclamaciones, puede consultar la información de las reclamaciones haciendo clic en View Claim Information en **Secure > Roles**. ### Ejemplo: Azure Active Directory Puede asignar un grupo de Azure Active Directory a un rol buscando el ID de objeto del grupo en Azure. Por ejemplo, en el dominio de Ironman Software, tenemos un grupo llamado Dashboard Administrators. Este grupo tiene el ID de objeto `61849bf2-e44b-4057-b589-6cd1812d7545`. En PowerShell Universal, puedo asignar a 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 fichero `roles.ps1` resultante tendrá este aspecto. Todos los demás roles están deshabilitados. ```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 ``` ### Asignación mediante políticas De forma predeterminada, los roles se asignan mediante políticas. Las políticas se ejecutan cuando el usuario inicia sesión. Puede cambiar los scripts de políticas en **Secure > Roles**. Haga clic en el botón Edit Code para configurar el script de políticas. Los scripts de políticas reciben un objeto `ClaimsPrincipal` como parámetro y deben devolver true o false. Se asumirá que las políticas que generen errores devuelven false. El objeto `ClaimsPrincipal` contiene la identidad del usuario y las reclamaciones que este 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. ```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(); } ``` ### Asignación de roles Para asignar un rol a un usuario, puede crear su identidad en Universal y luego seleccionar el rol en la lista desplegable de **Secure > Identities**. De forma predeterminada, las identidades reciben un rol mediante la asignación de reclamaciones o una política. ### Importar roles Cuando la autenticación de Windows está habilitada, puede hacer clic en el botón Import Windows Groups para seleccionar los grupos que quiera importar a PowerShell Universal. Después de seleccionar estos grupos, se crearán los roles, con la asignación de roles a reclamaciones, sin tener que configurarlo manualmente. ### Roles integrados #### Administrator Acceso completo a toda la plataforma PowerShell Universal y a su configuración. #### Operator Los operadores pueden añadir y eliminar recursos como APIs, scripts y dashboards. Los operadores no pueden cambiar opciones como los entornos, los roles o la configuración general. #### Execute El rol Execute concede la capacidad de ejecutar scripts y acceso de lectura a 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 quiera que los usuarios de RR. HH. vayan al dashboard de Recursos Humanos, mientras que los usuarios de TI vayan al dashboard de TI. ### Usuarios con muchos grupos Si sus usuarios son miembros de más de unos 40 grupos, puede experimentar 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 mediante la configuración de límites en el fichero `appsettings.json`. Tendrá que aumentar el tamaño de las cabeceras. Es un valor en bytes y, de forma predeterminada, es de 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 las cabeceras de solicitud. Puede recibir errores cuando habilite reclamaciones que incluyan muchos grupos. Pueden exceder 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. *Bad Request - Request Too Long* *HTTP Error 400. The size of the request headers is too long.* Si tiene HTTPS habilitado, recibirá un error relativo a un error de protocolo HTTP2. Puede aumentar el tamaño de solicitud de IIS estableciendo las siguientes claves de registro. Tendrá que reiniciar la máquina 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](https://docs.microsoft.com/en-us/troubleshoot/iis/http-bad-request-response-kerberos#workaround-2-set-maxfieldlength-and-maxrequestbytes-registry-entries). 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 se envíen únicamente 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 quiera incluir en las reclamaciones. (Nota: esto también puede utilizarse 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 en **User menu > User Settings > 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 usando \*\*\*\*\*\* src="" alt=""> Página de tokens de aplicación ## Entorno De forma predeterminada, los scripts de autenticación por formularios y de asignación de políticas se ejecutan dentro del proceso de PowerShell Universal. Cuando configura un entorno de seguridad, se inicia un proceso externo de PowerShell que se configura para usar los ajustes de su entorno. Para ajustar el entorno utilizado por el proceso de seguridad, establezca `-SecurityEnvironment` en `settings.ps1`. ```powershell Set-PSUSetting -SecurityEnvironment '5.1' ``` ## Ejemplo: autenticación por 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, tendrá que autenticar correctamente sus credenciales con Active Directory mediante un enlace LDAP simple. Esto se puede combinar con una comprobación de pertenencia a grupos de AD en las políticas 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. ```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 ``` ## Ejemplo: política basada en la pertenencia a grupos de Active Directory (autenticación de Windows) {% hint style="info" %} 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 por formularios no funcionará con este tipo de política. {% endhint %} Este ejemplo aprovecha las reclamaciones que se proporcionan durante la autenticación. Puede comprobar si el usuario tiene un groupsid (pertenencia a grupo) mediante asignaciones de reclamaciones. Asigne el tipo de reclamación groupid al valor al que quiera asignar el rol. ```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 ``` ## Ejemplo: política basada en la pertenencia a grupos de Active Directory En este ejemplo configuraremos nuestro script de política de Administrator para que utilice LDAP para recuperar la pertenencia a un grupo de Active Directory. Aquí hemos creado un grupo llamado "PowerShell Universal Admins", cuyos miembros deben recibir acceso de administrador en PowerShell Universal. En este caso realizamos una simple comprobación de samaccountname del usuario para asegurarnos de que es miembro del grupo. En entornos más robustos, sería más apropiada una comprobación de SID/DN/ObjectGUID. ```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 ``` ## 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. Primero, asegúrese de tener habilitadas las reclamaciones de pertenencia a grupos en el manifiesto del registro de su 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, tome nota del ID de objeto del grupo que quiere comprobar en Azure AD. A continuación, en su script `roles.ps1`, puede validar que un usuario tiene un rol determinado mediante la asignación de reclamaciones. ```powershell New-PSURole -Name 'Administrators' -ClaimType 'groups' -ClaimValue '4acabc67-56cc-4590-9de6-164f3c4faf10' ``` Cuando los usuarios inicien sesión, su pertenencia a grupos se validará con sus reclamaciones y se les asignará un rol. ### Véase también * [Devolutions Academy – Autenticación](https://academy.devolutions.net/student/path/3465905/activity/5612255) --- # 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/es/seguridad/authorization.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.