Firma SMB y enlace de canal LDAP — cerrar en la práctica «la otra mitad» de las medidas contra NTLM

«Ya empezamos a auditar NTLM. También estamos corrigiendo las conexiones que usan la IP directamente. Pero, mientras terminamos de eliminar todas las dependencias, ¿cómo nos protegemos de los ataques de relay?» — Esta fue la pregunta más frecuente tras publicar el artículo anterior, «¿Se detendrán las aplicaciones de negocio al retirar NTLM?»

La respuesta son la firma SMB y la firma LDAP / el enlace de canal LDAP, que trataremos en este artículo. Ninguna de las dos es una medida para «dejar de usar NTLM»: son defensas para que, mientras NTLM siga presente, no se pueda llevar a cabo el ataque que retransmite (relay) credenciales robadas. Y mientras que la firma SMB ya ha cambiado de valor predeterminado en Windows 11 24H2 y Windows Server 2025 —llega junto con la actualización del sistema operativo aunque no se haga nada—, la firma LDAP y el enlace de canal mantienen el mismo valor predeterminado de siempre: seguirán siendo laxos mientras el administrador no los cierre. Dicho de otro modo, con SMB la disyuntiva es «adelantarse o reaccionar después de un incidente provocado por la actualización del SO», y con LDAP la pregunta es «cuándo decide usted cerrarlo».

Este artículo es el tercero de la serie sobre NTLM. El procedimiento de auditoría de NTLM está en el primer artículo y el funcionamiento del protocolo en el segundo.

1. Conclusión primero

• La firma SMB es un mecanismo que añade a cada mensaje SMB una firma de detección de manipulación. La firma incluye el hash de todo el mensaje y la identidad del emisor y el receptor, y actúa como defensa frente a ataques de relay y de suplantación.¹
• El valor predeterminado ya ha cambiado. En Windows 11 versión 24H2, las ediciones Enterprise, Pro y Education tienen firma obligatoria tanto en el envío como en la recepción, y en Windows Server 2025 solo es obligatoria en el envío de forma predeterminada (en Home ninguna de las dos es obligatoria).²
• La obligatoriedad de la firma va siempre acompañada de la deshabilitación del acceso de invitado. Los NAS que no admiten firma o los equipos que dependen de conexiones de invitado empezarán a fallar en el momento de la actualización del sistema operativo, con el código de error 0xc000a000 (STATUS_INVALID_SIGNATURE) o con el mensaje de bloqueo de invitado (sección 4.3).²
• La firma LDAP es el mecanismo que permite al controlador de dominio rechazar los «bind SASL que no exigen firma» y los «bind simples en texto claro». Se debe a que el tráfico LDAP sin firmar es vulnerable a ataques de repetición y de intermediario.³
• El enlace de canal LDAP es el mecanismo que vincula al canal TLS la autenticación de Windows (bind SASL) realizada sobre LDAPS (SSL/TLS). El valor usado para este vínculo se denomina token de enlace de canal (CBT). El bind simple, que no tiene CBT, queda fuera del alcance de esta verificación (capítulo 6). Se controla mediante el valor de registro LdapEnforceChannelBinding (0/1/2) o mediante directiva de grupo.⁴
• En ambos casos se avanza en tres etapas: leer los eventos de auditoría → corregir los orígenes de conexión → pasar a la aplicación obligatoria. Para la firma LDAP, los orígenes se identifican con los eventos 2887 y 2889; para el enlace de canal, con los eventos 3039 y 3040 y con los eventos de auditoría 3074 y 3075 (capítulos 5 y 6).³⁴
• Como premisa importante, estas actualizaciones no cambian el valor predeterminado por sí solas. Microsoft ha declarado explícitamente, respecto a la serie de actualizaciones de LDAP publicadas desde marzo de 2020, que «no se cambia la directiva predeterminada de firma LDAP ni de enlace de canal». Cerrarlas es tarea del administrador.⁴

