¿Se detendrán las aplicaciones empresariales por la baja de NTLM? — Cómo recopilar el registro de auditoría y el orden para eliminar las dependencias

«Dicen que NTLM se va a dar de baja. ¿Nos afecta?» Desde que Microsoft anunció en junio de 2024 que todas las versiones de NTLM quedaban marcadas como obsoletas (deprecated), esta pregunta se ha vuelto cada vez más frecuente. La respuesta es: si nos afecta o no se puede averiguar, y si lo averiguamos ahora, llegamos a tiempo.

La baja de NTLM no es el tipo de cambio en el que “un día se instala un parche y toda la empresa se detiene”. Es un cambio que se va cerrando poco a poco con cada actualización del sistema operativo, y además solo ahora, mientras NTLM todavía funciona, se puede elaborar con seguridad un listado de “en qué puntos depende nuestra empresa de NTLM”. Detenerlo todo primero y buscar después qué se rompió es el peor orden posible.

Este artículo se centra en el procedimiento práctico para elaborar ese listado y eliminar las dependencias una por una. El funcionamiento del protocolo en sí (por qué NTLM es peligroso, por qué la autenticación “cae” a NTLM en lugar de usar Kerberos) queda para el artículo complementario “Cómo funcionan NTLM y Kerberos explicados con diagramas — por qué la autenticación “cae” a NTLM”.

1. Conclusión principal

• NTLM quedó marcado como obsoleto en junio de 2024. Esto afecta a todas las versiones, incluidas LANMAN, NTLMv1 y NTLMv2, y es una declaración de que “ya no habrá más desarrollo activo de funciones”. Al mismo tiempo se indicó que “el uso de NTLM seguirá funcionando tanto en el próximo Windows Server como en la siguiente versión anual de Windows”.¹
• Ya hay partes eliminadas. NTLMv1 se eliminó en Windows 11 versión 24H2 y en Windows Server 2025.¹
• La baja avanza en 3 fases. La fase 1 es la visualización y auditoría del uso; la fase 2 (segunda mitad de 2026) son las funciones para eliminar los escenarios donde no queda más remedio que depender de NTLM (IAKerb, KDC local); la fase 3 es la deshabilitación por defecto de la autenticación NTLM en red en la próxima versión principal.²
• Lo único que hay que hacer ahora mismo es una cosa. Ejecutar el modo de auditoría para elaborar un listado de “qué aplicación, en qué equipo, usa NTLM contra qué servidor” (capítulo 4).
• La investigación de las cuentas de dominio empieza en el controlador de dominio. Siguiendo el orden evento 8004 → 8003 del servidor miembro → 8001 del cliente, se llega finalmente hasta el nombre de la aplicación (sección 4.2). Sin embargo, la autenticación con cuentas locales no pasa por el controlador de dominio, así que el evento 8004 no se genera. Esta ruta hay que recogerla a partir del 8003 del lado servidor y el 8001 del lado cliente.³
• La mayoría de las causas son “de nombres”. Las direcciones IP escritas a mano y los SPN sin registrar son los dos factores principales, y ambos se pueden corregir sin reescribir la aplicación (capítulo 5).³²
• Existe una forma de probarlo con seguridad en un solo equipo. En Windows 11 24H2 / Windows Server 2025, con NET USE \\servidor\recurso /BLOCKNTLM se puede comprobar si la conexión funciona sin NTLM sin cambiar ninguna directiva (capítulo 7).⁴
• En las aplicaciones propias, hay que cambiar a Negotiate los puntos donde se menciona NTLM de forma explícita. La propia Microsoft escribe que “no hay que acceder directamente al paquete de seguridad NTLM” (capítulo 8).⁵

2. Qué significa “obsoleto”

Antes de nada, conviene aclarar la terminología. Si esto se explica de forma ambigua dentro de la empresa, circularán a la vez el mensaje de “parece que ya no se puede usar” y el de “parece que todavía queda tranquilo durante años”, y la conversación se confundirá.

La descripción de NTLM en la lista de funciones obsoletas de Microsoft se resume en estos tres puntos.¹

1. Todas las versiones de NTLM, incluidas LANMAN, NTLMv1 y NTLMv2, quedan fuera del desarrollo activo de funciones y se marcan como obsoletas.
2. El uso de NTLM seguirá funcionando tanto en el próximo Windows Server como en la siguiente versión anual de Windows.
3. Las llamadas a NTLM deben sustituirse por llamadas a Negotiate. Negotiate intenta autenticar con Kerberos y solo recurre a NTLM cuando es necesario.

Y como información de actualización se añade que NTLMv1 se eliminó en Windows 11 versión 24H2 y en Windows Server 2025.¹

Es decir, la situación actual es “obsoleto (deprecated)”, no “eliminado (removed)”. Aunque solo NTLMv1 ha superado la fase de obsolescencia y ya ha entrado en la fase de eliminación. Si una copiadora multifunción o un NAS antiguos solo pueden autenticarse con NTLMv1, la actualización a Windows 11 24H2 se convierte directamente en un fallo. Esto no es una cuestión futura: ya está ocurriendo ahora.

Otro punto que conviene tener presente es que a NTLM le queda un uso para el que “no existe alternativa”. Microsoft indica explícitamente que la autenticación de Windows en sistemas configurados como miembros de un grupo de trabajo, así como el inicio de sesión local fuera de los controladores de dominio, siguen usando NTLM y deben seguir usándolo.⁶ El KDC local previsto para la fase 2 es precisamente la función pensada para tapar este hueco de “NTLM es necesario para las cuentas locales”.²

2.1. La situación actual de las 3 fases

La hoja de ruta de la baja consta de 3 fases. Es información que depende del momento, así que la organizamos indicando la fecha de referencia (la tabla siguiente refleja la situación a julio de 2026).

Lo que hay que confirmar en esta tabla es que lo único que se puede mover con las propias manos ahora mismo es la fase 1. Hay puntos en la tabla de decisión del capítulo 6 donde se dice que las funciones de la fase 2 “pueden ser la solución”, pero en todos los casos se parte de comprobar la disponibilidad. La fecha de disponibilidad puede cambiar, así que revise siempre el contenido de esta tabla en el momento en que su empresa vaya a tomar la decisión.

