Autenticación de usuario NTLM en Windows


Resumen


En este artículo se describen los siguientes aspectos de la autenticación de usuario NTLM en Windows:
  • Almacenamiento de contraseñas en la base de datos de cuentas
  • Autenticación de usuario con el paquete de autenticación de MSV1_0
  • Autenticación de paso a través

Más información


Almacenamiento de contraseñas en la base de datos de cuentas

Los registros de usuario se almacenan en la base de datos del administrador de cuentas de seguridad (SAM) o de la base de datos de Active Directory. Cada cuenta de usuario está asociada a dos contraseñas: la contraseña compatible con LAN Manager y la contraseña de Windows. Cada contraseña se cifra y se almacena en la base de datos de SAM o en la base de datos de Active Directory. La contraseña compatible con LAN Manager es compatible con la contraseña que usa LAN Manager. Esta contraseña se basa en el conjunto de caracteres del fabricante de equipos originales (OEM). Esta contraseña no distingue entre mayúsculas y minúsculas y puede tener hasta 14 caracteres. La versión OWF de esta contraseña también se conoce como la versión OWF o ESTD de LAN Manager. Esta contraseña se calcula con el cifrado DES para cifrar una constante con la contraseña de texto no cifrado. La contraseña de LAN Manager OWF es de 16 bytes. Los primeros 7 bytes de la contraseña de texto sin cifrar se usan para calcular los primeros 8 bytes de la contraseña OWF de LAN Manager. Los segundos 7 bytes de la contraseña de texto sin cifrar se usan para repartir los segundos 8 bytes de la contraseña OWF de LAN Manager. La contraseña de Windows se basa en el conjunto de caracteres Unicode. Esta contraseña distingue mayúsculas de minúsculas y puede tener hasta 128 caracteres. La versión OWF de esta contraseña también se conoce como la contraseña OWF de Windows. Esta contraseña se calcula con el algoritmo de cifrado RSA MD-4. Este algoritmo calcula un resumen de 16 bytes de una cadena de longitud variable de bytes de contraseña de texto no cifrado. Es posible que cualquier cuenta de usuario carezca de la contraseña de LAN Manager o de Windows. Sin embargo, cada intento de mantener ambas versiones de la contraseña. Por ejemplo, si la cuenta de usuario se ha trasladado desde una base de datos UAS de LAN Manager mediante PortUas, o si la contraseña se cambia desde un cliente de LAN Manager o desde un cliente de Windows para trabajo en grupo, solo existirá la versión de LAN Manager de la contraseña. Si la contraseña está configurada o cambiada en un cliente de Windows y la contraseña no tiene una representación de LAN Manager, solo existirá la versión de Windows de la contraseña. (Es posible que la contraseña no tenga una representación de LAN Manager porque la contraseña tiene más de 14 caracteres o que los caracteres no se pueden representar en el conjunto de caracteres OEM). Los límites de la interfaz de usuario de Windows no permiten que las contraseñas de Windows superen los 14 caracteres. Las implicaciones de esta limitación se tratan más adelante en este artículo. En el Service Pack 2 de Windows 2000 y en versiones posteriores de Windows, hay disponible una configuración que le permite impedir que Windows almacene un hash de LAN Manager de su contraseña. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
299656 Cómo impedir que Windows almacene un hash de LAN Manager de su contraseña en Active Directory y en bases de datos de SAM locales
Nota: Microsoft no admite la modificación manual o manual de la base de datos de SAM.

Autenticación de usuario con el paquete de autenticación de MSV1_0

