Microsoft Advance Threat Analytics

Microsoft Advance Threat Analytics (ATA) es una herramienta enfocada a la seguridad de la plataforma de Active Directory para detectar en tiempo real amenazas, y acciones sospechosas sobre el dominio.

¿Qué es ATA?

Microsoft ATA es una plataforma de seguridad para Active Directory con el fin de detectar amenazas. ATA toma información de los eventos y registros de la red con el fin de aprender comportamiento de los usuarios u otras entidades creando un perfil de comportamiento.

ATA aprovecha un motor de análisis sobre la red para capturar y analizar el tráfico de red de diversos protocolos (Kerberos, DNS, NTLM entre otros), ATA obtiene información de las siguientes maneras:

  • Creación de reflejos de puertos en los DC y servidores de DNS directos hacia la puerta de enlace de ATA.
  • Implementación de ATA Light Gateway (LGW) en los DC.

ATA nos permite detectar actividades sospechosas centrándose en:

  • Reconocimiento
  • Desplazamiento lateral
  • Dominio del dominio (persistencia)

Ademas de actividades sospechosas, ATA permite detectar ataques malintencionados como cuales:

  • Pass-the-Ticket (PtT)
  • Pass-the-Hash (PtH)
  • Overpass-the-Hash
  • PAC falsificado (MS14-068)
  • Golden ticket
  • Replicaciones malintencionadas
  • Reconocimiento
  • Fuerza bruta
  • Ejecución remota

Arquitectura de ATA

ATA analiza el tráfico de red de los controladores de dominio mediante el uso de la creación de reflejo de puerto a una puerta de enlace de ATA con conmutadores físicos o virtuales, o implementando la puerta de enlace ligera de ATA directamente en los controladores de dominio. ATA puede sacar provecho de los eventos de Windows (reenviados directamente desde los controladores de dominio o desde un servidor SIEM) y analizar los datos en busca de amenazas y ataques.

1

Arquitectura de ATA

El siguiente diagrama muestra el flujo de red, captura de eventos y explorar en profundidad para la funcionalidad de los componentes de ATA.

2

Componentes de ATA

  • El ATA Center recibe datos de cualquier puerta de enlace de ATA o puerta de enlace ligera de ATA que implemente.
  • El ATA Gateway se instala en un servidor dedicado que supervisa el tráfico de los controladores de dominio mediante la creación de reflejo del puerto o un TAP de red.
  • La ATA Light Gateway se instala directamente en los controladores de dominio y supervisa el tráfico directamente, sin necesidad de un servidor dedicado ni de una configuración de creación de reflejo del puerto. Es una alternativa a la puerta de enlace de ATA.

ATA Center

El ATA Center cumple la función de administras la configuración de los Gateway de ATA, recibir datos desde los ATA Gateway, detectar actividades sospechosas, ejecutar algoritmos de aprendizajes de comportamiento. El ATA Center recibe el tráfico analizado por el ATA Gateway y la ATA Light Gateway, genera perfiles, lleva a cabo una detección determinista y ejecuta el aprendizaje automático.

ATA Gateway y ATA Light Gateway

El ATA Gateway cumple la función de captura y análisis del tráfico de red en los controladores de dominio, recibir eventos de servidores de Syslog o SIEM, recuperar datos sobre usuarios y dispositivos del dominio, realizar tareas de resolución de objetos y transferir los análisis hacia el ATA Center.

ATA es una herramienta la cual llegó para dar fin a la problemática de seguridad especial para Active Directory, considerando la importancia de esta solución (AD) y que es esencial para el resto de las soluciones Microsoft mantener un control sobre AD era una tarea difícil, con la implementación de ATA en su plataforma, podrá mantener control sobre cualquier tipo de ataque, actividades sospechosas e incluso comunicación entre servidores y AD.

Ernesto León, Consultor Infraestructura, Blue Solutions.

 

Migrar el perfil de usuarios (cuentas de dominio o perfiles locales)

Las empresas que no poseen Active Directory y desean implementarlo, es común que presenten el problema para la migración de sus perfiles. Esto puede verse como un problema menor, pero en realidad significa un gran cambio para el usuario, ya que no solo tendrá una nueva cuenta, sino que además todas sus configuraciones se pierden y debe copiar los archivos a nuevo perfil.