3. Por qué desaparece — en 3 minutos

Aquí solo cubrimos el mínimo necesario como base para decidir la migración. El diagrama detallado queda para el artículo complementario.

Microsoft afirma con claridad, en la documentación de configuración de directivas, que la autenticación NTLM y NTLMv2 es vulnerable a diversos ataques maliciosos, incluidos los ataques de retransmisión SMB, los ataques de intermediario (man-in-the-middle) y los ataques de fuerza bruta.⁷ En el fondo están las siguientes propiedades, que suelen describirse en comparación con Kerberos.⁸

• No hay autenticación mutua. Con NTLM, el cliente no puede verificar la identidad del servidor, ni un servidor puede verificar la identidad de otro servidor. NTLM fue diseñado para entornos de red donde se puede asumir que “el servidor es auténtico”. Kerberos no parte de esa suposición. Esta diferencia es precisamente la condición que hace posible los ataques de retransmisión, que hacen que las credenciales se envíen a un servidor falso.
• El servidor consulta al controlador de dominio en cada ocasión (en el caso de cuentas de dominio). Con NTLM, el servidor de aplicaciones necesita conectarse al controlador de dominio cada vez que autentica a un cliente con cuenta de dominio (si la cuenta es local al servidor, el propio servidor consulta su base de datos de cuentas local para decidir).⁶ Con Kerberos, los tickets de sesión renovables sustituyen esta autenticación de paso, y el servidor no necesita acudir al controlador de dominio salvo que se requiera validar el PAC (certificado de atributos de privilegio).
• El material de autenticación es directamente el hash de la contraseña. Las credenciales NTLM se componen de un hash unidireccional del nombre de dominio, el nombre de usuario y la contraseña, y el cliente cifra el desafío con ese hash para devolver la respuesta.⁵ De aquí se deriva la propiedad de que, si se roba el hash, se puede suplantar a la víctima sin conocer la contraseña en claro.

El significado práctico de “no hay autenticación mutua” es que con solo intentar conectarse a un recurso compartido SMB, se pueden llegar a entregar credenciales a un servidor falso. La razón por la que Microsoft creó la función de bloqueo de NTLM en el lado cliente de SMB también se explica como “impedir la técnica de hacer que se envíen solicitudes NTLM a un servidor malicioso”.⁴

4. Auditoría — elaborar un listado de dónde se usa NTLM

Este es el tema central. La propia guía de Microsoft indica explícitamente que, antes de implementar una directiva de restricción, es necesario descubrir y auditar el estado actual del tráfico de autenticación NTLM.⁹

4.1. Activar el modo de auditoría

Hay que configurar 3 directivas. Todas se encuentran en Configuración del equipo\Configuración de Windows\Configuración de seguridad\Directivas locales\Opciones de seguridad, y no requieren reiniciar. Tanto si se guarda localmente como si se distribuye por directiva de grupo, se activa en cuanto se aplica la configuración.⁷

Ahora bien, “no requiere reiniciar” y “surte efecto de inmediato en todos los equipos” son cosas distintas. Cuando se distribuye mediante un GPO de dominio, en el momento de guardar el GPO solo se actualiza la directiva almacenada en AD/SYSVOL; cada equipo no empieza realmente a auditar hasta la siguiente actualización en segundo plano o hasta ejecutar gpupdate /force. Cuente el inicio del periodo de auditoría a partir de “la fecha y hora en que la aplicación llegó a los equipos de destino”, no de “la fecha y hora en que se guardó el GPO”. Si se confunde este punto, el primer recuento saldrá distorsionado, con menos equipos de los que en realidad hay.

La tercera, “Tráfico NTLM saliente hacia servidores remotos”, tiene cuatro valores posibles: permitir todo / auditar todo / denegar todo / no definido, y “no definido” se trata igual que “permitir todo”. La recomendación de Microsoft también es clara: no elegir directamente “denegar todo”; primero poner “auditar todo”, revisar el registro de operación, comprobar qué servidores reciben solicitudes de autenticación y solo entonces elaborar la lista de excepciones.⁷

El destino del registro es Visor de eventos > Registros de aplicaciones y servicios > Microsoft > Windows > NTLM (Microsoft-Windows-NTLM/Operational). Para esta auditoría no existe una directiva de eventos de auditoría de seguridad correspondiente, así que hay que consultar este canal en lugar del registro de seguridad.⁷

Lo que más se confunde en la práctica es la correspondencia entre “a qué máquina, qué directiva aplicar, y qué evento consultar”. Tomando las 3 directivas de la tabla anterior como ①②③, se puede resumir en una lista de comprobación.

El registro es siempre el mismo Microsoft-Windows-NTLM/Operational, sea cual sea la máquina. ① solo surte efecto en el controlador de dominio, y un equipo al que se le olvidó configurar ②③ no es “un equipo que no usa NTLM”, sino “un equipo que no lo está registrando”. Esta diferencia es la principal causa de que el recuento salga distorsionado.

Aviso: el modo de auditoría solo registra, no bloquea nada. Por otro lado, en entornos con muchos equipos el volumen de registro crece de golpe. Si no se usa recopilación de eventos (WEF), revise antes el tamaño máximo del registro y el periodo de retención, y solo entonces habilite la auditoría. La propia guía de Microsoft indica que, según la complejidad del entorno, el análisis puede llevar varios meses.³

4.2. El seguimiento va “del controlador de dominio hacia abajo”

Existe un orden fijo para leer los eventos que se van recopilando. La ruta de seguimiento que indica la guía de Microsoft es la siguiente.³

flowchart TD
    accTitle: Orden de seguimiento de los eventos de auditoría NTLM
    accDescr: Diagrama que muestra cómo seguir el rastro desde el evento 8004 del controlador de dominio, pasando por el evento 8003 del servidor miembro, hasta el evento 8001 del cliente, para llegar finalmente a la aplicación responsable; también indica que si el PID en el servidor miembro es 4 (SYSTEM), la vía es SMB
    DC["Controlador de dominio<br/>evento 8004"]
    MS["Servidor miembro<br/>evento 8003"]
    CL["Cliente<br/>evento 8001"]
    APP["Aplicación responsable"]

    DC -->|"Nombre de canal seguro =<br/>servidor a investigar"| MS
    MS -->|"Nombre de estación de trabajo =<br/>cliente a investigar"| CL
    CL -->|"Nombre del proceso cliente"| APP
    MS -.->|"Si el PID es 4 (SYSTEM),<br/>vía SMB"| CL