2. Por qué la firma — «la otra mitad» del ataque de relay

Como se explicó en el segundo artículo, la debilidad fundamental de NTLM es que carece de autenticación mutua. Como el cliente no puede verificar la identidad del servidor, un atacante puede hacerse pasar por «el servidor legítimo» para que el cliente se autentique ante él, y luego retransmitir tal cual la respuesta de autenticación recibida hacia el servidor real. Esto es un ataque de relay, y el propio Microsoft indica explícitamente que la autenticación NTLM y NTLMv2 es vulnerable a los ataques de relay SMB y de intermediario.⁵

Si se detiene NTLM por completo, este ataque deja de ser posible, pero como vimos en el primer artículo, identificar y corregir las dependencias lleva varios meses. La defensa durante ese periodo es la firma.

flowchart LR
    CL["Cliente"]
    AT["Atacante<br/>(servidor falso)"]
    SV["Servidor legítimo"]

    CL -->|"① Respuesta de autenticación"| AT
    AT -->|"② Retransmite tal cual"| SV
    SV -.->|"③ Si la firma es obligatoria:<br/>el atacante, sin la clave de sesión,<br/>no puede generar la firma correcta y falla"| AT

Figura 1: relación entre el ataque de relay y la firma SMB

El punto clave es que la clave de la firma (la clave de sesión) la poseen, como resultado de la autenticación, únicamente el cliente y el servidor legítimo. El atacante que se limita a retransmitir la respuesta de autenticación no tiene la clave de sesión, de modo que en un entorno con firma obligatoria no puede falsificar los mensajes posteriores. La firma SMB cierra el relay hacia SMB, y la firma LDAP junto con el enlace de canal cierran el relay hacia LDAP/LDAPS del controlador de dominio.

Hay otra advertencia práctica. El efecto de la firma no es independiente de qué protocolo de autenticación se use. Como la clave de sesión deriva de la contraseña, si se autentica con NTLMv2 en lugar de con Kerberos, la clave que sostiene la firma es más débil. Microsoft también señala, como condiciones para maximizar el efecto de la firma SMB, usar Kerberos y no conectarse al recurso compartido mediante una dirección IP o un CNAME.¹ Esto se debe a que conectarse mediante una dirección IP o un alias sin el SPN correspondiente registrado hace que se use NTLM en lugar de Kerberos (el registro del SPN para quienes necesiten seguir usando un alias se trata en el primer artículo). En resumen, reducir la dependencia de NTLM y hacer obligatoria la firma no son medidas separadas, sino las dos caras de una misma estrategia.

3. Firma SMB — el mecanismo y el valor predeterminado que ya cambió

3.1. El mecanismo en un minuto

La firma SMB usa la clave de sesión y el conjunto de cifrado para firmar cada mensaje que circula por la conexión. La firma incluye, dentro de la cabecera SMB, el hash de todo el mensaje, de modo que si este se manipula en tránsito el hash deja de coincidir. Como el hash también incluye la identidad del emisor y el receptor, también permite detectar la suplantación.¹

El algoritmo se ha reforzado en cada generación. SMB1 usaba MD5, pero pasó a HMAC-SHA-256 en SMB 2.02 y a AES-CMAC en SMB 3.0, y en Windows Server 2022 y Windows 11 se incorporó la aceleración de firma mediante AES-128-GMAC.¹ Si la idea de que «firmar = lento» proviene de la época de SMB1, vale la pena dejarla de lado y volver a medirlo.

La configuración no se piensa en términos de «habilitado/deshabilitado», sino de si es obligatoria (Require). A partir de SMB 2.x se ignora el parámetro EnableSecuritySignature, y solo tiene efecto RequireSecuritySignature. Y si al menos uno de los dos lados, cliente o servidor, la hace obligatoria, esa conexión queda firmada. Solo deja de firmarse cuando ninguno de los dos la hace obligatoria.¹