En este artículo explicaremos cómo hacer la migración de perfiles en menos de 15 minutos, igualando todas las configuraciones y archivos del usuario.

Para el proceso de migración de perfiles se utilizará la herramienta User Profile Wizard 3.9, esta herramienta es gratuita y permite migrar un perfil local al nuevo perfil creado con las cuentas de dominio.

Antes de hacer la migración se debe subir el equipo al dominio e ingresar con el perfil del usuario para crear la carpeta del perfil, luego se debe cerrar la sesión del dominio e ingresar la cuenta local del usuario para realizar el proceso de migración.

Descarga y uso User Profile Wizard 3.9

Para descargar la herramienta de migración desde la página del fabricante debe acceder al siguiente enlace https://www.forensit.com/downloads.html.

Esto descargará un archivo .Zip el cual debe ser extraído para acceder al contenido. Luego de extraer, se identifica el instalador de la herramienta, además de un archivo .txt que informa sobre la licencia legal del software.

1

Esta herramienta no requiere instalación, por lo que para usarla solo debe hacer doble clic en el archivo Profwiz.exe y se abrirá el asistente de migración.

  1. Siguiente

2

2. Se debe seleccionar la cuenta a migrar

3

3. Seleccionar el dominio y especificar la cuenta

4

4. Se inicia el proceso de migración y se espera que finalice

5

Luego se debe cerrar sesión y se ingresa con la cuenta de dominio, donde ésta estará configurada igual que la antigua cuenta local del usuario.

El proceso de migración puede demorar dependiendo de la cantidad de información que se deba migrar, a pesar de esto, los procesos de migración son muy ágiles y no deben tomar más de 10 a 15 minutos. Si el tiempo de migración supera los estándares indicados anteriormente se recomienda revisa los archivos de log del proceso.

Nunca debe detener el proceso de migración, esto puede dañar los archivos o corromper el perfil que está siendo migrado. Si la aplicación tiene un cierre brusco e inesperado se debe verificar el acceso al perfil y revisar los documentos y archivos contenidos.

Es recomendable, como medida de seguridad, hacer un respaldo de los archivos para los usuarios VIP (Gerencias, jefatura, área de contabilidad, entre otros…) o todos aquellos que manejen información delicada esto con el objetivo de prevenir una pérdida de información en el caso de que la migración se vea interrumpida.

 

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.

 

Proteger todas las OU a la vez contra eliminación Accidental

Cada administrador de Active Directory debe saber que existe una configuración por defecto desde que apareció RSAT con Windows Vista y que se activa por defecto al momento de crear una nueva Unidad Organizativa. Esta funcionalidad reside en proteger la OU que vayamos a crear contra eliminación accidental, provocando que el técnico que quiera eliminar la OU deba primero desbloquear la limitación para poder eliminar la OU.

El siguiente paso a paso a explicar es un poco delicado, ya que si no se está seguro o si no se tienen los conocimientos suficientes de Active Directory, más algo de línea de comandos, será un poco extraño y posiblemente difícil de entender.

El procedimiento que vamos a seguir es un comando desde una cmd.exe que bloqueará al usuario (todos o everyone) según idioma contra eliminación de objetos he hijos, para así en caso de que un técnico por error vaya a eliminar una OU, ésta estará protegida contra eliminación.

Lo primero de todo, es diferenciar entre el lenguaje del sistema operativo donde vamos a realizar el comando, ya que en el caso que esté en inglés al usuario que le vamos a quitar los privilegios es “everyone” y si está en español es “todos”.

Crear una OU de pruebas sin marcar el pincho “Proteger objeto contra eliminación accidental”.

Desde una línea de comandos y con las herramientas de Active Directory instaladas, ejecutar el siguiente comando:

for /F “tokens=*” %i in (‘dsquery ou “ou=pruebas,dc=dominio,dc=com” -limit 0’) do dsacls %i /D “todos”:”SDDT;;”

Cuando esté realizado, nos vamos a las propiedades de la OU en el ADUC y comprobamos que el pincho “Proteger objeto contra eliminación accidental” vuelve a estar marcado como en la siguiente imagen:

