Cómo realizar el ajuste del rendimiento para la autenticación NTLM mediante la configuración MaxConcurrentApi

En este artículo se describe cómo realizar el ajuste del rendimiento para la autenticación NTLM mediante la configuración MaxConcurrentApi.

Número de KB original: 2688798

Introducción

Un aumento en la consumidorización de la tecnología de la información empresarial (aumento en dispositivos orientados al consumidor, como smartphones y tabletas usados en la empresa corporativa) ha llevado a aumentar el número de escenarios en los que las empresas pueden experimentar un gran aumento en la autenticación heredada en sus entornos empresariales. Este aumento de la autenticación heredada podría provocar problemas de rendimiento, como retrasos o tiempos de espera para los clientes.

Al detectar tiempos de espera o retrasos de autenticación (también conocidos como cuellos de botella de MaxConcurrentApi) en un entorno, la manera típica de resolver el problema es aumentar el máximo permitido de subprocesos de trabajo que atenien esa autenticación. Para ello, modifique el valor del Registro MaxConcurrentApi y reinicie el servicio Net Logon en los servidores.

Identificar qué servidores son víctimas del cuello de botella y qué servidores son realmente el origen de los retrasos del cuello de botella puede ser difícil. En este artículo se describe cómo realizar el ajuste del rendimiento para la autenticación NT LAN Manager (NTLM) mediante la configuración MaxConcurrentApi. Este artículo contiene instrucciones para que los administradores identifiquen los servidores en los que se va a generar el valor MaxConcurrentApi y la cantidad a la que se debe establecer ese valor.

Solución

Importante

Esta sección, método o tarea contiene pasos que le indican cómo modificar el Registro. No obstante, pueden producirse problemas graves si modifica el registro de manera incorrecta. Por lo tanto, asegúrese de que sigue estos pasos con atención. Para la protección añadida, realice una copia de seguridad del Registro antes de modificarlo. Después, puede restaurar el registro si se produce un problema. Para obtener más información acerca de cómo realizar una copia de seguridad y restaurar el Registro, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
322756 Hacer una copia de seguridad del Registro y restaurarlo en Windows

Para resolver este problema, debe revisar los datos de rendimiento que se tomaron de todos los servidores implicados en el escenario. A continuación, puede intentar aumentar la configuración MaxConcurrentApi en esos servidores que muestran una pérdida de rendimiento.

Hay Netlogon eventos disponibles que notifican problemas de autenticación NTLM, consulte:
2654097 nuevas entradas del registro de eventos que realizan un seguimiento de los retrasos y errores de autenticación NTLM en Windows Server 2008 R2 están disponibles.

Los eventos indican la actividad de dos contadores:

• Eventos 5818/5819: hay "Esperas de semáforo", si los eventos están habilitados.
• Eventos 5816/5817: Hay "Tiempos de espera de semáforo".

Para determinar el mejor valor de MaxConcurrentApi para los servidores, se deben reunir y calcular varios puntos de datos mediante una fórmula. Los datos que se usarán para calcular MaxConcurrentApi son los siguientes:

• Net Logon semaphore acquires
• Tiempos de espera de semáforo de inicio de sesión neto
• Tiempo medio de suspensión del semáforo de inicio de sesión neto
• Duración del registro de rendimiento completado, medido en segundos

Una vez obtenidos los datos, se puede usar la fórmula siguiente para calcular el valor correcto de MaxConcurrentApi:(semaphore_acquires + semaphore_time-outs) * average_semaphore_hold_time / time_collection_length = New_MaxConcurrentApi_setting <
Después de recopilar los datos de rendimiento de Inicio de sesión neto desde el momento en que el servidor estaba bajo carga de autenticación, debe determinar la duración del proceso de recopilación de datos examinando las horas de inicio y finalización de la vista de línea.

Nota

Los marcadores de posición semaphore_acquires y semaphore_time-outs representan números acumulativos que indican cuántos tiempos de espera se produjeron durante la vigencia de un canal de seguridad. Por lo tanto, es probable que los números no comiencen en cero en los datos recopilados. El número inicial debe restarse del número final al usar la vista de línea en el Monitor de rendimiento (Perfmon.msc). A continuación, use este número calculado en la fórmula para la nueva configuración MaxConcurrentApi. Para determinar el número de tiempos de espera que se produjeron durante la recopilación de datos, use vista de línea en Perfmon.msc y reste el puntero del mouse sobre la línea de ese contador al final y el inicio y, a continuación, reste el número inicial del número final. Ese resultado es el número que se va a colocar en la ecuación.