3.2. Tabla de decisión sobre los valores predeterminados

No es necesario leer toda esta tabla. Primero compruebe el sistema operativo y la edición de sus equipos y servidores, y lea solo la fila que le corresponda. La edición y la versión se pueden consultar en «Configuración > Sistema > Acerca de» (donde «Edición» muestra Pro/Home/Enterprise/Education, etc., y «Versión» muestra 24H2, etc.).

Las tres primeras filas son valores predeterminados documentados explícitamente por Microsoft.² La última fila refleja el comportamiento de siempre: el controlador de dominio exige firma SMB a todo el que se conecta a él. La distribución de directiva de grupo y de scripts de inicio de sesión siempre ha funcionado bajo el supuesto de la firma.¹

Solo la edición Home queda fuera de este cambio de valor predeterminado. Como ni el envío ni la recepción se vuelven obligatorios, actualizar a 24H2 no provoca errores de conexión por firma obligatoria en equipos Home (esto no garantiza que no cambie en el futuro, pero al menos no forma parte del «plazo límite» de 24H2).² Dicho de otro modo, incluso dentro de 24H2 el comportamiento difiere según la edición. Al diagnosticar un aviso de «dejó de poder conectarse al recurso compartido tras la actualización», compruebe primero la edición, no solo la versión.

El significado práctico de esta tabla es el siguiente. Actualizar a Windows 11 24H2 (Enterprise, Pro o Education) convierte en obligatoria la firma para todas las conexiones SMB salientes de ese equipo (Home queda excluido). Si el servidor de archivos interno es Windows, no ocurre nada (porque Windows admite firma en todas sus versiones). Los incidentes ocurren cuando el interlocutor es un equipo de terceros que no admite firma o la tiene deshabilitada: NAS antiguos, la configuración de destino de escaneo de una multifunción, o una implementación de Samba en Linux embebido, entre otros.

4. Pasos para llevar la firma SMB a «obligatoria»

4.1. Comprobar el estado actual

# Requisito de firma del lado cliente (envío)
Get-SmbClientConfiguration | FL RequireSecuritySignature

# Requisito de firma del lado servidor (recepción)
Get-SmbServerConfiguration | FL RequireSecuritySignature

Si el valor es True, la firma es obligatoria; si es False, no lo es.² Si se administra mediante directiva de grupo, la ruta es Configuración del equipo\Configuración de Windows\Configuración de seguridad\Directivas locales\Opciones de seguridad, con las directivas «Cliente de red Microsoft: firmar digitalmente las comunicaciones (siempre)» (cliente) y «Servidor de red Microsoft: firmar digitalmente las comunicaciones (siempre)» (servidor). El «siempre (always)» del nombre de la directiva equivale a «obligatorio».¹

4.2. Identificar primero a «quienes no pueden firmar» (auditoría)

A partir de Windows 11 versión 24H2 es posible habilitar una auditoría que detecta clientes y servidores de terceros que no admiten firma ni cifrado.¹

# Lado servidor: detecta clientes que no admiten firma
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# Lado cliente: detecta servidores que no admiten firma
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

El mismo mecanismo ofrece también una auditoría que detecta interlocutores que no admiten cifrado (-AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption),¹ pero eso es una preparación para una futura obligatoriedad del cifrado SMB, en una vía distinta de la hoja de ruta de la firma. No es raro encontrar equipos que admiten firma pero no cifrado, así que no mezcle los eventos de auditoría de cifrado con la decisión de dar por completa la firma.

El registro de eventos se escribe en los siguientes lugares.¹

Los pasos para revisar los eventos son estos tres.