3

El comando que vamos a usar para modificar los permisos de todas las OU’s del directorio activo para proteger contra eliminación accidental es el siguiente:

For /F “tokens=*” %i in (‘dsquery ou –limit 0’) do dsacls %i /D “everyone”:”SDDT;;”

Con este comando realizamos una búsqueda de todas las OU’s de AD (‘dsquery ou –limit 0’) y por cada resultado se le hace un dsacls para que el usuario everyone no pueda eliminar objetos (SD) y tampoco eliminar los hijos de los objetos (DT).

Recordar cambiar el nombre “everyone” por “todos” si el idioma de sistema operativo está en castellano.

Se mostrará por pantalla todos los permisos de todas las OU’s (este proceso es normal, no se asuste). NO CIERRE LA VENTANA.

El proceso tardará más en función de la organización de AD (Si es muy grande puede tardar alguna hora).

Dentro de las buenas prácticas de Microsoft, todas las OU’s del dominio deben estar con esta configuración, para validar la aplicación de este cambio se recomienda ejecutar un BPA (Best Practice Analyzer) para el rol de AD DS.

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.

¿Cómo instalar impresoras en sistemas operativos actuales?

La instalación de impresoras, tanto sea por máquinas, o por usuarios es algo que se puede hacer mediante Directivas de Grupo (GPOs). Me ha parecido interesante desarrollar este tema, no sólo porque he sido consultado muchas veces, sino porque ha cambiado de cómo era, en sistemas operativos “antiguos”.

Este post esta orientado a un servidor que comparte y administra una impresora de red, automatizando la instalación en máquinas cliente de acuerdo al usuario.

Como pueden ver en la siguiente figura, he creado una Unidad Organizativa (OU) con un usuario de pruebas (“User Uno”, U1), donde enlazaré la GPO que instalará la impresora.

n1

Comenzaré creando y enlazando una GPO a esta Unidad Organizativa, como muestran las siguientes figuras.

n2

 

n3

 

n4

Lo dejaremos stand by, lo utilizaré más adelante. Esto es así, porque en las actuales GPO ya no existe la opción “Deployed printers”

Por otro lado, en SRV1, tengo creada y compartida una impresora, puede ser la que necesiten, en mi caso es una conectada por un puerto TCP/IP, aunque sería exactamente igual si se tratara de un puerto local.

n5

Continuando en SRV1, instálo la funcionalidad “Print and Documents Services” de forma habitual.

n7

Solo es necesario seleccionar el rol de “Print Server”

n8

Una vez finalizada la instalación, tenemos disponible y abrimos “Print Management”

n9

Para esta demostración, comenzaré con botón derecho sobre la impresora a instalar automáticamente, y eligiendo “Deploy with Group Policy …”

n10

Primero debemos seleccionar con el botón “Browse” la GPO que creamos al principio.

n11

 

n12

 

Y luego seleccionar la opción si deseamos que la instalación sea por usuario o por máquina, en mi caso seleccioné por usuario, pero sería todo de igual forma si seleccionáramos por máquina, salvo que la GPO debe aplicarse a las cuentas de máquinas y no de los usuarios.

Recién cuando seleccionen la opción, se habilita el botón “Add”.

n13

Ahora solo debemos aceptar lo hecho.

n14

n15

En el cliente (CL1) podríamos necesitar ejecutar la aplicación forzada de la GPO, pero en mi caso decido iniciar sesión con el usuario de prueba (U1)

¿Cómo podemos observar si aparece la impresora correctamente instalada?

n16

Hemos visto una demostración de cómo se puede disponer de las impresoras de red en forma automática, en este caso por usuarios.

Nicolas Herrera, Consultor de Infraestructura, Blue Solutions.

6 Tips para troubleshooting de AD DS

1.- Determinar la salud del DNS

Lo primero que debemos determinar cuándo realizamos una asesoría en AD es la salud del DNS. Una falla en el DNS puede causar muchos problemas en la autentificación, fallo en las aplicaciones, exchange, replicaciones, problemas de respuesta en LDAP, entre otros.

