Академический Документы
Профессиональный Документы
Культура Документы
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
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
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.
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
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.
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
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.
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).
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:
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$
Crear la cuenta:
Ejercicio: Crear en el dominio una cuenta administrada de servicio, IISAcc1, y aplicarla al servicio web para que se
ejecute de forma automatica
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
Nos devuelve el resultado de aplicar GPOs a equipos y usuarios que podemos seleccionar. Nos da el resultado REAL.