Figura 1: Orden de seguimiento de los eventos de auditoría NTLM

Los elementos que hay que consultar en cada evento son los siguientes.³

En esta ruta, lo que tiene especial valor son el “servidor de destino” y el “nombre del proceso cliente” del evento 8001. El primero indica directamente “por qué no se usó Kerberos”, y el segundo, “quién es el responsable”. La propia guía de Microsoft explica que, con esta información, se puede determinar que el usuario se está conectando a la dirección IP de un servidor web en lugar de usar el nombre NetBIOS o el FQDN con el que sí podría haberse usado Kerberos.³

Además, hay casos en los que el controlador de dominio no genera el evento 8004. Si la conexión al servidor de archivos se hace con una cuenta de usuario local, esa autenticación no pasa por el controlador de dominio.³ No se puede concluir “no hay problema” solo porque el registro del DC muestre pocos casos.

4.3. Recuento con PowerShell

Revisar miles de entradas en la interfaz gráfica del Visor de eventos no es realista, así que se resume con Get-WinEvent. Primero se confirma cuántos eventos hay y de qué tipo en esa máquina.

# Contar los eventos de NTLM/Operational por Id (ejecutar como administrador)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

Una vez confirmado que hay eventos, se agrupan los 8001 del lado cliente por “servidor de destino × proceso que originó la llamada”. La estructura de los campos varía según el Id. de evento, así que lo más seguro es abrir primero un solo registro con Format-List para comprobar su estructura antes de decidir los índices.

# Comprobar primero el contenido de un solo evento
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# Para ver los campos estructurados
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

Una vez conocida la estructura, se extraen los campos por el atributo Name del XML y se agrupan. Como el nombre de los atributos varía según la versión del sistema operativo, buscar por nombre resulta más resistente que hacerlo por posición.

# Agrupar los 8001 de los últimos 7 días por "destino × proceso que originó la llamada"
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # Recoger, con orden de prioridad, solo los nombres de campo que realmente existan
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

El recuento final se devuelve en dos columnas: Count (número de casos) y Name (destino, proceso que originó la llamada unidos por una coma). Es decir, la salida tiene esta forma (los valores son un ejemplo ilustrativo).

Count Name
----- ----
  412 192.168.1.10, System
  118 fileserver.corp.example.com, System
   57 192.168.1.24, MyBizApp.exe
    9 legacy-nas, System

Lo que hay que mirar es la primera mitad de Name, es decir, el destino. Así se interpreta cada fila.

El valor absoluto del número de casos no dice gran cosa por sí solo. Fíjese en estos dos puntos: si las filas con dirección IP aparecen entre las primeras, y cuántas filas tienen ya identificado el nombre del ejecutable. El primero es una dependencia que, al corregirla, disminuye con seguridad; el segundo es una dependencia a la que ya se le puede asignar un responsable.

Como el nombre de los campos varía según la versión del sistema operativo, aquí se ordenan los candidatos en un arreglo con prioridad y solo se toman los que realmente existan. Si en este punto se usa una coincidencia parcial como -match 'Process', se puede terminar capturando también campos de PID como ClientProcessId, con lo que se agruparía por un PID que cambia en cada ejecución en lugar de por el nombre del ejecutable (como el orden de las claves de una tabla hash no está garantizado, tampoco es estable cuál de los dos se obtiene). Si la columna Process sale vacía en todas las filas, es señal de que los nombres candidatos no coinciden con el esquema real, así que añada al arreglo los nombres confirmados en el paso anterior.

Si va a recopilar datos de varios equipos, lo más rápido es ejecutarlo en paralelo con PowerShell Remoting (véase “Introducción a PowerShell Remoting (WinRM)”). El tiempo que tarda Get-WinEvent puede variar en un orden de magnitud según se use o no -FilterHashtable para filtrar; ese punto clave está reunido en “Cómo investigar el registro de eventos con Get-WinEvent en la práctica”.

4.4. Verlo desde el registro de seguridad — comprobar si todavía se usa NTLMv1

Además de NTLM/Operational, existe también la forma de confirmar la versión de NTLM a partir de los eventos de inicio de sesión del registro de seguridad. El procedimiento consiste en buscar “Paquete de autenticación” en el registro de seguridad y revisar la “Información de autenticación detallada” de cada evento.³

Información de autenticación detallada:
    Proceso de inicio de sesión:      NtLmSsp
    Paquete de autenticación:         NTLM
    Servicio migrado:                 -
    Nombre de paquete (solo NTLM):    NTLM V1
    Longitud de clave:                128

Este “Nombre de paquete (solo NTLM)” indica qué subprotocolo del conjunto NTLM se utilizó.³ Los hosts en los que aparece NTLM V1 son candidatos a dejar de autenticarse en cuanto se actualicen a Windows 11 24H2 / Windows Server 2025, porque NTLMv1 está eliminado en esas versiones.¹ Al ejecutar la auditoría, dé prioridad específicamente a recoger este dato.

4.5. Cuando el PID es siempre 4 (SYSTEM) y no se puede avanzar

Al empezar la auditoría, casi siempre se choca con este muro. En aplicaciones que se comunican a través de un redirector, como sucede con SMB (carpetas compartidas), el sujeto que solicita la autenticación es el redirector en modo kernel, así que el PID que queda en el evento es siempre 4 (SYSTEM).³

La solución que indica la guía de Microsoft es la siguiente.³

1. Instalar una herramienta de monitorización de procesos en el cliente que envía las credenciales NTLM (el “equipo” del evento 8001).
2. Filtrar la ruta por el nombre de equipo y la dirección IP del servidor de destino, ambos a la vez. Si se necesita una captura prolongada, ejecutarla en modo segundo plano.
3. Cruzar el resultado obtenido con la marca de tiempo del evento 8003 del lado servidor. Como coinciden el usuario, la ruta y el identificador de autenticación, a partir de ahí se puede identificar la aplicación que originó la llamada.

