Migracion de Active Directory hacia Windows Server 2012 - Fase 1: Assessment

Hola, somos Doug Symalla y Greg Jaworski, el equipo de TAG trayéndoles un blog pesado, lleno de detalles.

En el último blog de Doug, el planteó un roadmap de actualización de Active Directory. Les prometimos algunos detalles prácticos para cada una de las fases, así que iniciemos con la primera fase - El assesment. El objetivo de este blog es darles detalles a profundidad sobre la información que deben colectar, porqué deben colectarla y como pueden colectarla. Tengan en mente que nunca tendrán todo documentado perfectamente, siempre van a existir gaps al respecto. Será necesario tomar la decisión entre los costos asociados a obtener la información y el beneficio que se obtendría al contar con la misma. Si tienen alguna sugerencia sobre qué, cómo y porqué obtener más información, por favor háganoslo saber en la sección de "Comentarios". Su retroalimentación siempre es bienvenida.

Documentar la arquitectura de AD actual, el dimensionamiento de los DCs y la localización de los mismos

Qué: Una visión concisa de la infraestructura de AD completa. Esto incluye los sitios de AD, los Site links, la colocación de los Controladores de Dominio, el dimensionamiento de los Controladores de Dominio e información sobre el baseline de performance.

Porqué: Eventualmente se debe decidir (ver la Fase de Planeación) entre simplemente reemplazar todos los controladores de dominio existentes (los viejos) con nuevos controladores de dominio, o si se rediseñaría/redimensionaría la infraestructura.

Cómo:

· Dibujando el mapa con el AD Topology Diagrammer. Los diagramas de AD Sites y AD Domains son componentes muy importantes. También hay que poner atención en el nivele funcional del Dominio y del Forest y en las relaciones de confianza hacia otros Dominios o Forests.

· Recolectando algunos datos básicos sobre la configuración de todos los DCs. Esto debería incluir la versión del sistema operativo, la cantidad de memoria RAM, los CPUs, la configuración y el tamaño de los discos. Se pueden elaborar scripts de PowerShell para recolectar esta información de todos los controladores de dominio.

· Obteniendo un baseline de performance. Esta información puede obtenerse con Perfmon, apegándose a lo básico con los contadores para:

o Uso de CPU
o Uso de Memoria
o Uso de CPU y Working Set del proceso LSASS.exe
o Average Disk sec/read y Average Disk sec/write de cada uno de los discos
o LDAP searches per sec
o LDAP bind times
o NTLM authorizations per sec
o Kerberos authorizations per sec

Hacer un inventario de las configuraciones particulares de los Controladores de Dominio

Qué: Los detalles de la configuración en los Controladores de Dominio – especialmente aquellas configuraciones particulares que no son por default.

Porqué: Es necesario decidir si estas configuraciones van a seguirse utilizando y en dado caso, cómo hacer para mantenerlas y seguir adelante con la migración.

Cómo: Investigando en el Registry, las GPOs y la base de datos de AD.

· En el Registry de los Controladores de Dominio, deben buscarse las configuraciones listadas abajo (lo cual también se puede hacer con PowerShell). Después, se puede usar "Group Policy Modeling" o "Group Policy results" para revisar qué configuraciones podrían realizarse mediante política y cuales se realizarían manualmente.

o Revisar si se utilizan puertos estáticos de RPC. Por ejemplo, se configuró un rango fijo de puertos RPC, o un puerto para FRS o puertos para la replicación de AD?

o Se deshabilitó SMB signing alguna vez en el pasado?

o Se han implementado/instalado certificados (para LDAP) en los Controladores de Dominio?

o Se ha modificado el default del LMCompatibilityLevel?

o Se ha deshabilitado eDNS cuando se implementaron los Controladores de Dominio 2003 o en algún momento posterior?

o Se han modificado los limites en las conecciones NSPI?

o Alguna vez se habilitó DES encryption y después se descubrió que dicha configuración esta deshabilitada por default en Windows 7/2008 R2?

