-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Module 3: Managing User and Service Accounts

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Cuentas de usuarios y servicios:

Las politicas de Cuentas de Usuario tienen como objetivo proteger las cuentas de usuario.
El fin de estas politicas no es tanto controlar a los usuarios como el evitar que alguien pueda comprometer una
cuenta e iniciar sesion en el dominio haciendose pasar por un usuario que no es.

Tenemos 2 secciones dentro de las GPOs para configurar la seguridad en las cuentas de usuario:
-

Password Policies
Lock Policies

Podemos aplicar tanto a nivel local como a nivel de dominio.

Estas politicas intentas frenar los ataques tipo password guessing (adivinar contrasea). Tenemos 2 posibles ataques
de este tipo:
-

Fuerza bruta: el atacante prueba todas las combinaciones posibles con un numero de caracteres.
o John the Ripper (GPU y paralelo). Requiere el archivo de hashes (contraseas cifradas).
o The hydra: Hace ataques en red. Intenta iniciar sesion a traver de la red cientos o miles de veces
por segundo
Diccionario: El atacante parte de un conjunto de contraseas habituales y hace variaciones sobre ellas.

Kerberos es el protocolo de autentificacion utilizado por microsoft. En windows Server 2012 R2 usamos Kerberos v5.
Tiene novedades respecto a versiones anteriores como la autentificacion basada en Claims. DAC.

Kerberos permite que los usuarios inicien sesion en el dominio y controla sus permisos y privilegio.

1. Cuando el usuario inicia sesion valida sus credenciales en la base de datos del AD
2. Comprueba los grupos de los que es miebro el usuario.
3. Entrega al usuario de forma temporal un TGT (Ticket grating ticket) son el SID del usuario y el SID de los
grupos a los que pertenece

Gpedit.msc abre todas la politicas locales

Secpol.msc abre solo las politicas de seguridad

Al Trabajar con politicas de seguridad a nivel de dominio o de OU, no tenemos la flexibilidad de tener diferentes
politicas para diferentes usuarios o grupos.

Una forma de hacerlo es crear un grupo y una ou en la que solo este ese grupo.. en cualquier caso, todos los usuarios
de ese grupo tendrian que estar fisicamente en la OU.

La solucion es usar los passwords settings objets o fine-grained password policies

Las PSO tienen prioridad frente a las GPOs

Las PSO se pueden asignar a usuarios o grupos globales

Si un usuario que pertenece a varios grupos tiene enlazadas a traves de ellos varias PSOs se le aplica la de
precedencia mas baja.

NO es posible enlazar una PSO a una OU. La solucion seria crear un grupo que contenga todos los objetos de esa OU
y aplicar la PSO a ese grupo. Esto es lo que se denomina Shadow Group.

Para utilizar las PSOs, el nivel funcional del dominio debe ser almenos, Windows Server 2008

Add-ADFineGrainedPasswordPolicySubject es para aplicarla

Cuentas de Servicios Administradas:

Hay escenarios en los que tenemos que habilitar servicios en un dominio y gestionarlos de forma centralizada.

Cualquier servicio, igual que cualquier aplicacin, necesita una cuenta local o de dominio para ejecutarse. Esa cuenta
debe tener los permisos y privilegios necesarios para ejecutar el servicio.

Un ejemplo es el servidor web (Internet Information Services, IIS). Para que el servidor web pueda mostrar una
pagina web a los usuarios cuando hacen la peticion desde su navegador, el servidor web debe poder acceder a los
archivos de esa pagina.

El servidor web se ejecuta con una cuenta que tiene acceso a esos archivos, pero probablemente no tenga
privilegios como el de inicio de sesion local. No sera una cuenta con privilegios de administracion por que si se ve
comprometido el servidor web, un atacante podria hacerse con la cuenta administrativa.

Para ejecutar estos servicios tenemos varias opciones:

-

Podemos usar cuentas locales en cada maquina, pero a nivel de adminstracion implica mucho esfuerzo
administrativo.
En entornos de alta disponiblilidad (HA) Se suele usar una cuenta de dominio para ejecutar el servicio.
Asi podemos administrarla de forma centralizada. Esta cuenta de dominio estara sujeta a las directivas
de constraseas del dominio.