La herramienta es Process Monitor (ProcMon). Cómo aplicar los filtros y cómo interpretarlos está reunido en “Guía práctica de Process Monitor (ProcMon)”.

Un consejo práctico adicional: es abrumadoramente más rápido acotar primero “qué equipo es” usando solo el registro de eventos, hasta este punto, y solo entonces desplegar ProcMon en ese único equipo. Desplegar ProcMon en todos los equipos no es realista.

5. Patrones típicos que caen a NTLM

Una vez identificados los puntos mediante la auditoría, el siguiente paso es clasificar las causas. La guía de Microsoft menciona los siguientes cuatro tipos de aplicaciones que, en teoría, admiten Kerberos, pero terminan usando NTLM.³

• Aplicaciones que permiten elegir distintas configuraciones o proveedores de seguridad
• Aplicaciones cuyo SPN (nombre principal de servicio) no está configurado correctamente
• Aplicaciones que, por errores de configuración o por la documentación del proveedor, usan direcciones IP en lugar de nombres DNS
• Aplicaciones con una base de código heredada que aún conserva partes exclusivas de NTLM

El blog de soporte de tecnología Windows de Microsoft Japón menciona, como causas representativas del uso de NTLM, el acceso a servidores por dirección IP, la restricción por firewall de los puertos necesarios para Kerberos, los SPN sin registrar, la autenticación contra dominios de confianza y la autenticación en entornos de grupo de trabajo.²

Organizando todo esto en la forma en que se encuentra en la práctica, se obtiene la siguiente tabla. Las dos columnas de la derecha son criterios para asignar prioridad. “Alcance del impacto” indica la amplitud del problema si se detiene; “facilidad de corrección” indica si se puede resolver solo con las decisiones de la propia empresa. Con estas dos columnas ya se obtiene directamente el orden de un plan de trabajo.

El orden de trabajo se decide de forma mecánica a partir de estas dos columnas.

1. La máxima prioridad, sin importar el alcance del impacto, son los equipos que solo hablan NTLMv1 y los hosts donde se ha registrado NTLM V1 (sección 4.4). Aquí “el plazo ya venció”, así que se coloca fuera del cálculo de prioridad.¹
2. Le sigue alcance del impacto = grande y facilidad de corrección = alta, es decir, las direcciones IP escritas a mano. Tienen muchos casos y se pueden corregir solo con decisiones de la propia empresa. Concentre aquí el primer mes.
3. A continuación, lo relacionado con SPN, con facilidad de corrección = media. Se avanza junto con la unificación de nombres.
4. Los casos con facilidad de corrección = baja (dependientes de equipo, de la ruta, o a la espera de la fase 2) no son que se retrase su inicio, sino que tienen un plazo de entrega largo, así que solo la consulta al proveedor y la obtención de presupuesto conviene iniciarlas en paralelo con los puntos 1 a 3.

Los clasificados como “se corrige de inmediato” y “se corrige registrando el SPN” deberían representar la mayor parte del resultado de la auditoría. Al eliminar solo estos, las excepciones restantes se reducen considerablemente.

6. Tabla de decisión para corregir cada caso

7. Bloqueo de NTLM en SMB — la ruta más corta para una comprobación real

El registro de auditoría indica “que se está usando”, pero no indica “qué pasaría si se detuviera”. Aquí es donde resulta útil el bloqueo de NTLM en el lado cliente de SMB, añadido en Windows Server 2025 y Windows 11 versión 24H2.⁴

Esta función impide que el cliente SMB use autenticación NTLM en las conexiones salientes hacia un destino remoto. Microsoft indica que esto impide la técnica de hacer que se envíen solicitudes NTLM a un servidor malicioso, y ayuda a contrarrestar ataques de fuerza bruta, de descifrado y de Pass-the-Hash, y además señala que el bloqueo de NTLM es necesario para migrar el protocolo de autenticación de la organización a Kerberos. Al mismo tiempo, aclara que se puede habilitar solo esta capa de protección sin deshabilitar NTLM por completo.⁴

Los requisitos previos son estos dos.⁴

• Que el cliente SMB sea Windows Server 2025 o posterior, o Windows 11 versión 24H2 o posterior
• Que el servidor SMB de destino pueda usar Kerberos (el sistema operativo del servidor SMB puede ser cualquiera que admita PKU2U o Kerberos)

7.1. Probarlo primero con un solo equipo y una sola conexión

En lugar de distribuir directamente una directiva, se aprovecha que el bloqueo se puede especificar por conexión. Esta es la ruta más corta para una comprobación real.

# Prohibir NTLM solo en esa conexión y probar a conectarse
# (si conecta, ese recurso compartido funciona sin necesitar NTLM)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# Lo mismo se puede hacer con el mapeo de PowerShell
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

Si conecta, significa que esa ruta funciona sin necesitar NTLM. Si falla, ese es un punto de dependencia de NTLM. Se puede comprobar, conexión por conexión y sin cambiar ninguna directiva, si algo se detendría en producción, lo que resulta muy adecuado para verificar el registro de auditoría.

Hay tres lugares donde comprobar el resultado. (1) Si la conexión tuvo éxito o no se ve en el propio resultado del comando: si tiene éxito, se crea el mapeo y aparece en la lista de net use y en Get-SmbConnection -ServerName <nombre del servidor>; si falla, termina con un error y no queda ningún mapeo. (2) Si de verdad se debe a NTLM se determina comparándolo con el paso 3 más abajo (conectar sin la marca). Si también falla sin la marca, es otro problema distinto. (3) Con qué se autenticó, si se quiere confirmar con certeza, se determina con el método descrito al final de esta sección (klist y el registro de seguridad del lado servidor). No dé por sentado que depende de NTLM solo por el texto del mensaje de error.

Ahora bien, esta comprobación requiere seguir un procedimiento. Si se ejecuta sin más, se obtienen falsos resultados en ambas direcciones.