1. Abra el Visor de eventos con eventvwr.msc y, en el árbol de la izquierda, vaya a Visor de eventos > Registros de aplicaciones y servicios > Microsoft > Windows > SMBClient > Audit (para el lado servidor, use SMBServer > Audit en el mismo nivel).
2. En el panel derecho, elija «Filtrar el registro actual» e introduzca 31998,31999 (en el lado servidor, 3021,3022) en el campo «Todos los identificadores de eventos».
3. Al abrir los eventos que queden filtrados encontrará la información del interlocutor que no admitía firma. Vaya volcando esos datos en una lista de equipos.

Si prefiere obtenerlos todos de una vez con PowerShell, use lo siguiente.

# Lado cliente: eventos de auditoría que detectaron servidores sin firma
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBClient/Audit'; Id=31998,31999 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

# Lado servidor: eventos de auditoría que detectaron clientes sin firma
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBServer/Audit'; Id=3021,3022 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

Justo después de habilitar la auditoría, si aún no hay ningún registro, Get-WinEvent devuelve un error de que no hay eventos coincidentes (por eso se añade -ErrorAction SilentlyContinue arriba). La forma de escribir estos filtros está resumida en «Cómo consultar registros de eventos en la práctica con Get-WinEvent».

En directiva de grupo, el equivalente son las opciones «Audit client does not support signing», entre otras, dentro de Lanman Server / Lanman Workstation, bajo Configuración del equipo\Plantillas administrativas\Red.¹ El criterio sobre la duración de la auditoría descrito en el primer artículo (mantenerla activa hasta completar un ciclo completo de trabajo) también se aplica aquí sin cambios.

4.3. Conocer los patrones de incidente

Al conectarse, en un entorno con firma obligatoria, a un interlocutor que no puede firmar, se produce el siguiente error.²

0xc000a000
STATUS_INVALID_SIGNATURE
La firma cifrada no es válida.

Hay otro punto que se pasa por alto fácilmente: el acceso de invitado. La obligatoriedad de la firma va acompañada de la deshabilitación del acceso de invitado. Al conectarse a un NAS configurado para dar acceso sin autenticación (invitado), aparece un error como el siguiente.²

No se puede tener acceso a esta carpeta compartida porque la directiva de
seguridad de la organización bloquea el acceso de invitado no autenticado.

El orden de prioridad al corregirlo es claro. La primera opción es habilitar la firma SMB en el propio equipo y autenticarse con credenciales en lugar de como invitado. Configurar en el cliente Set-SmbClientConfiguration -RequireSecuritySignature $false evita el error de firma (0xc000a000), pero el bloqueo de invitado obedece a otra configuración del cliente (la prohibición de inicio de sesión de invitado inseguro), distinta de la firma, y relajar solo la firma no lo resuelve. Microsoft no recomienda ni deshabilitar la firma como solución alternativa para equipos de terceros, ni intentar usar la firma con una cuenta de invitado.² Si decide relajarlo, trátelo como «una excepción con fecha límite, hasta que se sustituya ese equipo».

4.4. Orden de implementación

Además, cuantos más equipos con 24H2 o posterior haya, más se irá volviendo «obligatoria de forma predeterminada en el lado cliente», de modo que el plazo real lo marca el plan de actualización del sistema operativo. Las organizaciones que estén migrando a Windows 11 24H2 o posterior como respuesta al fin de soporte de Windows 10 deben incluir esta verificación como trabajo previo de la migración («Opciones tras el fin de soporte de Windows 10»).

5. Firma LDAP — proteger la vía de acceso al controlador de dominio

En este capítulo y en el siguiente, el eje de la explicación son los tipos de «bind», así que antes conviene aclarar solo dos términos.

Es decir, «hacer obligatoria la firma LDAP» significa exigir firma en los bind SASL y rechazar el bind simple sobre una conexión en texto claro.

Tras SMB toca LDAP. El tráfico LDAP sin firmar hacia el controlador de dominio (y hacia AD LDS) es vulnerable a ataques de repetición y de intermediario. Si un atacante intercepta un paquete, lo modifica y lo reenvía al servidor, existe el riesgo de que el servidor tome decisiones basadas en una solicitud falsificada.³

