Compatibilidad con el nombre de entidad de seguridad de servicio (SPN) en conexiones de cliente en SQL Server Native Client

Artículo
01/10/2024

Se aplica a: SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

Importante

SQL Server Native Client (SNAC) no se incluye con:

SQL Server 2022 (16.x) y versiones posteriores
SQL Server Management Studio 19 y versiones posteriores

Sql Server Native Client (SQLNCLI o SQLNCLI11) y el proveedor MICROSOFT OLE DB heredado para SQL Server (SQLOLEDB) no se recomiendan para el desarrollo de aplicaciones nuevas.

En el caso de los proyectos nuevos, use uno de los siguientes controladores:

Para SQLNCLI que se incluye como componente de motor de base de datos de SQL Server (versiones 2012 a 2019), consulte esta excepción de ciclo de vida de soporte técnico.

A partir de SQL Server 2008 (10.0.x), se ha ampliado la compatibilidad con los nombres de entidad de seguridad de servicio (SPN) para habilitar la autenticación mutua en todos los protocolos. En versiones anteriores de SQL Server, los SPN solo se admitían en Kerberos sobre TCP, cuando el SPN predeterminado para la instancia de SQL Server se registraba en Active Directory.

El protocolo de autenticación usa los SPN para determinar la cuenta en la que se ejecuta una instancia de SQL Server. Si se conoce la cuenta de la instancia, la autenticación Kerberos puede usarse para proporcionar una autenticación mutua del cliente y el servidor. Si no se conoce la cuenta de la instancia, se usa la autenticación NTLM, que solo proporciona autenticación del cliente por parte del servidor. Actualmente, SQL Server Native Client realiza la búsqueda de autenticación, derivando el SPN del nombre de instancia y las propiedades de conexión de red. Las instancias de SQL Server intentarán registrar los SPN al inicio, o bien pueden registrarse manualmente. No obstante, se producirá un error en el registro si no hay suficientes derechos de acceso para la cuenta que intenta registrar los SPN.

Las cuentas de dominio y equipo se registran automáticamente en Active Directory. Estas cuentas pueden usarse como SPN, o bien los administradores pueden definir sus propios SPN. SQL Server hace que la autenticación segura sea más fácil de administrar y más confiable, ya que permite a los clientes especificar directamente el SPN que va a usarse.

Nota

Un SPN especificado por una aplicación cliente solamente se utiliza cuando se establece una conexión con la seguridad integrada de Windows.

Sugerencia

Microsoft Administrador de configuración de Kerberos para SQL Server es una herramienta de diagnóstico que sirve para solucionar problemas de conectividad de Kerberos relacionados con SQL Server. Para obtener más información, vea Administrador de configuración de Microsoft Kerberos para SQL Server.

Para obtener más información acerca de Kerberos, vea los siguientes artículos:

Uso

En la tabla siguiente se describen los escenarios más comunes en los que las aplicaciones cliente pueden habilitar la autenticación segura.