· Revisar las siguientes configuraciones en la base de datos de AD:

o Alguna vez han modificado los valores por default de la LDAP query policy?

o Existen cuentas de usuario en el directorio que hayan sido configuradas para utilizar DES encryption?

Hacer un inventario de otras aplicaciones/servicios instalados en los DCs

Qué: Determinar otras aplicaciones/servicios instalados en los Controladores de Dominio.

Porqué: Antes de retirar un Controlador de Dominio, es necesario tomar en cuenta los otros servicios como DHCP, WINS o DNS.

Cómo: Revisando los programas instalados y los servicios que se ejecutan en los DCs (esto también puede ser realizado utilizando PowerShell). Determinar cuáles de estos deberían ser migrados ya sea hacia los nuevos DCs o a algún otro servidor. Algunos de los servicios/aplicaciones que comúnmente vemos corriendo en los controladores de dominio y que son pasados por alto son:

· DHCP
· DNS
· WINS
· Terminal Services Licensing
· DFS Namespaces (ademas de SYSVOL)
· Certificate Services
· IAS/Radius/NPS
· Agentes de Directory Sync/Password Sync
· Password Filters personalizados

Investigar y Documentar las dependencias hacia AD en el ambiente

Qué: Hacer un inventario de las dependencias hacia Active Directory Dependents.

Porqué: You need to research whether or not your dependents are compatible with the new version of Active Directory/Domain Controllers.

Cómo: Dependiendo del tamaño de su ambiente, esto puede significar una tarea muy grande. Es muy común que existan en el ambiente clientes/aplicaciones que utilizan Active Directory sin que nadie sepa de su existencia. Por eso recomendamos iniciar con las:

1. Dependencias conocidas/obvias

2. Aplicaciones críticas de negocio (y otras dependientes de estas)

Dependencias conocidas/obvias:

· Iniciar con clientes/computadoras que están integradas al dominio. Consultar el atributo Operating System de cada uno de los objetos Computer. Buscar por sistemas operativos Microsoft que estén fuera de soporte como Windows NT o Windows 2000. Para sistemas operativos no Microsoft, revisar la compatibilidad con el fabricante del sistema operativo.

· Considerar aplicaciones Microsoft comunes, como Exchange o SCCM. En algunos casos la aplicación podría estarse ejecutando en el Controlador de Dominio (por ejemplo un agente de SCCM) mientras que en otros casos la aplicación quizás dependa de AD. Iniciar aquí para revisar la compatibilidad de dichas aplicaciones.

· Revisar y documentar la compatibilidad de cualquier otra dependencia conocida. Esto podría incluir por ejemplo, otros servicios de directorio que se integran/sincronizan con AD o aplicaciones LDAP que jalan información desde AD. Asegurarse de revisar si la aplicación "descubre" los controladores de dominio, o si la aplicación está configurada haciendo referencia directa a la dirección IP o al nombre de algún controlador de dominio. Si fuera este último caso, será necesario recordar que es necesario actualizar la configuración con el Nuevo nombre/dirección IP de alguno de los Controladores de Dominio nuevos una vez que estén en línea.

Aplicaciones Críticas de Negocio y Otras Dependencias

· ¡Que comience la cacería! Es necesario rastrear las dependencias e investigar el impacto potencial de la actualización. Hay que iniciar con los sistemas críticos/importantes que sustentan al negocio. Debe determinarse si se integran a AD y la manera en que lo hacen, después de lo cual se debe revisar si son compatibles con la nueva versión de los Controladores de Dominio.

· Si se sienten muy valientes, pueden optar por habilitar el modo verbose de LDAP logging y/o el modo verbose de Netlogon logging en los DCs, hacer a un lado todo el ruido y ver si se puede encontrar alguna dependencia “interesante”. Hay que proceder con mucha precaución antes de “explorar estos caminos”. Si no se tiene cuidado, puede generarse un montón de ruido (y muchos dolores de cabeza) sin obtener ninguna información útil.