Windows usa la API LsaLogonUser para todos los tipos de autenticaciones de usuario. La API de LsaLogonUser autentica a los usuarios llamando a un paquete de autenticación. De forma predeterminada, LsaLogonUser llama al paquete de autenticación MSV1_0 (MSV). Este paquete está incluido en Windows NT. El paquete de autenticación MSV almacena los registros de usuario en la base de datos SAM. Este paquete admite la autenticación de paso a través de los usuarios de otros dominios mediante el servicio NetLogon. Internamente, el paquete de autenticación MSV se divide en dos partes. La primera parte del paquete de autenticación MSV se ejecuta en el equipo en el que se está conectando. La segunda parte se ejecuta en el equipo que contiene la cuenta de usuario. Cuando ambas partes se ejecutan en el mismo equipo, la primera parte del paquete de autenticación MSV llama a la segunda parte sin involucrar al servicio NetLogon. La primera parte del paquete de autenticación MSV reconoce que es necesaria la autenticación de paso a través porque el nombre de dominio que se pasa no es su propio nombre de dominio. Cuando se requiere la autenticación de paso a través, MSV pasa la solicitud al servicio NetLogon. A continuación, el servicio NetLogon enruta la solicitud al servicio Netlogon en el equipo de destino. A su vez, el servicio NetLogon pasa la solicitud a la otra parte del paquete de autenticación MSV en ese equipo. LsaLogonUser admite inicios de sesión interactivos, inicios de sesión de servicio y inicios de sesión de red. En el paquete de autenticación MSV, todas las formas de inicio de sesión pasan el nombre de la cuenta de usuario, el nombre del dominio que contiene la cuenta de usuario y alguna función de la contraseña del usuario. Los distintos tipos de inicio de sesión representan la contraseña de forma diferente cuando la pasan a LsaLogonUser. para los inicios de sesión interactivos, los inicios de sesión por lotes y los inicios de sesión de servicio, el cliente de inicio de sesión se encuentra en el equipo que ejecuta la primera parte del paquete de autenticación MSV. En este caso, la contraseña de texto no cifrado se pasa a LsaLogonUser y a la primera parte del paquete de autenticación MSV. Para los inicios de sesión de servicio y de lotes, el administrador de control de servicios y el programador de tareas proporcionan una manera más segura de almacenar las credenciales de la cuenta. La primera parte del paquete de autenticación MSV convierte la contraseña de texto no cifrado en una contraseña OWF de LAN Manager y en una contraseña OWF de Windows NT. Después, la primera parte del paquete pasa la contraseña de texto no cifrado al servicio NetLogon o a la segunda parte del paquete. La segunda parte consulta la base de datos de SAM para las contraseñas OWF y se asegura de que sean idénticas. En el caso de los inicios de sesión en la red, el cliente que se conecta al equipo ya tenía un desafío de 16 bytes o "nonce". Si el cliente es un cliente de LAN Manager, el cliente calculó una respuesta de desafío de 24 bytes mediante el cifrado del desafío de 16 bytes con la contraseña OWF de 16 bytes de LAN Manager. Después, el cliente de LAN Manager pasa esta "respuesta de desafío de LAN Manager" al servidor. Si el cliente es un cliente de Windows, se calcula una "respuesta de desafío de Windows NT" usando el mismo algoritmo. Sin embargo, el cliente de Windows usa los datos de 16 bytes de Windows OWF, en lugar de los datos OWF de LAN Manager. Después, el cliente de Windows aprueba la respuesta de desafío de LAN Manager y la respuesta de desafío de Windows NT para el servidor. En cualquiera de los casos, el servidor autentica al usuario pasando todo lo siguiente a la API de LsaLogonUser:
  • El nombre de dominio
  • El nombre de usuario
  • El desafío original
  • Respuesta de desafío de LAN Manager
  • La respuesta de desafío de Windows NT opcional
La primera parte del paquete de autenticación MSV pasa esta información sin cambios a la segunda parte. En primer lugar, la segunda parte consulta las contraseñas OWF de la base de datos de SAM o de la base de datos de Active Directory. Después, la segunda parte calcula la respuesta de desafío mediante la contraseña OWF de la base de datos y el desafío que se ha pasado. La segunda parte compara la respuesta de desafío calculada con la respuesta de desafío aprobada.Nota NTLMv2 también permite que el cliente envíe un reto junto con el uso de claves de sesión que ayudan a reducir el riesgo de ataques comunes. Como se mencionó anteriormente, es posible que no se encuentre la versión de la contraseña de la base de datos SAM o de la base de datos de Active Directory. Además, puede que cualquiera de las versiones de la contraseña no se encuentre en la llamada a LsaLogonUser. Si tanto la versión de Windows de la contraseña de la base de datos de SAM como la de Windows de LsaLogonUser están disponibles, se usan ambas. De lo contrario, se usa la versión de LAN Manager de la contraseña para la comparación. Esta regla ayuda a exigir la distinción entre mayúsculas y minúsculas cuando se producen inicios de sesión desde Windows a Windows. Esta regla también permite la compatibilidad con versiones anteriores.

Autenticación de paso a través

El servicio NetLogon implementa la autenticación de paso a través. Realiza las siguientes funciones:
  • Selecciona el dominio al que se va a pasar la solicitud de autenticación.
  • Selecciona el servidor del dominio.
  • Pasa la solicitud de autenticación a través del servidor seleccionado.
La selección del dominio es sencilla. El nombre de dominio se pasa a LsaLogonUser. El nombre de dominio se procesa de la siguiente manera:
  • Si el nombre de dominio coincide con el nombre de la base de datos de SAM, la autenticación se procesa en ese equipo. En una estación de trabajo de Windows que es miembro de un dominio, se considera que el nombre de la base de datos SAM es el nombre del equipo. En un controlador de dominio de Active Directory, el nombre de la base de datos de la cuenta es el nombre del dominio. En un equipo que no es miembro de un dominio, todos los inicios de sesión procesan solicitudes de forma local.
  • Si el nombre de dominio especificado es de confianza para este dominio, la solicitud de autenticación pasa por el dominio de confianza. En los controladores de dominio de Active Directory, la lista de dominios de confianza es fácilmente disponible. En un miembro de un dominio de Windows, la solicitud siempre se transfiere al dominio principal de la estación de trabajo, lo que permite que el dominio principal determine si el dominio especificado es de confianza.
  • Si el nombre de dominio especificado no es de confianza para el dominio, la solicitud de autenticación se procesa en el equipo conectado como si el nombre de dominio especificado fuera ese nombre de dominio. NetLogon no diferencia entre un dominio inexistente, un dominio que no es de confianza y un nombre de dominio con nombre incorrecto.
NetLogon selecciona un servidor en el dominio mediante un proceso denominado descubrimiento. Una estación de trabajo de Windows detecta el nombre de uno de los controladores de dominio de Windows Active Directory en su dominio principal. Un controlador de dominio de Active Directory detecta el nombre de un controlador de dominio de Active Directory en cada dominio de confianza. El componente que hace la detección es el ubicador de DC que se ejecuta en el servicio NetLogon. El ubicador de DC usa la resolución de nombres NETBIOS o DNS para ubicar los servidores necesarios, según el tipo de dominio y confianza configurados.