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.