$server = 'fileserver.corp.example.com'

# 1. Quitar "todas y cada una" de las asignaciones a ese servidor
#    Si queda aunque sea un recurso compartido conectado, la sesión a nivel de servidor sigue viva
net use | Select-String $server              # primero ver qué hay conectado
net use \\$server\share  /delete
net use \\$server\other  /delete             # también todos los demás recursos del mismo servidor

# 2. Confirmar que la sesión realmente desapareció (no avanzar hasta que quede vacío)
Get-SmbConnection -ServerName $server

# 3. Primero confirmar que conecta sin la marca (si falla aquí, es un problema distinto de NTLM)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # volver a dejarlo vacío también aquí

# 4. Ahora sí, probar con /BLOCKNTLM
net use \\$server\share /BLOCKNTLM

• Por qué hacen falta los pasos 1 y 2: las sesiones SMB son por servidor, no por recurso compartido. Si queda una sesión ya autenticada contra ese servidor, el redirector la reutiliza sin volver a autenticarse. /BLOCKNTLM solo afecta a la autenticación que se realiza para ese mapeo concreto, y no revalida retroactivamente una sesión ya establecida (que pudo haberse creado con NTLM). Es decir, no basta con hacer /delete solo del recurso compartido que se está probando. Si queda conectado otro recurso compartido del mismo servidor, la prueba tendría éxito aunque exista dependencia de NTLM. Hay que llegar hasta el estado en el que Get-SmbConnection no devuelve nada. Además de las propias asignaciones, puede haber aplicaciones residentes o trabajos de copia de seguridad reteniendo sesiones. Para hacerlo con total seguridad, lo más rápido es probar desde un equipo que nunca se haya conectado a ese servidor.
• Por qué hace falta el paso 3: un fallo en la resolución de nombres, unas credenciales incorrectas o la falta de permisos sobre el propio recurso compartido también hacen fallar la ejecución con /BLOCKNTLM. Si también falla sin la marca, no es una dependencia de NTLM, sino otro problema.

Aquí solo se puede afirmar que “no hizo falta NTLM”, no que “se autenticó con Kerberos”; tenga presente esta distinción. El requisito previo de esta función es “un servidor SMB que pueda usar Kerberos”, pero el destino también puede ser un sistema operativo que admita PKU2U. Es decir, queda la posibilidad de que el éxito se deba a PKU2U y no a Kerberos. Cuando el otro extremo es un servidor de archivos unido al dominio, en la práctica esto casi nunca supone un problema, pero si de verdad se quiere confirmar con qué se autenticó, ejecute klist en el cliente tras la conexión para ver si se obtuvo un ticket cifs/ para ese servidor, o revise en el registro de seguridad del lado servidor el paquete de autenticación del evento de inicio de sesión (sección 4.4).

7.2. Habilitarlo por equipo

Una vez confirmado el resultado, se pasa a bloquear el equipo por completo en equipos piloto.⁴

# Bloquear NTLM en todo el cliente SMB (requiere permisos de administrador)
Set-SmbClientConfiguration -BlockNTLM $true

Con directiva de grupo, se habilita “Bloquear NTLM (LM, NTLM, NTLMv2)” en Configuración del equipo > Plantillas administrativas > Red > Estación de trabajo Lanman.⁴

7.3. Para los casos que a pesar de todo persisten, usar la lista de excepciones

Los servidores SMB que no están unidos al dominio y cualquier otro extremo que de verdad necesite NTLM se pueden dejar como excepción. Habilite la directiva de grupo Estación de trabajo Lanman > Bloquear la lista de excepciones de servidor NTLM y enumere la dirección IP, el nombre NetBIOS o el FQDN de los destinos permitidos.⁴

No existe un cmdlet de PowerShell para crear la propia lista de excepciones, así que la primera vez es necesario configurarla desde el Editor de directivas de grupo; una vez creada, sí se pueden añadir entradas individuales mediante la clave del registro.⁴

# Añadir una entrada a la lista de excepciones existente
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

Aviso: el ejemplo que aparece en la documentación de Microsoft, para el caso en el que el valor todavía no existe, se limita a asignar @(""), con lo que las entradas que se querían añadir se descartan directamente.⁴ Esto provoca que en la primera ejecución no entre ninguna excepción, y que solo se registren correctamente en la segunda ejecución; por eso el código anterior escribe directamente las entradas a añadir también en el caso de que aún no exista el valor. Aun así, este valor de registro sigue siendo, en principio, un área gestionada por la directiva de grupo. Gestione las excepciones permanentes desde la directiva de grupo, y use esta operación solo como medida temporal de emergencia. Se sobrescribirá en la siguiente aplicación de la directiva.

Aviso: esta función es una característica del lado cliente de SMB.⁴ NTLM en rutas que no son SMB (comunicación HTTP de aplicaciones propias, conexiones a SQL Server, WinRM, etc.) no queda detenido por esto. Esas rutas hay que eliminarlas individualmente siguiendo la clasificación del capítulo 5.

8. NTLM desde el punto de vista del desarrollador — usar Negotiate

Si su empresa desarrolla sus propias aplicaciones de Windows, los puntos que hay que corregir están bien delimitados. Microsoft lo indica de forma explícita.⁵

Las aplicaciones no deberían acceder directamente al paquete de seguridad NTLM. En su lugar, deberían usar el paquete de seguridad Negotiate. Negotiate permite utilizar protocolos de seguridad más avanzados si los sistemas implicados en la autenticación los admiten. Actualmente, el paquete de seguridad Negotiate elige entre Kerberos y NTLM. Negotiate elige Kerberos salvo que alguno de los sistemas implicados en la autenticación no pueda usarlo.

Es decir, el principio es cambiar por “Negotiate” los puntos donde aparece escrito “NTLM”. La lista de funciones obsoletas dice lo mismo: las llamadas a NTLM deben sustituirse por llamadas a Negotiate.¹

8.1. La mención explícita a “NTLM” habitual en .NET

// Mal ejemplo: se menciona explícitamente NTLM como tipo de autenticación
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// Buen ejemplo: lo único que cambia es el tipo de autenticación. Las credenciales se pasan igual
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