Como describimos anteriormente la revisión del DNS es crítica, para poder determinar el estado de salud de la plataforma, detallaremos unos CMDLET para complementar el Dcdiag.exe, el cual es:

dcdiag /test:DNS /e /v

La opción /e indica que la prueba correrá en todos los servidores de DNS, y /v indica una salida detallada de texto para el resultado de esta prueba. En un ambiente amplio, esto puede tardar un tiempo, pero vale la pena esperar.

Siempre comienzo leyendo desde el final del reporte, donde aparece una tabla como table 1. DCdiag ejecuta 6 pruebas diferentes: Authentication (Auth), Basic Connectivity (Basc), Forwarders (Forw), Delegation (Del), Dynamic Registration Enabled (Dyn) y Resource Record Registration (RReg). La tabla además lista la prueba de External (Ext), la conexión a internet, pero este comando no realiza esa prueba.

Captura de pantalla 2016-01-28 a la(s) 16.59.57

En la salida de la tabla 1, muestra cada servidor DNS (El cual usualmente también son los Domain Controlers) del bosque listado por dominio. Lo bueno de eso es que muestra la configuración de dominio del bosque, la cual es de mucha ayuda si eres consultor o ingeniero de soporte y no estas familiarizado con la infraestructura. En los datos de lectura de la tabla, los resultados son:

  • PASS: El servidor DNS completa el test.
  • FAIL: El servidor DNS falla el test.
  • N/A: La prueba no fue ejecutado. Esto ocurre generalmente por una falla en alguna prueba anterior, por lo que no tiene sentido realizar una prueba sobre un servicio que ya sabe que está fallando.

En la tabla 1 podemos ver el valor de esta prueba. Inmediatamente podemos ver los lugares conflictivos. En un bosque de multiple dominio, debes ejecutar este comando con credenciales de Enterprise Admin, u obtendrás resultados fallidos en todas las pruebas de los servidores DNS por que no tienes los privilegios suficientes. Esto es lo que sucede para el dominio EMEA en la tabla 1.

Al termino del reporte se presenta una lista completa de las fallas, donde se pueden ver todos los detalles. Por ejemplo puedo ir a la parte superior del reporte y buscar por Corp-DC02, y obtener los detalles que son mostrados en figure 1.

En este primer paso se presenta muy buena información, se puede construir la configuración del DNS Resolve para cada servidor DNS. Lo principal en este paso, es que se muestra el porque la prueba de Forwarder nos entregaba N/A en la tabla 1. Usando este método podemos elegir el camino entre los resultados “warning”, “failure” y “N/A” de la tabla 1. Y por supuesto lo mejor de todo esto, es que tienes la información de todos los servidores DNS del bosque en un archivo, generado por un solo comando.

Captura de pantalla 2016-01-28 a la(s) 17.03.19.png

2.- Determinando la salud de la replicación del AD

 La herramienta de soporte para Windows Server incluye la opción en Repadmin llamada /replsum. Similar al comando DCdiag /test:dns del Tips 1, /replsum colecciona la información de replicación de todos los DC del bosque. Esto muestra el reporte de en qué momento ocurre la replicación entre los DC, el comando debe ser ejecutado en cada uno de los DC del bosque. Aquí están las opciones más usadas:

Repadmin /replsum /bysrc /bydest /sort:delta

  • /bysrc indica la colección de datos de los DC que han replicado en otros DC.
  • /bydest indica la colección de datos de los DC que han replicado en otros DC.
  • /sort:Delta muestra los resultados en orden decendiente

Un ejemplo de esto se ve en table 2. Aquí se muestran seis DC y gracias a delta se muestran por orden de su última replicación. Aquí podemos ver fácilmente la salud del dominio, excepto para WTEC-DC2, el cual no ha sido replicado de hace cinco días, que arroja el error 1722. Yo sé que este DC se encuentra apagado ya que está siendo movido a un nuevo Data Center.

Captura de pantalla 2016-01-28 a la(s) 17.06.49

3.- Detalle de replicación para todos los DC del bosque.

 Esta técnica (similar a la del tips número 2) nos entrega mayor detalle. El comando es /repadmin /showrepl * /csv>showrepl.csv. Esta opción de salida en formato CSV, como se muestra en table 3.

