Tips & Tricks.Token Kerberos, Dynamic Access Control y servidor de ficheros en Windows Server 2012
Una de la tareas habituales en el día a día del administrador de sistemas es trabajar con los documentos de los usuarios. En anteriores versiones de Windows teníamos la posibilidad de establecer listas de control de acceso ACL sobre recursos de tipo carpeta/fichero en nuestros sistemas.
Las características que debían cumplir dichas listas ACL es otorgar permisos para acceder a estos recursos y su control. Podíamos establecer permisos NTFS a nivel local, y por encima permisos a nivel de compartir, solapándose estos en ese orden.
Por ejemplo, podíamos compartir una carpeta al grupo GRUPO1 y GRUPO2 con permiso total, y establecer un control mas fuerte a nivel de NTFS para que GRUPO1 control total y GRUPO2 solo lectura.
Mi experiencia en este sentido es que los administradores no prestaban mucha atención a los permisos a nivel de Compartir.
Imaginemos un escenario típico, en el que tenemos una estructura arborescente de carpetas, en la que raíz es la carpeta DOCUMENTOS DE MIEMPRESA. En ella es posible tener carpetas por departamentos, dentro de los departamentos por países, o viceversa, y toda una compleja estructura de carpetas, herencias y permisos.
Imaginemos el caso de que un empleado cambiaba de país, pero necesita seguir accediendo a documentos de su departamento en el otro país, y para mas alegría a ascendido de rango y ahora accede a los documentos de nivel de confidencialidad alto. Sumemos que la compañía ha comprado otra pequeña compañía, con su estructura de carpetas. Cuantas listas de control de acceso podemos manejar en un "pollo" así? Cuantos accesos podemos quitar/dar erróneamente a un usuario?
Los que trabajais a diario con servidor de ficheros sabéis de lo complejo que es mantener estas estructuras.
Otro problema conocido con este planteamiento era el tamaño del token Kerberos a la hora de anidar los permisos para múltiples carpetas/subcarpetas, creando problemas serios de rendimiento en el acceso a recursos compartidos ( la típica red de Windows que va lenta y los Linux no xD). Vamos a hablar un poco de este asunto.
Dento del token Kerberos hay una extensión denominada PAC (Privilege Attribute Certificate) donde se almacena la información de nombre de usuario, identificador sid,pertenencia a grupos etc. Esta información se guarda en un buffer temporal que es consultado por los servicios de RPC (Remote Procedure Call) para otorgar el acceso. Para el correcto manejo de los protocolos de red existe un tamaño máximo para este objeto denominado MaxTokenSize.
En servidores 2008 y Windows 7 el tamaño máximo estaba definido en 12k. Recordamos que estamos hablando de estructuras complejas de carpetas/ficheros/grupos de usuarios y de que su pertenencia genera identificadores en Kerberos que ocupan tamaño!!!
En Windows Server 2012 y Windows 8 el tamaño predefinido es de 48k. En anteriores versiones se podía cambiar por registro pero ahora tenemos una cómoda GPO Group Policy Object o simplemente política de grupo para cambiarlo.
Si queremos cambiarla mediante la clave del registro, simplemente: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Hay mucha literatura al respecto, os aconsejo leeros el RFC4120 de Keberos, que si bien no es necesario para implementar la solución de DAC en Windows Server 2012, si nos ayudará a comprender mejor el mundo en el que vivimos :-) y optimizar el comportamiento de Kerberos en nuestras instalaciones actuales.
***
Windows Server 2012 trae una mejora significativa al respecto con DAC Dinamyc Access Control. La teoría de este componente es la de usar metadatos y atributos de Active Directory para clasificar nuestros documentos y realizar un proceso constante de auto-clasificado de los mismos, pudiendo establecer las listas de control en base a estos elementos, y no a listas de control de acceso basadas en la ubicación del fichero/carpeta. Un ejemplo sencillo. Imaginemos el caso de tener documentos por países. Si establecemos correctamente que documentos son de cada país, es mucho más fácil otorgar permisos sobre estos ficheros, estén en la carpeta que estén.
Vamos a empezar desde cero con esta implementación.
Lo primero que tenemos que hacer es agregar el rol de servidor de ficheros. Para este laboratorio voy a usar un Windows Server 2012 controlador de dominio ya que por defecto instala este rol al promocionarlo ( hacerlo DC).
Nos situamos en el panel de control del servicio de Ficheros y Almacenamiento. En la opción compartir, y vamos a compartir una simple carpeta que hemos creado previamente. Indicamos que queremos compartir una carpeta mediante SMB de manera sencilla. Elegimos el servidor. Indicamos el nombre del recuso compartido.
Hasta aquí pocos cambios. En la siguiente pantalla seleccionamos las opciones "extra" o menos habituales si lo hacemos mediante carpeta/botón derecho/compartir.
Como podeís ver en la imagen, tenemos una opción para habilitar Enumeración basada en accesos. Es decir, que el usuario pueda o no ver documentos que no tiene permisos. Muy interesante esta opción.
Almacenamiento en cache todos sabeis lo que es, dejar una copia en local para su posterior uso en caso de perdida de conexión. Como veís en gris, tenemos la opción de configurar Branch Office, otra característica muy interesante en Windows Server 2012. Otro día podemos hablar de ella, pero básicamente se trata de establecer caché local de ficheros, por ejemplo en el caso de oficinas remotas en ubicaciones externas, pero con la capacidad de ser accesibles desde otros dispositivos dentro de esa ubicación. Digamos que es como un "servidor de ficheros en cache local".
También podemos configurar la opción de cifrado desde aquí.
En la siguiente pantalla podemos establecer los permisos a usuarios y grupos.
Hasta aquí hemos creado una carpeta compartida en el sistema.
Como os he comentado, he partido de un DC con los servicios de Archivo y Almacenamiento instalados. Ahora hay que entrar en la consola administrativa, que en el caso del DC no se ha instalado por defecto. Debemos agregar el rol de la consola administrativa.
Si estás en un entorno CORE o tienes algún problema para instalar la consola de administración podemos tirarle por PowerShell.
Como tengo mala memoria, voy a listar las funciones instaladas, solo para ver el nombre. Una vez lo identifico, lanzo el script para instalarlo.
Ahora ya podemos empezar con DAC, o dentro de un poco...
Recordamos la introducción que vamos a usar propiedades de Active Directory para clasificar los ficheros/carpetas. Recordamos esas pestañas que no siempre se rellenan cuando creamos un usuario en Active Directory? Vamos a usar la relativa a Departamento.
Si queremos volvernos locos por Powershell modificando el esquema de Active Directory estamos hablando de CN=Departament.
Abrimos el centro de administración de Active Directory
En tipo de notificación o Claim añadimos uno nuevo.
Y añadimos dos valores para dicha notificación, Marketing y Finanzas por ejemplo.
Ahora creamos una propiedad para un recurso.
Me invento una propiedad para mis documentos/carpetas, un ejemplo "Esta casado" sería de ejemplo si/no. Podríamos crear "Confidencial" o una propiedad que requiera varias opciones "Nivel de acceso 1"...
Ejecutamos la siguiente Powershell para actualizar el servicio FSRM:
Update-FSRMClassificationPropertyDefinition
Podemos comprobar en las propiedades de una carpeta/documento a nivel de disco como tenemos la opción de clasificar el objeto en cuestión bajo los criterios que le hemos marcado como propiedades.
Es hora analizar como queremos agrupar nuestra información a nivel de archivos y carpetas, mediante departamentos, ubicaciones, niveles de confidencialidad etc etc .
Estos aspectos son necesarios para el inventariado de objetos.
En el próximo artículo seguiremos configurando la clasificación de objetos y el control de acceso sobre los mismos.
Espero que os haya gustado y os aconsejo seguir el tutorial, no solo comprenderlo, ya que es fácil pero requiere de cierta habilidad con el manejo general de Windows Server 2012.
Las características que debían cumplir dichas listas ACL es otorgar permisos para acceder a estos recursos y su control. Podíamos establecer permisos NTFS a nivel local, y por encima permisos a nivel de compartir, solapándose estos en ese orden.
Por ejemplo, podíamos compartir una carpeta al grupo GRUPO1 y GRUPO2 con permiso total, y establecer un control mas fuerte a nivel de NTFS para que GRUPO1 control total y GRUPO2 solo lectura.
Mi experiencia en este sentido es que los administradores no prestaban mucha atención a los permisos a nivel de Compartir.
Imaginemos un escenario típico, en el que tenemos una estructura arborescente de carpetas, en la que raíz es la carpeta DOCUMENTOS DE MIEMPRESA. En ella es posible tener carpetas por departamentos, dentro de los departamentos por países, o viceversa, y toda una compleja estructura de carpetas, herencias y permisos.
Imaginemos el caso de que un empleado cambiaba de país, pero necesita seguir accediendo a documentos de su departamento en el otro país, y para mas alegría a ascendido de rango y ahora accede a los documentos de nivel de confidencialidad alto. Sumemos que la compañía ha comprado otra pequeña compañía, con su estructura de carpetas. Cuantas listas de control de acceso podemos manejar en un "pollo" así? Cuantos accesos podemos quitar/dar erróneamente a un usuario?
Los que trabajais a diario con servidor de ficheros sabéis de lo complejo que es mantener estas estructuras.
Otro problema conocido con este planteamiento era el tamaño del token Kerberos a la hora de anidar los permisos para múltiples carpetas/subcarpetas, creando problemas serios de rendimiento en el acceso a recursos compartidos ( la típica red de Windows que va lenta y los Linux no xD). Vamos a hablar un poco de este asunto.
Dento del token Kerberos hay una extensión denominada PAC (Privilege Attribute Certificate) donde se almacena la información de nombre de usuario, identificador sid,pertenencia a grupos etc. Esta información se guarda en un buffer temporal que es consultado por los servicios de RPC (Remote Procedure Call) para otorgar el acceso. Para el correcto manejo de los protocolos de red existe un tamaño máximo para este objeto denominado MaxTokenSize.
En servidores 2008 y Windows 7 el tamaño máximo estaba definido en 12k. Recordamos que estamos hablando de estructuras complejas de carpetas/ficheros/grupos de usuarios y de que su pertenencia genera identificadores en Kerberos que ocupan tamaño!!!
En Windows Server 2012 y Windows 8 el tamaño predefinido es de 48k. En anteriores versiones se podía cambiar por registro pero ahora tenemos una cómoda GPO Group Policy Object o simplemente política de grupo para cambiarlo.
Hay mucha literatura al respecto, os aconsejo leeros el RFC4120 de Keberos, que si bien no es necesario para implementar la solución de DAC en Windows Server 2012, si nos ayudará a comprender mejor el mundo en el que vivimos :-) y optimizar el comportamiento de Kerberos en nuestras instalaciones actuales.
***
Windows Server 2012 trae una mejora significativa al respecto con DAC Dinamyc Access Control. La teoría de este componente es la de usar metadatos y atributos de Active Directory para clasificar nuestros documentos y realizar un proceso constante de auto-clasificado de los mismos, pudiendo establecer las listas de control en base a estos elementos, y no a listas de control de acceso basadas en la ubicación del fichero/carpeta. Un ejemplo sencillo. Imaginemos el caso de tener documentos por países. Si establecemos correctamente que documentos son de cada país, es mucho más fácil otorgar permisos sobre estos ficheros, estén en la carpeta que estén.
Vamos a empezar desde cero con esta implementación.
Lo primero que tenemos que hacer es agregar el rol de servidor de ficheros. Para este laboratorio voy a usar un Windows Server 2012 controlador de dominio ya que por defecto instala este rol al promocionarlo ( hacerlo DC).
Nos situamos en el panel de control del servicio de Ficheros y Almacenamiento. En la opción compartir, y vamos a compartir una simple carpeta que hemos creado previamente. Indicamos que queremos compartir una carpeta mediante SMB de manera sencilla. Elegimos el servidor. Indicamos el nombre del recuso compartido.
Almacenamiento en cache todos sabeis lo que es, dejar una copia en local para su posterior uso en caso de perdida de conexión. Como veís en gris, tenemos la opción de configurar Branch Office, otra característica muy interesante en Windows Server 2012. Otro día podemos hablar de ella, pero básicamente se trata de establecer caché local de ficheros, por ejemplo en el caso de oficinas remotas en ubicaciones externas, pero con la capacidad de ser accesibles desde otros dispositivos dentro de esa ubicación. Digamos que es como un "servidor de ficheros en cache local".
También podemos configurar la opción de cifrado desde aquí.
En la siguiente pantalla podemos establecer los permisos a usuarios y grupos.
Hasta aquí hemos creado una carpeta compartida en el sistema.
Como os he comentado, he partido de un DC con los servicios de Archivo y Almacenamiento instalados. Ahora hay que entrar en la consola administrativa, que en el caso del DC no se ha instalado por defecto. Debemos agregar el rol de la consola administrativa.
Como tengo mala memoria, voy a listar las funciones instaladas, solo para ver el nombre. Una vez lo identifico, lanzo el script para instalarlo.
Recordamos la introducción que vamos a usar propiedades de Active Directory para clasificar los ficheros/carpetas. Recordamos esas pestañas que no siempre se rellenan cuando creamos un usuario en Active Directory? Vamos a usar la relativa a Departamento.
Abrimos el centro de administración de Active Directory
Ejecutamos la siguiente Powershell para actualizar el servicio FSRM:
Update-FSRMClassificationPropertyDefinition
Podemos comprobar en las propiedades de una carpeta/documento a nivel de disco como tenemos la opción de clasificar el objeto en cuestión bajo los criterios que le hemos marcado como propiedades.
Estos aspectos son necesarios para el inventariado de objetos.
En el próximo artículo seguiremos configurando la clasificación de objetos y el control de acceso sobre los mismos.
Espero que os haya gustado y os aconsejo seguir el tutorial, no solo comprenderlo, ya que es fácil pero requiere de cierta habilidad con el manejo general de Windows Server 2012.
