La autenticación AD utiliza dos protocolos principales: Kerberos y NTLM
NTLM
El proceso de certificación es el siguiente:
- El cliente genera un hash NTLM localmente, y el valor es el valor hash de la contraseña del usuario.
- El cliente envía el nombre de usuario al servidor de aplicaciones.
- El servidor de aplicaciones genera un valor aleatorio para el cliente, que normalmente se denomina nonce o desafío.
- el cliente cifra el nonce con hash NTLM y lo envía al servidor de aplicaciones.
- Tras recibirlo, el servidor de aplicaciones lo envía al servidor AD junto con el nombre de usuario y el nonce.
- AD genera un hash NTLM basado en la contraseña del usuario, cifra el nonce y luego compara el mensaje del cliente.
- Si los valores son los mismos, la autenticación pasa, y si son diferentes, la autenticación falla.
Kerberos
Términos clave:
- KDC: Centro de Distribución de Claves, que ofrece dos servicios: Servicio de Autenticación (AS) y Servicio de Emisión de Tickets (TGS). El dominio genera una cuenta de dominio llamada krbtgt para KDC, y TGT utiliza la contraseña para cifrado y descifrado. Cuando un usuario de dominio accede por primera vez, quiere que el AS se autentique y, tras pasar, el AS solicita a TGS que proporcione un ticket (TGT) al usuario del dominio.
- SPN: Nombre principal del servicio。 Además de las cuentas de usuario, las cuentas de AD también tienen cuentas de servicio. La aplicación también tendrá una cuenta de servicio asociada, que facilitará el acceso a recursos del servidor, como Exchange, SQL, IIS, etc. SPN es un servicio utilizado para asociar el servicio, habilitado por la aplicación, con la cuenta del servicio en AD.
Proceso de certificación:
1. Cuando un usuario de dominio inicia sesión, se envía una solicitud AS (AS_REQ) al DC, que contiene una marca de tiempo cifrada cifrada con el hash de la contraseña y el nombre de usuario del usuario.
2. Tras recibir la solicitud, el DC utiliza el hash del nombre de usuario y la contraseña del usuario para descifrarla. El DC responde una respuesta AS (AS_REP) al cliente, que incluye una clave de sesión y un TGT (Ticket Granting Ticket). La clave de sesión está cifrada con el hash de la contraseña del usuario. El TGT contiene la pertenencia al grupo, dominio, marca de tiempo, IP del cliente y clave de sesión. TGT también está cifrado, cifrado con la contraseña de la cuenta del servicio KDC, y el cliente no puede descifrarlo. (TGT es válido por defecto durante 10 horas, y las actualizaciones posteriores no requieren que el usuario vuelva a introducir la contraseña)
3. Cuando un usuario solicita un recurso en el dominio, se envía una Solicitud de Servicio de Concesión de Tickets (TGS_REQ), incluyendo el nombre de usuario, la marca de tiempo, el TGT y el SPN. Las marcas de tiempo y los nombres de usuario se cifran con una clave de sesión.
4. Tras recibir la solicitud, el KDC primero determina si hay un SPN en la solicitud, luego descifra el TGT, extrae la clave de sesión y la marca de tiempo en TGT, y utiliza la clave de sesión en el TGT para descifrar el nombre de usuario y la marca de tiempo cifrados. Realiza varias comprobaciones:
(1) La marca de tiempo descifrada por TGT debe ser válida. (Si ocurre un ataque de repetición, la marca de tiempo es inválida.) ）
(2) Si el nombre de usuario en el TGT es consistente con el nombre de usuario de la solicitud.
(3) Si la dirección IP en el TGT es la misma que la dirección IP de la solicitud.
La comprobación responderá al ServiceReply (TGS_REP) de Concesión de Tickets del cliente, que contiene el acceso autorizado del SPN, la nueva clave de sesión utilizada para el acceso entre el cliente y el SPN, y el nuevo ticket de servicio del Ticket de Servicio (incluyendo la nueva clave de sesión, nombre de usuario y grupo de usuarios). Tanto el SPN autorizado como la clave de sesión que accede al SPN están cifrados con la clave de sesión en TGT. El ticket de servicio se cifra con la contraseña de la cuenta de servicio SPN correspondiente.
1. Tras el proceso anterior, el usuario ha obtenido la clave de sesión y el ticket de servicio relacionados con el servicio de la aplicación. El usuario envía una Solicitud de Aplicación (AP_REQ) al servicio de aplicación, que contiene el nombre de usuario y la marca de tiempo, y se cifra con una clave de sesión.
2. El servicio de aplicación utiliza el hash de la contraseña de la cuenta de servicio para descifrar el ticket de servicio y extraer el usuario, el grupo de usuarios y la clave de sesión. Descifra el nombre de usuario y la marca de tiempo en la AP_REQ con la clave de sesión descifrada. AP_REQ Si es así, la solicitud se acepta y el servicio de aplicación asigna permisos basados en la información del grupo de usuarios en el ticket de servicio, y entonces el usuario puede acceder al servicio solicitado.
Dirección original:El inicio de sesión del hipervínculo es visible.
|
Publicado en 22/8/2023 19:16:28
|
|
|
|