El tiempo medio de retención del semáforo se puede determinar cambiando la vista predeterminada de Vista de línea a Vista de informe en Perfmon.msc. Por ejemplo, considere el siguiente escenario:

• El semáforo adquiere el valor 8.286.
• El valor de tiempo de espera del semáforo es 883.
• El tiempo medio de retención del semáforo es .5 (es decir, medio segundo).
• La duración de los informes es de 90 segundos.

En este escenario, la fórmula sería la siguiente:
(8,286 + 883) *.5 / 90 =< 51

Si el valor derivado de la fórmula es 150 o superior, debe agregar más servidores para atender la carga de autenticación heredada.

Si el valor es menor que 150, debe modificar el valor del Registro MaxConcurrentApi en ese servidor al valor sugerido por la fórmula o a un valor mayor.

Nota

Si decide aumentar el valor de MaxConcurrentApi a más de 10, la carga y el rendimiento de la configuración deseada se deben probar en un entorno que no sea de producción antes de implementar el cambio en un entorno de producción. Esto se recomienda asegurarse de que aumentar este valor no provoca otros cuellos de botella de recursos. Además, tenga en cuenta que las condiciones de carga pueden cambiar en función de cada escenario y entorno empresarial. Por lo tanto, el valor MaxConcurrentApi puede tener una configuración diferente en una fecha posterior si cambia la carga del servicio.

Para cambiar la configuración maxConcurrentApi, siga estos pasos:

1. Haga clic en Inicio, haga clic en Ejecutar, escriba regedity, a continuación, haga clic en Aceptar.

2. Busque la siguiente subclave del Registro y haga clic en ella: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

3. En el menú Edición, seleccione Nuevo y haga clic en Valor DWORD.

4. Escriba MaxConcurrentApi y presione Entrar.

5. En el menú Editar , haga clic en Modificar.

6. Escriba la nueva configuración MaxConcurrentApi en decimal y, a continuación, haga clic en Aceptar.

7. En un símbolo del sistema, escriba el siguiente comando y presione Entrar:
   net stop netlogon

8. Escriba el siguiente comando y presione ENTRAR:
   net start netlogon

Más información

Puede usar el siguiente artículo de Knowledge Base para identificar los síntomas del lado cliente de los cuellos de botella de autenticación heredadas con más detalle:
975363 Se le pedirán de forma intermitente credenciales o tiempos de espera de experiencia al conectarse a servicios autenticados El cuello de botella de autenticación puede estar en varios servidores en el escenario. Por lo tanto, debe asegurarse de que todos los servidores de un escenario determinado tengan revisados sus datos de rendimiento mientras están ocupados en mantenimiento de cargas pesadas.

Los contadores de los semáforos adquieren, para los tiempos de espera de semáforo y para el tiempo medio de retención del semáforo deben revisarse en todos los servidores de aplicaciones, controladores de dominio y controladores de dominio de confianza implicados en el mantenimiento de las solicitudes de cliente.

Se debe realizar un seguimiento de los datos de rendimiento mientras los servidores están bajo una carga pesada. La carga pesada se produce cuando los servidores ven la mayoría de las solicitudes de cliente. Por ejemplo, en un escenario de servidor de correo electrónico, el mejor momento para recopilar los datos de rendimiento es cuando los usuarios llegan al trabajo y comprueban sus mensajes de correo electrónico.

Los elementos adicionales que se tienen en cuenta son los siguientes:

• Ningún valor significa que no se necesita ninguna acción. Los contadores Semaphore Holders y Semaphore Hold Time no mostrarán ningún valor a menos que haya una carga sostenida en un servidor. Si no hay ningún valor presente, no se necesita ningún cambio en el valor maxConcurrentApi.

• Un tamaño no se ajusta a todos. El valor maxConcurrentApi puede tener que ser un valor diferente para cada servidor. Esta situación puede deberse a que varios servidores de aplicaciones obtienen autenticación desde un único controlador de dominio o por escenarios similares en los que varios servidores proporcionan un mayor volumen de carga con el que debe tratar el controlador de dominio.

• Confía. Si los usuarios que se autentican son de dominios de confianza, pueden provocar retrasos más largos, ya que el controlador de dominio local debe esperar la respuesta del controlador de dominio de confianza antes de que el controlador de dominio local proporcione la respuesta al servidor de aplicaciones.

• Latencia de red. La latencia de red también puede desempeñar un papel importante en la causa de los cuellos de botella de MaxConcurrentApi. Este problema puede producirse cuando el semáforo MaxConcurrentApi usa un contador de tiempo de espera basado en tiempo de espera para que los clientes no esperen indefinidamente para la autenticación heredada.