Aquí lo único que cambia es la cadena del tipo de autenticación. Si en lugar de eso se sustituye credential por CredentialCache.DefaultNetworkCredentials, no solo cambia el protocolo de autenticación, sino también quién se autentica. En vez de autenticarse con la cuenta especificada, se autenticará con la cuenta que ejecuta ese proceso (una cuenta de servicio o el usuario que tenga la sesión iniciada), y según los permisos configurados en el destino puede dejar de funcionar. Mantenga separados el cambio de protocolo y la revisión de las credenciales; son dos cambios distintos.

Por otro lado, si lo que se busca directamente es autenticarse con las credenciales del usuario que tiene la sesión iniciada (autenticación integrada de Windows), se puede escribir de forma más sencilla. Esta es la forma de escribirlo cuando se quiere cambiar de manera intencionada “con quién” se autentica.

// Autenticación integrada de Windows (se autentica con el usuario que ha iniciado sesión actualmente)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

El manejo de HttpClient en sí (no envolverlo en using, el patrón de creación, el diseño de tiempos de espera) está reunido en “No envuelva HttpClient en un using”.

Si es necesario manejar SSPI directamente, System.Net.Security.NegotiateAuthentication, añadido en .NET 7, permite gestionar la autenticación a través de Negotiate desde código administrado. También aquí el punto clave es no especificar NTLM como nombre de paquete.

8.2. Lo que hay que revisar antes que el código: “cómo se escribe el destino”

Aunque se corrija el código, si el destino sigue siendo una dirección IP, al final se seguirá cayendo a NTLM. Por defecto, cuando el nombre de host es una dirección IP, Windows no intenta la autenticación Kerberos contra ese host y recurre a otro protocolo válido, como NTLM.¹⁰ En concreto, revise lo siguiente.

• Nombres de servidor escritos en archivos de configuración (appsettings.json, App.config, archivos ini)
• La indicación del servidor en la cadena de conexión de SQL Server (Data Source)
• Los puntos donde se construye una ruta UNC. Si hay alguna dirección IP escrita directamente
• Los valores por defecto del instalador o del procedimiento de preparación de equipos (kitting)
• Puntos donde, en una respuesta a una incidencia anterior, se cambió a IP “porque la resolución de nombres era inestable” y nunca se revirtió

Este último punto se encuentra con muchísima frecuencia. La dirección IP escrita a mano fue, en su momento, una solución de emergencia correcta, pero hoy es deuda técnica.

8.3. Si desarrolla el lado del servicio

Si quiere que un servicio de Windows o una aplicación de IIS de desarrollo propio se reciba por Kerberos, es necesario registrar en la cuenta que descifra el ticket el SPN correspondiente al nombre que usa el cliente para acceder. Como se mencionó, la propia Microsoft cita, como ejemplo representativo, que las aplicaciones sin SPN registrado caen a NTLM aunque digan admitir Kerberos.³

Si se piensa de forma simplista que el destino del registro es “la cuenta que ejecuta el servicio”, se tropieza con IIS. La autenticación de Windows de IIS tiene habilitada por defecto la autenticación en modo kernel, y en ese caso quien descifra el ticket Kerberos no es la identidad del grupo de aplicaciones, sino la cuenta de equipo que usa HTTP.sys. Aunque se ejecute el grupo de aplicaciones con una cuenta de dominio dedicada, si se registra el SPN HTTP del sitio en esa cuenta, se produce un desajuste entre el titular del SPN y la cuenta que realmente descifra, y no solo cae a NTLM, sino que la propia autenticación falla directamente con KRB_AP_ERR_MODIFIED.

El punto clave es hacer que coincidan el destino del registro del SPN y la identidad que descifra el ticket. Hay dos formas de lograrlo.

• Descifrar con la cuenta de equipo (comportamiento por defecto): si el sitio se publica con un nombre de host, registrar el SPN HTTP de ese nombre de host en la cuenta de equipo.
• Descifrar con la identidad del grupo de aplicaciones: habilitar useAppPoolCredentials y registrar el SPN HTTP en la cuenta del grupo de aplicaciones.

Cuál elegir depende de si se comparte la misma cuenta de servicio entre varios servidores (si se comparte, alinearse con la identidad del grupo resulta más manejable). Tenga en cuenta que un SPN solo se puede registrar en una cuenta, así que al cambiar de una a otra no olvide eliminar el registro anterior. Un registro duplicado rompe la propia autenticación Kerberos.

Si su diseño se hace pasar por el cliente para acceder a otros servidores (delegación), el tratamiento cambia entre NTLM y Kerberos. Kerberos admite un mecanismo de delegación mediante el cual un servicio se conecta a otro servicio en representación del cliente, mientras que lo que ofrece NTLM llega solo hasta la información de autorización necesaria para la suplantación local.⁸ La implementación relativa a la suplantación se trata en “Suplantación (Impersonation) y tokens en Windows”.

9. Hoja de ruta para ir cerrando el acceso por etapas

En resumen, el avance sigue este orden. En cada etapa debe poder “revertirse”.

9.1. Bloquear SMB es solo la mitad de la medida contra NTLM

Lo que cubren las etapas 4 a 6 es únicamente SMB. Como se mencionó en el capítulo 7, el bloqueo de NTLM del cliente SMB es una función del lado cliente de SMB⁴ y no surte efecto en otras rutas. Lo que en la etapa 2 se clasificó como “se autentica por HTTP”, “SQL Server usa NTLM” o “WinRM usa NTLM” sigue sin tocarse aunque se llegue hasta la etapa 6. Y como tampoco aparece en la lista de excepciones de SMB, ni siquiera se ve al contar los números.

Cerrar eso es lo que hace la etapa 6b. Se usan las mismas 3 directivas que se pusieron en modo auditoría en el capítulo 4. El procedimiento sigue la misma forma.¹¹

1. Manteniendo “Tráfico NTLM saliente hacia servidores remotos” en auditar todo, identificar los destinos de conexión que aún quedan
2. Registrar en “Agregar excepciones de servidor remoto” a los destinos que de verdad sean imprescindibles
3. En equipos piloto, cambiar a denegar todo y esperar a que el negocio complete un ciclo
4. Si no hay problemas, desplegarlo