Me gusta este comando por que frecuentemente muestra un error en mayor detalle qué el comando /replsum. Además, ofrece un reporte de distintos errores (o errores adicionales, código de error y más) y especifica los datos que /replsum no entrega.

Captura de pantalla 2016-01-28 a la(s) 17.08.03

4.- Diagnóstico NTDS

Este punto es esencial para obtener información adicional de los datos en el visor de eventos de Directory Service (DS). Está habilitado por registro en HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\NTDS\Diagnostic. Es bastante sencillo. Aquí hay una variedad de atributos que, cuando son habilitados entregan información adicional en los logs de eventos para ayudarte en las tareas de troubleshooting. Los datos válidos de estos registros es una variable de 0 a 5. El valor por defecto es 0, significando una entrega de datos mínima, y añadiendo 5 entrega más datos de los que quieres. Generalmente configuro 3 y reviso si es que llegase a necesitar más información. En ciertos casos, si necesito mayor detalles en la replicación, al valor de “5 replication event” lo cambio a 3, para reproducir el problema. Asegúrate de cambiar el valor a 0 cuando las labores de troubleshooting finalicen.

Los valores más comunes que utilizo son:

  • 1 Knowledge Consistency Checker
  • 10 Performance Counters
  • 13 Name resolution (Relacionado con el DNS)
  • 15 Field Engineering
  • 18 Global Catalog
  • 2 Security Events
  • 5 Replication Events
  • 8 Directory Acces
  • 9 Internal Processing

El valor 9 Internal Processing es útil para obtener información adicional sobre el DS event, esto indica que error interno está ocurriendo. Esto a menudo muestra eventos adicionales que ayudarán en el diagnóstico del problema. Es común añadir un valor mayor a 1. Realizando troubleshooting de replicación, es buena idea habilitar el valor 1 Knowledge Consistency y 5 Replication Events.

El valor 15 Field Engineering entregará diversa información adicional a los logs de DS. A diferencia de los otros diagnósticos, este debe ser ajustado a cinco para que entregue información relevante. Específicamente, esto genera los eventos 1644 y 1643, que mostrarán la ineficiencia en las consultas a LDAP, incluyendo a los clientes que generan las consultas, el tipo de consulta, y la raíz de la consulta. Esto es importante, ya que uno de los dolores de cabeza relacionados con el AD, es el proceso Local System Authority Subsystem Services (LSASS), que se encuentre utilizando suficientes recursos para colgar, o crashear nuestro DC, causando una lentitud en el ingreso del usuario. Una ineficiencia en las consultas a LDAP de parte de los usuarios o aplicaciones puede suponer una enorme carga en LSASS. Habilitando este diagnóstico podemos identificar de manera más rápida al culpable según su nombre o dirección IP. Algunos administradores dejan este diagnóstico habilitado permanentemente en organizaciones ocupadas, pero de nuevo, esto llenará nuestros logs de eventos, y posiblemente esconda o sobre escriba otros eventos importantes en los logs de DS.

5.- Reportes HTML y consola de administración de políticas de grupo.

Seguramente todos los administradores de AD han usado esta herramienta en algún momento, pero pensé que valdría la pena mencionar los valores de los reportes HTML. Aquí hay dos tipos de reportes que uso frecuentemente cuando trato con entornos con los cuáles no estoy familiarizado y por lo general quiero probar las configuraciones de las Group Policy Object (GPO), así como los resultados en un cliente en particular o clientes.

Obtener un reporte de las GPO es valioso, incluso si eres el administrador de la plataforma, ya que muestra exactamente las configuraciones definidas (de hecho, solo muestra las configuraciones definidas), por lo que no tendrás dificultades para investigar en el editor de políticas para encontrar las que se encuentran establecidas. Esta es una manera rápida de ver si la GPO está definida como esperas que lo esté. Incluso muestra los links, filtros aplicados y otros detalles. Los reportes HTML para la Default Domain Policy son simples de leer y pueden ser expandidos o cerrados por sección según lo necesites, ya que se encuentran en formato HTML. Para obtener este reporte, de click derecho sobre la GPO y selecciona “save report”.