Escenario	Descripción
Una aplicación heredada no especifica ningún SPN.	Este escenario de compatibilidad garantiza que no habrá ningún cambio de comportamiento en las aplicaciones desarrolladas para versiones anteriores de SQL Server. Si no se especifica ningún SPN, la aplicación se basa en los SPN generados y no tiene ningún conocimiento del método de autenticación utilizado.
Una aplicación cliente que usa la versión actual de SQL Server Native Client especifica un SPN en el cadena de conexión como una cuenta de usuario o equipo de dominio, como un SPN específico de la instancia o como una cadena definida por el usuario.	La palabra clave ServerSPN puede usarse en una cadena de conexión, inicialización o proveedor para hacer lo siguiente: - Especificar la cuenta usada por la instancia de SQL Server para una conexión. Esto simplifica el acceso a la autenticación Kerberos. Si hay presente un centro de distribución de claves Kerberos (KDC) y se especifica la cuenta correcta, es más probable que se use la autenticación Kerberos que la autenticación NTLM. El KDC reside normalmente en el mismo equipo que el controlador de dominio. - Especificar un SPN para buscar la cuenta de servicio para la instancia de SQL Server. Por cada instancia de SQL Server, se generan dos SPN predeterminados que pueden usarse para este propósito. No obstante, no se garantiza que estas claves estén presentes en Active Directory, por lo que en esta situación no se garantiza la autenticación Kerberos. - Especificar un SPN que se usará para buscar la cuenta de servicio para la instancia de SQL Server. Ésta puede ser cualquier cadena definida por el usuario que se asigne a la cuenta de servicio. En este caso, la clave debe registrarse manualmente en el KDC y debe cumplir las reglas de un SPN definido por el usuario. La palabra clave FailoverPartnerSPN puede usarse para especificar el SPN para el servidor del asociado de conmutación por error. El intervalo de valores de cuenta y de clave de Active Directory es el mismo que los valores que pueden especificarse para el servidor principal.
Una aplicación ODBC especifica un SPN como un atributo de conexión para el servidor principal o servidor del asociado de conmutación por error.	El atributo de conexión SQL_COPT_SS_SERVER_SPN puede usarse para especificar el SPN de una conexión al servidor principal. El atributo de conexión SQL_COPT_SS_FAILOVER_PARTNER_SPN puede usarse para especificar el SPN para el servidor del asociado de conmutación por error.
Una aplicación OLE DB especifica un SPN como una propiedad de inicialización del origen de datos para el servidor principal o para un servidor del asociado de conmutación por error.	La propiedad de conexión SSPROP_INIT_SERVER_SPN del conjunto de propiedades DBPROPSET_SQLSERVERDBINIT puede usarse para especificar el SPN de una conexión. La propiedad de conexión SSPROP_INIT_FAILOVER_PARTNER_SPN de DBPROPSET_SQLSERVERDBINIT puede usarse para especificar el SPN para el servidor del asociado de conmutación por error.
Un usuario especifica un SPN para un servidor o servidor de asociado de conmutación por error en un nombre del origen de datos ODBC (DSN).	El SPN puede especificarse en un DSN ODBC a través de los cuadros de diálogo de configuración del DSN.
El usuario especifica un SPN para un servidor o servidor de asociado de conmutación por error en un cuadro de diálogo Vínculo de datos o Inicio de sesión de OLE DB.	El SPN puede especificarse en un cuadro de diálogo Vínculo de datos o Inicio de sesión . El cuadro de diálogo Inicio de sesión puede usarse con ODBC u OLE DB.
Una aplicación ODBC determina el método de autenticación que se usa para establecer una conexión.	Cuando una conexión se ha abierto correctamente, una aplicación puede consultar el atributo de conexión SQL_COPT_SS_INTEGRATED_AUTHENTICATION_METHOD para determinar qué método de autenticación se ha utilizado. Entre los valores se incluyen NTLM y Kerberos.
Una aplicación OLE DB determina el método de autenticación que se usa para establecer una conexión.	Cuando una conexión se ha abierto correctamente, una aplicación puede consultar la propiedad de conexión SSPROP_AUTHENTICATION_METHOD en el conjunto de propiedades DBPROPSET_SQLSERVERDATASOURCEINFO para determinar qué método de autenticación se ha utilizado. Entre los valores se incluyen NTLM y Kerberos.

Conmutación por error

Los SPN no se almacenan en la memoria caché de conmutación por error y, por lo tanto, no pueden pasarse entre conexiones. Los SPN se usarán en todos los intentos de conexión a la entidad de seguridad y al asociado cuando se especifiquen en los atributos de cadena de conexión o atributos de conexión.

Agrupar conexiones

Las aplicaciones deben tener en cuenta que especificar los SPN en algunas cadenas de conexión, pero no en todas, pueden contribuir a la fragmentación del grupo.

