Autenticación de usuario NTLM en Windows


Resumen


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

Más información


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

Registros de usuario se almacenan en la base de security accounts manager (SAM) o en la base de datos de Active Directory. Cada cuenta de usuario está asociado con dos contraseñas: la contraseña compatible con LAN Manager y la contraseña de Windows. Cada contraseña está cifrada y almacenada en la base de datos SAM o en la base de datos de Active Directory.

La contraseña compatible con LAN Manager es compatible con la contraseña que se utiliza por LAN Manager. Esta contraseña se basa en el juego de caracteres de fabricante de equipos originales (OEM). Esta contraseña no distingue mayúsculas de minúsculas y puede tener hasta 14 caracteres. La versión OWF de esta contraseña es también conocida como la versión de LAN Manager OWF o ESTD. Esta contraseña se calcula utilizando el cifrado DES para cifrar una constante con la contraseña de texto sin cifrar. La contraseña de LAN Manager OWF tiene una longitud de 16 bytes. Los 7 primeros bytes de la contraseña de texto sin cifrar se utilizan para calcular los 8 primeros bytes de la contraseña de LAN Manager OWF. El segundo 7 bytes de la contraseña de texto sin cifrar se utilizan para la segunda 8 bytes de la contraseña de LAN Manager OWF del equipo.


La contraseña de Windows se basa en el juego 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 es también conocida como la contraseña de Windows OWF. Esta contraseña se calcula utilizando el algoritmo de cifrado RSA MD-4. Este algoritmo calcula una síntesis de 16 bytes de una cadena de longitud variable de bytes de la contraseña de texto sin cifrar.

Cualquier cuenta de usuario carece de la contraseña de LAN Manager o la contraseña de Windows. Sin embargo, cada intento se realiza para mantener ambas versiones de la contraseña. Por ejemplo, si la cuenta de usuario es trasladada desde una base de datos UAS LAN Manager utilizando PortUas, o si se cambia la contraseña desde un cliente de LAN Manager o desde un cliente Windows para trabajo en grupo, existirá sólo la versión de LAN Manager de la contraseña. Si la contraseña se establece o se cambia de un cliente de Windows y la contraseña no tiene ninguna representación de LAN Manager, existirá la versión de Windows de la contraseña. (La contraseña no puede tener ninguna representación de LAN Manager porque la contraseña es mayor de 14 caracteres o porque no se puede representar los caracteres en el juego de caracteres OEM). Límites de la interfaz de usuario de Windows no permiten las contraseñas de Windows tener más de 14 caracteres. Las implicaciones de esta limitación se describen más adelante en este artículo.

En Windows 2000 Service Pack 2 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 administrador de LAN de su contraseña en Active Directory y bases de datos locales de SAM

Nota: Microsoft no admite la modificación de la base de datos de SAM de manualmente o mediante programación.

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

Windows utiliza la API LsaLogonUser para todo tipo de autenticaciones de usuario. La API LsaLogonUser autentica a los usuarios mediante una llamada a un paquete de autenticación. De manera predeterminada, LsaLogonUser llama el paquete de autenticación MSV1_0 (MSV). Este paquete se incluye con Windows NT. El MSV autenticación paquete almacena registros de usuario en la base de datos SAM. Este paquete permite la autenticación transferida 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 que está conectado. La segunda parte se ejecuta en el equipo que contiene la cuenta de usuario. Cuando ambas piezas se ejecutan en el mismo equipo, la primera parte del paquete de autenticación MSV llama a la segunda parte sin involucrar el servicio Netlogon. La primera parte del paquete de autenticación MSV reconoce que la autenticación de paso a través es necesaria 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. 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 los inicios de sesión de red. En el paquete de autenticación MSV, todos los formularios 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 pasen a LsaLogonUser.

Para 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 está en el equipo que está ejecutando la primera parte del paquete de autenticación MSV. En este caso, se pasa la contraseña de texto sin cifrar a LsaLogonUser a la primera parte del paquete de autenticación MSV. Para los inicios de sesión de servicio y los inicios de sesión por lotes, el Administrador de Control de servicios y el programador de tareas proporcionan una forma 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 simple a una contraseña de LAN Manager OWF y a una contraseña de Windows NT OWF. A continuación, la primera parte del paquete pasa la contraseña de texto sin cifrar al servicio NetLogon o a la segunda parte del paquete. La segunda parte, a continuación, consulta la base de datos de SAM para las contraseñas OWF y se asegura de que son idénticas.

