A partir de Windows Server 2012 disponemos de una nueva forma de asignar permisos, además de los conocidos de compartido (“Share”) y de seguridad (“NTFS”), como es Dynamic Access Control
He leído bastante sobre el tema, pero todos los ejemplos de implementación que he visto de parte de Microsoft y algunos sitios, han resultado prácticamente un “copiar y pegar” del mismo ejemplo, que a mi entender es muy poco claro para comprender y comenzar a implementarlo
Por lo tanto he decido hacer una pequeña introducción teórica del tema, e ir desarrollando un ejemplo, desde lo más básico a las posibilidades más avanzadas
La implementación de Dynamic Access Control, en adelante DAC, nos permite asignar condiciones de acceso de acuerdo no sólo a grupos o cuentas, sino que además en base a propiedades adicionales de cuentas de usuario, o propiedades de los datos o equipo donde se incia sesión; y por supuesto combinando condiciones como hemos visto en una nota anterior
Un ejemplo, para aclarar más, asignar permiso de acceso a un recurso, teniendo en cuenta, una propiedad de la cuenta de usuario, por ejemplo el título o el departamento, y una propiedad del recurso creada por clasificación
Para esta nota dispondré de la misma infraestructura utilizada en todas las notas con Windows Server 2012 (R2): un Controlador de Dominio (DC1), un servidor miembro (SRV1) y un cliente con Windows 8.1 (CL1)
Para habilitar DAC, primero debemos preparar el ambiente:
- Modificar la “Default Domain Controllers Policy, o enlazar una nueva
- Modificar la “Default Domain Policy”, o enlazar una nueva
- Instalar “File Server Resource Manager” en SRV1
- Crear una carpeta compartida para demostrar
- Tener creados dos usuarios para probar (U1 y U2 en mi caso)
Comencemos editando la “Default Domain Controller Policy”, se podría también haber creado una nueva, y enlazarla a la Unidad Organizativa “Domain Controllers”
Debemos configurar Computer Configuration / Policies / Administrative Templates / System / KDC / KDC support for claims, compound authentication and Kerberos armoring, a “Supported”
Vamos a definir qué es un “Claim”, es una aseveración que hace un Controlador de Dominio, sobre una cuenta. Que por ejemplo, además de la información de cuentas y grupos, se incluya el valor de un atributo, que en el ejemplo que desarrollaré será la propiedad “Department” (Departamento)
Luego durante la evaluación del acceso al recurso se podrá tener en cuenta este valor del “Claim”
Ahora debemos editar, o crear una nueva, “Default Domain Policy” para que la máquina cliente solicite el uso de “Claims”
Debemos configurar Computer Configuration / Policies / Administrative Templates / System / Kerberos / Kerberos client support for claims, compound authentication and Kerberos armoring
Es un buen momento, para en todas las máquinas forzar la actualización de GPOs (GPUPDATE /FORCE)
Ahora en SRV1, y en la forma habitual debemos agregar el componente “File Server Resource Manager”
Y continuando en SRV1, crearé y compartiré una carpeta que yo he llamado “DAC1-Administracion”. El nombre es porque es la primera prueba, y permitiré el acceso a las cuentas cuyo departamente será “Administracion”
Comentario: por las dudas no he usado acentos (tildes) 😉
Para asegurarme que no interfieran los permisos de compartido he asignado que todos tengan control total
Y por último, para la preparación he creado algunos usuarios normales para prueba. En uno de ellos (U1) he completado el campo Departamento, poniéndo como valor “Administracion”
El objetivo final es que a la carpeta compartida (DAC1-Administracion) puedan acceder solamente los usuarios cuyo campo Departamento sea “Administracion”
Ahora sí, comencemos con el tema que nos ocupa
En el Controlador de Dominio debemos abrir “Active Directory Administrative Center” y poner foco en “Dynamic Acces Control / Claim Types” para crear nuestro primer “Claim”
Como pueden ver hay una cantidad bastante grande de atributos que podemos utilizar, muchos más que los que se observan normalmente, si desean revisen un poco 🙂
Además hay algunos que se aplican a usuarios, otros a máquinas, y otros a ambos; es configurable
A los efectos de mantener la demostración lo más simple para su fácil comprensión, utilizaré el atributo “Department”
Si ingresamos a las propiedades de este “Claim” veremos que debemos agregarle valores sugeridos. Puede ser solamente uno, pero en mi caso supondré que disponemos de tres departamentos diferentes que veremos si más adelante usamos
Vamos ahora a la carpeta compartida sobre la que trabajaremos, y entremos en la ficha “Security”, botón “Advanced”. Primero que nada deshabilitemos la herencia de permisos, así podremos modificarlos
Eliminemos las dos entradas correspondiente a “Users”
Ahora lo que haré es permitir el acceso, usando una entidad muy amplia como es “Authenticated Users”, pero limitando con la condición que su campo Departamento sea “Administración”
Veamos ahora en la ficha “Effective Access” cuál es el permiso efectivo para U1, que tiene el atributo Departamento “Administracion”
Y podemos ver que tiene el permiso asignado correctamente
Y procediendo análogamente con el usuario U2, podemos observar que como no tiene datos en el campo Departamento, no tendrá acceso
Como, por malas experiencias en sistemas anteriores desconfío de la ficha de permisos efectivos, voy a probarlo desde el cliente
Incio sesión en CL1 con U1, y compruebo que puede acceder y además modificar
Y si hacemos lo mismo, pero con U2, como es esperable no tiene acceso, pues no tiene Departamento “Administración”
Resumiendo, DAC es una nueva forma de administrar permisos de acceso a recursos. Ya no solamente tenemos permisos de compartido y permisos de seguridad, sino que además tenemos DAC
Es importante tener en cuenta, que dado que hay recursos sobre los que se aplicarán los tres tipos de permisos, el permiso efectivo será el más restrictivo de los tres
Continuaremos con el tema en la siguiente nota: "Dynamic Access Control – 2"
