Active Directory : Le guide ultime des Service Principal Names (SPN) et de la sécurité Kerberos

Dans un environnement Active Directory, la sécurité et la fluidité des accès reposent sur un protocole central : Kerberos. Souvent considéré comme une boîte noire par les administrateurs, Kerberos ne peut fonctionner correctement sans une configuration rigoureuse des Service Principal Names (SPN). Un SPN mal configuré, manquant ou en doublon, et c'est l'ensemble de l'authentification d'une application (comme SQL Server ou IIS) qui s'effondre ou se dégrade vers des protocoles moins sécurisés.

Ce guide technique s'appuie sur les mécanismes internes de Windows pour décortiquer l'anatomie des SPN, analyser la matrice de décision du système et vous prémunir contre les attaques de type Kerberoasting.

1. Rappel anatomique : Le flux d'authentification Kerberos

Pour comprendre l'utilité d'un SPN, il faut d'abord visualiser la cinématique des tickets au sein du Key Distribution Center (KDC), incarné par vos contrôleurs de domaine. Le flux se divise en deux grandes étapes :

Étape 1 : La demande de TGT (Ticket Granting Ticket)

1. KRB_AS_REQ : Le client envoie une demande de TGT au service d'authentification (AS) du KDC, contenant son identité chiffrée avec le hash de son propre mot de passe (pré-authentification).

2. KRB_AS_REP : Le KDC vérifie l'identité en base, génère une clé de session et renvoie le TGT. Ce TGT est chiffré avec la clé secrète du compte spécial krgtgt. Le client ne peut pas lire le contenu du TGT, mais il peut déchiffrer la clé de session reçue.

Étape 2 : La demande de Ticket de Service (TGS)

1. KRB_TGS_REQ : Lorsque le client veut accéder à une ressource (par exemple, un partage de fichiers sur \\SERVER01), il présente son TGT au service de tickets (TGS) et spécifie le nom du service cible sous la forme d'un SPN (ex: CIFS/SERVER01).

2. KRB_TGS_REP : Le KDC cherche le SPN dans sa base Active Directory. S'il le trouve sur un objet (compte machine ou compte de service), il génère un ticket de service chiffré avec la clé de cet objet cible, puis le renvoie au client. Le client présente enfin ce ticket au serveur cible pour ouvrir sa session.

2. Qu'est-ce qu'un SPN et comment est-il structuré ?

Un SPN (Service Principal Name) est l'identifiant unique d'un service sur un réseau Active Directory. Sans lui, le client est incapable d'indiquer au KDC quel compte possède la clé de chiffrement nécessaire pour sceller le ticket de service.

Syntaxe d'un SPN

La structure standard d'un SPN respecte la nomenclature suivante :

ClasseService/NomHote:Port/NomService

• ClasseService : Le type de protocole ou d'application (ex: MSSQLSvc pour SQL Server, HTTP pour IIS, CIFS pour les partages de fichiers).

• NomHote : Le nom FQDN ou NetBIOS du serveur qui héberge le service (ex: sqlserver01.entreprise.local).

• Port (Optionnel) : Requis si le service écoute sur un port non standard (ex: :1433 pour SQL).

Le cas particulier du service HOST

Le SPN HOST/ est un alias générique créé par défaut pour chaque compte machine dans l'AD. Il englobe automatiquement de nombreux services standards de Windows (comme la gestion à distance, l'impression, etc.). Si un service spécifique n'a pas son propre SPN déclaré, Windows vérifie si le service HOST peut prendre le relais.

3. Sous le capot : La matrice d'authentification

Le comportement du système varie drastiquement selon le type de compte qui exécute le service (un compte système local vs un compte utilisateur AD) et la présence du SPN. En cas d'anomalie, l'authentification Kerberos échoue et bascule automatiquement (downgrade) vers le protocole historique NTLM, beaucoup plus vulnérable aux attaques par relais.

Voici la matrice de décision technique :

4. Le Risque Cyber : L'attaque Kerberoasting

Comprendre les SPN est également une obligation de sécurité. L'attaque dite du Kerberoasting cible précisément ce mécanisme.

Lorsqu'un compte utilisateur standard du domaine possède un SPN configuré (par exemple, un compte de service applicatif créé manuellement sans utiliser de compte de service managé gMSA), n'importe quel utilisateur authentifié du domaine peut demander un ticket TGS pour ce SPN au KDC.

Comme le KDC chiffre le TGS avec le hash du mot de passe de ce compte de service, l'attaquant peut extraire le ticket de la mémoire de sa machine (via un outil comme Mimikatz) et tenter de casser le mot de passe hors-ligne par force brute (Hashcat). Si le mot de passe du compte de service est faible, l'attaquant obtient instantanément ses privilèges.

5. Boîte à outils : Scripts d'audit et de configuration

Script 1 : Détecter les comptes utilisateurs vulnérables au Kerberoasting

Ce script PowerShell filtre votre Active Directory pour lister tous les comptes de type "Utilisateur" (et non "Machine") qui possèdent un SPN actif, représentant ainsi des cibles prioritaires pour un attaquant.

# Prérequis : Module ActiveDirectory
Import-Module ActiveDirectory

Write-Host "Recherche des comptes utilisateurs avec des SPN enregistrés (Cibles Kerberoasting)..." -ForegroundColor Yellow

# Filtrer les objets utilisateurs ayant un attribut ServicePrincipalName non vide
$KerberoastableAccounts = Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName, PasswordLastSet, Enabled

foreach ($Account in $KerberoastableAccounts) {
    [PSCustomObject]@{
        SamAccountName = $Account.SamAccountName
        Actif          = $Account.Enabled
        DernierChgtPwd = $Account.PasswordLastSet
        SPN_Enregistres= $Account.ServicePrincipalName -join " | "
    }
}

Script 2 : Enregistrer manuellement un SPN pour SQL Server

Si vous devez configurer manuellement un SPN pour une instance SQL Server s'exécutant sous un compte de service AD (manipulation indispensable pour activer l'authentification Kerberos sur vos bases de données) :

# Définition des variables
$ServiceAccount = "DOMAIN\svc-sql-prod"
$ServerFQDN     = "sqlserver01.domain.local"
$Port           = "1433"

Write-Host "Enregistrement du SPN pour l'instance SQL Server..." -ForegroundColor Cyan

# Appel de l'outil natif setspn
setspn.exe -S "MSSQLSvc/$($ServerFQDN):$Port" $ServiceAccount
setspn.exe -S "MSSQLSvc/$ServerFQDN" $ServiceAccount

# Vérification des SPN sur le compte
Write-Host "Vérification des SPN appliqués :" -ForegroundColor Green
setspn.exe -L $ServiceAccount

Note: L'option -S de setspn vérifie au préalable que le SPN n'existe pas en doublon ailleurs dans la forêt AD avant de l'ajouter, évitant ainsi de corrompre la résolution Kerberos.

6. Références officielles Microsoft

Pour approfondir la configuration de vos environnements de production et assurer la liaison de vos bases de données, consultez les référentiels de l'éditeur :

• Enregistrer un SPN pour les connexions Kerberos - SQL Server

• Vue d'ensemble technique du protocole Kerberos pour Windows

Conclusion

Le fonctionnement des SPN n'est pas optionnel dès lors qu'on souhaite élever le niveau de sécurité d'un domaine Windows Server en s'affranchissant de NTLM. En systématisant l'usage des comptes de service managés de groupe (gMSA) qui gèrent et renouvellent automatiquement des mots de passe complexes de 240 caractères, vous éliminez à la fois les erreurs d'enregistrement de SPN et le risque de compromission par Kerberoasting.