Tutorial: Uso de la autenticación de Active Directory con SQL Server en Linux

Se aplica a:SQL Server en Linux

En este tutorial se explica cómo configurar SQL Server en Linux para admitir la autenticación de Active Directory, también conocida como autenticación integrada. Para consultar una introducción, vea Autenticación de Active Directory para SQL Server en Linux.

Este tutorial consta de las tareas siguientes:

• Únete el host de SQL Server a un dominio de Active Directory
• Crea un usuario de Active Directory para SQL Server y establece un SPN
• Configuración del archivo keytab del servicio SQL Server
• Protección del archivo keytab
• Configuración de SQL Server para usar el archivo keytab para la autenticación Kerberos
• Creación de inicios de sesión basados en Active Directory en Transact-SQL
• Conexión a SQL Server mediante la autenticación de Active Directory

Prerequisites

Antes de configurar la autenticación de Active Directory, necesitas:

• Configura un controlador de dominio Active Directory (Windows) en tu red
• Instalar SQL Server
  • Inicio rápido: Instalación de SQL Server y creación de una base de datos en Red Hat Enterprise Linux
  • Inicio rápido: Instalación de SQL Server y creación de una base de datos en SUSE Linux Enterprise Server
  • Inicio rápido: Instalación de SQL Server y creación de una base de datos en Ubuntu

Note

A partir de SQL Server 2025 (17.x), no se admite SUSE Linux Enterprise Server (SLES).

Unión de un host de SQL Server a un dominio de Active Directory

Conecta tu host Linux de SQL Server a un controlador de dominio de Active Directory. Para información sobre cómo unirse a un dominio de Active Directory, consulte Unir SQL Server en un host Linux a un dominio de Active Directory.

Creación del usuario de Active Directory para SQL Server y establecimiento del SPN

Note

En los siguientes pasos se usa el nombre de dominio totalmente cualificado (FQDN). Si está en Azure, debe crear un FQDN para poder continuar.

1. En el controlador de dominio, ejecute el comando de PowerShell New-ADUser para crear un usuario de Active Directory con una contraseña que no expire nunca. En el ejemplo siguiente se asigna el nombre sqlsvc a la cuenta, pero el nombre de la cuenta puede ser el que quiera. Se le pedirá que escriba una contraseña nueva para la cuenta.

   Import-Module ActiveDirectory
   
   New-ADUser sqlsvc -AccountPassword (Read-Host -AsSecureString "Enter Password") -PasswordNeverExpires $true -Enabled $true
   

   Un procedimiento de seguridad recomendado es tener una cuenta de Active Directory dedicada para SQL Server, de modo que las credenciales de la instancia de SQL Server no se compartan con otros servicios que usen la misma cuenta. Sin embargo, opcionalmente, puede usar una cuenta de Active Directory existente si conoce la contraseña (que es necesaria para generar un archivo keytab en el paso siguiente). Además, la cuenta debe estar habilitada para admitir el cifrado AES de Kerberos de 128 y 256 bits (atributo msDS-SupportedEncryptionTypes) en la cuenta de usuario. Para validar que la cuenta está habilitada para el cifrado AES, busque la cuenta en la utilidad Usuarios y equipos de Active Directory y seleccione Propiedades. Busque la pestaña Cuentas en las Propiedades y compruebe que estén activadas las dos casillas de verificación siguientes.

   1. Esta cuenta admite cifrado AES de Kerberos de 128 bits
   2. Esta cuenta admite cifrado AES de Kerberos de 256 bits

2. Establece el nombre principal del servicio (SPN) para esta cuenta usando la herramienta setspn.exe . El SPN debe tener el formato exacto que se especifica en el ejemplo siguiente. Para buscar el nombre de dominio completo del equipo host de SQL Server, ejecute hostname --all-fqdns en el host de SQL Server. El puerto TCP debe ser 1433 a menos que haya configurado SQL Server para usar otro número de puerto.

   setspn -A MSSQLSvc/<fully qualified domain name of host machine>:<tcp port> sqlsvc
   setspn -A MSSQLSvc/<netbios name of the host machine>:<tcp port> sqlsvc
   

   Note

   Si recibe el error Insufficient access rights, pídale al administrador del dominio que compruebe si tiene permisos suficientes para establecer un SPN en esta cuenta. La cuenta que se usa para registrar un SPN necesitará los permisos Write servicePrincipalName. Para obtener más información, consulte Registrar un Nombre Principal de Servicio para las conexiones con Kerberos.

   Si cambia el puerto TCP en el futuro, debe volver a ejecutar el comando setspn con el nuevo número de puerto. También debe seguir los pasos de la siguiente sección para agregar el nuevo SPN al archivo keytab del servicio SQL Server.

