En una red de Windows , NT (New Technology) LAN Manager ( NTLM ) es un conjunto de protocolos de seguridad de Microsoft destinados a proporcionar autenticación, integridad y confidencialidad a los usuarios. [1] [2] [3] NTLM es el sucesor del protocolo de autenticación en Microsoft LAN Manager (LANMAN), un producto de Microsoft más antiguo. El conjunto de protocolos NTLM se implementa en un proveedor de soporte de seguridad , que combina el protocolo de autenticación LAN Manager, los protocolos de sesión NTLMv1, NTLMv2 y NTLM2 en un solo paquete. El hecho de que estos protocolos se utilicen o se puedan utilizar en un sistema se rige por la Política de grupo. configuraciones, para las cuales las diferentes versiones de Windows tienen diferentes configuraciones predeterminadas.
Las contraseñas NTLM se consideran débiles porque se pueden forzar bruta muy fácilmente con hardware moderno. [4]
Protocolo
NTLM es un protocolo de autenticación de desafío-respuesta que utiliza tres mensajes para autenticar a un cliente en un entorno orientado a la conexión (sin conexión es similar) y un cuarto mensaje adicional si se desea integridad. [5] [6] [7] [8]
- Primero, el cliente establece una ruta de red al servidor y envía un NEGOTIATE_MESSAGE anunciando sus capacidades. [9]
- A continuación, el servidor responde con CHALLENGE_MESSAGE que se utiliza para establecer la identidad del cliente. [10]
- Finalmente, el cliente responde al desafío con un AUTHENTICATE_MESSAGE. [11]
El protocolo NTLM utiliza uno o ambos de dos valores de contraseña hash, los cuales también se almacenan en el servidor (o controlador de dominio), y que debido a la falta de salazón son contraseñas equivalentes , lo que significa que si obtiene el valor hash del servidor , puede autenticarse sin conocer la contraseña real. Los dos son el hash LM (una función basada en DES que se aplica a los primeros 14 caracteres de la contraseña convertida al juego de caracteres de PC de 8 bits tradicional para el idioma) y el hash NT ( MD4 de la contraseña Unicode UTF-16 de little endian ). Ambos valores hash tienen 16 bytes (128 bits) cada uno. [12]
El protocolo NTLM también utiliza una de las dos funciones unidireccionales , según la versión de NTLM; NT LanMan y NTLM versión 1 utilizan la función unidireccional LanMan basada en DES (LMOWF), mientras que NTLMv2 utiliza la función unidireccional basada en NT MD4 (NTOWF). [12] [13]
NTLMv1
El servidor autentica al cliente enviando un número aleatorio de 8 bytes, el desafío. El cliente realiza una operación que involucra el desafío y un secreto compartido entre el cliente y el servidor, específicamente uno de los dos hashes de contraseña descritos anteriormente. El cliente devuelve el resultado de 24 bytes del cálculo. De hecho, en NTLMv1 los cálculos se suelen realizar utilizando ambos hashes y se envían ambos resultados de 24 bytes. El servidor verifica que el cliente ha calculado el resultado correcto y de ello infiere la posesión del secreto y, por tanto, la autenticidad del cliente.
Ambos hash producen cantidades de 16 bytes. Se agregan cinco bytes de ceros para obtener 21 bytes. Los 21 bytes están separados en tres cantidades de 7 bytes (56 bits). Cada una de estas cantidades de 56 bits se utiliza como clave para cifrar DES el desafío de 64 bits. Los tres cifrados del desafío se reúnen para formar la respuesta de 24 bytes. Tanto la respuesta que usa el hash LM como el hash NT se devuelven como respuesta, pero esto es configurable.
C = desafío del servidor de 8 bytes, aleatorioK1 | K2 | K3 = NTLM-Hash | 5 bytes 0respuesta = DES (K1, C) | DES (K2, C) | DES (K3, C)
NTLMv2
NTLMv2, introducido en Windows NT 4.0 SP4, [14] es un protocolo de autenticación de desafío-respuesta. Está diseñado como un reemplazo criptográficamente reforzado para NTLMv1.
NTLM versión 2 (NTLMv2), que se introdujo en Windows NT 4.0 SP4 (y se soportó de forma nativa en Windows 2000), mejora la seguridad de NTLM fortaleciendo el protocolo contra muchos ataques de suplantación de identidad y agregando la capacidad de que un servidor se autentique ante el cliente. [1] [15] [16]
NTLMv2 envía dos respuestas a un desafío de servidor de 8 bytes . Cada respuesta contiene un hash HMAC - MD5 de 16 bytes del desafío del servidor, un desafío del cliente generado total o parcialmente al azar y un hash HMAC-MD5 de la contraseña del usuario y otra información de identificación. Las dos respuestas difieren en el formato del desafío del cliente. La respuesta más corta utiliza un valor aleatorio de 8 bytes para este desafío. Para verificar la respuesta, el servidor debe recibir como parte de la respuesta el desafío del cliente. Para esta respuesta más corta, el desafío del cliente de 8 bytes adjunto a la respuesta de 16 bytes crea un paquete de 24 bytes que es consistente con el formato de respuesta de 24 bytes del protocolo NTLMv1 anterior. En cierta documentación no oficial (por ejemplo, DCE / RPC sobre SMB, Leighton) esta respuesta se denomina LMv2.
La segunda respuesta enviada por NTLMv2 usa un desafío de cliente de longitud variable que incluye (1) la hora actual en formato NT Time , (2) un valor aleatorio de 8 bytes (CC2 en el cuadro a continuación), (3) el nombre de dominio y (4) algunas cosas de formato estándar. La respuesta debe incluir una copia de este desafío del cliente y, por lo tanto, es de longitud variable. En la documentación no oficial, esta respuesta se denomina NTv2.
Tanto LMv2 como NTv2 codifican el desafío del cliente y del servidor con el hash NT de la contraseña del usuario y otra información de identificación. La fórmula exacta es comenzar con el hash NT, que se almacena en el SAM o AD, y continuar con el hash usando HMAC - MD5 , el nombre de usuario y el nombre de dominio. En el cuadro siguiente, X representa el contenido fijo de un campo de formato.
SC = desafío del servidor de 8 bytes, aleatorioCC = desafío de cliente de 8 bytes, aleatorioCC * = (X, hora, CC2, nombre de dominio)v2-Hash = HMAC-MD5 (NT-Hash, nombre de usuario, nombre de dominio)LMv2 = HMAC-MD5 (v2-Hash, SC, CC)NTv2 = HMAC-MD5 (v2-Hash, SC, CC *)respuesta = LMv2 | CC | NTv2 | CC *
Sesión NTLM2
El protocolo de sesión NTLM2 es similar a MS-CHAPv2. [17] Consiste en la autenticación de NTLMv1 combinada con la seguridad de sesión de NTLMv2.
Brevemente, se aplica el algoritmo NTLMv1, excepto que se agrega un desafío de cliente de 8 bytes al desafío de servidor de 8 bytes y un hash MD5. La mitad de al menos 8 bytes del resultado hash es el desafío utilizado en el protocolo NTLMv1. El desafío del cliente se devuelve en un intervalo de 24 bytes del mensaje de respuesta, la respuesta calculada de 24 bytes se devuelve en el otro intervalo.
Esta es una forma reforzada de NTLMv1 que mantiene la capacidad de utilizar la infraestructura del controlador de dominio existente, pero evita un ataque de diccionario por parte de un servidor deshonesto. Para una X fija , el servidor calcula una tabla donde la ubicación Y tiene un valor K tal que Y = DES_K (X) . Sin que el cliente participa en la elección del desafío, el servidor puede enviar X , buscar la respuesta Y en la tabla y obtener K . Este ataque se puede hacer práctico mediante el uso de tablas de arcoíris . [18]
Sin embargo, la infraestructura NTLMv1 existente permite que el servidor no verifique el par desafío / respuesta, sino que lo envíe a un controlador de dominio para su verificación. Con la sesión NTLM2, esta infraestructura continúa funcionando si el servidor sustituye el desafío por el hash del servidor y los desafíos del cliente.
NTLMv1 Cliente <-Servidor: SC Cliente-> Servidor: H (P, SC) Servidor-> DomCntl: H (P, SC), SC Servidor <-DomCntl: sí o noSesión NTLM2 Cliente <-Servidor: SC Cliente-> Servidor: H (P, H '(SC, CC)), CC Servidor-> DomCntl: H (P, H '(SC, CC)), H' (SC, CC) Servidor <-DomCntl: sí o no
Disponibilidad y uso de NTLM
Desde 2010, Microsoft ya no recomienda NTLM en aplicaciones: [19]
Los implementadores deben tener en cuenta que NTLM no admite ningún método criptográfico reciente, como AES o SHA-256. Utiliza comprobaciones de redundancia cíclica (CRC) o MD5 para la integridad y RC4 para el cifrado.
Derivar una clave a partir de una contraseña es como se especifica en RFC1320 y FIPS46-2. Por lo tanto, generalmente se recomienda a las aplicaciones que no utilicen NTLM.
A pesar de estas recomendaciones, NTLM todavía se implementa ampliamente en los sistemas. Una de las principales razones es mantener la compatibilidad con sistemas más antiguos. Sin embargo, se puede evitar en algunas circunstancias. [ ¿cómo? ]
Microsoft ha agregado el hash NTLM a su implementación del protocolo Kerberos para mejorar la interoperabilidad (en particular, el tipo de cifrado RC4-HMAC). Según un investigador independiente, esta decisión de diseño permite engañar a los controladores de dominio para que emitan a un atacante un ticket de Kerberos si se conoce el hash NTLM. [20] Microsoft adoptó Kerberos como el protocolo de autenticación preferido para Windows 2000 y los subsiguientes dominios de Active Directory. [16] Kerberos se utiliza normalmente cuando un servidor pertenece a un dominio de Windows Server . Microsoft recomienda a los desarrolladores que no utilicen Kerberos ni el Proveedor de soporte de seguridad (SSP) de NTLM directamente. [21]
Su aplicación no debe acceder directamente al paquete de seguridad NTLM; en su lugar, debería utilizar el paquete de seguridad Negotiate. Negotiate permite que su aplicación aproveche los protocolos de seguridad más avanzados si son compatibles con los sistemas involucrados en la autenticación. Actualmente, el paquete de seguridad Negotiate selecciona entre Kerberos y NTLM. Negotiate selecciona Kerberos a menos que no pueda ser utilizado por uno de los sistemas involucrados en la autenticación.
Uso del proveedor de soporte de seguridad NTLM
El NTLM SSP se utiliza en las siguientes situaciones:
- El cliente se está autenticando en un servidor que no pertenece a un dominio o no existe ningún dominio de Active Directory (comúnmente conocido como "grupo de trabajo" o "peer-to-peer")
- El servidor debe tener habilitada la función de "uso compartido protegido por contraseña", que no está habilitada de forma predeterminada y que es mutuamente excluyente con HomeGroup en algunas versiones de Windows.
- Cuando el servidor y el cliente pertenecen al mismo HomeGroup , se utilizará un protocolo similar a Kerberos, autenticación de usuario a usuario basada en criptografía de clave pública en lugar de NTLM. [22] HomeGroup es probablemente la forma más fácil de compartir recursos en una red pequeña, requiriendo una configuración mínima, incluso en comparación con la configuración de algunos usuarios adicionales para poder usar el uso compartido protegido por contraseña, lo que puede significar que se usa mucho más que una contraseña. uso compartido protegido en redes pequeñas y redes domésticas.
- Si el servidor es un dispositivo compatible con SMB , como dispositivos NAS e impresoras de red, es posible que NTLM SSP ofrezca el único método de autenticación compatible. Algunas implementaciones de SMB o distribuciones más antiguas de, por ejemplo, Samba pueden hacer que Windows negocie NTLMv1 o incluso LM para la autenticación saliente con el servidor SMB, lo que permite que el dispositivo funcione aunque puede estar cargado con software desactualizado e inseguro independientemente de si se trataba de un dispositivo nuevo. .
- Si el servidor es miembro de un dominio pero no se puede utilizar Kerberos .
- El cliente se está autenticando en un servidor utilizando una dirección IP (y no hay disponible una resolución de nombre inversa)
- El cliente se está autenticando en un servidor que pertenece a un bosque de Active Directory diferente que tiene una confianza NTLM heredada en lugar de una confianza transitiva entre bosques
- Donde un firewall restringiría de otra manera los puertos requeridos por Kerberos (típicamente TCP 88)
Uso de versiones de protocolo
Después de que el desarrollador de la aplicación o el SSP de negociación haya decidido que se utilizará el SSP de NTLM para la autenticación, la directiva de grupo dicta la capacidad de utilizar cada uno de los protocolos que implementa el SSP de NTLM. Hay cinco niveles de autenticación. [23]
- Envíe respuestas LM y NTLM : los clientes utilizan la autenticación LM y NTLM, y nunca utilizan la seguridad de sesión NTLMv2; Los controladores de dominio aceptan la autenticación LM, NTLM y NTLMv2.
- Enviar LM y NTLM: utilice la seguridad de sesión NTLMv2 si se negocia : los clientes utilizan la autenticación LM y NTLM, y la seguridad de sesión NTLMv2 si el servidor la admite; Los controladores de dominio aceptan la autenticación LM, NTLM y NTLMv2.
- Enviar solo respuesta NTLM : los clientes usan solo la autenticación NTLM y usan la seguridad de sesión NTLMv2 si el servidor lo admite; Los controladores de dominio aceptan la autenticación LM, NTLM y NTLMv2.
- Enviar solo respuesta NTLMv2 : los clientes usan solo la autenticación NTLMv2 y usan la seguridad de sesión NTLMv2 si el servidor lo admite; Los controladores de dominio aceptan la autenticación LM, NTLM y NTLMv2.
- Enviar solo respuesta NTLMv2 \ rechazar LM : Los clientes usan solo la autenticación NTLMv2 y usan la seguridad de sesión NTLMv2 si el servidor lo admite; Los DC rechazan LM (aceptan solo autenticación NTLM y NTLMv2).
- Enviar solo respuesta NTLMv2 \ rechazar LM y NTLM : los clientes usan solo la autenticación NTLMv2 y usan la seguridad de sesión NTLMv2 si el servidor lo admite; Los DC rechazan LM y NTLM (aceptan solo la autenticación NTLMv2).
DC significaría controlador de dominio, pero el uso de ese término es confuso. Cualquier computadora que actúe como servidor y autentique a un usuario cumple la función de DC en este contexto, por ejemplo, una computadora con Windows con una cuenta local como Administrador cuando esa cuenta se usa durante un inicio de sesión en la red.
Antes de Windows NT 4.0 Service Pack 4, el SSP negociaba NTLMv1 y recurría a LM si la otra máquina no lo admitía.
A partir de Windows NT 4.0 Service Pack 4, el SSP negociaría la sesión NTLMv2 siempre que tanto el cliente como el servidor lo admitieran. [24] Hasta Windows XP inclusive, esto utilizaba cifrado de 40 o 56 bits en computadoras fuera de los EE. UU., Ya que los Estados Unidos tenían restricciones severas sobre la exportación de tecnología de cifrado en ese momento. A partir de Windows XP SP3, el cifrado de 128 bits podría agregarse instalando una actualización y en Windows 7, el cifrado de 128 bits sería el predeterminado.
En Windows Vista y versiones posteriores, LM se ha deshabilitado para la autenticación entrante. Los sistemas operativos basados en Windows NT hasta Windows Server 2003 inclusive almacenan dos hash de contraseña, el hash de LAN Manager (LM) y el hash de Windows NT. A partir de Windows Vista , la capacidad de almacenar ambos está ahí, pero uno está desactivado de forma predeterminada. Esto significa que la autenticación LM ya no funciona si la computadora que ejecuta Windows Vista actúa como servidor. Las versiones anteriores de Windows (hasta Windows NT 4.0 Service Pack 4) podían configurarse para comportarse de esta manera, pero no era la predeterminada. [25]
Debilidades y vulnerabilidades
NTLM sigue siendo vulnerable al ataque pass the hash , que es una variante del ataque de reflexión que fue abordado por la actualización de seguridad de Microsoft MS08-068. Por ejemplo, Metasploit se puede usar en muchos casos para obtener credenciales de una máquina que se pueden usar para obtener el control de otra máquina. [3] [26] El kit de herramientas de Squirtle se puede utilizar para aprovechar los ataques de secuencias de comandos entre sitios web en ataques a activos cercanos a través de NTLM. [27]
En febrero de 2010, Amplia Security descubrió varias fallas en la implementación de Windows del mecanismo de autenticación NTLM que rompió la seguridad del protocolo permitiendo a los atacantes obtener acceso de lectura / escritura a archivos y ejecución remota de código. Uno de los ataques presentados incluyó la capacidad de predecir números pseudoaleatorios y desafíos / respuestas generados por el protocolo. Estos defectos habían estado presentes en todas las versiones de Windows durante 17 años. El aviso de seguridad que explica estos problemas incluía exploits de prueba de concepto totalmente funcionales. Todos estos defectos fueron corregidos por MS10-012. [28] [29]
En 2012, se demostró que cada posible permutación de hash de contraseña NTLM de 8 caracteres se puede descifrar en menos de 6 horas. [30]
En 2019, este tiempo se redujo a aproximadamente 2,5 horas mediante el uso de hardware más moderno. [4] [31] Además, las tablas Rainbow están disponibles para contraseñas NTLM de ocho y nueve caracteres. Las contraseñas más cortas se pueden recuperar mediante métodos de fuerza bruta. [32]
Tenga en cuenta que los hashes equivalentes a contraseñas que se utilizan en los ataques pass-the-hash y el descifrado de contraseñas primero deben ser "robados" (por ejemplo, comprometiendo un sistema con permisos suficientes para acceder a hashes). Además, estos hash no son los mismos que el "hash" NTLMSSP_AUTH transmitido a través de la red durante una autenticación NTLM convencional.
Compatibilidad con Linux
Las implementaciones de NTLM para Linux incluyen Cntlm [33] y winbind (parte de Samba ). [34] Estos permiten que las aplicaciones Linux utilicen proxies NTLM.
FreeBSD también admite el almacenamiento de contraseñas a través de Crypt (C) en la forma insegura NT-Hash. [35]
Ver también
- Administrador de LAN
- NTLMSSP
- Autenticación de Windows integrada
- Kerberos
Referencias
- ^ a b "Introducción" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) , Microsoft , consultado el 15 de agosto de 2010
- ^ a b "Detalles de seguridad de la sesión" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) , Microsoft , consultado el 15 de agosto de 2010
- ^ a b Takahashi, T (2009-12-17), "Reflecting on NTLM Reflection" , Blog de FrequencyX , IBM Internet System Security (ISS), archivado desde el original el 31 de diciembre de 2009 , consultado el 14 de agosto de 2010
- ^ a b Claburn, Thomas (14 de febrero de 2019). "¿Usar una contraseña de Windows NTLM de 8 caracteres? No lo haga. Cada uno puede descifrarse en menos de 2,5 horas" . www.theregister.co.uk . Consultado el 26 de noviembre de 2020 .
- ^ "Microsoft NTLM" , MSDN , Microsoft , consultado el 15 de agosto de 2010
- ^ "Sintaxis del mensaje | sección 2.2" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) , Microsoft , consultado el 15 de agosto de 2010
- ^ "Orientado a la conexión" , NT LAN Manager (NTLM) Especificación del protocolo (3.1.5.1 ed.), Microsoft , recuperada 2010-08-15
- ^ "Sin conexión" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) (3.1.5.2 ed.), Microsoft , consultado el 15 de agosto de 2010
- ^ "NEGOTIATE_MESSAGE" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) (2.2.1.1 ed.), Microsoft , consultado el 15 de agosto de 2010
- ^ "CHALLENGE_MESSAGE" , NT LAN Manager (NTLM) Especificación del protocolo (2.2.1.2 ed.), Microsoft , recuperada 2010-08-15
- ^ "AUTHENTICATE_MESSAGE" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) (2.2.1.3 ed.), Microsoft , consultado el 15 de agosto de 2010
- ^ a b "NTLM v1 Authentication" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) (3.3.1 ed.), Microsoft , consultado el 15 de agosto de 2010
- ^ "NTLM v2 Authentication" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) (3.3.1 ed.), Microsoft , consultado el 15 de agosto de 2010
- ^ ¿Qué hay de nuevo en el Service Pack 4 de Windows NT 4.0?
- ^ Cómo habilitar la autenticación NTLM 2 , Soporte, Microsoft, 2007-01-25 , consultado el 2010-08-14
- ^ a b "Configuración de seguridad" , Guía de refuerzo de seguridad de Microsoft Windows 2000 , TechNet, Microsoft , consultado el 14 de agosto de 2010
- ^ Glass, Eric, "NTLM", Davenport , Source forge
- ^ Varughese, Sam (febrero de 2006). "Rainbow Cracking y contraseña de seguridad" . Empalizada. Archivado desde el original el 1 de junio de 2010 . Consultado el 14 de agosto de 2010 .
- ^ "Consideraciones de seguridad para implementadores" , Especificación del protocolo de autenticación de NT LAN Manager (NTLM) , Microsoft , consultado el 16 de agosto de 2010
- ^ "Copia archivada" . Archivado desde el original el 6 de octubre de 2014 . Consultado el 5 de octubre de 2014 .CS1 maint: copia archivada como título ( enlace )
- ^ "Microsoft NTLM" . Biblioteca TechNet . Microsoft . Consultado el 2 de noviembre de 2015 .
- ^ "Resumen de autenticación de usuario a usuario basado en criptografía de clave pública" . Biblioteca TechNet . Microsoft . Consultado el 2 de noviembre de 2015 .
- ^ "Nivel de autenticación de LAN Manager" . Biblioteca de MSDN . Microsoft . Consultado el 2 de noviembre de 2015 .
- ^ "Autenticación de Windows" . Biblioteca TechNet . Microsoft. 29 de junio de 2011 . Consultado el 2 de noviembre de 2015 .
- ^ Jesper Johansson. "La configuración de seguridad de Windows más incomprendida de todos los tiempos" . Revista TechNet . Microsoft . Consultado el 2 de noviembre de 2015 .
- ^ HD Moore. "MS08-068: Metasploit y SMB Relay" .
- ^ Kurt Grutzmacher (8 de agosto de 2008). Clave el ataúd cerrado, NTLM ha muerto . Defcon 16.
- ^ Hernán Ochoa y Agustín Azubel (28-07-2010). Comprensión de la vulnerabilidad de Windows SMB NTLM Weak Nonce (PDF) . Blackhat USA 2010.
- ^ Hernán Ochoa y Agustín Azubel. "Aviso de seguridad de vulnerabilidad de Windows SMB NTLM Weak Nonce" .
- ^ Goodin, Dan (10 de diciembre de 2012). "El clúster de 25 GPU descifra todas las contraseñas estándar de Windows en <6 horas" . Ars Technica . Consultado el 23 de noviembre de 2020 .
- ^ hashcat (13 de febrero de 2019). "El hashcat 6.0.0 beta ajustado a mano y 2080Ti (relojes de valores) rompe la marca de velocidad de craqueo NTLM de 100GH / s en un solo dispositivo de cómputo" . @hashcat . Consultado el 26 de febrero de 2019 .
- ^ Un caso para el uso moderno de la mesa de arco iris
- ^ http://cntlm.sourceforge.net/
- ^ https://docs.moodle.org/32/en/NTLM_authentication#Using_the_NTLM_part_of_Samba_for_Apache_on_Linux
- ^ "Hash de contraseña NT MD4 como nuevo método de cifrado de contraseña para FreeBSD" . Mail-archive.com . Consultado el 2 de diciembre de 2018 .
enlaces externos
- Hash crack NTLM en línea usando tablas Rainbow
- Especificación del protocolo de autenticación de NT LAN Manager (NTLM)
- Cntlm: proxy de autenticación NTLM, NTLMSR, NTLMv2 y acelerador HTTP (S) personal y proxy SOCKS5 para aplicaciones que no reconocen NTLM (Windows / Linux / UNIX)
- Proveedor de soporte de seguridad y protocolo de autenticación NTLM Un análisis detallado del protocolo NTLM.
- Artículo de MSDN que explica el protocolo y que ha cambiado de nombre
- Página de MSDN sobre autenticación NTLM
- Libntlm : una implementación gratuita.
- Software de servidor proxy de autorización NTLM que permite a los usuarios autenticarse a través de un servidor proxy de MS.
- Instalación de la autenticación NTLM: instrucciones de configuración de NTLM para Samba y Midgard en Linux
- NTLM versión 2 (NTLMv2) y la configuración LMCompatibilityLevel que lo gobierna
- Jespa - Integración con Java Active Directory Proveedor de servicios de seguridad NTLM completo con validación NETLOGON del lado del servidor (comercial pero gratuito para hasta 25 usuarios)
- EasySSO - NTML Authenticator para JIRA NTLM Authenticator que utiliza la biblioteca Jespa para proporcionar IWA para productos Atlassian .
- ntlmv2-auth API NTLMv2 y filtro de servlet para Java
- Una herramienta generadora de mensajes ntlm
- WAFFLE - Marco de autenticación de Windows Java / C #
- objectif-securite (tablas arcoíris para ophcrack)
- Px para Windows : un servidor proxy HTTP para autenticarse automáticamente a través de un proxy NTLM