Políticas de Contraseñas Granulares (Password Setting Objects): Automatización (y III)

Como podéis leer en el post anterior, además de utilizar la herramienta ADSI Edit también existe la posibilidad de generar objetos de tipo PSO mediante la importación de ficheros LDF. Este segundo modo es bastante más sencillo de implementar (no requiere tanto uso de ratón), pero es algo complejo de entender debido a ciertos parámetros que veremos a continuación.

Para situarnos, os recuerdo que en nuestro ejemplo contabamos con la siguiente estructura lógica de Directorio Activo:

Generacion de PSO – Estructura Logica de Directorio Activo

En el anterior post generamos un objeto PSO para «Standard Users». En este caso generaremos vía LDF un objeto PSO adicional para cualquier cuenta ubicada dentro del contenedor «Service Accounts».

Se puede generar un fichero LDF con un contenido similar al siguiente:

dn: CN=Service Accounts PSO,CN=Password Settings Container,CN=System,DC=externalforest,DC=net
changetype: add
objectClass: msDS-PasswordSettings
msDS-MaximumPasswordAge: -9223372036854775808
msDS-MinimumPasswordAge: -864000000000
msDS-MinimumPasswordLength: 15
msDS-PasswordHistoryLength: 24
msDS-PasswordComplexityEnabled: TRUE
msDS-PasswordReversibleEncryptionEnabled: FALSE
msDS-LockoutObservationWindow: -36000000000
msDS-LockoutDuration: -864000000000
msDS-LockoutThreshold: 5
msDS-PasswordSettingsPrecedence: 100
msDS-PSOAppliesTO: CN=Service Accounts Group,OU=Service Accounts,OU=Password Settings Demo,DC=externalforest,DC=net

Notad el extraño formato de los parámetros msDS-MinimumPasswordAge, msDS-MaximumPasswordAge, msDS-LockoutObservationWindow y msDS-LockoutDuration. Como podéis ver en el post anterior, debía imputarse algo tipo dias:horas:minutos:segundos, pero… ¿Que significan los números negativos?

Los números negativos significan que Directorio Activo almacena dichos valores en formato I8, o lo que es lo mismo, en múltiplos de -100 nanosegundos. Por tanto, las entidades de tiempo más comunes serán las siguientes:

• 1 segundo = -1 * (10^7) = -10000000
• 1 minuto = -60 * (10^7) = -600000000
• 1 hora = -60 * 60 * (10^7) = -36000000000
• 1 día = -24 * 60 * 60 * (10^7) = -864000000000

Por tanto basta con multiplicar los valores anteriores por el número de días, horas, minutos o segundos que consideréis necesario.

En el caso anterior los parámetros que nos ocupan son:

• msDS-LockoutObservationWindow: -36000000000 (1 hora , es decir, 0:01:00:00
• msDS-LockoutDuration: -864000000000  (1 día, es decir, 1:00:00:00)
• msDS-MinimumPasswordAge: -864000000000 (1 día, es decir, 1:00:00:00)
• msDS-MaximumPasswordAge: 9223372036854775808 = Nunca (never)

Observad que en msDS-PSOAppliesTo por claridad he especificado de nuevo el DN del grupo al que se aplica el PSO.

Una vez generado el fichero de texto bastará con importarlo mediante el siguiente comando:

• Ldifde -i -f <Fichero.ldf>

De este modo se genera un segundo objeto PSO aplicado al grupo que debe contener las Cuentas de Servicio (Service Accounts) ubicadas dentro de la unidad organizativa correspondiente. De nuevo, si se precisa adecuar la pertenencia al grupo con las cuentas existentes dentro de la OU, bastará con ejecutar las siguientes líneas:

• dsmod group «CN=Service Accounts Group,OU=Service Accounts,OU=Password Settings Demo,DC=externalforest,DC=net» -chmbr «CN=Service Account 10,OU=SQL,OU=Service Accounts,OU=Password Settings Demo,DC=externalforest,DC=net»
• dsmod group «CN=Service Accounts Group,OU=Service Accounts,OU=Password Settings Demo,DC=externalforest,DC=net» -rmmbr «CN=Service Account 10,OU=SQL,OU=Service Accounts,OU=Password Settings Demo,DC=externalforest,DC=net»
• dsquery user «OU=Service Accounts,OU=Password Settings Demo,DC=externalforest,DC=net» | dsmod group «CN=Service Accounts Group,OU=Service Accounts,OU=Password Settings Demo,DC=externalforest,DC=net»  -addmbr

Recordad que las dos primeras sentencias sustituyen la membresía del grupo por un usuario concreto (Service Account 10 en este caso) y eliminan al usuario sustituido del grupo, para posteriormente agregar única y exclusivamente los usuarios ubicados dentro de dicha OU.

Por tanto, entre los dos últimos post habremos generado dos objetos PSO, uno manual mediante ADSI Edit aplicado a «Standard Users», y otro más automático mediante un fichero LDF y aplicado a «Service Accounts», tal como muestra la siguiente imagen:

PSO Generada Mediante Ficheros LDF (y LDIFDE)

Un saludo,

Alberto Robledo.

Políticas de Contraseñas Granulares (Password Setting Objects): Implementación (II)

Al hilo del post del otro día, y una vez explicado el funcionamiento de los objetos PSO (Password Setting Objects), quedó pendiente la segunda parte, más práctica: la implementación de éste tipo de objetos.

En el caso que nos ocupa vamos a trabajar con la siguiente estructura lógica de Directorio Activo (muestro solo la parte relevante):

Generacion de PSO – Estructura Logica de Directorio Activo

La generación de un objeto PSO se debe efectuar mediante ADSI Edit o por medio de ficheros LDF.

En primer lugar explicaré el modo de generar este tipo de objetos desde ADSI Edit. Una vez abierta la herramienta, se debe navegar a la siguiente ruta:

• CN=Password Settings Container,CN=System,DC=dominio,DC=local

Una vez situados en la ruta anterior se hará clic con el botón derecho del ratón y se seleccionará Nuevo (New) –> Objeto (Object):

Generacion de Nuevo Objeto PSO desde ADSI Edit

Al hacer clic sobre Objeto (Object) aparecerá la siguiente ventana que indica que se va a generar un nuevo objeto desde la clase msDS-PasswordSettings :

Generacion de Nuevo Objeto PSO – Tipo

 Al hacer clic en Siguiente aparece otra ventana que solicita que indiquemos el CN del nuevo objeto PSO:

Generacion de Nuevo Objeto PSO – CN

Al hacer clic en Siguiente, aparecerá una ventana que solicita que indiquemos la precedencia (IMPORTANTE):

Generacion de Nuevo Objeto PSO – Precedencia (IMPORTANTE)

MPORTANTE: A la hora de diseñar objetos PSO se debe simplificar para evitar situaciones de conflicto, con lo que se recomienda definir pocos objetos PSO y con valores de precedencia distintos

Una vez especificado el nivel de precedencia (prioridad) y seleccionado Siguiente aparecerán ventanas adicionales tales que:

• msDS-PasswordReversibleEncryptionEnabled: Sus posibles valores serán True/False. Se debe indicar si el objeto PSO permite almacenar las contraseñas para que sea posible desencriptarlas con el mismo algoritmo utilizado para encriptarlas (True, menos seguro). Si no se utilizan aplicaciones legacy que lo requieran, debe indicarse False (valor por defecto).

• msDS-PasswordHistoryLength: Indicará mediante un valor numérico positivo la cantidad de contraseñas que se van a recordar para los usuarios que apliquen el objeto PSO en curso.

• msDS-PasswordComplexityEnabled: Sus posibles valores serán True/False. Indicará si las contraseñas de los usuarios que apliquen el nuevo objeto PSO deberán imputar contraseñas complejas (requiere tres tipos de carácter de cuatro conjuntos: mayúsculas, minúsculas, números y carácteres «extraños» (%, &, …))

• msDS-MinimumPasswordLength: Indicará mediante un valor numérico positivo el numero mímimo de caracteres que debe tener la contraseña de los usuarios que apliquen la PSO en curso.

• msDS-MinimumPasswordAge: Su formato será días:horas:minutos:segundos, aunque también puede especificarse que sea (none). Indicará el mínimo tiempo que debe transcurrir para que un usuario pueda cambiar su contraseña por una nueva. Por ejemplo, para que los usuarios deban utilizar una contraseña durante 24 horas como mínimo, se debe teclear el texto 1:00:00:00. (1 día, 0 horas, 0 minutos y 0 segundos).

• msDS-MaximumPasswordAge: Su formato será días:horas:minutos:segundos, aunque también puede especificarse que sea (never). Indicará el máximo tiempo que puede transcurrir para que un usuario pueda cambiar su contraseña por una nueva (con otras palabras, el tiempo de caducidad). Por ejemplo, para que los usuarios deban cambiar la contraseña a los 45 días, se debe teclear el texto 45:00:00:00. (45 días, 0 horas, 0 minutos y 0 segundos).

• msDS-LockoutThreshold: Indicará mediante un valor numérico la cantidad de intentos de inicio de sesión incorrectos que debe superarse en cierto lapso de tiempo para que una cuenta concreta quede bloqueada (Por ejemplo, 5  si se desea que tras 5 tecleos incorrectos se bloquee una cuenta concreta).

• msDS-LockoutObservationWindow: Su formato será días:horas:minutos:segundos, aunque también puede especificarse que sea (none). Indicará el período de observación (lapso de tiempo) durante el que se observarán los inicios incorrectos de sesión de una cuenta concreta. Superar el Threshold anterior durante el lapso de tiempo indicado en este punto rovocará el bloqueo de una cuenta concreta. Por ejemplo, para que una cuenta se bloquee tras cinco intentos incorrectos durante una hora, deberá especificarse 0:01:00:00 (0 días, 1 hora, 0 minutos y 0 segundos).

• msDS-LockoutDuration:  formato será días:horas:minutos:segundos, aunque también puede especificarse que sea (never) o (none). Indicará el período que se mantendrán bloqueadas las cuentas de los usuarios. Por ejemplo, para mantener bloqueada una cuenta durante un día completo, se debe teclear 1:00:00:00 (1 día, 0 horas, 0 minutos y 0 segundos).

Una vez llegado a este punto aparecerá la siguiente ventana que indica el final de la primera fase del proceso de generación de un objeto PSO:

Generacion de PSO – Fin de la Primera Fase

Tras hacer clic en Finish se debe vincular el objeto PSO a un grupo concreto. Para ello se mostrarán las propiedades del nuevo objeto, tras lo que se accederá al atributo msDS-PSOAppliesTo:

Aplicacion de PSO - Seleccion de Atributo msDS-PSOAppliesTo

Al hacer clic en Editar se puede introducir el DN de un usuario/grupo concreto (más claro) o seleccionar un usuario/grupo, lo que vinculará el SID de la cuenta. Las siguientes dos imagenes muestran sendas opciones:

Aplicacion de PSO - Opcion 1: Introduccion del DN del Grupo

Aplicacion de PSO - Opcion 2: Seleccion de SID del Grupo

Cualquiera de las dos opciones anteriores son válidas, aunque por claridad yo os recomendaría teclear el DN del grupo en cuestión. Por supuesto, al mover el grupo de ubicación el Servicio de Directorio modifica el DN correspondiente en todos los objetos PSO vinculados al mismo.

Una vez aplicada, podréis ver en el editor de atributos del usuario correspondiente que la PSO resultante debe ser la recién generada (ver post anterior).

Un saludo,

Alberto Robledo.

 

 

Políticas de Contraseñas Granulares (Password Setting Objects): Descripción (I)

Tal como os anticipaba en un post anterior, una de las mejores novedades que aporta Windows Server 2008 una vez elevado el nivel funcional al máximo es la posibilidad de generar distintas políticas de complejidad y bloqueo de contraseñas dentro de un mismo dominio. Anteriormente la necesidad imperativa de esta funcionalidad implicaba necesariamente la generación de dominios adicionales, lo que aumentaba el nivel de complejidad del bosque.

En Windows Server 2008 ya es posible utilizar Políticas de Contraseñas Granulares. Éste aspecto implica la generación de un nuevo tipo de objeto: Password Setting Object (PSO). Cada objeto de este tipo contiene una definición completa de políticas de contraseñas (longitud mínima, máxima duración, complejidad, etc…), y puede ser vinculado a uno o más objetos de grupo/usuario.

Antes de crear objeto PSO alguno debéis entender cual es su funcionamiento. Éstas son las claves de los objetos PSO que se deben tener en cuenta en todo momento:

• En un dominio pueden coexistir varios objetos de tipo PSO.
• Un objeto de tipo PSO puede ser vinculado a la vez a varios usuarios o grupos.
• Un usuario puede pertenecer a varios grupos afectados por objetos de tipo PSO.

Por tanto, un usuario tipo puede llegar a tener asociados varios objetos de tipo PSO, tanto directamente (PSO aplicado al usuario) como indirectamente (PSO aplicado a grupos a los que el usuario pertenece). Sin embargo, un usuario solo puede tener aplicada una política de contraseñas… ¿Cómo resolver la incógnita?

Para resolver la incógnita los objetos de tipo PSO llevan asociado, entre otras cosas, un número de precedencia (prioridad), que será almacenado en el atributo msDS-PasswordSettingsPrecedence. El atributo anterior debe tomar valores positivos superiores a ‘0’, donde el valor ‘1’ indica la mayor prioridad.

Por tanto, el Servicio de Directorio calculará el objeto PSO que será aplicable a cada usuario en cada caso. Para ello toma las siguientes consideraciones:

• Si el usuario pertenece a varios grupos sometidos a distintos PSO, se aplicará la política del PSO del grupo que tenga mayor precedencia (menor valor –> más prioridad).
• Si el usuario tiene asociados objetos PSO directamente, se ignoran las de los grupos (menos específicas)… y, de nuevo, se aplicará la política del PSO que tenga mayor precedencia.
• En caso de «empate» (es decir, existen varios PSO a aplicar con la misma precedencia), el Servicio de Directorio tomará una determinación totalmente arbitraria: Aplicará la política del PSO que disponga del menor valor de GUID.

IMPORTANTE: A la hora de diseñar objetos PSO se debe simplificar para evitar situaciones de conflicto, con lo que se recomienda definir pocos objetos PSO y con valores de precedencia distintos.

Windows Server 2008 dispone de un modo sencillo para determinar el último objeto PSO que se ha aplicado a un usuario concreto mediante un atributo calculado en el momento: msDS-PSOApplied. Del mismo modo permite determinar el objeto PSO que se aplicará a dicho usuario la próxima vez que inicie sesión (conocido como PSO resultante), mediante un atributo similar: msDS-ResultantPSO.

Para determinar este aspecto, de nuevo, se puede utilizar la consola de Usuarios y Equipos de Directorio Activo y examinar la nueva pestaña Editor de Atributos tal como muestra la siguiente imagen: 

PSO Aplicada (Resultante)

Evidentemente, y según la estructura lógica del Servicio de Directorio, se puede llegar a pensar que lo lógico sería vincular una PSO dentro de una Unidad Organizativa (OU)… pero los objetos PSO solo pueden ser aplicados a usuarios y/o grupos. Por tanto… ¿que solución cabe?

Microsoft propone generar lo que se denomina «Shadow Group». Un grupo de este tipo es conceptual, ya que contendrá todos y cada uno de los usuarios ubicados dentro de una OU.

Debéis tener claro que la gestión del contenido del grupo debe llevarse en paralelo a la gestión del contenido de la Unidad Organizativa. Dicha gestión es sencilla cuando se elimina una cuenta de usuario (desaparece automáticamente del grupo), pero… ¿que ocurre cuando se mueve una cuenta hacia otra OU?

Se puede generar un CMD que actualiza automáticamente el contenido del grupo con las siguientes líneas:

• dsmod group <Grupo a Modificar> -chmbr <Usuario>
• dsmod group <Grupo a Modificar> -rmmbr <Usuario>
• dsquery user <Unidad Organizativa> | dsmod group <Grupo a Modificar> -addmbr

(NOTA: Los valores introducidos entre <> deben ser los Distinguished Names del Usuario, Grupo y Unidad Organizativa, respectivamente)

Os explico:

• El primer DSMOD con el parámetro –chmbr elimina por completo la membresía del grupo a modificar, sustituyéndola por el único usuario <Usuario>,
• El segundo DSMOD  con el parámetro –rmmbr elimina el usuario <Usuario> y deja la membresía del grupo a modificar en blanco, y
• El DSQUERY efectúa una consulta de los usuarios residentes dentro de la Unidad Organizativa deseada y efectúa el alta en el grupo a modificar mediante DSMOD utilizando el parámetro -addmbr

De ese modo se puede mantener de modo dinámico el contenido del grupo, mediante una tarea programada que se ejecute cada cierto tiempo (diariamente, semanalmente, etc…)

Una vez entendido su funcionamiento, ya os contaré en un siguiente post como se generan los objetos PSO.

Un saludo,

Alberto Robledo.

Informacion Sobre el Ultimo Inicio de Sesión Interactivo

Lo prometido es deuda… y tal como os anticipaba en el post anterior, ahí va el primer post que explica una de las novedades introducidas en Windows Server 2008 una vez elevado el nivel funcional del dominio hacia Windows Server 2008.

Antes de nada: Debéis tener mucho, mucho cuidado con esta nueva funcionalidad, ya que, mal implementada puede evitar el inicio de sesión en cualquier equipo del dominio. Se debe tener en cuenta en todo momento que la funcionalidad requiere:

• Que se haya elevado el nivel funcional del dominio hacia Windows Server 2008,
• Que se haya configurado una GPO a nivel de los Controladores de Dominio para que éstos almacenen la información en los nuevos atributos de usuario, y
• Que se haya configurado una GPO a nivel de equipo en los puestos que vayan a reportar la información

Dado que la funcionalidad requiere el uso de GPO’s, se debe destacar que ésta funcionalidad es aplicable tanto para equipos Windows Vista como para equipos Windows Server 2008. Si se dispone de algún cliente XP, éste ignorará la directiva.

Windows Server 2008 introduce una serie de nuevos atributos que permiten hacer uso de ésta funcionalidad. Los atributos que nos ocupan en este caso son los siguientes:

• msDS-LastSuccessfulInteractiveLogonTime: Almacena información acerca del momento en el que se efectuó un Inicio de Sesión Interactivo correcto.
• msDS-LastFailedInteractiveLogonTime: Contiene información sobre el último momento en el que se intentó efectuar un Inicio de Sesión Interactivo de modo incorrecto (contraseña incorrecta).
• msDS-FailedInteractiveLogonCount: Informa acerca del número total de Inicios de Sesión Interactivos fallidos desde que se habilitó la funcionalidad.
• msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon: Indica el número total de Inicios de Sesión Interactivos fallidos, tomando como referencia el último inicio de sesión correcto. Nótese que la diferencia entre éste parametro y el anterior permite verificar el número total de intentos de Inicio de Sesión Interactivo incorrectos desde el último correcto.

La siguiente imagen contiene un detalle de los parámetros que nos ocupan (observad el «Editor de Atributos«, una de las nuevas pestañas presentes en la consola de «Usuarios y Equipos de Directorio Activo» de Windows Server 2008 y que proporciona acceso a los atributos del objeto seleccionado… y para lo que en Windows Server 2003 se debía utilizar ADSIEdit):

Atributos Relacionados en Informacion de Logon Interactivo

Por medio de los parámetros descritos anteriormente se puede ofrecer información detallada a cada cliente en el momento de efectuar un inicio de sesión, tal como muestra la siguiente imagen:

Informacion sobre Logon Interactivo

Si es la primera vez que se efectúa un Inicio de Sesión Interactivo despues de haber habilitado la funcionalidad que nos ocupa aparecerá un mensaje como el que sigue:

Primer Inicio de Sesion Interactivo

Ahora bien, reitero lo que os indicaba anteriormente: Ésta funcionalidad tan solo debe ser habilitada adecuadamente, y una vez que se haya elevado el Nivel Funcional del dominio hacia Windows Server 2008. Si se habilita antes puede evitar (lo hará) el inicio de sesión en todo el dominio, tal como muestra la siguiente imagen:

Error al Efectuar un Logon Interactivo

IMPORTANTE: Si se ha elevado el nivel funcional del dominio hacia Windows Server 2008 y sigue apareciendo el error anterior, muy probablemente se deba a que no se ha configurado una GPO a nivel de Controlador de Dominio para que se almacene la información anterior, o que se ha configurado la GPO pero ésta no se ha replicado hacia todos los Controladores de Dominio.

La directiva que hay que habilitar se encuentra localizada en la siguiente rama:

• Computer Configuration\Policies\Administrative Templates\Windows Logon Options

El setting a modificar se denomina «Display information about previous logons during user logon».

Cabe destacar que el mismo setting sirve tanto para indicarle a los Controladores de Dominio que deben almacenar la información como para indicarle a los equipos cliente que deben mostrarla. Por tanto, sirve con generar una única GPO y vincularla tanto bajo la OU de los Controladores de Dominio como bajo la OU de los equipos que se pretende reporten la información anterior.

Por supuesto, conviene habilitar en primer lugar la GPO a nivel de Controlador de Dominio y dejar que la replicación haga su trabajo, y posteriormente habilitar el mostrado de información a nivel cliente. De ese modo se evitarán muchos «sustos»…

Un saludo,

Alberto Robledo.

Novedades en el Servicio de Directorio Activo de Windows Server 2008 (AD DS)

El Servicio de Directorio ya es un servicio maduro, ya que lleva en el mercado cerca de 10 años. Como bien sabréis, Windows Server 2003 introdujo ciertas mejoras sobre el servicio ofrecido incialmente en Windows 2000 Server, como por ejemplo la replicación incremental (aka LVR) o la posibilidad de efectuar relaciones de confianza a nivel de bosque.

Del mismo modo, Windows Server 2008 no podía quedarse atrás… con lo que éste Sistema Operativo introduce más mejoras a nivel de AD DS, una vez elevado el nivel funcional adecuadamente.

Una vez elevado el nivel funcional del dominio hacia Windows Server 2008 se obtienen cuatro nuevas funcionalidades:

• Replicación Distribuida de SYSVOL (DFS-R): Se trata de un modo de replicación más robusto y detallada, en detrimento de FRS (File Replication Service).
• Sistema Avanzado de Encriptación (AES): Se puede configurar Kerberos para que utilice sistemas de encriptación más avanzados (AES 128 y AES 256), en detrimento del algoritmo RC4-HMAC (Hash Message Authentication Code).
• Información del Último Logon Interactivo: Éste aspecto permite modificar el objeto del usuario para establecer atributos relativos al inicio de sesión, como puede ser la fecha y hora del último inicio de sesión, o el número de intentos fallidos de logon desde el último aceptado. Además, tanto Windows Vista como Windows 2008 (clientes) permiten explotar esta nueva funcionalidad.
• Políticas de Password Granulares: Para mí, una de las mejores funcionalidades de Windows Server 2008, ya que, hasta ahora, la necesidad de dicha funcionalidad requería la gestión de múltiples dominios. Ésta posibilidad permite generar mediante objetos PSO (Password Setting Object) diversas políticas de contraseñas (complejidad, caducidad, etc…) y establecerlas en base a grupos. Por ejemplo, mediante esta funcionalidad se puede generar una política general (más relajada) para los usuarios de dominio, y establecer políticas adicionales más seguras para las cuentas administrativas… e incluso una mucho más segura para las cuentas de servicio.

Prometo generar nuevos post con el detalle de estas nuevas funcionalidades…

Un saludo,

Alberto Robledo