Uno de los problemas a solucionar en las GPO está relacionado con un cliente el cuál molesta al usuario, quien se encuentra a cientos de kilómetros de distancia para ingresar y obtener un GPOResult. Si el usuario ha ingresado en al menos una estación de trabajo, la consola de administración de políticas de grupos (GPMC) puede entregar con un formato HTML el resultado del GPResult que se produce cuando el usuario ingresa.

6.- Diagnóstico de rendimiento para Active Directory.

Si bien hay muchos otros tips para troubleshooting que pude haber añadido, este es uno que probablemente, no del todo conocido. En el troubleshooting del rendimiento de los servidores, hay un conjunto estándar de objetos, incluidos el procesador, disco lógico, memoria del servidor, sistema y así entre otros. Sin embargo hay un objeto de NTDS que nos proporciona contadores relevantes del AD como, DRA, Kerberos, LDAP y contadores incluso relacionados con eventos en NTLM. Además podemos recopilar valores importantes de los datos de nuestro AD mediante el monitoreo de los procesos de LSASS. Recomiendo habilitar los siguientes:

  • Object: Process
    • Contadores: % de tiempo de procesado, conjunto de trabajo, y pico de conjunto de trabajo.
  • Object: NTDS
    • Contadores: Todos los contadores.

Desafortunadamente hay poca información disponible dentro de lo aceptable. El más útil encontrado es la guía de implementación para la rama de Microsoft Office. Si bien hay muchos contadores y puedes o no estar familiarizados con ellos, aquí hay algunos significados.

  • DRA Pending Replication Synchronization: Este es el directorio de sincronización de las colas y los retrasos en la replicación, Microsoft dice que estos valores deben ser lo más bajo posibles y que el hardware está retrasando la replicación. Estos son indicios de que los recursos del DC tienen un alto porcentaje de utilización.
  • LDAP Cliente Sessions: Este es el número de sesiones abiertas simultáneamente por clientes LDAP. Esto es útil para determinar la actividad de los clientes de LDAP y si el DC está habilitado para soportar esa carga. Por supuesto los picos se registran durante la autenticación de los clientes lo cual no es un problema necesariamente, pero en largos periodos los altos valores significan un exceso de trabajo para el DC.
  • LDAP Bind Time: Este es el tiempo en milisegundos que es necesario para completar la unión de LDAP. La documentación de Microsoft indica que esto debe tener el menor tiempo posible, pero si corres un análisis a través de los logs de análisis de rendimiento (PAL), indicara 15 sobre milisegundos como un warning, y sobre 30 como un error.

En el diagnóstico de procesos LSASS, como en cualquier análisis de rendimiento, debe haber una base establecida. Una nota en el DS blog de Microsoft indica que si una base no está establecida, debe ser utilizado el 80%. Es decir los contadores LSASS no deben superar el 80% de consumo, ya que sobre el 80% indicará una sobre carga, lo que podrá traer una alta demanda de consultas a LDAP, o la falta de recursos en el servidor. La solución es aumentar los recursos del servidor, o disminuir la demanda de consultas, pero tenga en cuenta que el alto uso de recursos puede causar un impacto en el rendimiento del dominio.

Si desea solucionar problemas de recursos, utilize una plataforma x64 en los DC, con diversos procesadores, y 32GB de Ram. Es sorprendente cuanta memoria realmente puede utilizar los recursos LSASS.

Espero que estos tips sean de gran utilidad a la hora de realizar un troubleshooting de AD DS.

Ernesto León, Técnico en Soporte, Blue Solutions.

¿Cómo podemos actualizar el protocolo de replicación de archivos para AD DS en Windows Server 2012 y 2012 R2?

EL protocolo de replicación en archivos en Active Directory Domain Services es imprescindible para el óptimo funcionamiento de la plataforma, de lo contrario existirían problemas de inconsistencia en la información y bases de datos de AD DS. Microsoft al estar consciente de esto, ha decidido crear un nuevo protocolo de replicación de archivos, 15 veces más rápido y mucho más estable que su versión FRS.

En este artículo usted aprenderá a realizar la actualización del protocolo FRS a DFS-R, para aprovechar todas las bondades que ofrecer Windows Server 2012, y 2012 R2.