· Otra opción interesante (otra vez debemos advertirles que el grado de dificultad es alto) sería cazar específicamente a los clientes obsoletos LM/NTLMv1. Nuestros colegas de AskDS tienen un gran blog sobre este tema.

Investigar los cambios al comportamiento por default del SO/DCs y su impacto potencial

Mucha de la información que les hemos pedido recolectar en las secciones anteriores, provee algunos consejos sobre los cambios en el comportamiento por default de las nuevas versiones de los sistemas operativos Windows. La tabla que mostramos a continuación hace un resumen de estos cambios. Después hay una descripción con más detalles de estos elementos, como podrían impactarles y nuestras recomendaciones y posibles workarounds. Nota: NO estamos incluyendo comportamientos/errores inesperados que puedan presentarse cuando se actualiza. Pueden encontrar esos aquí . Dichos errores deberían ser investigados durante las fases de Planeación y Pruebas.

Hemos incluido esta tabla y una breve descripción de todos los cambios en una hoja Excel. Esperamos que sea una buena herramienta táctica para ustedes. Pueden encontrar la hoja aquí .

LM Hash y LM Authentication:

A partir de Windows Server 2008, los controladores de dominio (y los miembros del dominio) ya no almacenan el LM hash de los passwords. Estos “hashes” son fácilmente hackeados para obtener los passwords. Adicionalmente ya no será posible utilizar LM authentication.

Recomendaciones:
Adoptar el nuevo comportamiento por default y dejar de almacenar el valor de LMHash para los passwords. Es mucho más seguro. También cualquier cliente o aplicación “legacy” que utilicen LM authentication necesitan ser actualizados/eliminados.

Referencias:
https://support.microsoft.com/?id=299656
https://support.microsoft.com/?id=946405

Algoritmos de Criptografía NT 4.0 y Relaciones de Confianza NT 4.0:

A partir de Windows Server 2008, el sistema operativo dejó de usar algoritmos de criptografía “legacy” para la comunicación del canal seguro (secure cannel). Por default, Windows NT 4.0 (y otras aplicaciones/sistemas operativos que usan este algoritmo) no serán capaces de establecer un canal seguro (o autenticarse) con un controlador de dominio Windows Server 2008 o superior. Hay una opción de configuración/GPO que puede revertir este comportamiento – "Allow cryptography algorithms compatible with Windows NT 4.0". No obstante, se debe tomar en cuenta que incluso con esta configuración, no es posible establecer una relación de confianza entre Windows Server 2008 R2 y Windows NT 4.0.

Recomendaciones:
Esto es relativamente simple, más aún porque nosotros (Microsoft) ya no damos soporte a Windows NT 4.0. Debido a lo anterior, la mejor recomendación es alejarse de Windows NT 4.0. No vale la pena perder tiempo y recursos intentando arrastrar a Windows NT 4.0 al mundo moderno. Si el negocio aún necesita de un NT 4.0, lo mejor es sacarlo del dominio, desconectarlo de internet y hacer todo lo que sea posible para aislarlo, de esa forma podrá “morir en paz”.

Referencias:
https://support.microsoft.com/kb/942564https://support.microsoft.com/kb/2021766

Cifrado DES y Autenticación Kerberos:

A partir de Windows Server 2008 R2, los controladores de dominio (y los miembros del domino) ya no permiten el cifrado DES para los tickets de Kerberos. El cifrado DES fue quebrado desde el milenio pasado, así que es tiempo de pasar a mejores mecanismos de cifrado como AES.

Recomendaciones:
Recopilar información para determinar quién/qué sigue utilizando cifrado DES en el dominio. Se debe decidir entre eliminar o actualizar al implicado. Si esto último fuera necesario, es posible configurar los controladores de dominio Windows Server 2008 R2 y superiores para permitir el cifrado DES de Kerberos.

References:
https://support.microsoft.com/kb/978055

Cifrado AES y Autenticación Kerberos:

A partir de Windows Server 2008 y Windows Vista, se agregó soporte de cifrado AES para Kerberos. Aun cuando esto es algo buen, es muy probable que ustedes noten eventos en el log de sus clientes anteriores “quejándose” por tipos de cifrado no soportados. No es necesario preocuparse, ya que los clientes y los controladores de dominio van a negociar el tipo de cifrado apropiado para ambos.

Recomendaciones:
No es necesario hacer nada. Hay que tomar en cuenta que los clientes anteriores a Windows Vista no soportaran los nuevos tipos de cifrado y es probable que registren advertencias o errores en su log de eventos de seguridad.

Referencias:
https://technet.microsoft.com/en-us/library/cc749438(v=WS.10).aspx

Limites en las políticas de LDAP Query:

A partir de Windows Server 2008, se han implementado límites “hardcoded” a las politicas de LDAP. Dichos límites son significativamente más agresivos que el rango configurable en Windows Server 2003. Específicamente los valores MaxReceiveBuffer, MaxPageSize, MaxQueryDuration, MaxTempTableSize y MaxValRange han sido limitados. Si en el ambiente, se han configurado estos parámetros quedando muy alejados de los valores por default, es probable sobrepasar estos límites “hardcoded”.

Recomendaciones:
Evaluar la configuración actual para la política de LDAP query. Si está configurada por default, no hay nada de que preocuparse. Si la política ha sido modificada, asegúrese de que no exceda los nuevos límites. Si fuera el caso, trate de determinar la razón y qué se puede hacer con el cliente o la aplicación que generó esta modificación.

Referencias:
https://support.microsoft.com/default.aspx?scid=kb;en-US;2009267

Límites a las conexiones NSPI:

La “Name Server Provider Interface” (NSPI) es una interfaz que proporcionan los controladores de dominio para permitir a los clientes de mensajería acceder y manipular los datos del directorio (address book). A partir de Windows Server 2008, el número de conexiones NSPI concurrentes ha sido limitada a 50 conexiones por usuario, por DC. Este comportamiento fue implementado a fin de proteger a los DCs de un posible agotamiento de recursos en el escenario en que los clientes NSPI sigan abriendo conexiones sin cerrar las conexiones anteriores que ya no son necesarias. Algunas aplicaciones de mensajería usan una cuenta de servicio para realizar las conexiones NSPI en nombre de los usuarios. En este escenario, una sola cuenta de usuario puede abrir cientos o miles de conexiones NSPI hacia un solo DC bajo el contexto de un solo usuario. En este caso, podría ser necesario aumentar el número máximo de conexiones NSPI en los controladores de dominio Windows Server 2008 R2.

Recomendaciones:
Si ustedes tienen alguna aplicación o cliente de mensajería que requiere más de 50 conexiones NSPI simultáneas por usuario/cuenta de servicio, pueden modificar este límite por default. Estimen un valor más apropiado (algo entre el valor predeterminado de Windows Server 2008 de 50 y el valor por default de Windows Server 2003 de 4 billones) y configuren sus controladores de dominio con ese valor.

Referencias:
https://support.microsoft.com/kb/949469

SMB Signing:

El SMB signing ha andado por aquí desde hace algún tiempo. Desde Windows NT 4.0 SP3 los sistemas operativos Microsoft han sido capaces de utilizar SMB signing. Y ha sido habilitado de forma predeterminada desde Windows Server 2003. Así que si ustedes deshabilitaron esta configuración alguna vez, este es un buen momento para volver a habilitarla.

Recomendaciones:
Revisar la configuración actual para SMB signing – especialmente si ha sido deshabilitada. En dado caso, determinar el porqué y si ya se puede volver a habilitar esta configuración relacionada a la seguridad.

Referencias:
https://support.microsoft.com/kb/887429

Servicio Computer Browser:

Windows Server 2008 y los sistemas operativos posteriores tienen deshabilitado el servicio de Computer Browser por default. Esto parece relativamente inofensivo (y una buena idea); No obstante, hay que tener en cuenta que, tanto "My Network Places " como " Network Neighborhood" se basan en el servicio de Computer Browser.