Para todo el dominio, se avanza con “Autenticación NTLM en este dominio”, también en el orden auditar → excepciones (registrar en “Agregar excepciones de servidor de este dominio”) → denegar.¹² Microsoft también indica que, antes de elegir la opción de denegar, hay que configurar la directiva de auditoría correspondiente con la misma opción para evaluar el impacto.¹²

No dé por completada la medida contra NTLM solo por haber bloqueado SMB. Si necesita un indicador de finalización, cuente ambas listas: la de excepciones de SMB y la de excepciones de servidor de Restringir NTLM.

9.2. El periodo de auditoría se decide por “un ciclo del negocio”, no por “días”

En la etapa 1, el error más frecuente es cómo decidir el periodo. Si se da por completado diciendo “ya llevamos dos semanas recopilando”, los procesos que no se ejecutaron durante esas dos semanas no aparecerán en el listado. Y lo que no aparece se romperá recién cuando se distribuya el bloqueo en la etapa 6.

En concreto, lo que más se suele pasar por alto es esto:

• Procesos de cierre mensual o trimestral. Un caso típico es un proceso por lotes de fin de mes que se conecta por dirección IP a una carpeta compartida o a una base de datos.
• Procesos anuales. Inventarios, cambio de ejercicio fiscal, procesos ligados al cierre contable.
• Rutas que solo se activan en caso de incidencia. Procedimientos de recuperación desde copia de seguridad, cambio a un servidor alterno, simulacros de recuperación ante desastres (DR).
• Equipos que permanecen fuera de línea durante mucho tiempo. Portátiles que se llevan fuera, equipos de personas de vacaciones prolongadas, equipos de repuesto que normalmente están apagados.
• Aplicaciones de negocio que se usan solo unas pocas veces al año.

La propia guía de Microsoft indica que, según la complejidad del despliegue, el análisis puede llevar varios meses.³ Hay dos líneas realistas a seguir:

1. Mantener la auditoría activa hasta que el negocio complete un ciclo. Como mínimo, un cierre mensual; si es posible, que abarque un trimestre.
2. Identificar de antemano los procesos de baja frecuencia y ejecutarlos de forma intencionada. Si no se puede esperar el periodo, ejecutar los procesos de cierre o los procedimientos de DR en un entorno de pruebas y añadir el resultado al listado. El punto clave es enumerar de antemano, mediante entrevistas con los responsables, los procesos que “no aparecen simplemente porque no se han ejecutado”.

En ambos casos, avance a la siguiente etapa solo después de estar en condiciones de distinguir entre “no apareció ningún evento” y “todavía no se ha ejecutado”.

9.3. No pasar de golpe a denegar

Aquí el punto clave es no pasar de golpe a “denegar todo” en el tráfico NTLM saliente. Microsoft también indica que, si esta directiva se configura en denegar, numerosas solicitudes de autenticación NTLM fallarán y puede reducirse la productividad, por lo que antes de implementarla hay que confirmar el registro con “auditar todo”, analizar los servidores y elaborar una lista de excepciones a excluir.⁷ Existe una advertencia similar para la directiva “Autenticación NTLM en este dominio”, que se aplica a todo el dominio.¹²

10. Resumen

• NTLM quedó marcado como obsoleto en todas sus versiones en junio de 2024. No es un cambio que se detenga de inmediato: se indica que seguirá funcionando tanto en el próximo Windows Server como en la siguiente versión anual de Windows.¹
• Por otro lado, NTLMv1 ya está eliminado (Windows 11 24H2 / Windows Server 2025). Los equipos que solo hablan NTLMv1 y los hosts donde queda registrado NTLM V1 son el plazo más cercano.¹
• La baja avanza en 3 fases: la fase 1 es auditoría, la fase 2 (segunda mitad de 2026) es IAKerb y el KDC local, la fase 3 es la deshabilitación por defecto.²
• La auditoría consiste en poner en modo auditoría las 3 directivas y recopilar Microsoft-Windows-NTLM/Operational. Para las cuentas de dominio, se sigue el orden 8004 del DC → 8003 del servidor miembro → 8001 del cliente, y al final se llega hasta el nombre de la aplicación. La autenticación con cuentas locales no genera el 8004, así que se recoge a partir de los eventos de servidor y de cliente.³⁷
• La vía SMB siempre muestra el PID como 4 (SYSTEM). Acote primero el equipo con el registro de eventos y luego persiga solo ese equipo con ProcMon.³
• La mayoría de las causas son “de nombres”. Eliminando solo las direcciones IP escritas a mano y los SPN sin registrar, las excepciones restantes se reducen enormemente.³²
• NET USE \\servidor\recurso /BLOCKNTLM es el medio de verificación más seguro: permite confirmarlo con una sola conexión, sin cambiar ninguna directiva.⁴
• En las aplicaciones propias, sustituya la mención explícita a NTLM por Negotiate y unifique la forma de escribir el destino usando FQDN.⁵
• La lista de excepciones no es una solución, sino un plazo concedido. Use como indicador si el número disminuye cada año.

Artículos relacionados

• Cómo funcionan NTLM y Kerberos explicados con diagramas — por qué la autenticación “cae” a NTLM
• Los inconvenientes de las unidades de red y las rutas UNC — cómo trabajar con servidores de archivos (carpetas compartidas) en aplicaciones de negocio
• Cómo investigar el registro de eventos con Get-WinEvent en la práctica — la velocidad del filtrado decide el tiempo de investigación
• Guía práctica de Process Monitor (ProcMon) — identifique en 10 minutos “no se lee la configuración” o “ACCESS DENIED”
• Introducción a PowerShell Remoting (WinRM) — gestione varios equipos Windows de forma centralizada
• Manejo seguro de credenciales en PowerShell — destierre las contraseñas en texto plano de los scripts
• Integrar la autenticación de Entra ID en aplicaciones WinForms/WPF — configuración práctica con MSAL.NET y el intermediario WAM
• Qué es el TPM de Windows — la “caja fuerte que no deja salir la llave” y el arranque medido, explicados con diagramas

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa del inventario de dependencias de NTLM, de la modificación de aplicaciones de negocio como parte de la migración hacia un supuesto basado en Kerberos, y de la investigación de incidencias relacionadas con la autenticación.

