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:
- Configurar un controlador de Dominio de Active Directory (Windows) en la red
- Instalar SQL Server
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.
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.Esta cuenta admite cifrado AES de Kerberos de 128 bits
Esta cuenta admite cifrado AES de Kerberos de 256 bits
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 permisosWrite 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
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.- En los ejemplos siguientes se supone que
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.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.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
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.
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
Conéctese a SQL Server y cree un inicio de sesión basado en Active Directory:
CREATE LOGIN [CONTOSO\user] FROM WINDOWS;
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.
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 más información, vea Cómo colaborar en la documentación de SQL Server.