Recomendaciones:
A menos que tengan una buena razón para no hacerlo, sigan adelante y deshabiliten el servicio de Computer Browser.

Referencias:
https://technet.microsoft.com/en-us/library/bb726965.aspx

LMCompatibilityLevel predeterminado:

El LMCompatibilityLevel puede ser configurado de 0 a 5. EL default de Windows Server 2003 para el LMCompatibilityLevel es 2, mientras que para Windows Server 2008 en adelante el valor por default del LMCompatibilityLevel es 3. Por lo tanto, los controladores de dominio Windows Server 2008 (y superiores) seguirán aceptando los mismos niveles de autenticación NTLM (LM, NTLM, NTLMv2) igual que los controladores de dominio Windows Server 2003. Sin embargo, cuando actúe como cliente, Windows Server 2008 (y superior) utilizará NTLMv2 (en vez de NTLMv1). Esto difiere de Windows Server 2003 cuando actúa como cliente, el cual utilizará LM o NTLM (v1 o v2). Así, el comportamiento del lado del servidor no va a cambiar, mientras que el comportamiento del lado cliente cambiará.

Recomendaciones:
Leer la referencia de abajo para entender correctamente cómo funciona la autenticación NTLM. Esto les ayudará a entender las implicaciones del movimiento en la configuración por default de 2 a la configuración por default de 3. Entonces determinen que configuración están utilizando actualmente (la predeterminada o alguna otra). Finalmente, determinen que valor les gustaría dejar (el nuevo valor por default o algún otro).

Referencias:
https://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx

DFS Site-Costed Referrals:

En los controladores de dominio Windows Server 2008 y superiores se habilitan los DFS Site-Costed Referrals de forma predeterminada. Esto permite a un cliente de DFS localizar objetivos (incluyendo SYSVOL y NETLOGON) más cercanos al cliente, en base a los costos definidos en los Site-links de Active Directory. Los controladores de dominio Windows Server 2003 ordenan las referencias de forma aleatoria (y poco eficiente).

Recomendaciones:
Adoptar la nueva configuración predeterminada con Site-Costed Referrals habilitado. Si los controladores de dominio recientes va a coexistir por un periodo de tiempo considerable con los controladores de dominio Windows Server 2003, debe considerarse la posibilidad de habilitar Site-Costed Referrals en los DCs Windows Server 2003.

Referencias:
https://support.microsoft.com/kb/905846

Null Session Pipes y Null Session Shares:

La lista predeterminada de excepciones en Windows Server 2003 incluye acceso anónimo a “named pipes” para (entre otros) Systems Network Architecture (SNA), print spooler, browser, netlogon, lsarpc y el Security Account Manager (SAMR). Estas excepciones fueron permitidas para lograr compatibilidad con aplicaciones y clientes “legacy”. En Windows Server 2008 R2 la lista predeterminada para NullSessionPipes es más corta (solo 3 entradas) y la lista predeterminada de NullSessionShares está vacía. Esta configuración podría causarle problemas a los clientes/aplicaciones “legacy” que siguen utilizando acceso por null session hacia los controladores de dominio a través de name pipes y/o recursos compartidos específicos.

Recomendaciones:
Es poco probable que tengan clientes que requieran este tipo de acceso. Si fuera el caso, es poco probable que sepan cuáles son los clientes que lo requieren. Hagan pruebas siempre que sea posible. De lo contrario, sólo hay que estar conscientes del cambio. Si llegan a descubrir algún problema, es posible hacer roll back a este cambio.

Referencias:
https://technet.microsoft.com/en-us/library/dd162275.aspxhttps://msdn.microsoft.com/en-us/library/aa365590(VS.85).aspx

EDNS0:

La funcionalidad “Extension Mechanisms for DNS” (EDNS0) permite el uso de paquetes UDP (User Datagram Protocol) de mayor tamaño. Sin embargo, algunos programas de firewall no permiten que los paquetes de UDP sean mayores a 512 bytes. Como resultado, estos paquetes de DNS podrían ser bloqueados por el firewall. Técnicamente EDNS0 fue habilitado desde Windows Server 2003; no obstante algunos clientes deshabilitaban su comportamiento. Es necesario investigar si sus DCs/Servidores DNS actuales tienen EDNS= habilitado o deshabilitado.

Recomendaciones:
Dejar EDNS0 habilitado. Si fuera necesario, configurar el firewall u otro dispositivo de red para permitir paquetes de UDP mayores a 512 bytes. En el peor de los casos, el comportamiento de EDNS0 puede ser deshabilitado.

Referencias:
https://support.microsoft.com/kb/828263https://support.microsoft.com/kb/832223

Comportamiento LDAP:

Los controladores de dominio Windows Server 2008 R2 y Windows Server son más estrictos en lo que respecta al cumplimiento del RFC2696 Section 3. Específicamente cuando se realiza una consulta paginada, cada página de la consulta debe contener valores idénticos exceptuando el messageID, la cookie y opcionalmente un pageSize modificado. Si las páginas de la consulta no se forman correctamente, el controlador de dominio regresará un error UNAVAIL_EXTENSION en lugar de la página solicitada. Ni los controladores de dominio Windows Server 2003 ni los Windows Server 2008 cumplen esta regla.

Recomendaciones:
La aplicación LDAP o el query LDAP afectado debe ser actualizado o modificado para realizar consultas compatibles con el RFC2696. Si esto no fuera posible, se puede modificar el comportamiento del controlador de dominio para que actúe como lo hace Windows Server 2003.

Referencias:
https://support.microsoft.com/kb/2468316https://support.microsoft.com/kb/977180

SID Compression:

La autenticación de Kerberos en Windows incluye “tokens” de acceso (el SID del usuario, además de los SIDs de los grupos a los cuales pertenece el usuario, además del histórico de SID…) en la porción de datos de autenticación de los tickets de Kerberos. Si un token de acceso es demasiado grande, los datos de autenticación no cabrían en el ticket de Kerberos. Para ayudar a reducir el tamaño de los datos de autenticación, los controladores de dominio Windows Server 2012 comprimen los SIDs por default. Algunos clientes de Kerberos de terceros podrían no entender los datos de autenticación con la compresión de SIDs.

Recomendaciones:
Investigar los clientes de Kerberos no-Windows para determinar si son compatibles con la compresión de SIDs. En caso contrario, este comportamiento predeterminado se puede deshabilitar en los controladores de dominio Windows Server 2012.

Referencias:
https://support.microsoft.com/kb/2774190https://blogs.technet.com/b/askds/archive/2012/09/12/maxtokensize-and-windows-8-and-windows-server-2012.aspx

Rango de puertos dinámicos RPC:

A fin de cumplir con las recomendaciones de la “Internet Assigned Numbers Authority” (IANA), Microsoft cambió el rango de puertos dinámicos de cliente para conexiones salientes a partir de Windows Vista y Windows Server 2008. Por default, el nuevo puerto de inicio es 49152 y el puerto final es el 65535. Esto representa un cambio de la configuración en versiones anteriores de Windows que utilizaban de forma predeterminada el rango de puertos del 1025 al 5000.

Este cambio no está directamente relacionado a los servicios de Active Directory, no obstante Active Directory utiliza RPC para comunicarse, por lo tanto, se ve afectado por este cambio.

Recomendaciones:
Ser conscientes de los cambios en el comportamiento de RPC. Si los controladores de dominio se comunican (para replicar AD y FRS) a través de un firewall, asegurarse de que los firewalls están configurados para permitir este nuevo rango de puertos.

Referencias:
https://support.microsoft.com/kb/929851https://support.microsoft.com/kb/832017

Esperamos el esfuerzo que ponemos en esto sea valioso para ustedes.

Greg “AD Upgrade Ninja” Jaworski

Doug “Out of Blogging Breath“ Symalla