• Desarrollo de aplicaciones Windows
• Investigación de incidencias y análisis de causas
• Aprovechamiento de activos existentes y soporte de migración
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

Si NTLM se da de baja, ¿desde cuándo se detendrá la operación de mi empresa?

El simple anuncio de "obsoleto (deprecated)" no detiene nada por sí solo. Microsoft marcó todas las versiones de NTLM como obsoletas en junio de 2024, pero el propio aviso indicaba que "el uso de NTLM seguirá funcionando tanto en el próximo Windows Server como en la siguiente versión anual de Windows". El cambio concreto que ya ha dejado de funcionar es la eliminación de NTLMv1 en Windows 11 versión 24H2 y en Windows Server 2025. Se ha anunciado un plan para deshabilitar por defecto NTLM en red en una futura versión, pero incluso entonces se podrá volver a habilitar mediante directiva. Es decir, no se trata del tipo de cambio en el que "un día, toda la empresa se detiene de golpe", sino de un cambio que se va cerrando poco a poco con cada actualización del sistema operativo. Precisamente por eso, la única medida realista es identificar los puntos de dependencia mediante los registros de auditoría mientras NTLM todavía funciona, en lugar de investigar después de que algo se detenga.

¿Cómo puedo obtener un listado de los lugares donde se usa NTLM?

Active en modo de auditoría las directivas del tipo "Seguridad de red: Restringir NTLM" de la directiva de grupo y recopile el registro NTLM/Operational. Si configura "Auditar la autenticación NTLM en este dominio" en los controladores de dominio, y "Auditar el tráfico NTLM entrante" junto con "Tráfico NTLM saliente hacia servidores remotos = Auditar todo" en servidores y clientes, los eventos quedarán registrados en el Visor de eventos, en "Registros de aplicaciones y servicios > Microsoft > Windows > NTLM". Para la autenticación con cuentas de dominio, el orden de seguimiento es: identificar en el controlador de dominio el usuario y el servidor de conexión (nombre de canal seguro) con el evento 8004, ver el identificador de proceso (PID) en el evento 8003 de ese servidor, y finalmente confirmar en el evento 8001 del cliente "qué aplicación, con qué nombre de servidor" hizo la solicitud. El evento 8001 incluye el nombre del servidor de destino y el nombre del proceso cliente, así que al llegar hasta aquí ya se identifica la aplicación responsable. Sin embargo, la autenticación con cuentas locales no pasa por el controlador de dominio, por lo que el evento 8004 no se genera. Las rutas de conexión a recursos compartidos mediante cuentas locales en equipos de grupo de trabajo o en servidores de archivos deben recogerse a partir del evento 8003 del lado servidor y del evento 8001 del lado cliente. No concluya que "tenemos pocos casos" basándose únicamente en el registro del controlador de dominio.

Al auditar, el PID de los eventos es casi siempre 4 (SYSTEM) y no sé qué aplicación es.

Es porque la comunicación pasa por SMB (carpetas compartidas). La autenticación de SMB la realiza el redirector en modo kernel, así que la aplicación que originó la solicitud queda oculta detrás del paquete SMB y el PID que queda registrado en el evento siempre es 4 (SYSTEM). La propia guía de Microsoft documenta este caso explícitamente, y como solución recomienda ejecutar Process Monitor (ProcMon) en el cliente donde aparece el evento, filtrar la ruta por el nombre de equipo y la dirección IP del servidor de destino, y cruzar el resultado con la marca de tiempo del evento 8003 del lado servidor para identificar el proceso que originó la llamada. En la práctica, lo más rápido es primero acotar "qué equipo" mediante el registro de eventos y después perseguir solo ese equipo con ProcMon.

¿Por qué una aplicación que en teoría admite Kerberos termina cayendo a NTLM?

En la mayoría de los casos es un problema de nombres. La guía de Microsoft menciona cuatro tipos de aplicaciones que, aunque en teoría admiten Kerberos, terminan usando NTLM: aplicaciones que permiten elegir la configuración o el proveedor de seguridad, aplicaciones cuyo SPN (nombre principal de servicio) no está registrado correctamente, aplicaciones que se conectan por dirección IP en lugar de por nombre DNS debido a errores de configuración o a instrucciones del proveedor, y aplicaciones con código heredado que aún conserva partes exclusivas de NTLM. Si el "servidor de destino" del evento 8001 no tiene formato NetBIOS ni FQDN (es decir, es una dirección IP), con la configuración predeterminada no se usará Kerberos. Las dos primeras medidas son sustituir la dirección IP escrita a mano por un FQDN y, si se accede con un alias, registrar el SPN con ese nombre. Para los casos en los que de verdad no se puede pasar a un nombre, existe también la opción de configurar TryIPSPN en el cliente y registrar manualmente el SPN de la dirección IP, pero la propia Microsoft indica que debe reservarse para cuando sea imposible cambiar a un nombre DNS, así que es en verdad el último recurso.

Si desarrollamos nuestras propias aplicaciones de Windows, ¿qué debemos corregir?

Sustituir los puntos donde el paquete de autenticación menciona NTLM de forma explícita por Negotiate. Microsoft indica claramente que "las aplicaciones no deberían acceder directamente al paquete de seguridad NTLM, sino usar el paquete Negotiate". Negotiate elige entre Kerberos y NTLM, y opta por Kerberos salvo que alguno de los sistemas implicados en la autenticación no pueda usarlo. En .NET, la corrección típica es cambiar el tipo de autenticación que se pasa a CredentialCache.Add de "NTLM" a "Negotiate" (el tipo de autenticación se especifica en CredentialCache.Add, no en el constructor de NetworkCredential). Además, hay que especificar el destino con el FQDN en lugar de una dirección IP o un alias definido en el archivo hosts, y si el servicio propio se va a recibir por Kerberos, también hay que registrar el SPN en la cuenta de servicio correspondiente.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.