Para obtener más información, consulte Registrar un Nombre Principal de Servicio para las conexiones con Kerberos.

Configuración del archivo keytab del servicio SQL Server

La configuración de la autenticación de Active Directory para SQL Server en Linux requiere una cuenta de usuario de Active Directory y el SPN creado en la sección anterior.

Importante

Si se cambia la contraseña de la cuenta de Active Directory o de la cuenta a la que se asignan los SPN, tendrá que actualizar el archivo keytab con la nueva contraseña y el número de versión de la clave (KVNO). Algunos servicios también pueden rotar las contraseñas automáticamente. Consulte las directivas de rotación de contraseñas de las cuentas en cuestión y adáptelas a las actividades de mantenimiento programado para evitar tiempos de inactividad inesperados.

Entradas del archivo keytab de SPN

1. Consulta el número de versión de clave (KVNO) de la cuenta de Active Directory creada en la sección anterior. Suele ser 2, pero podría ser otro entero si ha cambiado la contraseña de la cuenta varias veces. En el equipo host de SQL Server, ejecute los siguientes comandos:

   • En los ejemplos siguientes se supone que user está en el dominio @CONTOSO.COM. Cambie el nombre de usuario y el nombre de dominio por su nombre de usuario y el nombre de dominio propios.

   kinit user@CONTOSO.COM
   kvno user@CONTOSO.COM
   kvno MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM
   

   Note

   Los SPN pueden tardar varios minutos en propagarse por el dominio, sobre todo si el dominio es grande. Si recibe el error , kvno: Server not found in Kerberos database while getting credentials for MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COMespere unos minutos e inténtelo de nuevo. Los comandos anteriores solo funcionan si el servidor se ha unido a un dominio de Active Directory, que se ha tratado en una sección anterior.

2. Usando ktpass, añade entradas keytab para cada SPN usando los siguientes comandos en el prompt de comandos de Windows:

   • <DomainName>\<UserName>: cuenta de usuario de Active Directory
   • @CONTOSO.COM - Utilice su nombre de dominio.
   • /kvno <#>: reemplace <#> por el valor KVNO obtenido en un paso anterior.
   • <password> - La contraseña debe seguir la directiva de contraseña predeterminada de SQL Server. De forma predeterminada, la contraseña debe tener al menos ocho caracteres y contener caracteres de tres de los siguientes cuatro conjuntos: mayúsculas, minúsculas, dígitos en base 10 y símbolos. Las contraseñas pueden tener hasta 128 caracteres. Use contraseñas lo más largas y complejas posible.

   ktpass /princ MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   
   ktpass /princ MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   
   ktpass /princ MSSQLSvc/<netbios name of the host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   
   ktpass /princ MSSQLSvc/<netbios name of the host machine>:<tcp port>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   
   ktpass /princ <UserName>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto aes256-sha1 /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   
   ktpass /princ <UserName>@CONTOSO.COM /ptype KRB5_NT_PRINCIPAL /crypto rc4-hmac-nt /mapuser <DomainName>\<UserName> /in mssql.keytab /out mssql.keytab -setpass -setupn /kvno <#> /pass <password>
   

   Los comandos anteriores permiten cifrados de cifrado AES y RC4 para la autenticación de Active Directory. RC4 es un codificador de cifrado más antiguo y, si se requiere un mayor grado de seguridad, puede optar por crear las entradas del archivo keytab solo con el codificador de cifrado AES.

   Note

   Las dos UserName últimas entradas deben estar en minúscula, o la autenticación puede fallar.

