Just Enough Administration - Configuración

miércoles, 26 de abril de 2017


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:

Just Enough Administration - Cómo funciona

martes, 25 de abril de 2017


En el artículo anterior, hice una breve introducción a JEA (Just Enough Administration). En este artículo vamos a ver cómo funciona

¿Cómo funciona JEA?


JEA funciona con sesiones remotas de PowerShell, utilizando Restricted Endpoints, éstos últimos básicamente definen lo que puede hacer un usuario en la sesión, JEA no es más que una mejora es esto incluyendo cosas como definición de roles, lo que facilita la restricción en los endpoints y sesiones remotas de PowerShell. Anteriormente JEA hacia parte de PowerShell DSC (Desired State Configuration), pero luego se separó y se encuentra como característica de Windows Management Framework (WMF) 5.0 y posteriores.

Los endpoints de PowerShell que menciona antes son sobre los cuales funciona JEA y consisten básicamente en dos componentes: Archivo de configuración de sesión y Archivo de funcionalidad de rol

Archivo de configuración de sesión: Es un archivo con extensión .pssc que define quién se puede conectar al endpoint , el archivo básicamente contiene cuáles usuarios, grupos o cuentas virtuales pueden establecer la conexión.

Archivo de funcionalidad de rol: Es un archivo con extensión .psrc define lo que los usuarios en el archivo de configuración de sesión pueden hacer, se específica cuáles cmdlets o funciones pueden ejecutar.




¿Cómo obtener JEA?

JEA hace parte de Windows Management Framework a partir de la versión 5.0 en Windows Server 2016 ya viene integrado, para las versiones anteriores es necesario instalar WMF 5.0. Otras versiones donde podemos hacer uso de JEA son:

  • Windows 10 con el update (1511), Windows 8, 8.1 y Windows 7
  • Windows Server 2012, 2012 R2 y Windows Server 2008 R2


Habilitar PowerShell Remoting

JEA se basa en PowerShell Remoting, para lo cual debemos habilitarlo previamente, corriendo el siguiente comando en una consola elevada:

Enable-PSRemoting


En Windows Server 2016 ya viene habilitado por defecto.

Ya que hemos visto esta introducción y lo que necesitamos para empezar a utilizar JEA, en el próximo artículo veremos cómo hacer la configuración.

JEA - Just Enough Administration

Just Enough Administration (JEA, en adelante), se trata de una tecnología de seguridad que básicamente sirve para restringir lo que pueden hacer los administradores de TI sobre la infraestructura, lo anterior sin necesidad de otorgarles privilegios de administrador, lo cual ayuda a mitigar en gran medida los riesgos que pueden existir al utilizar cuentas con privilegios elevados, y no solamente por lo que los administradores de TI puedan llegar a realizar con estas  credenciales, sino por otro tipo de amenazas como por ejemplo virus y código malicioso que puede aprovecharse de de esto para poner en riesgo nuestra infraestructura. JEA es basado en Windows PowerShell, por lo cual cualquier tecnología que se pueda administrar con PowerShell está completamente dentro del alcance de JEA.

JEA no se trata de algo  nuevo en el mundo Microsoft, de hecho el empleo de Windows PowerShell-constrained run spaces, ya es utilizado en entornos como Exchange Online, donde se puede asignar asignar tareas utilizando en modelo RBAC para controlar las tareas que se pueden realizar en esta plataforma.

El modelo RBAC se usa ya hace buen tiempo, sin embargo no siempre satisface al 100% las necesidades de las organizaciones, y muchas veces se resulta otorgando más permisos de los que realmente necesita un administrador para hacer determinada tarea. Adicionalmente este modelo es más usado a nivel de aplicación, hasta el momento Windows no incorpora un modelo RBAC, pero ahora gracias a JEA (ya incorporado en Windows Server 2016) podemos establecer un modelo basado en roles para asignar permisos a los administradores de TI utilizando el principio de Least -Privilge

Principal desafío

El principal desafío para empezar a implementar y utilizar JEA es el uso de PowerShell, pues muchos de los administradores de TI están bastante acostumbrados a la interfaz gráfica (GUI) y no se encuentran familiarizados con el uso de la línea de comando, así que el primer desafío es empezar a entender y usar  PowerShell, es algo muy importante  hoy en día, ya que la gran mayoría de tecnologías Microsoft y algunas de terceros incluyen módulos para administrar mediante Windows PowerShell

Caso de uso