Hacer obligatoria la firma LDAP consiste en que el servidor de directorio rechace estos dos tipos de bind.³

1. Bind SASL que no exige firma (verificación de integridad) (SASL incluye Negotiate, Kerberos, NTLM y Digest)
2. Bind simple realizado sobre una conexión en texto claro (sin SSL/TLS)

5.1. Tabla de referencia rápida de IDs de evento (común a la firma LDAP y al enlace de canal)

Antes de continuar, aquí están reunidos los identificadores de evento que aparecen en este capítulo y en el 6. Todos se registran en el registro «Directory Service» del controlador de dominio (Visor de eventos > Registros de aplicaciones y servicios > Directory Service). Esta tabla está pensada para poder construir directamente el diseño de la auditoría a partir de ella.

El uso de cada uno es simple. Los eventos de recuento (2887 y 3040) muestran «cuántos casos quedan todavía», y los eventos individuales (2889, 3039, 3074 y 3075) muestran «de dónde vienen». Mientras el recuento no llegue a cero, no se avanza a la aplicación obligatoria. A continuación, en la sección 5.2 se examina en detalle el lado de la firma LDAP, y en el capítulo 6 el lado del enlace de canal.

5.2. Primero, auditar — eventos 2886/2887/2889

El registro Directory Service del controlador de dominio ya ofrece pistas desde el principio. De la tabla de referencia de la sección 5.1, los relacionados con la firma LDAP son cuatro: 2886, 2887, 2888 y 2889. De ellos, el 2887 indica «cuántos bind sin firmar quedan todavía» y el 2889 indica «de dónde vienen» (el 2888 es el recuento posterior a configurar el rechazo).³

Solo el 2889 no aparece de forma predeterminada: se empieza a registrar al subir la configuración de diagnóstico «16 LDAP Interface Events» a 2 (Basic).³ El procedimiento es: primero comprobar con el recuento del 2887 «cuántos bind sin firmar hay, para empezar», y si no es cero, habilitar el 2889 para identificar los orígenes. Tenga en cuenta que el 2889 no es un recuento, sino que se registra por cada ocurrencia del bind en cuestión, así que en un entorno donde persistan bind heredados con alta frecuencia puede llenar rápidamente el registro Directory Service. Una vez identificados los orígenes, vuelva a poner la configuración de diagnóstico en su nivel original (el predeterminado es 0). Si decide dejarlo activo de forma permanente, asegure antes el reenvío y la retención del registro.

Los orígenes típicos son sistemas de negocio integrados con LDAP (federación de autenticación, integración con el sistema de RR. HH.), la búsqueda en la libreta de direcciones LDAP de las multifunciones y la autenticación LDAP de equipos de red. En particular, la «configuración del servidor LDAP» de las multifunciones y de otros equipos suele ser un bind simple en texto claro, así que es lo primero que hay que sospechar. La corrección consiste en cambiar la configuración del equipo o la aplicación a LDAPS (puerto 636) o a un bind SASL firmado.

5.3. Aplicarlo de forma obligatoria

Una vez corregidos los orígenes de conexión, se aplica de forma obligatoria mediante directiva de grupo.³

• Lado del controlador de dominio: en Default Domain Controller Policy, configure «Controlador de dominio: requisitos de firma del servidor LDAP», dentro de Opciones de seguridad, como «Requerir firma»
• Lado del cliente: configure «Seguridad de red: requisitos de firma de cliente LDAP» como «Requerir firma»

Puede verificarlo con ldp.exe. Conéctese al puerto 389, intente un bind simple y, si obtiene el siguiente error, la configuración está activa.³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. Enlace de canal LDAP — la defensa del lado LDAPS

