The SQL Network Interface library was unable to register SPN

The SQL Network Interface library was unable to register SPN.

Problem

In the SQL Server error log you got the following message:

The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

To understand the error you can transcribe the error message 0x2098 in a more readable.

ERROR_DS_INSUFF_ACCESS_RIGHTS

8344 (0x2098)

Insufficient access rights to perform the operation.

This error message indicates that the service account SQL server does not have sufficient rights to register the SPN.

Cause

SPNs are used by the Kerberos authentication protocol. If the account of the proceeding is known, the Kerberos authentication can be used to provide mutual authentication by the client and server. If the account of the proceedings is not known, NTLM authentication, which provides only authentication of the client by the server is used.

If you run SQL Server under the LocalSystem account, the SPN is automatically registered as SQL registering with the machine account that has the right to create an SPN default. So Kerberos interacts successfully with the server running SQL Server.

However, if you run SQL Server under a domain account or a local account, the attempt to create the SPN may fail. When creating the service principal name fails, this means that no SPN is set for the service that is running SQL Server.

Solution

Therefore, you must implement a solution to that the SPN is created for your SQL Server instance where you want to use the Kerberos protocol.

Method 1 : The method recommended by Microsoft Support. You can give in Active Directory rights below to the service account of SQL Server:
- Read servicePrincipalName
- Write servicePrincipalName