Un caso de uso típico es que voy a poner a continuación.

Un administrador del servicio DNS necesita realizar tareas de mantenimiento del servicio como por ejemplo vaciar la caché DNS e incluso reiniciar el servicio, normalmente el servicio de DNS se encuentra instalado en el servidor que tiene el rol de controlador de dominio, y para que el administrador de DNS pueda realizar las tareas que necesita la única posibilidad es otorgarle privilegios de administrador de dominio, es decir agregarlo al grupo Domain Admins, que es el grupo con más altos privilegios en Active Directory, lo cual puede comprometer toda la organización bien sea porque un administrador inescrupuloso abuso del acceso que se le otorgó o bien sea porque software malintencionado utilizó las credenciales para ejecutar código potencialmente peligroso.

JEA proporciona una solución para el caso anterior, ya que los administradores de DNS se pueden conectar a un endpoint donde pueden tener acceso a los cmdlets de PowerShell necesarios para administrar el servicio de DNS, como por ejemplo reiniciar el servicio y eliminar la caché, la mejor parte es que para hacer uso de estos comandos que generalmente requieren altos privilegios se usará una cuenta virtual que se usa solo durante la sesión y cada sesión que se establezca creará una cuenta virtual diferente en cada servidor. Lo anterior nos ayuda a eliminar de nuestra organización el número de administradores con altos privilegios.

En los próximos artículos veremos cómo funciona JEA.

Como siempre espero esta información les sea de utilidad.


Instalación de Active Directory en Windows Server 2016

miércoles, 19 de abril de 2017


A continuación vamos a ver los pasos para instalar Active Directory en Windows Server 2016, en realidad se trata de una tarea básica que ya hemos hecho en versiones anteriores, simplemente lo hago con el fin de ver si existe algún cambio, y además para escribir algunos otros artículos sobre AD en Windows Server 2016, así que veamos el paso a paso.

De igual forma que en Windows Server 2012 no existe el dcpromo, así que agregamos el rol directamente desde Server Manager.

Leemos las recomendaciones antes de instalar como por ejemplo tener el servidor actualizado y hacemos clic en Next



En tipo de instalación dejamos marcada la primer opción (que es la predeterminada) y hacemos clic en Next



Seleccionamos el servidor y hacemos clic en Next. Es una buena oportunidad para revisar la dirección IP y el nombre del servidor.


En roles de servidor, marcamos Active Directory Domain Services, si solicita características adicionales las agregamos, y luego hacemos clic en Next




En características dejamos las que se encuentran marcadas, por ejemplo podemos ver la consola de directivas de grupo y las consolas de administración.


Por fin algo diferente, la siguiente ventana nos muestra a parte de unas recomendaciones, podemos ver información sobre Azure Active Directory y contiene enlaces para obtener más información así como también un enlace con información para configurar Office 365 con Azure AD Connect


Por último la confirmación de la configuración elegida, y la opción para reiniciar de manera automática el servidor si se requiere.



Al finalizar la instalación, y de la misma manera que en Windows Server 2012, aparece la opción para promover el servidor como controlador de dominio, hacemos clic para empezar.


El asistente para promover el servidor no cambia para con respecto a la versión anterior, lo primero elegir el tipo de despliegue, en este caso crearemos un nuevo bosque llamado itpros-dc.local


A continuación  podemos seleccionar el nivel funcional, mínimo Windows Server 2008, la opción para el servicio DNS, GC, RODC y la contraseña del modo de restauración de servicios de directorio (DSRM). 


En Opciones DNS hacemos clic en Next para continuar.



En nombre NetBIOS dejamos el nombre sugerido y hacemos clic en Next


Seleccionamos las clásicas rutas de bases de datos, logs y SYSVOL y hacemos clic en Next


Una última revisión a la configuración elegida y hacemos clic en Next




Verificamos que se cumplan todos los prerequisitos y hacemos clic en Install


Al finalizar y después de reiniciar ya tenemos instalado nuestro controlador de dominio en Windows Server 2016, como podemos ver ni hay ningún cambio en la instalación, todo sigue igual que antes, en otros artículos explicaré lo que se ha incluido nuevo en los servicios de dominio de Active Directory.





 

MVP Award

MVP Award
Microsoft Azure

Lo más visto

Certificaciones

Comunidad

Comunidad
Comunidad Técnica

Sobre mi

Mi foto
Microsoft Azure MVP MCT|MCSE|MCSA

Visitantes


flags.es