«Nosotros ya usamos LDAPS, así que estamos bien» — el enlace de canal es lo que cierra el resquicio que queda ahí. LDAPS cifra la comunicación, pero eso por sí solo no basta para impedir el relay del tipo «hacer que el cliente se autentique y retransmitir esas credenciales a otra conexión TLS propia del atacante». El token de enlace de canal (CBT) vincula la autenticación al propio canal TLS, de modo que hace detectable la retransmisión hacia otro canal.

Dicho con precisión, el ámbito de aplicación son las conexiones que realizan autenticación de Windows (bind SASL) mediante NTLM, Kerberos, etc., sobre LDAPS. El bind simple, al no tener CBT en absoluto, queda fuera de esta verificación. Lo que protege al bind simple sobre LDAPS es el propio cifrado TLS y la gestión de credenciales, y aunque se configure Always, un cliente con bind simple nunca aparecerá en los eventos de auditoría del CBT.

El control se realiza mediante un valor de registro del controlador de dominio, o mediante la directiva de grupo equivalente.⁴

Los eventos usados para la auditoría son los siguientes (es el desarrollo, con su contenido completo, del lado del enlace de canal de la tabla de referencia de la sección 5.1). La actualización del 10 de marzo de 2020 añadió los eventos relacionados con el enlace de canal, y las actualizaciones a partir de 2023 ampliaron aún más los eventos de auditoría.⁴

El procedimiento es el mismo que para la firma LDAP, y la propia guía de Microsoft indica: «supervisar en el registro Directory Service de todos los controladores de dominio el evento 2889 (fallo de firma), el 3039 (fallo de enlace de canal) y los eventos de auditoría 3074 y 3075, identificar los equipos problemáticos, consultar con su proveedor y confirmar la corrección antes de pasar a la aplicación obligatoria».⁴

Conviene subrayar un punto: Microsoft no ha cambiado el valor predeterminado con estas actualizaciones. Se declara explícitamente que la actualización del 10 de marzo de 2020 y las actualizaciones posteriores previstas no cambian la directiva predeterminada de firma LDAP ni de enlace de canal LDAP.⁴ A diferencia de la firma SMB (cuyo valor predeterminado cambió en 24H2), el lado de LDAP seguirá siendo laxo mientras el administrador no lo cierre por su cuenta. Dicho de otro modo, se puede avanzar de forma planificada mientras aún se pueda elegir el momento de hacerlo.

7. Cómo corregir aplicaciones de negocio y equipos (tabla de decisión)

A continuación se organizan por causa los orígenes de conexión detectados en la auditoría.

Si tiene una aplicación .NET de desarrollo interno que usa LDAP, lo primero que hay que sospechar es si está enviando un bind simple en texto claro.

// Ejemplo incorrecto: bind simple en texto claro al puerto 389. Se rechaza si se hace obligatoria la firma LDAP
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Basic;
conn.Bind(new NetworkCredential(user, password));

// Ejemplo correcto 1: exigir Negotiate + firma y cifrado (Kerberos se elige si el SPN y la resolución de nombres están correctos)
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Negotiate;
conn.SessionOptions.Signing = true;
conn.SessionOptions.Sealing = true;
conn.Bind();  // Autenticación con la cuenta en ejecución

// Ejemplo correcto 2: si se usa bind simple, hacerlo siempre sobre LDAPS
var id = new LdapDirectoryIdentifier("dc01.corp.example.com", 636);
var conn2 = new LdapConnection(id);
conn2.SessionOptions.SecureSocketLayer = true;
conn2.AuthType = AuthType.Basic;
conn2.Bind(new NetworkCredential(user, password));