Lo primero que debemos saber, es si se está usando FRS o DFS-R. No es fácil detectarlo, ya que la interfaz gráfica usada para administrar o configurar el Dominio no cuenta con la información. Sin embargo, existe una opción para averiguarlo y es a través del Registro (registry), debemos utilizar REGEDIT.EXE y encontrar:

”HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters”

Cuando llegamos aquí, tendremos dos posibilidades, que exista o no una sub carpeta “Syvols\Migrating SysVols”.

Opción 1 Subcarpeta SysVols:

“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\Sysvols\Migrating SysVols”

Esto significa que que se está utilizando DFS-R

1q

Opción 2 No existe subcarpeta SysVols:

Sí la subcarpeta SysVols no existe, significa que se está usando FRS.

2Q

La primera figura, que usa DFS-R, está tomada en un Controlador de Dominio donde se ha creado un Dominio y Bosque nuevos directamente con niveles funcionales Windows 2012 R2.

La segunda figura, corresponde a un Dominio que se ha actualizado desde versiones anteriores.

Entonces, ¿Cómo podemos hacer la migración del servicio de replicación de archivos?

1.- Debemos elevar el nivel funcional de Dominio y Bosque a “Windows Server 2012”.

2.- En uno de los Controladores de Dominio debemos abrir una línea de comandos como administrador y pasar al primer estado. Debemos ejecutar:

DFSRMIG /SetGlobalState 1

Y periódicamente verificar si el proceso fue completado con:

DFSRMIG /GetGlobalState

3g

Una vez alcanzado el nuevo estado (Prepared) podemos seguir con el siguiente:

DFSRMIG /SetGlobalState 2

4g

De forma análoga pasaremos al estado 3.

5q

Y si queremos comprobar, podemos verificar en el registro, que aparece la carpeta mencionada al principio de la nota, y además que el estado es 3 (Eliminated).

6.

El cambio de FRS a DFS–R, en muchos casos permanece oculto para los administradores de Active Directory, que suponen erróneamente su actualización automática cuando se actualiza el Domino. Afectando la calidad y el desaprovechamiento de recursos en nuestros servicios al utilizar un protocolo antiguo.

Nicolas Herrera, Consultor de Infraestructura, Blue Solutions

¿Cómo se debe configurar el SPN para la migración de File Server?

No hay migración de servicios que no esté acompañada de dolores de cabeza. Especialmente si son servicios críticos para las organizaciones, como es el caso de los servidores de archivos.

Nunca hay que creer cuando comentan que la migración de un File Server es solo mover los archivos de un lugar a otro usando Robocopy y luego hacer el cambio en el servidor DNS para que siga conservando el mismo nombre que el servidor de origen y el cambio sea transparente a los usuarios.

Antes de explicar el cambio de SPN, me gustaría que se entendiera el concepto de SPN en su definición más fundamental.
SPN viene de la sigla de Service Principal Name.
Éstos deben estar asociados a un objeto de Active Directory (cuenta de usuario, grupo o computador) en el cual el servicio se ejecuta. Su función principal es soportar la autenticación mutua entre un cliente y un servicio.

Entonces, la configuración de un SPN consiste en la asociación de un servicio a un objeto de AD. Un objeto de AD puede tener varios SPN asociados, pero un SPN solo puede estar asociado a un objeto de AD. En el caso de que se duplique un SPN, vendrán los problemas.