Para inicios de sesión de red, el cliente que se conecta al equipo fue remitido previamente a un desafío de 16 bytes o "nonce". Si el cliente es un cliente de LAN Manager, el cliente calcula un desafío de 24 bytes de respuesta cifrando el desafío de 16 bytes con la contraseña de LAN Manager OWF de 16 bytes. El cliente de LAN Manager, a continuación, pasa esto "Respuesta de desafío de LAN Manager" en el servidor. Si el cliente es un cliente de Windows, se calcula utilizando el mismo algoritmo de "Respuesta de desafío de Windows NT". Sin embargo, el cliente de Windows utiliza los datos de Windows OWF de 16 bytes en lugar de los datos de LAN Manager OWF. El cliente de Windows, a continuación, pasa la respuesta de desafío de LAN Manager y la respuesta de desafío de Windows NT en el servidor. En cualquier caso, el servidor autentica al usuario pasando la API LsaLogonUser todo lo siguiente:
  • El nombre de dominio
  • El nombre de usuario
  • El desafío original
  • La 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 cambiar a la segunda parte. En primer lugar, la segunda parte consulta las contraseñas OWF desde la base de datos SAM o desde la base de datos de Active Directory. A continuación, la segunda parte calcula la respuesta de desafío mediante la contraseña OWF desde la base de datos y el reto que se pasó. La segunda parte, a continuación, compara la respuesta de desafío calculada a la respuesta de desafío en el pasado.

Nota: NTLMv2 también permite que el cliente envía un desafío junto con el uso de claves de sesión que ayudan a reducir el riesgo de ataques comunes.

Como se mencionó anteriormente, cualquier versión de la contraseña puede perderse desde la base de datos SAM o desde la base de datos de Active Directory. Además, ambas versiones de la contraseña puedan faltar en la llamada a LsaLogonUser. Si la versión de Windows de la contraseña de la base de datos SAM y la versión de Windows de la contraseña de LsaLogonUser están disponibles, se utilizan. De lo contrario, la versión de LAN Manager de la contraseña se utiliza para la comparación. Esta regla ayuda a exigir entre mayúsculas y minúsculas cuando se producen los inicios de sesión de red de Windows a Windows. Esta regla también permite 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 para pasar la solicitud de autenticación.
  • Selecciona el servidor dentro del dominio.
  • Pasa a través de la solicitud de autenticación al servidor seleccionado.
Seleccionar el dominio es sencillo. El nombre de dominio se pasa a LsaLogonUser. El nombre de dominio se procesa como sigue:
  • Si el nombre de dominio coincide con el nombre de la base de datos de SAM, se procesa la autenticación en el equipo. En una estación de trabajo Windows que sea miembro de un dominio, el nombre de la base de datos SAM se considera 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 localmente.
  • Si el nombre de dominio es de confianza para este dominio, la solicitud de autenticación se pasa al dominio de confianza. En controladores de dominio de Active Directory, la lista de dominios de confianza está fácilmente disponible. En un miembro de un dominio de Windows, siempre se pasa la solicitud a través del dominio principal de la estación de trabajo, permitir que el dominio principal a determinar si el dominio especificado es de confianza.
  • Si el nombre de dominio especificado no es de confianza por el dominio, se procesa la solicitud de autenticación en el equipo al que está conectado, como si el nombre de dominio especificado fuera ese nombre de dominio. NetLogon no distingue entre un dominio inexistente, un dominio de confianza y un nombre de dominio escrito incorrectamente.
NetLogon selecciona un servidor en el dominio mediante un proceso denominado descubrimiento. Una estación de trabajo Windows descubre el nombre de uno de los controladores de dominio de Active Directory de Windows en su dominio principal. Un controlador de dominio de Active Directory descubre el nombre de un controlador de dominio de Active Directory en cada dominio de confianza. El componente que realiza la detección es el ubicador de DC se ejecuta en el servicio Netlogon. El ubicador de DC utiliza resolución de nombres NETBIOS o DNS para localizar los servidores necesarios, dependiendo del tipo de dominio y de confianza que está configurado.