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»
WindowServer 
Comentarios
Hola Guillermo! Ante la llegada de Windows server 10 merece la pena certificarse todavía en 2012. Gracias!
Hola Francisco, es una pregunta difícil de responder
Si ya tuviera aprobado algún examen de W2012 no lo dudaría y seguiría. En cambio si recién comienzo a estudiar, está para pensarlo
También tener en cuenta que hasta que salga la nueva versión de server va a pasar bastante tiempo, y además hay que esperar que estén disponibles los exámenes, que a veces pasan varios meses
Revisa los siguientes enlaces que tiene las novedades de la nueva versión (¿se llamará Server10? ¿Server X?)
What’s New in the Windows Server Technical Preview
http://technet.microsoft.com/en-us/library/dn765472.aspx
Hyper-V
http://technet.microsoft.com/en-us/library/dn765471.aspx
Realmente no veo cambios substanciales
Pareciera entonces que te estoy sugiriendo que sigas con W2012, pero no es así, porque históricamente cuando recién sale un producto los exámenes suelen ser más fáciles; y al fin de vida del producto mejor ni te cuento de los exámenes :-)
Evalua, piensa, piensa otra vez, y decide :-)
Muchas gracias Guillermo !!
A vos Jorge :-)
Hola Guillermo, buenas tardes, he realizado el procedimiento tal cual lo mencionas, utilizando otros nombres. Tengo un SVR w2012r2, como DC, en el AD cree algunos usuarios que se encuentran en diferentes grupos y tengo una PC (PC1) en red con la que pruebo los cambios de GPO y de AD.
Ahora bien cree un usuario U1 que pertenece a la OU RRHH. Le cree a ese usuario una GPO para que no pueda ingresar a la configuracion de IE (solo para comenzar a jugar con las GPO luego de ver tu post sobre asistencia remota, el cual hice y funciono perfectamente). A este usuario U1 le agregue en Departament: Recursos
Agregue las 2 politicas de GPO en Default Domain Controller Policy (KDC/KERBEROS), luego de agregar la caracteristica File Server Resource Manager, cree la carpeta RRHH-Admin en el C:\
Le di los permisos tal cual lo mencionas. Pero en la PC1 conectada en red al loguearme con el U1 veo la carpeta pero no tengo permisos. Ejecute GPUPDATE /FORCE, revise los pasos y nada sigo sin poder acceder. Si elimino el DAC y le doy permisos en la carpeta compartida al usuario funciona, lo que no me replica es el DAC con el Departament = Recursos.
Consultas:
1- Debe ser con “Authenticated Users” o tambien puede ser con Domain Users, los permisos, lo he probado con ambos y nada.
2- Siguiendo tu 2do post al respecto veo que ejecutas una instruccion en el powerShell: “Update-FSRMClassificationPropertyDefinition”
Logueado en el server como user Administrator me dice: Update-FSRMClassificationPropertyDefinition: 0x80070005, access is denied.
3- El tiempo de replicacion de lo realizado para que impacte en el usuario deberia ser inmediato luego de ejecutar GPUPDATE /FORCE. Cerrando y abriendo sesion nuevamente?
Que crees me puede estar fallando?
Hola lbally, es un tema muy largo y hay que ir revisando que cada uno de los pasos no presente errores. Hay dos cosas que nombras que dan la pista sobre dónde puede estar el problema:
– Dices que si le das permiso al usuario entra, pero no con DAC. Recuerda que el permiso efectivo es el más restrictivo entre todos: Compartido, Seguridad, y DAC, así que no puede no tener permisos de los «normales»
– Si cuando ejecutas el comando de PowerShell para actualizar la clasificación, te da «access denied», entonces ahí hay un problema de permisos, porque si no actualiza la clasificación de los documentos eso no va a funcionar
Respecto a la última pregunta, siempre para estar seguro que una GPO se aplica, si no funciona de primera, hacer un reinicio de máquina y dos inicios de sesión con usuario, es de lo primero a hacer
También puedes ver si se están aplicando las GPOs con GPRESULT, o inclusive desde la consola de administración de GPOs en el servidor puedes ver las configuraciones, y revisar el log de errores
DAC es un tema muy largo y con cierta complejidad, te soy sincero y habría que revisar cada uno de los pasos que haz hecho, que por supuesto no puedo :)
Gracias por la respuesta Guillermo, el comando lo estoy ejecutando como Admin del equipo, con el usuario administrador y con otro que cree que lo puse como adminitrador del dominio y como administrador local del server. Realizaré los pasos nuevamente.
Gracias
Acordate que si se incluye un usuario en un grupo, el mismo debe cerrar sesión y volver a iniciar para que se actualicen las credenciales
No hay caso, al intentar ejecutar Update-FsrmClassificationPropertyDefinition me indica: Update-FsrmClassificationPropertyDefinition: 0x80070005, Access is denied.
Lo ejecuto como Admin y con otro user que es miembro de Domain Admin y miembro de Enterprise Admins.
Estoy bajando actualizaciones al server, por las dudas… en internet no encontre nada respecto a este mensaje de Access is Denied.
Se te ocurre algo mas? el entorno armado es muy sencillo y no tiene nada complejo el diseño del AD. Cinco usuarios en una OU con diferentes permisos y una PC en otra OU.
Por otro lado te consulto: cuando agregas el claim type Departament por defecto viene en Disable, vos lo pones en Enable tambien verdad?, en un documento de Microsoft leí que tambien ponian en Enable los claim Impact, y Personally Identifiable Information. Vos tuviste que ponerlos en enable tambien o te funciono sin cambiar esos valores?
Para el tema del acceso denegado, voy a jugarme a los más obvio :) ¿la consola de PowerShell la inciaste con botón derecho y «Run as administrator» creo que apostaría a que es eso :)
Si, por supuesto «Department» habilitado, y el resto no toqué nada
Guillermo luego de las actualizaciones me dejo correr el comando, pero lamentablemente no lo puedo hacer funcionar. Es un misterio el DAC. Gracias por responder de todas formas.
Hola lbally, no, no es un misterio, pero es complicado, muchos detalles y al más mínimo que falte ya no funciona
A mí me ha costado bastante trabajo hacerlo funcionar, y fue por eso que puse la nota :)
Hola Guillermo!
Interesante esta nueva capa de seguridad, con este nivel extra se puede hacer un control más detallado de acceso a los recursos.
El ejemplo de la segunda parte no es tan interesante ya que se puede lograr lo mismo con los permisos de seguridad, por eso me encuentro a la espera de la tercera parte :) donde esta asignación se puede hacer de forma automática.
Hola Coldfran, no la esperes :)
El tema es interesante, pero a mi entender no es fácil de implementar, y su aplicación es para situaciones muy específicas, por lo que no creo que retome este tema en el blog
Trackbacks
[…] con el tema Dynamic Access Control, y habiendo visto en la nota anterior “Dynamic Access Control – 1” las configuraciones inciales y cómo asignar acceso a recursos mediante “User Claims”, en […]
[…] con el tema Dynamic Access Control, y habiendo visto en la nota anterior “Dynamic Access Control – 1” las configuraciones inciales y cómo asignar acceso a recursos mediante “User Claims”, en […]