Negotiate, en el ejemplo correcto 1, prioriza Kerberos pero no lo impone. Si el destino es una dirección IP, o si el SPN no está registrado o está duplicado, cae silenciosamente a NTLM (aun así, la exigencia de firma y cifrado sigue en efecto). La forma fiable de confirmar que se está autenticando con Kerberos es comprobar con klist que se ha obtenido el ticket del servicio correspondiente. En un entorno donde esté habilitada la auditoría de NTLM del primer artículo (auditar todo el tráfico NTLM saliente), la ausencia del evento 8001 también sirve como indicio indirecto. Tenga en cuenta que, si la directiva de auditoría sigue deshabilitada, «que no aparezca el 8001» no significa nada. Por otro lado, el bind simple del ejemplo correcto 2 se cifra con TLS, pero, como se explicó en el capítulo 6, lo que queda sujeto a la verificación de CBT es el lado de la autenticación de Windows. Si puede elegir en un entorno de dominio, tome el ejemplo correcto 1 como base. Si accede mediante DirectoryEntry (ADSI), lo más fiable es indicar explícitamente AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing. El principio expuesto en el primer artículo de la serie NTLM (escribir el destino como FQDN y no como dirección IP) también resulta clave aquí, como condición previa para que se establezca el bind SASL con Kerberos.

8. Resumen

• La firma SMB y la firma/enlace de canal LDAP son defensas para impedir el ataque de relay mientras se termina de eliminar la dependencia de NTLM, y al mismo tiempo son un refuerzo permanente que se mantiene incluso después de retirar NTLM (la detección de manipulación de la firma y el enlace de canal también surten efecto en las sesiones autenticadas con Kerberos). Avance con esto como las dos caras de la misma estrategia de reducción de NTLM.¹⁵
• El valor predeterminado de la firma SMB ya cambió. En Windows 11 24H2 (Enterprise/Pro/Education) es obligatoria tanto en el envío como en la recepción, y en Windows Server 2025 es obligatoria en el envío. El plan de actualización del sistema operativo se convierte, tal cual, en el plazo límite.²
• Los patrones de incidente están bien delimitados: el 0xc000a000 de los equipos que no admiten firma y el bloqueo del acceso de invitado. Se pueden identificar de antemano con la función de auditoría disponible desde 24H2.²¹
• En LDAP se identifican los orígenes con los eventos 2887 y 2889 (firma) y 3039, 3040, 3074 y 3075 (enlace de canal); se corrigen y después se aplica de forma obligatoria.³⁴
• El valor predeterminado del lado LDAP no cambia con las actualizaciones. Seguirá siendo laxo mientras el administrador no lo cierre. Avance de forma planificada mientras aún pueda hacerlo.⁴
• En las aplicaciones internas, eliminar el «bind simple en texto claro» y las «conexiones directas por dirección IP» resuelve la mayor parte de los casos.

Artículos relacionados

• ¿Se detendrán las aplicaciones de negocio al retirar NTLM? — Cómo obtener los registros de auditoría y el orden para eliminar dependencias
• NTLM y Kerberos explicados con diagramas — por qué la autenticación «cae» a NTLM
• Trampas de las unidades de red y las rutas UNC — cómo tratar el servidor de archivos (carpeta compartida) en aplicaciones de negocio
• Cómo consultar registros de eventos en la práctica con Get-WinEvent — la rapidez del filtrado determina el tiempo de investigación
• Soluciones realistas tras el fin de soporte de Windows 10 — tabla de decisión entre ESU, LTSC y renovación
• Lista de comprobación mínima de seguridad para aplicaciones de Windows

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa de la adaptación de aplicaciones de negocio derivada de la aplicación obligatoria de la firma SMB y LDAP, así como de la investigación de fallos de conexión relacionados con la autenticación y el uso compartido de archivos.

• Desarrollo de aplicaciones de Windows
• Investigación de errores y análisis de causas
• Aprovechamiento de activos existentes y apoyo a la 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.

¿Hacer obligatoria la firma SMB ralentiza el servidor de archivos?