Method 2 : You can also give him the rights manually using the tool SetSPN.(https://msdn.microsoft.com/fr-fr/library/cc280459.aspx )

For SQL server Standalone

SetSPN -A MSSQLSvc/<ComputerName>.<DomainName>:<port> <AccountName>

So for a multi-server instance you must configure the SPN for each instance, for each instance of SQL Server usefulness port TCP / IP only. For the port of the proceeding open SQL Server Configuration Manager>> Right click the instance>> TCP / IP protocol (default port)

Pour un cluster

SetSPN -A MSSQLSvc/<virtualName>.<DomainName>:<port> <AccountName>
SetSPN -A MSSQLSvc/<virtualName>.<DomainName> <AccountName>

For an instance of SQL Server cluster, you must use the FQDN of the virtual SQL server. You must also configure the SPN with a port and a second SPN without the port.

Verification

Then you can confirm that the operation went smoothly with the following command:
SetSPN -L <AccountName>

SQL server side to check, you can use the DMV sys.dm_exec_connections with the column auth_scheme :
select auth_scheme from sys.dm_exec_connections where session_id=@@spid
If kerberos is used, you should see "KERBEROS".

Documentation

The SQL Network Interface library was unable to register SPN.

Problème

Dans les Error Logs SQL serveur vous obtenez le message d'erreur suivant :

**

La bibliothèque SQL Network Interface Impossible d'inscrire le nom principal service (SPN) pour le service SQL Server. Erreur : 0x2098. Échec d'inscrire un nom principal de service peut entraîner intégrée l'authentification revenir à NTLM au lieu de Kerberos. Ceci est un message d'information. Action supplémentaire n'est obligatoire si Kerberos authentification est requise par les stratégies d'authentification.

Pour comprendre l'erreur vous devez transcrire le message d'erreur 0x2098. Vous pouvez :

ERROR_DS_INSUFF_ACCESS_RIGHTS

8344 (0x2098)

Insufficient access rights to perform the operation.

Ce message d'erreur indique que le compte de service SQL server n'a pas les droits suffisants pour enregistrer les SPN. 

Cause

Les SPN sont utilisés par le protocole d'authentification Kerberos. Si le compte de l'instance est connu, l'authentification Kerberos peut être utilisée pour fournir une authentification mutuelle par le client et le serveur. Si le compte de l'instance n'est pas connu, l'authentification NTLM, qui fournit uniquement une authentification du client par le serveur, est utilisée.

Si vous exécutez le service SQL Server sous le compte LocalSystem, le nom principal de service est généralement enregistré car SQL s'enregistre avec le compte machine qui dispose du droit de créer un SPN par défaut. Kerberos interagit correctement avec le serveur qui exécute SQL Server.

Cependant, si vous exécutez le service SQL Server sous un compte de domaine ou un compte local au que le compte localsystem, la tentative de création du nom principal de service peut échouer. Lorsque la création du nom principal de service échoue, cela signifie qu'aucun nom principal de service n'est configuré pour le service qui exécute SQL Server.

Résolution

Par conséquent, vous devez mettre en œuvre une solution pour que le SPN soit créé pour votre instance SQL Server lorsque vous souhaitez utiliser le protocole Kerberos.

Méthode 1 : La méthode recommandée par le Support Microsoft. Vous pouvez donner dans Active Directory les droits ci-dessous au compte de service SQL Server :
- Read servicePrincipalName
- Write servicePrincipalName

Méthode 2 : Vous pouvez aussi créer le SPN manuellement avec l'outil SetSPN.(https://msdn.microsoft.com/fr-fr/library/cc280459.aspx )

Pour un SQL server Standalone

SetSPN -A MSSQLSvc/<ComputerName>.<DomainName>:<port> <AccountName>

Pour un serveur multi instance vous devez configurer le Server Principal Name (SPN) pour chaque instance, car chaque instance de SQL Server utilise un port TCP unique. Pour obtenir le port de l'instance ouvrez SQL Server Configuration Manager >> Clic droit sur l'instance >> TCP/IP protocole (default port)

Pour une instance virtuelle  (cluster en cluster)

SetSPN -A MSSQLSvc/<virtualName>.<DomainName>:<port> <AccountName>
SetSPN -A MSSQLSvc/<virtualName>.<DomainName> <AccountName>

Pour une instance SQL server en cluster, vous devez utiliser le FQDN du server SQL virtuel. Vous devez configurer le Service Principal Name (SPN) premièrement en spécifiant un port puis un second SPN sans  port.

Vérification

Ensuite vous pouvez confirmer que l'opération s'est bien déroulé avec la commande suivante :
SetSPN -L <AccountName>

Coté SQL server, vous pouvez utiliser la DMV sys.dm_exec_connections avec la colonne auth_scheme :
select auth_scheme from sys.dm_exec_connections where session_id=@@spid
Si kerberos est utilisé, vous devriez voir "KERBEROS".

Documentation

 

The SQL Network Interface library was unable to register SPN.

Problema

En las contrapartes de error de SQL Server recibe el mensaje de error siguiente:

La biblioteca SQL Network Interface no se pudo registrar el nombre principal de servicio (SPN) para el servicio de SQL Server. Error: 0x2098. Un error al registrar un SPN puede producir la autenticación integrada se retrocede a NTLM en lugar de Kerberos. Se trata de un mensaje informativo. Acción más sólo es necesario si se requiere autenticación por directivas de autenticación de Kerberos.

 

Para entender el error que transcribir el mensaje de error 0x2098 de una forma más legible. Usted puede:

ERROR_DS_INSUFF_ACCESS_RIGHTS

8344 (0x2098)

Insufficient access rights to perform the operation.

Este mensaje de error indica que el servidor de cuenta de servicio de SQL no tiene suficientes derechos para registrar el SPN.

Causa

SPN son utilizados por el protocolo de autenticación Kerberos. Si se sabe que la cuenta del procedimiento, la autenticación Kerberos puede ser utilizado para proporcionar autenticación mutua entre el cliente y el servidor. Si la cuenta de las actuaciones no se conoce, la autenticación NTLM, que proporciona sólo la autenticación del cliente por el servidor, se utiliza.

Si ejecuta SQL Server en la cuenta LocalSystem, el SPN se registra automáticamente como SQL registrarse en la cuenta de equipo que tiene el derecho a crear un defecto de SPN. Así Kerberos interactúa correctamente con el servidor que ejecuta SQL Server.

Sin embargo, si ejecuta SQL Server bajo una cuenta de dominio o una cuenta local, el intento de crear el SPN puede fallar. Al crear el nombre principal de servicio falla, esto significa que no SPN se establece para el servicio que se ejecuta SQL Server.

Resolución

Por lo tanto, debe implementar una solución para que el SPN se crea para la instancia de SQL Server donde desea utilizar el protocolo Kerberos.

Método 1 : El método recomendado por el Soporte Microsoft. Usted puede dar en el Directorio Activo de derechos por debajo de la cuenta de servicio de SQL Server :
- Read servicePrincipalName
- Write servicePrincipalName

Método 2 : También puede darle los derechos de forma manual utilizando la herramienta de

SetSPN.(https://msdn.microsoft.com/fr-fr/library/cc280459.aspx )

Para un SQL server Standalone

SetSPN -A MSSQLSvc/<ComputerName>.<DomainName>:<port> <AccountName>

Así que para una instancia de servidor de múltiples debe configurar el SPN para cada instancia, para cada instancia de SQL Server utilidad uno  port TCP / IP. Para obtener el puerto del  instancia abierto SQL Server Configuration Manager>> Haga clic en la instancia>> protocolo TCP / IP (puerto por defecto)

Para un clúster

SetSPN -A MSSQLSvc/<virtualName>.<DomainName>:<port> <AccountName>
SetSPN -A MSSQLSvc/<virtualName>.<DomainName> <AccountName>

De una instancia de clúster de SQL Server, debe utilizar el nombre completo del servidor virtual SQL. También debe configurar el SPN con un puerto y un SPN segundo sin el puerto.

Verificación

Entonces usted puede confirmar que la operación se desarrolló sin problemas con el siguiente comando:
SetSPN -L <AccountName>

Del lado del servidor SQL para la verificación, puede utilizar el  DMV sys.dm_exec_connections  con la columna auth_scheme :
select auth_scheme from sys.dm_exec_connections where session_id=@@spid
Si se utiliza Kerberos, debería ver "KERBEROS".

Documentación

How to: Enable Kerberos Authentication on a SQL Server Failover Cluster
https://msdn.microsoft.com/en-us/library/ms189585(SQL.90).aspx

Registering a Service Principal Name
https://msdn.microsoft.com/en-us/library/ms191153.aspx

How to configure SQL Server 2005 Analysis Services to use Kerberos authentication
https://support.microsoft.com/kb/917409

How to make sure that you are using Kerberos authentication when you create a remote connection to an instance of SQL Server 2005
https://support.microsoft.com/kb/909801

You cannot start the SQL Server Agent service of a failover cluster of SQL Server 2005 if the build of SQL Server is 3179 or a later build
https://support.microsoft.com/kb/943525

Registering Kerberos Service Principal Names
https://msdn2.microsoft.com/en-us/library/ms178119.aspx

How to Configure the Service Principal Name
https://msdn.microsoft.com/en-us/library/ms942980.aspx

How to troubleshoot the "Cannot generate SSPI context" error message
https://support.microsoft.com/kb/811889

Enable Kerberos authentication for virtual servers
https://technet.microsoft.com/en-us/library/cc780918.aspx

How to: Enable Kerberos Authentication on a SQL Server Failover Cluster
https://msdn.microsoft.com/en-us/library/ms189585(SQL.90).aspx

Best practices for configuring and operating server clusters
https://technet.microsoft.com/en-us/library/cc785714.aspx

How to use Kerberos authentication in SQL Server
https://support.microsoft.com/kb/319723/en-us

Michel Degremont | Microsoft EMEA
Product Support Services Developer - SQL Server Core Engineer |