Las aplicaciones pueden especificar los SPN mediante programación como atributos de conexión, en lugar de especificar las palabras clave de cadena de conexión. Esto puede contribuir a administrar la fragmentación del grupo de conexiones.

Las aplicaciones deben tener en cuenta que los SPN de las cadenas de conexión pueden invalidarse estableciendo los atributos de conexión correspondientes, pero las cadenas de conexión utilizadas por la agrupación de conexiones usarán los valores de las cadenas de conexión para los propósitos de agrupación.

Comportamiento de un servidor de nivel inferior

El cliente implementa el nuevo comportamiento de conexión; por lo tanto, no es específico de una versión de SQL Server.

Servidores vinculados y delegación

Cuando se crean servidores vinculados, el parámetro @provstr de sp_addlinkedserver puede usarse para especificar los SPN del servidor y del asociado de conmutación por error. Las ventajas de hacerlo son las mismas que cuando los SPN se especifican en las cadenas de conexión del cliente: resulta más sencillo y confiable establecer conexiones que usan la autenticación Kerberos.

La delegación con servidores vinculados requiere la autenticación Kerberos.

Aspectos de la administración de los SPN especificados por aplicaciones

A la hora de decidir si debe especificar los SPN en una aplicación (a través de cadenas de conexión) o mediante programación a través de propiedades de conexión (en lugar de confiar en el proveedor predeterminado que generó los SPN), tenga en cuenta los factores siguientes:

Seguridad: ¿el SPN especificado revela información protegida?
Confiabilidad: para habilitar el uso de los SPN predeterminados, la cuenta de servicio donde se ejecuta la instancia de SQL Server necesita tener privilegios suficientes para actualizar Active Directory en el KDC.
Comodidad y transparencia de ubicación: ¿cómo afectará a los SPN de una aplicación que su base de datos se mueva a una instancia distinta de SQL Server ? Esto se aplica tanto al servidor principal como a su asociado de conmutación por error si se usa la creación de reflejo de la base de datos. Si un servidor cambia, ¿significa que deben modificarse los SPN?, ¿cómo afectará esto a las aplicaciones?, ¿se administrarán los cambios?

Especificar el SPN

Un SPN puede especificarse en cuadros de diálogo y en el código. En esta sección se muestra cómo especificar un SPN.

La longitud máxima de un SPN es de 260 caracteres.

La sintaxis que usan los SPN en los atributos de cadena de conexión o atributos de conexión es la siguiente:

Sintaxis	Descripción
MSSQLSvc/fqdn	SPN predeterminado generado por el proveedor para una instancia predeterminada cuando se usa un protocolo distinto de TCP. fqdn es un nombre de dominio completo.
MSSQLSvc/fqdn:port	SPN predeterminado generado por el proveedor cuando se usa TCP. puerto en un número de puerto TCP.
MSSQLSvc/fqdn:InstanceName	SPN predeterminado generado por el proveedor para una instancia con nombre cuando se usa un protocolo distinto de TCP. InstanceName es un nombre de instancia de SQL Server.
HOST/fqdn HOST/MachineName	SPN que se asigna a las cuentas de equipo integradas que Windows registra automáticamente.
Username@Domain	Especificación directa de una cuenta de dominio. Username es un nombre de cuenta de usuario de Windows. Domain es un nombre de dominio de Windows o nombre de dominio completo.
MachineName$@Domain	Especificación directa de una cuenta de equipo. (Si el servidor al que está conectándose se ejecuta en las cuentas LOCAL SYSTEM o NETWORK SERVICE, para obtener la autenticación Kerberos, ServerSPN puede tener el formato MachineName$@Domain .)
KDCKey/MachineName	SPN especificado por el usuario. KDCKey es una cadena alfanumérica que se ajusta a las reglas de una clave KDC.

Sintaxis de ODBC y OLE DB compatible con los SPN

Para obtener información específica de la sintaxis, vea los siguientes temas:

Consulte también

Características de SQL Server Native Client
Registrar un nombre principal de servicio para las conexiones con Kerberos

Compartir a través de