• Colocación. Si existe latencia de red y está causando retrasos y cuellos de botella en la finalización de subprocesos de MaxConcurrentApi, una solución común consiste en colocar los servidores en la misma ubicación física para que se reduzca la latencia de red. En un modelo de dominio en el que un dominio de confianza tiene servidores CAS de Microsoft Exchange, por ejemplo, y el dominio del usuario está en otra región o sitio de Active Directory, significaría colocar los controladores de dominio del usuario en la misma ubicación física y el sitio de Active Directory que los servidores CAS de Exchange y sus controladores de dominio.

• Posible retraso de bajada. Si el valor del contador Esperas de semáforos es continuamente mayor que 0 (cero) para cualquier momento y el valor De los titulares del semáforo es menor que el valor maxConcurrentApi en ese servidor, el cuello de botella no se encuentra en ese servidor. En este caso, busque el controlador de dominio que se cita en el nombre del contador que aparece como un nombre de dominio completo del equipo host. Se deben revisar los datos de rendimiento de los waiters y los titulares de semáforos del controlador de dominio.

• Cambios en la carga o en la configuración de red. Los cambios futuros en la carga que se está realizando el servicio o en las configuraciones de red pueden producir latencia de red y podrían dar lugar a una necesidad de calcular de nuevo la configuración correcta de MaxConcurrentApi. En el caso de los entornos en los que se ve el volumen de autenticación heredado en la medida en que se examina la configuración de MaxConcurrentApi, se recomienda encarecidamente supervisar y revisar continuamente los contadores de objetos de rendimiento de Net Logon. Puede hacerlo mediante recopiladores de datos personalizados de Perfmon.msc programados, mediante Microsoft System Center Operations Manager o mediante otros métodos.

• Windows Server 2008 como máximo. La configuración máxima permitida para MaxConcurrentApi en Windows Server 2008 y en versiones posteriores de Windows es 150. Aplique la revisión que se describe en el siguiente artículo de Knowledge Base para tener la configuración 150 máxima disponible si el servidor que usa no ejecuta Windows Server 2008 R2:
  975363 Se le pedirán de forma intermitente credenciales o tiempos de espera de experiencia al conectarse a servicios autenticados.

• Máximo de Windows Server 2003. La configuración máxima permitida para MaxConcurrentApi en Windows Server 2003 y en versiones anteriores es 10.

• Windows Server 2012 y valores predeterminados más recientes. El valor predeterminado de MaxConcurrentApi se ha cambiado en Windows Server 2012. Es 10 para servidores miembros y controladores de dominio. Permanece en 1 para estaciones de trabajo miembro.

• Contadores de rendimiento y Windows Server 2003. La versión original de Windows Server 2003 no contenía los contadores de rendimiento de Net Logon. Puede aplicar una revisión para agregarla.

La identificación de clientes o servicios no autorizados o desconocidos que realizan la autenticación NTLM repetida y continua puede ser útil cuando desea reducir la carga general de autenticación NTLM y, por lo tanto, reducir en última instancia el número de usos de semáforos de MaxConcurrentApi. La autenticación repetida de esa manera se puede identificar mediante el registro de depuración del servicio Net Logon. Para obtener más información sobre cómo usar el archivo Netlogon.log para depurar el servicio Net Logon, haga clic en el número de artículo siguiente para ver el artículo en Microsoft Knowledge Base:
109626 Habilitación del registro de depuración para el servicio Net Logon

El contador Perfmon.msc para las autenticaciones NTLM en el objeto Security System-Wide Statistics no es una reflexión del número de usos del subproceso de seguimiento MaxConcurrentApi. No hay ninguna correlación uno a uno entre el uso del semáforo MaxConcurrentApi que se muestra en el contador de rendimiento de Inicio de sesión neto y los incrementos del contador de autenticación NTLM. El contador de autenticación NTLM no es útil para determinar el mejor valor de MaxConcurrentApi.

Además, es probable que se vean tiempos de espera de rendimiento de autenticación heredados relacionados con MaxConcurrentApi, pero que no se reflejen en ningún contador de rendimiento que no sea el contador de inicio de sesión de Net. Significa que otras métricas de rendimiento, como el uso de CPU y el uso de disco y red, pueden mostrar ninguna carga aunque la carga de MaxConcurrentApi sea pesada y los usuarios tengan problemas.

Se puede realizar un procedimiento de minimización adicional en controladores de dominio que tienen entradas en su registro de depuración del servicio Net Logon que indica que los clientes envían <null>\username en lugar de domainname\username. Este procedimiento se describe en el siguiente artículo de Microsoft Knowledge Base:
923241 El proceso de Lsass.exe puede dejar de responder si tiene muchas confianzas externas en un controlador de dominio de Active Directory