Configurer les SPN SQL pour SharePoint On-Premise : Guide et Bonnes Pratiques

Lors de la mise en place d'une infrastructure SharePoint On-Premise, la configuration de l'authentification Kerberos est une étape incontournable pour garantir la sécurité et les performances. Au cœur de cette configuration se trouvent les SPN (Service Principal Names).

Pour le service SQL Server qui héberge les bases de données de votre ferme SharePoint, une attention particulière est requise : il faut saisir les entrées SPN manuellement. En effet, lors de l'installation du service SQL, celui-ci n'est pas automatiquement reconnu pour les comptes d'ordinateurs (Built-in SPNs).

Voici tout ce que vous devez savoir pour configurer vos SPN dans les règles de l'art et vérifier que Kerberos fonctionne correctement.

Les règles d'or pour la création des SPN

Microsoft impose des règles strictes de syntaxe pour que la résolution Kerberos se fasse sans accroc. Voici ce qu'il faut respecter lors de la création de vos SPN :

Le type de service : Il doit impérativement être écrit en MAJUSCULES. Pour SQL, on utilisera MSSQLSvc (et HTTP pour les applications web).
Le nom du serveur : Il doit être écrit en minuscules et correspondre exactement à l'enregistrement DNS. C'est une recommandation forte de Microsoft pour éviter les conflits de casse.
Le port (pour SQL) : Bien qu'il n'ait pas d'importance critique, la norme veut qu'on l'écrive après le nom du serveur, séparé par des deux-points (ex: :1433).

Note : Le port n'est généralement pas nécessaire pour les types HTTP, mais il est très utile (voire indispensable) pour les entrées SQL.
La règle des "DEUX" : Pour que Kerberos fonctionne de manière fiable à 100%, la règle d'or de Microsoft est simple : il faut enregistrer les deux formats. Vous devez créer un SPN avec le nom court (NetBIOS) ET un SPN avec le nom de domaine complet (FQDN - Fully Qualified Domain Name).

Comment vérifier que vos comptes utilisent bien Kerberos ?

Une fois vos SPN configurés, il est indispensable de valider que l'authentification Kerberos est bien active. S'il n'y a pas de connexions Kerberos, cela signifie que vos entrées SPN sont incorrectes ou manquantes. Voici deux méthodes pour le vérifier.

Méthode 1 : Vérification via une requête SQL (SSMS)

C'est la méthode la plus directe. Connectez-vous à votre serveur SQL, ouvrez SQL Server Management Studio (SSMS), ouvrez une nouvelle fenêtre de requête et lancez le script suivant :

use master
GO
SELECT COUNT(auth_scheme) as sessions_count, net_transport, auth_scheme 
FROM sys.dm_exec_connections 
GROUP BY net_transport, auth_scheme

Dans les résultats, vous devez vérifier la colonne auth_scheme. Vous devriez y voir des sessions utilisant KERBEROS aux côtés des sessions NTLM. Si Kerberos n'apparaît pas, votre configuration SPN doit être revue.

Méthode 2 : L'outil Microsoft dédié

Si la première méthode vous indique un problème, ou si vous souhaitez un diagnostic plus approfondi, utilisez la deuxième méthode : l'outil officiel Kerberos Configuration Manager for SQL Server. Cet outil développé par Microsoft analysera votre environnement et vous indiquera exactement quels SPN sont manquants ou mal configurés.

Le piège à éviter : Ne jamais tester en local !

C'est une erreur classique lors du déploiement : on ne teste jamais Kerberos depuis le serveur qui héberge le service ! Pourquoi ? Parce qu'un serveur ne sait faire que du NTLM avec lui-même. Si vous testez la connexion directement depuis le serveur SQL, vous serez toujours authentifié en NTLM, ce qui faussera votre diagnostic.

Pour voir Kerberos réellement en action, il faut obligatoirement qu'il y ait une "distance réseau". Le flux doit suivre ce cheminement : Un Client (votre PC) ➔ Un Contrôleur de Domaine ➔ Le Serveur cible (SQL / SSRS)

Testez toujours vos connexions depuis une machine distante pour valider le bon fonctionnement de vos SPN et de Kerberos.

Configurer les SPN SQL pour SharePoint On-Premise : Guide et Bonnes Pratiques