Compartir a través de


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

Se aplica a: SQL Server - 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:

  • Unión de un host de SQL Server a un dominio de Active Directory
  • Creación del usuario de Active Directory para SQL Server y establecimiento del 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

Requisitos previos

Antes de configurar la autenticación de Active Directory, debe hacer lo siguiente:

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

Una el host Linux de SQL Server con un controlador de dominio de Active Directory. Para obtener información sobre cómo unir un dominio de Active Directory, consulte Unión de SQL Server en un host de Linux a un dominio de Active Directory.

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

Nota:

En los siguientes pasos se usa el nombre de dominio completo (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
    

    Nota:

    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. Establezca el ServicePrincipalName (SPN) de esta cuenta mediante 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
    

    Nota

    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, vea Registrar un nombre de entidad de seguridad 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, vea Registrar un nombre de entidad de seguridad 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. Compruebe el número de versión de la clave (KVNO) de la cuenta de Active Directory creada en el paso 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 de dominio por los suyos.
    kinit user@CONTOSO.COM
    kvno user@CONTOSO.COM
    kvno MSSQLSvc/<fully qualified domain name of host machine>:<tcp port>@CONTOSO.COM
    

    Nota

    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.COM, espere unos minutos y vuelva a intentarlo.

    Los comandos anteriores solo funcionarán si el servidor se ha unido a un dominio de Active Directory, lo que se ha descrito en la sección anterior.

  2. Con ktpass, agregue entradas de archivo keytab para cada SPN mediante los comandos siguientes en un símbolo del sistema del equipo Windows:

    • <DomainName>\<UserName>: cuenta de usuario de Active Directory
    • @CONTOSO.COM: use el nombre de dominio.
    • /kvno <#>: reemplace <#> por el valor KVNO obtenido en un paso anterior.
    • <StrongPassword>: use una contraseña segura.
    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 <StrongPassword>
    
    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 <StrongPassword>
    
    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 <StrongPassword>
    
    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 <StrongPassword>
    
    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 <StrongPassword>
    
    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 <StrongPassword>
    

    Nota

    Los comandos anteriores permiten los cifrados 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. Las dos últimas entradas UserName deben estar en minúsculas, o es posible que se produzca un error en la autenticación del permiso.

  3. Después de ejecutar el comando anterior, 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 opción de configuración siguiente se debe establecer con la herramienta mssql-conf para especificar la cuenta que se va a usar al acceder al archivo keytab.

    sudo mssql-conf set network.privilegedadaccount <username>
    

    Nota

    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
    

    Sugerencia

    Opcionalmente, deshabilite 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:

    /etc/krb5.conf
    [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 con sqlcmd sin especificar ninguna credencial:

sqlcmd -S mssql-host.contoso.com

A diferencia de SQL para Windows, la autenticación Kerberos funciona para la conexión local en SQL para Linux. Sin embargo, sigue siendo necesario proporcionar el FQDN del host de SQL para Linux, y la autenticación de Active Directory no funcionará si intenta conectarse a ., localhost, 127.0.0.1, etc.

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 usa utilidades de terceros como PBIS, VAS o Centrify para unir el host de Linux con el dominio de Active Directory y quiere forzar que SQL Server use la biblioteca OpenLDAP directamente, puede configurar la opción disablesssd con mssql-conf de la siguiente forma:

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

Nota:

Hay utilidades como realmd que configuran SSSD, mientras que otras herramientas como PBI, VAS y Centrify no configuran SSSD. Si la utilidad que ha usado para unirse al dominio de Active Directory no configura SSSD, se recomienda configurar la opción disablesssd en true. Aunque no es necesario, ya que SQL Server intentará usar SSSD para Active Directory antes de revertir al mecanismo de OpenLDAP, sería más eficaz configurarlo para que SQL Server haga las llamadas a OpenLDAP omitiendo directamente el mecanismo de 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
systemctl restart mssql-server

De esta forma, se usará LDAPS antes que SSSD si la unión a un dominio de Active Directory en el host se ha realizado mediante el paquete SSSD y disablesssd no está establecido en true. Si disablesssd está establecido en true y forcesecureldap está establecido en true, usará el protocolo LDAPS antes que las llamadas a la biblioteca OpenLDAP realizadas por SQL Server.

A partir de SQL Server 2017 CU 14

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

Esto puede ser útil para el escenario en el que quiere configurar manualmente los controladores de dominio con los que SQL Server intenta comunicarse. Para usar el mecanismo de la biblioteca OpenLDAP, se utiliza la lista de KDC de 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
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.

Nota:

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.

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 más información, vea Cómo colaborar en la documentación de SQL Server.