3. Después de ejecutar los comandos anteriores, debe tener un archivo keytab denominado mssql.keytab. Copie el archivo en la carpeta /var/opt/mssql/secrets del equipo en el que se ejecute SQL Server.

4. Proteja el archivo keytab.

   Cualquier persona con acceso a este archivo keytab puede suplantar SQL Server en el dominio, por lo que debe asegurarse de restringir el acceso al archivo de forma que solo la cuenta mssql tenga acceso de lectura:

   sudo chown mssql:mssql /var/opt/mssql/secrets/mssql.keytab
   sudo chmod 400 /var/opt/mssql/secrets/mssql.keytab
   

5. La siguiente opción de configuración debe establecerse con la mssql-conf herramienta para especificar la cuenta que se va a usar al acceder al archivo keytab.

   sudo mssql-conf set network.privilegedadaccount <username>
   

   Note

   Incluya solo el nombre de usuario, no nombreDeDominio\nombreDeUsuario ni nombreDeUsuario@dominio. De forma interna, SQL Server agrega el nombre de dominio según sea necesario junto con este nombre de usuario cuando se usa.

6. Siga los pasos que se indican a continuación para configurar SQL Server a fin de empezar a usar el archivo keytab para la autenticación Kerberos.

   sudo mssql-conf set network.kerberoskeytabfile /var/opt/mssql/secrets/mssql.keytab
   sudo systemctl restart mssql-server
   

   Opcionalmente, puede deshabilitar las conexiones UDP al controlador de dominio para mejorar el rendimiento. En muchos casos, se produce un error coherente en las conexiones UDP al conectarse a un controlador de dominio, por lo que puede establecer opciones de configuración en /etc/krb5.conf para omitir las llamadas a UDP. Edite /etc/krb5.conf y establezca las siguientes opciones:

   [libdefaults]
   udp_preference_limit = 0
   

Ahora está preparado para usar inicios de sesión basados en Active Directory en SQL Server.

Creación de inicios de sesión basados en Active Directory en Transact-SQL

1. Conéctese a SQL Server y cree un inicio de sesión basado en Active Directory:

   CREATE LOGIN [CONTOSO\user]
       FROM WINDOWS;
   

2. Compruebe que el inicio de sesión aparece en la vista del catálogo del sistema sys.server_principals:

   SELECT name
   FROM sys.server_principals;
   

Conexión a SQL Server mediante la autenticación de Active Directory

Inicie sesión en un equipo cliente con sus credenciales de dominio. Ahora puede conectarse a SQL Server sin volver a escribir la contraseña, mediante la autenticación de Active Directory. Si crea un inicio de sesión para un grupo de Active Directory, cualquier usuario de Active Directory que pertenezca a ese grupo podrá conectarse de la misma manera.

El parámetro de cadena de conexión específico para que los clientes usen la autenticación de Active Directory depende del controlador que se esté usando. Fíjese en los ejemplos de las secciones siguientes.

sqlcmd en un cliente Linux unido a un dominio

Inicie sesión en un cliente Linux unido a un dominio con ssh y sus credenciales de dominio:

ssh -l user@contoso.com client.contoso.com

Asegúrese de que ha instalado el paquete mssql-tools y, después, conéctese mediante sqlcmd sin especificar credenciales:

sqlcmd -S mssql-host.contoso.com

A diferencia de SQL Server en Windows, la autenticación Kerberos funciona para conexiones locales a SQL Server en Linux. Sin embargo, aún necesitas proporcionar el FQDN del host de SQL Server. La autenticación de Active Directory no funcionará si intentas conectarte a ., localhost, o 127.0.0.1.

SSMS en un cliente Windows unido a un dominio

Inicie sesión en un cliente Windows unido a un dominio con sus credenciales de dominio. Asegúrese de que SQL Server Management Studio esté instalado y luego conéctese a su instancia de SQL Server (por ejemplo, mssql-host.contoso.com) al especificar Autenticación de Windows en el cuadro de diálogo Conectar al servidor.

Autenticación de Active Directory con otros controladores de cliente

En la tabla siguiente se describen las recomendaciones de otros controladores de cliente:

Controlador de cliente	Recomendación
JDBC	Use la autenticación integrada Kerberos para conectarse con SQL Server.
ODBC	Use la autenticación integrada.
ADO.NET	Sintaxis de la cadena de conexión.

Opciones de configuración adicionales

Si usas utilidades de terceros como PBIS, VAS o Centrify para unir el host de Linux a un dominio de Active Directory y quieres forzar a SQL Server a usar directamente la biblioteca OpenLDAP, puedes configurar la disablesssd opción de mssql-conf la siguiente manera:

sudo mssql-conf set network.disablesssd true
sudo systemctl restart mssql-server

Note

Hay utilidades como realmd que configuran SSSD, mientras que otras herramientas como PBIS, VAS y Centrify no configuran SSSD. Si la utilidad utilizada para unirse al dominio de Active Directory no configura SSSD, deberías configurar la disablesssd opción para true. Aunque no es necesario porque SQL Server intenta usar SSSD para Active Directory antes de recurrir al mecanismo OpenLDAP, configurar esta opción permite a SQL Server realizar llamadas directamente a OpenLDAP y evitar SSSD.

Si su controlador de dominio admite LDAPS, puede forzar que todas las conexiones de SQL Server a los controladores de dominio sean a través de LDAPS. Para comprobar si el cliente puede ponerse en contacto con el controlador de dominio mediante LDAPS, ejecute el siguiente comando de Bash, ldapsearch -H ldaps://contoso.com:3269. Para establecer SQL Server para que solo use LDAPS, ejecute lo siguiente:

sudo mssql-conf set network.forcesecureldap true
sudo systemctl restart mssql-server

SQL Server usa LDAPS sobre SSSD si el host se unió al dominio de Active Directory usando SSSD y disablesssd no está configurado como true. Si ambos disablesssd y forcesecureldap están configurados en true, SQL Server usa LDAPS en lugar de OpenLDAP.

SQL Server 2017 CU 14 y versiones posteriores

A partir de SQL Server 2017 (14.x) CU 14, si SQL Server se unió a un controlador de dominio Active Directory usando proveedores de terceros y está configurado para usar llamadas OpenLDAP para la búsqueda general de Active Directory configurando disablesssd en true, también puedes usar la enablekdcfromkrb5conf opción para forzar a SQL Server a usar la biblioteca krb5 para la búsqueda KDC en lugar de la búsqueda DNS inversa para el servidor KDC.

Esto puede ser útil cuando quieras configurar manualmente los controladores de dominio con los que SQL Server intenta comunicarse y usar el mecanismo de biblioteca OpenLDAP con la lista KDC en krb5.conf.

En primer lugar, establezca disablesssd y enablekdcfromkrb5conf en true y reinicie SQL Server:

sudo mssql-conf set network.disablesssd true
sudo mssql-conf set network.enablekdcfromkrb5conf true
sudo systemctl restart mssql-server

Luego, configure la lista de KDC en /etc/krb5.conf como se indica a continuación:

[realms]
CONTOSO.COM = {
  kdc = dcWithGC1.contoso.com
  kdc = dcWithGC2.contoso.com
}

Aunque no se recomienda, es posible usar utilidades, como realmd, que configuran SSSD a la vez que unen el host de Linux al dominio, al mismo tiempo que se configura disablesssd en true para que SQL Server use las llamadas a OpenLDAP en lugar de SSSD para las llamadas relacionadas con Active Directory.

Note

No se admite el inicio de sesión de SQL Server mediante un FQDN (por ejemplo, CONTOSO.COM\Username). Use el formato CONTOSO\Username.

No se admiten inicios de sesión de SQL Server desde grupos locales de dominio. En vez de estos, debe usar grupos de dominio de seguridad global.

Contenido relacionado

• Cifrado de las conexiones a SQL Server en Linux
• Descripción de la autenticación de Active Directory para SQL Server en Linux y contenedores
• Solución de problemas de la autenticación de Active Directory para SQL Server en Linux y contenedores

Contribuya a la documentación de SQL

¿Sabía que puede editar el contenido de SQL usted mismo? Si lo hace, no solo contribuirá a mejorar la documentación, sino que también se le reconocerá como colaborador de la página.

Para obtener más información, consulte Editar documentación de Microsoft Learn.