Just Enough Administration - Configuración

Esta es la tercera parte de la serie JEA - Just Enough Administration.

En este post voy a realizar la configuración y pruebas de esta tecnología, en el artículo anterior vimos los pre requisitos, así que asumo que ya se cuenta con ellos para partir de allí, para este ejemplo utilizaré Windows Server 2016, el cual ya viene con la versión de WMF que se requiere, en otras palabras Windows Server 2016 viene preparado para JEA, si se usa otro sistema es necesario instalar los componentes requeridos.

Grupos o usuarios

Antes de empezar voy a definir los usuarios con los cuales haré las pruebas (usuarios no administradores), para ello crearé un usuario en AD y lo agregaré a un grupo que será el que utilice más adelante, también crearé una OU donde ubicaré todo. Al final mi estructura quedó como se muestra en la siguiente imagen:

El usuario JEAUser pertenece al grupo JEAGroup, ambos objetos se encuentran en la OU JEA

Nota: Recordemos que los permisos podemos asignarlos tanto a usuarios como a grupos.

Crear archivo funcionalidad de rol

En el post anterior vimos para que sirve el archivo de funcionalidad de rol (Role Capability File), ahora veremos cómo crearlo, para ello basta con ejecutar el código a continuación. leer los comentarios en verde para entender lo que hace cada parte de código.

$powerShellPath = "$env:SystemRoot\System32\WindowsPowerShell\v1.0"

#Campos para el comando que creará el archivo de funcionalidad de rol, esto facilita la creación del archivo de funcionalidad de rol, otra forma de hacerlo es utilizando el cmdlet y pasarle cada uno de los parámetros necesarios, lo cual puede ser más engorroso, de esta forma se hace mucho más sencillo si deseamos, adicionar, cambiar o agregar parámetros.

$RoleParams = @{

    Author =

        "César Herrada"

    ModulesToImport=

        "Microsoft.PowerShell.Core"

    VisibleCmdlets=

        "Restart-Service"

    CompanyName=

        "ITPros-DC"

    FunctionDefinitions = @{ Name = 'Get-UserInfo'; ScriptBlock = {$PSSenderInfo}}

        }

# Crea el módulo, El cuál contendrá el archivo de funcionalidad de rol, se llamará Modulo.psd1  se creará en un directorio llamado MiModulo, el siguiente bloque de código creará toda la estructura de directorios y el módulo en sí, también creará la carpeta RoleCapabilities donde almacenaremos el archivo de funcionalidad de rol que se creará más adelante

New-Item -Path “$env:ProgramFiles\WindowsPowerShell\Modules\MiModulo” -ItemType Directory

New-ModuleManifest -Path “$env:ProgramFiles\WindowsPowerShell\Modules\MiModulo\Modulo.psd1"

New-Item -Path “$env:ProgramFiles\WindowsPowerShell\Modules\MiModulo\RoleCapabilities” -ItemType Directory

archivo de funcionalidad de rol utilizando los parámetros que definimos al inicio en la variable $RoleParams, el archivo se llamará Operadores.psrc lo ideal es nombrar este archivo con las tareas de rol que contendrá, por ejemplo: AdministradoresDNS, AdminUsuarios, etc.

New-PSRoleCapabilityFile -Path “$env:ProgramFiles\WindowsPowerShell\Modules\MiModulo\RoleCapabilities\Operadores.psrc" @RoleParams

  

Tras ejecutar el código anterior, puede ser en una sesión de PowerShell ISE o en Visual Studio Code, tendremos una estructura similar a la siguiente:

En la carpeta del módulo estará la siguiente información:

y en la subcarpeta RoleCapabilities:

Si abrimos el archivo .psrc recién creado, podemos ver que se encuentran los valores de las variables que establecimos, el resto de parámetros aparecerán comentados, pero podemos ver una explicación de cada uno, en las siguientes imágenes, podemos observar los parámetros que establecimos.

Los cmdlets que estarán disponibles para este rol, que en mi caso son: Restart-Service y Get-LocalUser

En el código también definimos una función personalizada que llamamos Get-User y si observamos el bloque de código para esta función lo que hace es ejecutar el cmdlet Get-LocalUser, el cual básicamente arroja la información de los usuarios locales, prácticamente trae la misma información que en la línea de comando clásica (cmd.exe) obtenemos con el comando: net user