Para que las cuentas que usamos para los servicios cumplan las directivas de contraseas y cambien de
forma automatica segn la caducidad establecida, usamos las cuentas administradas de servicios

Cuentas de servicios administradas:

El propio sistema (AD) se encarga de la gestion de las contraseas y SPN de estas cuentas. Si tenemos una politica de
caducidad de contraseas de 42 dias (por ejemplo), el AD se encargara de cambiar la contrasea en todos los
equipos en los que se usa una cuenta de servicio para la ejecucion de servicios.

Cambia la constrasea en el AD y la distribuye a todos los hosts en los que se este

Grupos de de cuentas de servicio administradas es obligatorio un controlador de dominio con Windows 2012 R2
usando

Es posible usar cuentas de servicio administradas en entornos con servidores windows 2003, pero tenemos que
actualizar elo esquema para que tenga soporte:
1. Adprep /forestprep
2. Adperp /domainprep

Ademas necesitamos un sistema de distribucion de contraseas para que la nueva que se ha generado en el AD
llegue a los servicios que la van a usar en otros host.
La clave que se usa para cifrar estas constraseas que vamos a distribuir se llama Root Key. El servicio de distribucion
de constraseas de llama KDS (Key Distribution Service).

Antes de usar cuentas administradas necesitamos crear la Root Key:

Add-KDSRootKey EfectiveInmediatly

Con esta opcion, la clave sera efectiva dentro de 10 horas (tiempo necesario para garantizar que la Root Key se ha
replicado en todos los DCs).
Para que este disponible de forma inmediata:

Add-KDSRootKey EffectiveTime ((Get-Date).addhours(-10))

Las cuentas de servicio son hibridas entre las cuentas de usuario y las de equipo. Las caracteristicas de gestion
automatizada de contraseas las hereda de las cuentas de equipo. Por ese motivo, las cuentas de servicio terminan
su UPN con el simbolo $, por ejemplo, SrvAcc1$

Creacion de cuenta de servicio

Creacion de la clave root

Crear la cuenta:

New-ADServiceAccount -Name SrvAcc1 -DNSHostName LON-DC1.adatum.com PrincipalsAllowedToRetrieveManagedPassword LON-SRV1$

Aadir la cuenta al equipo que la va a utilizar

Add-ADComputerServiceAccount -Identity LON-SRV1 -ServiceAccount Srvacc1

Ahora ya podriamos usar esa cuenta para iniciar servicios:

Para consultar cuentas de servicio creadas

Ejercicio: Crear en el dominio una cuenta administrada de servicio, IISAcc1, y aplicarla al servicio web para que se
ejecute de forma automatica

Requisitos para que una GPO se aplique a un usuario o un grupo:

-

El usuario debe estar en el contenedor afectado por la GPO.

El usuario o grupo al que el pertenece debe estar en el filtro de seguridad con el permiso READ como
minimo.

Si se cumples las 2 condiciones el orden de aplicacin es:

1.
2.
3.
4.

Sitio
Dominio
OU
Subou

El order de prioridad:
1.
2.
3.
4.

Subou
OU
Dominio
Sitio

Si hay forzado (Enforced) el orden se invierte desde el contenedor en que forzamos la GPO.

Si hay bloqueo de herencia, todo los que este por encima del nivel en que bloqueamos, se ignora. A no ser que
alguna GPO por encima del bloqueo este forzada. En ese caso, el forzado supera al bloqueo

CMAK para configurar conexiones remotas en varias maquinas a la vez

GPResult o Group Policy Results Wizard:

Nos devuelve el resultado de aplicar GPOs a equipos y usuarios que podemos seleccionar. Nos da el resultado REAL.

Para obtener el resultado actual necesitamos:

1. Que el equipo del que queremos obtener el informe se haya reiniciado desde que se modifico o aadio una
GPO con computer settings
2. Que el usuario del que queremos obtener el informe haya iniciado sesion 2 veces desde que se modifico o
aadio una GPO con user settings