El costo de cálculo de la firma no es cero, pero el algoritmo ha mejorado en cada generación. Frente al MD5 de SMB1, SMB 2.02 pasó a HMAC-SHA-256 y SMB 3.0 a AES-CMAC, y en Windows Server 2022 y Windows 11 se incorporó la aceleración de firma mediante AES-128-GMAC. Además, los controladores de dominio llevan mucho tiempo exigiendo firma SMB a todo el que se conecta a SYSVOL y NETLOGON, de modo que la distribución de directiva de grupo siempre ha funcionado bajo el supuesto de la firma. Antes de descartar la opción por motivos de rendimiento, se recomienda activar la obligatoriedad en equipos piloto y medir el impacto real. La diferencia perceptible se concentra en usos concretos, como la transferencia continua de archivos de gran tamaño.

Tras actualizar a Windows 11 24H2 dejé de poder conectarme al NAS. ¿Es por la firma SMB?

Típicamente esa es la causa. En Windows 11 versión 24H2, las ediciones Enterprise, Pro y Education hacen obligatoria de forma predeterminada la firma SMB tanto en el envío como en la recepción, de modo que al conectarse a un NAS de terceros que no admite firma (o la tiene deshabilitada) falla con 0xc000a000 (STATUS_INVALID_SIGNATURE). Además, como la obligatoriedad de la firma va acompañada de la deshabilitación del acceso de invitado, un NAS configurado para usarse sin autenticación mostrará un error del tipo «esta carpeta compartida no se puede usar porque la directiva de seguridad de la organización bloquea el acceso de invitado no autenticado». La primera medida es habilitar la firma SMB en el propio NAS y conectarse con credenciales en lugar de como invitado. También existe la opción de deshabilitar en el cliente la exigencia de firma, pero eso solo resuelve el lado del error de firma. El bloqueo de la conexión de invitado obedece a otra configuración del cliente (la prohibición de inicio de sesión de invitado inseguro) y seguirá fallando mientras no se relaje también esa opción. Microsoft no recomienda ni deshabilitar la firma ni operar mediante invitado.

¿Cuál es la diferencia entre la firma LDAP y LDAPS (LDAP sobre SSL/TLS)?

Son cosas distintas. La firma LDAP es un mecanismo que exige verificación de integridad (firma) en los bind SASL (Negotiate, Kerberos, NTLM, Digest) realizados sobre una conexión LDAP en el puerto 389, y no cifra la comunicación. LDAPS es el mecanismo que cifra toda la conexión con SSL/TLS. Y el enlace de canal LDAP es una defensa adicional por encima de LDAPS: vincula la autenticación al canal TLS y así impide el ataque que consiste en «retransmitir solo las credenciales a otra conexión TLS distinta». Para proteger el controlador de dominio conviene pensar en un conjunto de tres medidas: dejar de permitir el bind simple en texto claro, exigir firma en los bind SASL y exigir la verificación del token de enlace de canal para la autenticación de Windows (bind SASL) sobre LDAPS. Tenga en cuenta que el bind simple, al no tener CBT, queda fuera del alcance de la verificación de enlace de canal, y que lo que protege al bind simple sobre LDAPS es el propio cifrado TLS.

¿En qué orden conviene ir cerrando estas medidas?

El orden auditar → corregir → forzar es el mismo que en la restricción de NTLM. Para SMB, primero se habilita la auditoría disponible desde Windows 11 24H2 en adelante que detecta a los interlocutores que no admiten firma, y así se identifican los equipos que no pueden firmar. Para LDAP, se revisa en el registro Directory Service del controlador de dominio el evento 2887 (recuento cada 24 horas de bind sin firmar) y, si aparecen recuentos, se ajusta la configuración de diagnóstico «16 LDAP Interface Events» a 2 para identificar a los clientes mediante el evento 2889. El enlace de canal se identifica de forma análoga con los eventos 3039 y 3040, y con los eventos de auditoría 3074 y 3075 añadidos en las actualizaciones a partir de 2023. Una vez corregidos todos los orígenes problemáticos, se pasa a hacer obligatoria la firma SMB, obligatoria la firma LDAP y se cambia el enlace de canal a Always. El único principio es no saltar directamente a la aplicación obligatoria.

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.