Con lo anterior, hemos definido el archivo que contiene los cmdlets que se podrán ejecutar,  como apreciamos es Restart-Service con lo cual los usuarios asignados a este rol podrán utilizar éste para reiniciar cualquier servicio sin necesidad de contar con privilegios de administrador, por otro lado hemos creado una función con un nombre inventado en este caso Get-User que en realidad hace un llamado a un cmdlet real Get-LocalUser, debido a que la función hace una llamada a este cmdlet, debemos ponerlo en la variable VisibleCmdlets ya que si no lo hacemos, no estará disponible para el usuario y saldrá error al invocar la función Get-User

Crear y registrar el archivo de configuración de sesión.

Ahora que ya tenemos el módulo y el archivo de roles vamos a crear el archivo de configuración de sesión, que como vimos en el artículo anterior entre otras cosas sirve para definir quiénes están autorizados para conectarse al endpoint.

El código a continuación se encarga de la tarea:

#Determinar el dominio

$domain = (Get-CimInstance -ClassName Win32_ComputerSystem).Domain

#Aquí va el grupo no-administrador, reemplazar por el propio, en este caso JEAGropup

$NonAdministrator = "$domain\JEAGroup"

$JEAConfigParams = @{

        SessionType= "RestrictedRemoteServer"

        RunAsVirtualAccount = $true

        RoleDefinitions = @{ $NonAdministrator = @{RoleCapabilities = 'Operadores'}}

        TranscriptDirectory = "$env:ProgramData\JEAConfiguration\Transcripts”

        }

    

if(-not (Test-Path "$env:ProgramData\JEAConfiguration"))

{

    New-Item -Path "$env:ProgramData\JEAConfiguration” -ItemType Directory

}

$sessionName = "JEA_Demo"

if(Get-PSSessionConfiguration -Name $sessionName -ErrorAction SilentlyContinue)

{

    Unregister-PSSessionConfiguration -Name $sessionName -ErrorAction Stop

}

New-PSSessionConfigurationFile -Path "$env:ProgramData\JEAConfiguration\JEADemo.pssc" @JEAConfigParams

#Registra la sesión de configuración.

Register-PSSessionConfiguration -Name $sessionName -Path "$env:ProgramData\JEAConfiguration\JEADemo.pssc"

Restart-Service WinRM

En la ruta establecida se creará el archivo de configuración de sesión JEADemo.pssc cuyo contenido tiene definidos los parámetros que establecimos en la variable $JEAConfigParams. La siguiente imagen muestra el grupo que indicamos tendrá permiso para utilizar el endpoint y el rol asignado al grupo, que en este caso es Operadores.

Con lo anterior ya tenemos todo listo para empezar a probar JEA, ahora lo que debemos hacer es conectarnos a la sesión con uno de los usuarios no administradores, para este caso el usuario  JEAUser para ello hacemos lo siguiente desde una consola de PowerShell:

$NonAdminCred = Get-Credential

Nos solicitará las credenciales del usuario no administrador:

Una vez estemos en la sesión, escribimos lo siguiente:

Enter-PSSession -ComputerName SRV2016 -ConfigurationName JEA_Demo -Credential $NonAdminCred 

Con esto ya estamos conectados al endpoint, si ejecutamos un Get-Command podemos ver tanto los cmdlets visibles para el rol y la función que definimos, en la siguiente imagen resaltadas en amarillo.

Ahora ejecutemos nuestra función Get-User

Como podemos observar arroja la información del cmdlet Get-LocalUser en el equipo remoto.

Ahora reiniciemos un servicio, algo que claramente no puede hacer un usuario normal.

Pero si intentamos ejecutar otro cmdlet que requiere privilegios elevados pero el cual no se encuentra definido para este rol, obtendremos el siguiente error:

De este modo hemos probado el funcionamiento de JEA, de aquí en adelante lo restante es identificar cuáles roles se necesitan en la organización y definir detalladamente cuáles cmdlets, funciones y programas externos conformarán cada rol, esto es algo que se debe ir implementando de forma gradual, probando el resultado de cada rol en detalle, espero que con esta corta introducción al tema sea suficiente para que cualquier pueda poner en marcha esta tecnología e ir ajustando a su necesidad, en otros artículos escribiré información sobre temas más específicos relacionados con esta característica de seguridad, como por ejemplo definir solo solo ciertos cmdlets, por ejemplo que de cierto módulo solo se puedan usar los que tengan como verbo "Get-". Como vemos aún hay bastante por abordar en este tema. Así que los ánimo a que empiecen a probar y porqué no compartir sus experiencias aquí. Un saludo y como siempre espero les sea de utilidad.

Bibliografía:

Just Enough Administration: Windows PowerShell security controls help protect enterprise data:

https://msdn.microsoft.com/en-us/library/dn896648.aspx