Compartir a través de

Descripción de la autenticación de Active Directory para SQL Server en Linux y contenedores

  • Artículo

Se aplica a: SQL Server - Linux

En este artículo se proporcionan detalles sobre cómo funciona la autenticación de Active Directory para SQL Server implementado en Linux o contenedores.

Conceptos

Protocolo ligero de acceso a directorios (LDAP)

LDAP es un protocolo de aplicación para trabajar con varios servicios de directorio, incluido Active Directory. Los servicios de directorio almacenan información de usuarios y cuentas, e información de seguridad, como contraseñas. Esa información se cifra y, a continuación, se comparte con otros dispositivos de la red.

Para más información sobre la protección de LDAP, consulte Cómo habilitar las firmas LDAP en Windows Server.

Kerberos

Kerberos es un protocolo de autenticación que se utiliza para comprobar la identidad de un equipo host o del usuario. Puede considerarlo como una manera de comprobar el cliente y el servidor.

Cuando se trabaja en un entorno heterogéneo (mixto) en el que tiene servidores y clientes Windows y no Windows, hay dos tipos de archivos que necesita para trabajar con servicios de directorio basados en Active Directory:

  • Archivos keytab (abreviatura de "key tables")
  • Archivos de configuración de Kerberos (krb5.conf o krb5.ini)

¿Qué es un archivo keytab?

Los procesos de servidor en sistemas Linux o Unix no se pueden configurar para ejecutar procesos con una cuenta de servicio de Windows. Si desea que un sistema Linux o Unix inicie sesión automáticamente en Active Directory durante el inicio, debe usar un archivo keytab.

Un archivo keytab es un archivo criptográfico que contiene una representación de un servicio protegido por Kerberos y su clave a largo plazo de su nombre de entidad de seguridad de servicio asociado en el Centro de distribución de claves (KDC). La clave no es la propia contraseña.

Los archivos keytab se usan para:

  • autenticar el propio servicio en otro servicio de la red o
  • descifrar el vale de servicio Kerberos de un usuario del directorio de entrada en el servicio.

¿Qué es un archivo krb5.conf?

El archivo /etc/krb5.conf (también denominado krb5.ini) proporciona entradas de configuración para las bibliotecas de Kerberos v5 (KRB5) y de API de Nivel de seguridad y autenticación simples GNU (GSSAPI).

Esta información incluye el dominio predeterminado, las propiedades de cada dominio (como los Centros de distribución de claves) y la duración de vale Kerberos predeterminada.

Este archivo es necesario para que funcione la autenticación de Active Directory. krb5.conf es un archivo INI, pero cada valor del par clave-valor puede ser un subgrupo delimitado por { y }.

Para obtener más información sobre el archivo krb5.conf, consulte la Documentación de Kerberos del MIT.

Configuración de Kerberos para SQL Server en Linux

Estos son los valores que necesita en el servidor host que ejecuta SQL Server en Linux. Si tiene otros servicios (que no son SQL Server) que se ejecutan en el mismo host, es posible que el archivo krb5.conf necesite varias entradas más.

Este es un archivo krb5.conf de ejemplo de referencia:

[libdefaults]
default_realm = CONTOSO.COM

[realms]
CONTOSO.COM = {
  kdc = adVM.contoso.com
  admin_server = adVM.contoso.com
  default_domain = contoso.com
}