Cuando se realiza una migración de File Server y posteriormente se hace el cambio en el DNS para que el antiguo servidor apunte al nuevo y se intenta acceder a la ruta, el visor de eventos mostrará un error así:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SRV-NUEVO$. The target name used was cifs/SRV-VIEJO. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMINIO.CL) is different from the client domain (DOMINIO.CL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server. 

Como el SPN no estaba configurado de forma correcta, no es posible hacer ni mantener la autenticación, por lo tanto, da error.

Para configurar el SPN, se debe hacer con una cuenta con privilegios sobre el dominio.

Eliminando un SPN
Antes de asignar un SPN a un objeto, hay que eliminarlo  del objeto al cual estaba asignado. Se debe seguir la sintaxis:
setspn -D servicio/host ObjetoAD Por ejemplo:

setspn -D host/srv-viejo.midominio.cl srv-viejo

setspn -D host/srv-viejo srv-viejo
setspn -D cifs/srv-viejo.midominio.cl srv-viejo
setspn -D cifs/srv-viejo srv-viejo

De esta forma se elimina los SPN asociados al file server del objeto srv-viejo.

Asociar un SPN
Una vez desasociados los SPN al antiguo objeto, se debe asociar al nuevo objeto. La sintaxis es:
setspn -S servicio/host ObjetoAD Por ejemplo:

setspn -S host/srv-viejo.midominio.cl srv-nuevo
setspn -S host/srv-viejo srv-nuevo
setspn -S cifs/srv-viejo.midominio.cl srv-nuevo
setspn -S cifs/srv-viejo srv-nuevo

De esta forma, el servicio podrá autenticar y mantener la autenticación. El recurso compartido es accesible desde los clientes. Hay que tener un especial cuidado con los clientes con Windows XP. Por que aparte de configurar los SPN correspondientes, también hay que hacer un cambio en el editor del registro de Windows. Seguir la documentación de este link: https://support.microsoft.com/en-us/kb/281308

Más información sobre la herramienta setspn se puede encontrar en: https://technet.microsoft.com/en-us/library/cc961723.aspx

Podemos concluir que las migraciones de File Server, no son tan sencilla ni con pocos pasos como afirman algunos, hay que realizarlas de manera cuidadosa para no incurrir en errores.

Maximiliano Marín, Consultor de Infraestructura, Blue Solutions.

Active Directory Right Management Services (AD RMS) ¿Puede proteger un directorio?

 AD RMS es un servicio que funciona a nivel de dominio, se encarga de proteger el contenido de documentos Office, correos electrónicos y eventualmente otro tipo de documentos como PDF.

Vamos a determinar la posibilidades que tenemos para proteger un directorio con AD RMS, convencionalmente siguiendo la línea Microsoft y según nuestra experiencia las distintas posibilidades de hacer esto efectivo.

Primeramente hablaremos de la solución más común para tratar nuestra interrogante. File Classification Infraestructure es una solución que funciona sobre el servicio de File Server de Windows Server, se encarga de la clasificación de archivos en base a reglas generadas según las necesidades de la organización. Por ejemplo, se puede clasificar los archivos en base al impacto que tiene sobre el negocio la revelación de la información.

Una buena forma de extender el uso de esta solución, es usando AD RMS Bulk Tool como tarea programada dentro de la solución para no solo clasificar la información, sino también agregar derechos sobre los documentos.

Otra herramienta que nos ayuda a responder nuestra interrogante es Active Directory Rights Management Services Bulk Protection Tool, se encarga de proteger los documentos de una carpeta en base a planillas de permisos.

Las plantillas de permisos deben ser generadas en la consola de AD RMS. En la plantilla, se puede asignar permisos por usuario o por grupo.

1

Se deben definir de forma correcta los permisos para que funcione de manera optima.

Al seleccionar permisos que tendrá el usuario o grupo de Active Directory sobre el o los documentos, los privilegios que son dependencias de otros se irán seleccionando automáticamente según su requerimiento.

2

Una vez que la plantilla está creada y disponible en un directorio compartido, se invoca a la herramienta que protege de forma masiva. Esta herramienta debe estar instalada en el  mismo servidor donde están los documentos. Se puede tomar como si fuera un servidor de archivos.

La forma de usar la herramienta es:

RMSBulk [/decrypt location] [/encrypt location rms_template [owner_email]] [/log log_file [/append] [/simple]] [/preserveattributes] [/silent]

3

La herramienta no tiene interfaz gráfica. Deja abierta la posibilidad de crear un script y automatizar el proceso. Mejor aún, crear una tarea programada con la secuencia de comandos.

En conclusión, se puede proteger los documentos contenidos en un directorio. El acceso al directorio se puede manejar en las propiedades de acceso del directorio.

Con una buena organización de directorios y plantillas, se puede automatizar la protección de documentos  a gran escala.

 Maximiliano Marín, Consultor de Infraestructura, Blue Solutions.