Con Windows Server® 2008 podemos establecer distintas políticas de contraseñas y de bloqueo de cuentas para distintos usuarios en un dominio En dominios Windows 2000 y Windows Server 2003, sólo se podía definir una única política de contraseñas y de bloqueo de cuentas para todos los usuarios del dominio. Estas políticas se definían en la Default Domain Policy. Las únicas opciones para establecer configuraciones distintas para distintos usuarios eran Crear un “password filter” o Crear dominios distintos 3 Con FGPP: Podemos aplicar múltiples políticas de contraseñas en un único dominio. Podemos configurar distintas políticas para distintos (conjuntos de) usuarios Por ejemplo; Una política estricta para Administradores (las contraseñas caducan cada 14 días..) Una política menos estricta para usuarios normales (las contraseñas caducan cada 90 días) Una política específica para cuentas de servicio (longitud mínima de contraseña, 32 caracteres….) 4 A Administradores de Dominio interesados en definir diferentes políticas de contraseñas para diferentes grupos de usuarios dentro del Dominio 5 Solo aplican a objetos user (o objetos inetOrgPerson) y a grupos globales de seguridad, no a equipos Solo los Domain Admins pueden establecer políticas FGPP Se pueden delegar permisos a otros usuarios No se puede establecer FGPP directamente sobre una OU Se pueden utilizar “Shadow Groups”: Un grupo global de seguridad que se mapea lógicamente a (los miembros de) una OU Para funcionar correctamente, requiere nivel funcional de dominio Windows Server 2008 No interfiere con password filters 6 Almacenamiento de FGPP Windows Server 2008 incluye 2 nuevos clases de objetos en el esquema: Password Settings Container (PSC) Password Settings (PSO) Un contenedor Password Settings Container (PSC) se crea por defecto debajo del contenedor System del dominio. (visible desde ADU&C con opciones avanzadas habilitadas) Almacena los objetos Password Settings (PSOs) para ese dominio No se puede borrar, renombrar o mover No se consideran contenedores PSC “custom” a la hora de calcular el conjunto de políticas aplicables a un objeto. 7 PSO Se crean y se modifican con ADISEDIT o con LDIFDE Un objeto PSO contiene atributos para todas las opciones disponibles para políticas de contraseñas en el Default Domain Policy (salvo las de Kerberos): Enforce password history (msDS-PasswordHistoryLength) Maximum password age (msDS-MaximumPasswordAge) Minimum password age (msDS-MinimumPasswordAge) Minimum password length (msDS-MinimumPasswordLength) Passwords must meet complexity requirements (msDS-PasswordComplexityEnabled) Store passwords using reversible encryption (msDSPasswordReversibleEncryptionEnabled) También contienen atributos para las siguientes opciones de políticas de bloqueo de cuentas: Account lockout duration (msDS-LockoutDuration) Account lockout threshold (msDS-LockoutThreshold) Reset account lockout counter after (msDS-LockoutObservationWindow) 8 Un objeto PSO también contiene los siguientes atributos nuevos: PSO link (msDS-PSOAppliesTo) Atributo multi-valor asociado a usuarios/grupos Precedence (msDS-PasswordSettingsPrecedence). Valor númerico (integer) que sirve para la resolución de conflictos si se aplican múltiples PSO a un mismo usuario/grupo Todos estos atributos, salvo msDS-PSOAppliesTo, son obligatorios (mustHave) Hay que definir cada uno de ellos y no se pueden combinar las opciones de distintos PSO Step-by-Step Guide for Fine-Grained Password and Account Lockout Policy (Step 1: Create a PSO) http://technet2.microsoft.com/windowsserver2008/en/library/67dc7808-5fb4-42f88a48-7452f59672411033.mspx 9 Definir el ámbito de FGPP Los PSO se aplican a usuarios, grupos o objetos inetOrgPerson del mismo dominio que el PSO El atributo msDS-PSOAppliesTo del PSO: contiene un enlace (forward link) a usuarios o grupos Es de tipo multivalor, por tanto aplicable a múltiples usuarios/ grupos Podemos aplicar una única política a distintos conjuntos de usuarios/ grupos Para usuarios/grupos existe el nuevo atributo msDS-PSOApplied: contiene un enlace (back-link) al PSO Al contener un “back-link”, cada usuario o grupo puede tener múltiples PSO aplicados. La configuración que finalmente se aplica se calcula mediante RSOP Podemos aplicar (enlazar) un PSO a otros tipos de grupos (de distribución, no globales) pero a la hora de calcular RSOP, sólo se considerarán los PSO aplicados a usuarios o grupos globales de seguridad. 10 RSOP (Conjunto Resultante de Políticas) Un usuario/grupo puede tener múltiples PSO aplicados: Por pertenencia a múltiples grupos que a su vez tienen distintos PSO aplicados Por tener múltiples PSO aplicados de forma directa Sin embargo, sólo un único PSO puede ser efectivo Sólo la configuración de ese PSO puede ser efectivo, las opciones de distintos PSO enlazados al mismo usuario/grupo no se pueden combinar Solo se calcula RSOP para usuarios. Un PSO se aplica a un objeto usuario de dos maneras: Directamente: (enlazado al usuario) Indirectamente: (enlazado a un grupo(s) al que pertenece el usuario Cada PSO tiene otro atributo, msDS-PasswordSettingsPrecedence; para calcular el RSOP. Tiene un valor numérico de 1 en adelante Un valor menor indica mayor preferencia/prioridad sobre otros PSO 11 RSOP Por ejemplo, teniendo 2 PSO aplicados, con valores de “precedence” 2 y 4, el valor 2 sería el efectivo al tener mayor prioridad Si un usuario/grupo tiene múltiples PSO aplicados, el PSO efectivo se calcula de la siguiente manera 1. 2. 3. Un PSO enlazado directamente al usuario es el que se aplica. Si hay mas de un PSO enlazado al usuario (no recomendado), se escribe un evento de aviso en el visor de sucesos y se aplica el PSO con menor valor de precedence Si no hay PSO enlazado al usuario, se compara su pertenencia a grupos globales de seguridad y los PSO aplicables en base a esta pertenencia . De nuevo se aplica el PSO de menor valor (mayor prioridad) Si no se obtiene ningún PSO de las opciones 1 y 2, se aplica el Default Domain Policy 12 RSOP Se recomienda crear un valor msDS-PasswordSettingsPrecedence único para cada PSO. Si se obtiene el mismo valor msDS-PasswordSettingsPrecedence para un usuario de las opciones 1 y 2 anteriores, se aplica el PSO con el menor GUID. Existo otro nuevo atributo, msDS-ResultantPso para objetos usuario. Contiene el DN (distinguished name) del PSO que finalmente aplica al usuario. Si no se le aplica ningún PSO al usuario, el valor es NULL Si queremos configurar una política especial para un miembro de un grupo distinta a la política que se aplica al grupo, creamos un PSO “excepcional” y lo enlazamos directamente al usuario. Cuando se calcula msDS-ResultantPso esta PSO excepcional tiene preferencia sobre todos los demás 13 RSOP Al igual que sobre las políticas de contraseñas en Windows 2000/ 2003, los siguientes bits/valores del atributo userAccountControl del objeto usuario tienen preferencia sobre las opciones del PSO resultante/efectivo Reversible password encryption required Password not required Password does not expire 14 15 Seguridad y Delegación Por defecto solo los Domain Admins pueden crear PSOs. Solo ellos tienen permisos Create Child y Delete Child sobre el contenedor Password Settings Solo ellos tienen permisos Write Property sobre PSOs Por tanto solo ellos pueden aplicar PSOs a usuarios o grupos. Se pueden delegar estos permisos a otros usuarios o grupos. Puedes enlazar un PSO a usuarios o grupos sin tener permisos sobre ellos. Tener permisos de escritura sobre un usuario o grupo no implica poder enlazarles un PSO. El dueño de un grupo no tiene permisos para enlazarle un PSO por que se enlazan desde el propio PSO. El dueño de un PSO lo puede enlazar a un usuario o grupo 16 Seguridad y Delegación Por defecto: Los usuarios autentificados no tienen permisos de Read Property sobre un PSO (no pueden ver las opciones) al considerarse información confidencial. Sólo Domain Admins tienen permisos de Read Property sobre el security descriptor del objeto PSO en el esquema. Se pueden delegar estos permisos a cualquier grupo del dominio o del bosque (p.ej un grupo Helpdesk) Un usuario puede leer los atributos msDS-ResultantPso o msdsPSOApplied pero solo muestran el nombre distinguido del PSO que aplica al usuario (no puede ver las opciones configuradas). 17 Hay que ejecutar ADPREP para poder añadir un DC Windows Server 2008 a un dominio existente Al ejecutar ADPREP se extiende el esquema para incluir las nuevas clases de objeto para FGPP Si no creamos políticas FGPP, seguirá aplicándose a todos los usuarios las políticas de contraseñas del Default Domain Policy al igual que en dominios Windows 2000 y Windows Server 2003 18 Disponible en todas las versiones de Windows Server 2008 19 demo Enlaces http://technet2.microsoft.com/windowsserver2008/en/librar y/2199dcf7-68fd-4315-87cc-ade35f8978ea1033.mspx © 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