[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM

  • libdefaults: el valor default_realm debe estar presente. Este valor especifica el dominio al que pertenece el equipo host.

  • realms (opcional): para cada dominio, se puede establecer el valor kdc para especificar con qué Centros de distribución de claves debe ponerse en contacto el equipo al buscar cuentas de Active Directory. Si ha establecido más de un KDC, el KDC de cada conexión se seleccionará mediante round robin.

  • domain_realm (opcional): se pueden proporcionar asignaciones para cada dominio kerberos. Si no es así, SQL Server en Linux da por sentado que el dominio contoso.com se asigna al dominio kerberos CONTOSO.COM.

Proceso de autenticación Kerberos

Al igual que con la autenticación Kerberos en Windows, los dos primeros pasos para obtener un vale de concesión de vales (TGT) son los mismos:

  • Un cliente comienza el proceso de inicio de sesión enviando su nombre de usuario y contraseña (cifrada) al controlador de dominio (DC).

  • Después de comprobar el nombre de usuario y la contraseña en su almacenamiento interno, el controlador de dominio devuelve un TGT para el usuario al cliente.

SQL Server en Linux usa el archivo keytab para leer la contraseña del nombre de entidad de seguridad de servicio (SPN) y, a continuación, descifra el blob cifrado, que usa para autorizar la conexión. En los pasos siguientes se describe este proceso.

  • Una vez que el usuario tiene el TGT, el cliente inicia una conexión a SQL Server especificando el nombre de host y el puerto de la instancia de SQL Server.

  • El cliente SQL crea internamente un nombre de entidad de seguridad de servicio con el formato MSSQLSvc/<host>:<port>. Se trata de un formato codificado de forma rígida en la mayoría de los clientes de SQL Server.

  • El cliente inicia el protocolo de enlace de Kerberos solicitando una clave de sesión del controlador de dominio para ese SPN. Tanto el TGT como el SPN se envían al controlador de dominio.

Diagrama que muestra la autenticación de Active Directory para SQL Server en Linux: vale de concesión de vales y nombre de entidad de seguridad de servicio enviados al controlador de dominio.

  • Una vez que el controlador de dominio valida el TGT y el SPN, envía la clave de sesión al cliente para conectarse al SPN de SQL Server.

Diagrama que muestra la autenticación de Active Directory para SQL Server en Linux: clave de sesión devuelta al cliente por el controlador de dominio.

  • El blob cifrado de la clave de sesión se envía al servidor.

Diagrama que muestra la autenticación de Active Directory para SQL Server en Linux: clave de sesión enviada al servidor.

  • SQL Server lee la contraseña del SPN desde su archivo keytab (mssql.keytab), que es un archivo en disco que contiene tuplas cifradas (SPN, contraseña).

  • SQL Server descifra el blob cifrado del cliente con la contraseña que acaba de buscar, para obtener el nombre de usuario del cliente.

  • SQL Server busca el cliente en la tabla sys.syslogins para comprobar si el cliente tiene autorización para conectarse.

  • La conexión se acepta o se deniega.

Diagrama que muestra la autenticación de Active Directory para SQL Server en Linux: conexión aceptada o denegada.

Configuración de Kerberos para contenedores de SQL Server

La autenticación de Active Directory para SQL Server en contenedores es esencialmente la misma que para SQL Server en Linux. La única diferencia es el SPN de host de SQL Server. En el escenario anterior, el SPN era MSSQLSvc/<host>:<port>, puesto que nos conectábamos a través del nombre del host de SQL Server. Sin embargo, ahora es necesario conectarse al contenedor.

En el caso de los contenedores de SQL Server, puede crear el archivo krb5.conf dentro del contenedor. El nodo de host que ejecuta el contenedor no necesita formar parte del dominio, pero debe poder llegar al controlador de dominio al que el contenedor intentará conectarse.

Dado que nos conectamos a un contenedor, el nombre del servidor en la conexión cliente puede ser diferente de solo el nombre de host. Podría ser el nombre de host, el nombre del contenedor u otro alias. Además, es muy probable que el puerto expuesto para SQL Server no sea el puerto 1433 predeterminado.

Deberá usar el SPN almacenado en mssql.keytab para conectarse al contenedor de SQL Server. Por ejemplo, si el SPN de mssql.keytab es MSSQLSvc/sqlcontainer.domain.com:8000, usaría sqlcontainer.domain.com,8000 como cadena de conexión en el cliente (incluidos sqlcmd, SQL Server Management Studio y Azure Data Studio).

Diagrama que muestra la autenticación de Active Directory para contenedores de SQL Server.

group refresh de SQL Server

Es posible que se pregunte por qué hay una cuenta de usuario en el archivo keytab si solo necesita un nombre de entidad de seguridad de servicio para autenticarse.

Imagine tiene un usuario adUser, que es miembro de un grupo adGroup. Si adGroup se agrega como inicio de sesión a SQL Server, significa que adUser también tiene permiso para iniciar sesión en la instancia de SQL Server. Mientras adUser está aún conectado a SQL Server, un administrador de dominio podría quitar adUser de adGroup. Ahora adUser no debería tener permiso para iniciar sesión en SQL Server, pero ya han pasado el proceso de autenticación Kerberos y están conectados.

Ejecutamos un proceso llamado group refresh de forma periódica para protegerse frente a un escenario en el que un usuario conectado ya no puede realizar una acción con privilegios (por ejemplo, crear un inicio de sesión o modificar una base de datos).

SQL Server tiene una cuenta de Active Directory con privilegios que usa para group refresh. Esta cuenta se configura mediante mssql-conf con la configuración network.privilegedadaccount o tiene como valor predeterminado la cuenta de equipo del equipo host (<hostname>$).

Las credenciales de la cuenta con privilegios de mssql.keytab se usan para suplantar al cliente (adUser en este ejemplo). SQL Server realiza un protocolo de enlace de Kerberos consigo mismo para identificar la información de pertenencia a grupos y la compara con sys.syslogins para comprobar si adUser sigue teniendo los permisos necesarios para conectarse y ejecutar los comandos Transact-SQL solicitados. Si adUser se ha quitado de adGroup, SQL Server termina la conexión.

Group refresh requiere las dos condiciones siguientes:

  • Conectividad de red entre la instancia de SQL Server y el dominio de Active Directory local.
  • Confianza bidireccional entre el dominio al que SQL Server está conectado y el dominio de Active Directory local. Para obtener más información, consulte Descripción de Active Directory.

Contenido relacionado