Actualizaciones de componentes de Servicios de directorio
Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 y Windows Server 2012.
Autor: Justin Turner, ingeniero sénior de escalación de soporte técnico con el grupo de Windows
Nota
Este contenido está escrito por un ingeniero de asistencia al cliente de Microsoft y está destinado a los arquitectos de sistemas y administradores con experiencia que están buscando explicaciones técnicas más detalladas de características y soluciones de Windows Server 2012 R2 que los temas que se suelen proporcionar en TechNet. Sin embargo, no ha experimentado los mismos pasos de edición, por lo que parte del lenguaje puede parecer menos perfeccionado de lo que se encuentra normalmente en TechNet.
En esta lección se explican las actualizaciones de componentes de Servicios de directorio en Windows Server 2012 R2.
Temas que se abordarán
Explique las siguientes nuevas actualizaciones de componentes de Servicios de directorio:
Explique las siguientes nuevas actualizaciones de componentes de Servicios de directorio:
Niveles funcionales de dominios y bosques
Información general
En la sección se proporciona una breve introducción a los cambios de nivel funcional del dominio y del bosque.
Nuevo DFL y FFL
Con la versión, hay nuevos niveles funcionales del dominio y del bosque:
Nivel funcional del bosque: Windows Server 2012 R2
Nivel funcional del dominio: Windows Server 2012 R2
El nivel funcional del dominio de Windows Server 2012 R2 habilita la compatibilidad con lo siguiente:
Protecciones en el lado del controlador de dominio para los usuarios protegidos
Los usuarios protegidos que se autentiquen en un dominio de Windows Server 2012 R2 ya no podrán:
Autenticarse mediante la autenticación NTLM
Uso de los conjuntos de cifrado DES o RC4 en la autenticación previa de Kerberos
Delegarse mediante una delegación con o sin restricciones
Renovar los vales de usuario (TGT) más allá de las 4 horas de vigencia inicial
Authentication Policies
Nuevas directivas de Active Directory basadas en bosques que se pueden aplicar a las cuentas de los dominios de Windows Server 2012 R2 para controlar en qué host puede iniciar sesión una cuenta y aplicar condiciones de control de acceso para la autenticación en los servicios que se ejecutan como una cuenta.
Authentication Policy Silos
Nuevo objeto de Active Directory basado en bosques, que puede crear una relación entre el usuario, el servicio administrado y las cuentas de equipo que se van a usar para clasificar las directivas de autenticación o el aislamiento de autenticación.
Consulte Configuración de cuentas protegidas para obtener más información.
Además de las características anteriores, el nivel funcional del dominio de Windows Server 2012 R2 garantiza que cualquier controlador de dominio del dominio se ejecute en Windows Server 2012 R2. El nivel funcional del bosque de Windows Server 2012 R2 no proporciona características nuevas, pero garantiza que todo dominio nuevo creado en el bosque funcione automáticamente en el nivel funcional del dominio de Windows Server 2012 R2.
DFL mínimo aplicado en la creación de un dominio nuevo
DFL de Windows Server 2008 es el nivel funcional mínimo admitido en la creación de un dominio nuevo.
Nota
El desuso de FRS se logra quitando la capacidad de instalar un nuevo dominio con un nivel funcional del dominio inferior a Windows Server 2008 con el Administrador del servidor o a través de Windows PowerShell.
Reducción de los niveles funcionales del bosque y del dominio
Los niveles funcionales del bosque y del dominio se establecen en Windows Server 2012 R2 de manera predeterminada cuando se crea un dominio nuevo y un bosque nuevo, pero pueden reducirse mediante Windows PowerShell.
Para elevar o reducir el nivel funcional del bosque mediante Windows PowerShell, use el cmdlet Set-ADForestMode.
Para establecer el FFL de contoso.com en modo Windows Server 2008:
Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com
Para elevar o reducir el nivel funcional del dominio mediante Windows PowerShell, use el cmdlet Set-ADDomainMode.
Para establecer el DFL de contoso.com en modo Windows Server 2008:
Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com
Promoción de un controlador de dominio que ejecuta Windows Server 2012 R2 como una réplica adicional en un dominio existente que ejecuta trabajos de DFL 2003.
Creación de un dominio nuevo en un bosque existente
ADPREP
No hay operaciones de bosque o dominio en esta versión.
Estos archivos .ldf contienen cambios de esquema para el servicio de registro de dispositivos.
Sch59
Sch61
Sch62
Sch63
Sch64
Sch65
Sch67
Carpetas de trabajo:
- Sch66
MSODS:
- Sch60
Silos y directivas de autenticación
Sch68
Sch69
Degradación de NTFRS
Información general
FRS ha quedado en desuso en Windows Server 2012 R2. El desuso de FRS se logra aplicando un nivel funcional del dominio mínimo (DFL) de Windows Server 2008. Esta aplicación solo está presente si el nuevo dominio se crea con el Administrador del servidor o Windows PowerShell.
Debe usar el parámetro -DomainMode con los cmdlets Install-ADDSForest o Install-ADDSDomain para especificar el nivel funcional del dominio. Los valores admitidos para este parámetro pueden ser un entero válido o un valor de cadena enumerado correspondiente. Por ejemplo, para establecer el nivel de modo de dominio en Windows Server 2008 R2, puede especificar un valor de 4 o bien "Win2008R2". Al ejecutar estos cmdlets desde Server 2012 R2, los valores válidos incluyen los de Windows Server 2008 (3, Win2008) Windows Server 2008 R2 (4, Win2008R2) Windows Server 2012 (5, Win2012) y Windows Server 2012 R2 (6, Win2012R2). El nivel funcional del dominio no puede ser inferior que el del bosque, pero puede ser superior. Como FRS está en desuso en esta versión, Windows Server 2003 (2, Win2003) no es un parámetro reconocido con estos cmdlets cuando se ejecuta desde Windows Server 2012 R2.
Cambios en el optimizador de consultas LDAP
Información general
El algoritmo del optimizador de consultas LDAP se ha reevaluado y optimizado aún más. El resultado es una mejora del rendimiento de la eficiencia de búsqueda LDAP y el tiempo de búsqueda LDAP de las consultas complejas.
Nota
Desde el Desarrollador: mejoras en el rendimiento de las búsquedas a través de mejoras en la asignación de la consulta LDAP a la consulta ESE. Los filtros LDAP más allá de un determinado nivel de complejidad impiden la selección de índices optimizada, lo que reduce drásticamente el rendimiento (en 1000 veces o más). Este cambio modifica la forma en que se seleccionan los índices para las consultas LDAP para evitar este problema.
Nota
Una revisión completa del algoritmo del optimizador de consultas LDAP, lo que da como resultado:
- Tiempos de búsqueda más rápidos
- Las mejoras en la eficiencia permiten a los controladores de dominio hacer más
- Menos llamadas de soporte técnico relacionadas con problemas de rendimiento de AD
- Migración inversa a Windows Server 2008 R2 (KB 2862304)
Información previa
La capacidad de buscar en Active Directory es un servicio básico que proporcionan los controladores de dominio. Otros servicios y aplicaciones de línea de negocio dependen de las búsquedas de Active Directory. Las operaciones empresariales pueden detenerse si esta característica no está disponible. Como servicio básico y muy usado, es fundamental que los controladores de dominio controlen el tráfico de búsquedas LDAP de forma eficaz. El algoritmo del optimizador de consultas LDAP intenta hacer que las búsquedas LDAP sean lo más eficaces posible mediante la asignación de filtros de búsqueda LDAP a un conjunto de resultados que se puede satisfacer a través de registros ya indexados en la base de datos. Este algoritmo se ha reevaluado y optimizado aún más. El resultado es una mejora del rendimiento de la eficiencia de búsqueda LDAP y el tiempo de búsqueda LDAP de las consultas complejas.
Detalles del cambio
Una búsqueda LDAP contiene:
Una ubicación (encabezado NC, OU, objeto) dentro de la jerarquía para comenzar la búsqueda
Un filtro de búsqueda
Una lista de atributos que se van a devolver
El proceso de búsqueda se puede resumir de la siguiente manera:
Si es posible, simplifique el filtro de búsqueda.
Seleccione un conjunto de claves de índice que devolverá el conjunto cubierto más pequeño.
Realice una o varias intersecciones de claves de índice para reducir el conjunto cubierto.
Para cada registro del conjunto cubierto, evalúe la expresión de filtro, así como la seguridad. Si el filtro se evalúa como TRUE y se concede acceso, devuelva este registro al cliente.
El trabajo de optimización de consultas LDAP modifica los pasos 2 y 3 para reducir el tamaño del conjunto cubierto. Más concretamente, la implementación actual selecciona claves de índice duplicadas y realiza intersecciones redundantes.
Comparación entre el algoritmo antiguo y el nuevo
El destino de la búsqueda LDAP ineficaz de este ejemplo es un controlador de dominio de Windows Server 2012. La búsqueda se completa en aproximadamente 44 segundos como resultado de no encontrar un índice más eficaz.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfind.txt
Using server: WINSRV-DC1.blue.contoso.com:389
<removed search results>
Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
DNT_index:516615:N
Pages Referenced : 4619650
Pages Read From Disk : 973
Pages Pre-read From Disk : 180898
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Resultados de ejemplo con el nuevo algoritmo
En este ejemplo se repite exactamente la misma búsqueda que anteriormente, pero tiene como destino un controlador de dominio de Windows Server 2012 R2. La misma búsqueda se completa en menos de un segundo debido a las mejoras en el algoritmo del optimizador de consultas LDAP.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfindBLUE.txt
Using server: winblueDC1.blue.contoso.com:389
.<removed search results>
Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
idx_userPrincipalName:648:N
idx_postalCode:323:N
idx_cn:1:N
Pages Referenced : 15350
Pages Read From Disk : 176
Pages Pre-read From Disk : 2
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Si no se puede optimizar el árbol:
Por ejemplo: una expresión del árbol estaba sobre una columna no indizada.
Registro de una lista de índices que impiden la optimización
Expuesto a través del seguimiento ETW y el identificador de evento 1644
Habilitación del control Stats en LDP
Abra LDP.exe y, después, conéctese y enlácese a un controlador de dominio.
En el menú Opciones, seleccione Controles.
En el cuadro de diálogo Controles, expanda el menú desplegable Cargar predefinidos, seleccione Estadísticas de búsqueda y después Aceptar.
En el menú Examinar, seleccione Buscar
En el cuadro de diálogo Buscar, seleccione el botón Opciones.
Asegúrese de que la casilla Extendida está activada en el cuadro de diálogo Opciones de búsqueda y seleccione Aceptar.
Pruébelo: uso de LDP para devolver estadísticas de consulta
Realice lo siguiente en un controlador de dominio o desde un cliente o servidor unido a un dominio que tenga instaladas las herramientas de AD DS. Repita lo siguiente indicando como destino el controlador de dominio de Windows Server 2012 y el controlador de dominio de Windows Server 2012 R2.
Revise el artículo "Creación de aplicaciones habilitadas para Microsoft AD más eficaces" y vuelva a consultarlo según sea necesario.
Con LDP, habilite las estadísticas de búsqueda (consulte Habilitación del control Stats en LDP).
Realice varias búsquedas LDAP y observe la información estadística en la parte superior de los resultados. Repetirá la misma búsqueda en otras actividades, por lo que debe documentarlas en un archivo de texto del Bloc de notas.
Realización de una búsqueda LDAP que el optimizador de consultas debería ser capaz de optimizar debido a índices de atributos
Intente construir una búsqueda que tarde mucho tiempo en completarse (es posible que quiera aumentar la opción Límite de tiempo para que no se agote el tiempo de espera de la búsqueda).
Recursos adicionales
¿Qué son las búsquedas de Active Directory?
Funcionamiento de las búsquedas de Active Directory
Creación de aplicaciones habilitadas para Microsoft Active Directory más eficaces
951581 Las consultas LDAP se ejecutan más lentamente de lo esperado en el servicio de directorio AD o LDS/ADAM y se puede registrar el identificador de evento 1644.
Mejoras en el evento 1644
Información general
En esta actualización se agregan estadísticas adicionales de resultados de búsqueda LDAP al identificador de evento 1644 para ayudar a solucionar problemas. Además, hay un nuevo valor del Registro que se puede usar para habilitar el registro en un umbral basado en el tiempo. Estas mejoras estaban disponibles en Windows Server 2012 y Windows Server 2008 R2 SP1 a través de Knowledge Base 2800945 y estarán disponibles para Windows Server 2008 SP2.
Nota
- Se agregan estadísticas de búsqueda LDAP adicionales al identificador de evento 1644 para ayudar a solucionar problemas relacionados con búsquedas LDAP ineficaces o costosas.
- Ahora puede especificar un umbral de tiempo de búsqueda (por ejemplo, Evento de registro 1644 para búsquedas que tardan más de 100 ms) en lugar de especificar los valores de umbral de resultados de búsqueda costosos e ineficaces.
Información previa
Al solucionar problemas de rendimiento de Active Directory, resulta evidente que la actividad de búsqueda LDAP puede contribuir al problema. Decide habilitar el registro para poder ver las consultas LDAP costosas o ineficaces que ha procesado el controlador de dominio. Para habilitar el registro, debe establecer el valor de diagnóstico de ingeniería de campo y, opcionalmente, puede especificar los valores de umbral de resultados de búsqueda costosos o ineficaces. Al habilitar el nivel de registro de ingeniería de campo en un valor de 5, cualquier búsqueda que cumpla estos criterios se registrará en el registro de eventos de Servicios de directorio con un identificador de evento 1644.
El evento contiene lo siguiente:
Dirección IP y puerto del cliente
Nodo de inicio
Filtrar
Ámbito de búsqueda
Selección de atributos
Controles de servidor
Entradas visitadas
Entradas devueltas
Sin embargo, faltan datos clave del evento, como la cantidad de tiempo invertido en la operación de búsqueda y qué índice (si existe) se ha usado.
Estadísticas de búsqueda adicionales agregadas al evento 1644
Índices usados
Páginas a las que se hace referencia
Páginas leídas del disco
Páginas preleídas del disco
Páginas limpias modificadas
Páginas desfasadas modificadas
Tiempo de búsqueda
Atributos que impiden la optimización
Nuevo valor del registro de umbral basado en tiempo para el registro del evento 1644
En lugar de especificar los valores de umbral de resultados de búsqueda costosos e ineficaces, puede especificar el umbral de tiempo de búsqueda. Si quiere registrar todos los resultados de búsqueda que tomaron 50 ms o más, especificaría 50 decimales / 32 hexadecimales (además de establecer el valor de Ingeniería de campo).
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032
Comparación del identificador de evento 1644 antiguo y nuevo
OLD
Nuevo...
Pruébelo: uso del registro de eventos para devolver estadísticas de consulta
Repita lo siguiente indicando como destino el controlador de dominio de Windows Server 2012 y el controlador de dominio de Windows Server 2012 R2. Observe el identificador de evento 1644 en ambos controladores de dominio después de cada búsqueda.
Con regedit, habilite el registro del identificador de evento 1644 mediante un umbral basado en el tiempo en el controlador de dominio de Windows Server 2012 R2 y mediante el método antiguo en el controlador de dominio de Windows Server 2012.
Realice varias búsquedas LDAP que superen el umbral y observe la información estadística en la parte superior de los resultados. Use las consultas LDAP que documentó anteriormente y repita las mismas búsquedas.
Realice una búsqueda LDAP que el optimizador de consultas no pueda optimizar porque uno o varios atributos no están indexados.
Mejora del rendimiento de replicación de Active Directory
Información general
La replicación de AD usa RPC para su transporte de replicación. De manera predeterminada, RPC usa un búfer de transmisión de 8K y un tamaño de paquete de 5K. Esto tiene el efecto neto en el que la instancia de envío transmitirá tres paquetes (unos 15 000 datos) y, a continuación, tendrá que esperar un recorrido de ida y vuelta de la red antes de enviar más. Suponiendo un tiempo de ida y vuelta de 3 ms, el rendimiento más alto sería de aproximadamente 40 Mbps, incluso en redes de 1 Gbps o 10 Gbps.
Nota
En esta actualización se ajusta el rendimiento máximo de replicación de AD de 40 Mbps a unos 600 Mbps.
- Se aumenta el tamaño de búfer de envío RPC, lo que reduce el número de recorridos de ida y vuelta de red.
El efecto será más notable en la red de alta velocidad y latencia alta.
En esta actualización se aumenta el rendimiento máximo a unos 600 Mbps cambiando el tamaño de búfer de envío RPC de 8K a 256 KB. Este cambio permite que el tamaño de la ventana TCP crezca más allá de 8K, lo que reduce el número de recorridos de ida y vuelta de red.
Nota
No hay ninguna opción configurable para modificar este comportamiento.
Recursos adicionales
Funcionamiento del modelo de replicación de Active Directory
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de