SPN et son rôle dans Active Directory et la sécurité

Les Service Principal Names (SPNs) sont des identifiants uniques dans Active Directory utilisés pour associer des instances de service à des comptes de service pour l'authentification Kerberos. Cet article explique la structure des SPN, l'enregistrement, les exigences d'unicité, les outils (par exemple, setspn) et les implications sécuritaires. Il couvre les attaques telles que le Kerberoasting, les meilleures pratiques, les méthodes de détection et les cas d'utilisation avancés dans des environnements hybrides, cloud et conteneurisés.

Introduction aux Service Principal Names (SPNs)

Qu'est-ce qu'un SPN ? Même un administrateur Windows ayant une certaine expérience avec Active Directory peut ignorer le rôle que les Service Principal Names jouent dans les environnements de domaine. Un nom de principal de sécurité (SPN) est un identifiant unique qui relie une instance de service spécifique au compte qui l'exécute, permettant aux clients de s'authentifier et de se connecter au bon service au sein d'Active Directory (AD). Cela est particulièrement important dans les grands environnements d'entreprise où plusieurs instances d'un service peuvent fonctionner sur différents serveurs. Dans cet article, nous discuterons de ce qu'est le SPN d'Active Directory, de sa contribution à la sécurité et de la manière dont ses utilisations continuent de s'étendre dans les réseaux modernes d'aujourd'hui.

Rôle des SPN dans l'authentification Kerberos

Tout comme vous avez besoin d'un billet pour monter à bord d'un avion ou entrer dans un cinéma, vous avez également besoin d'un billet pour accéder aux ressources au sein d'Active Directory (AD). Lorsqu'un client demande l'accès à un service hébergé par AD, le processus se déroule comme suit :

1. Un client qui essaie d'utiliser un service crée un SPN pour ce service
2. Le client demande au contrôleur de domaine un ticket en utilisant ce SPN
3. Le contrôleur de domaine recherche dans Active Directory le SPN correspondant
4. Une fois trouvé, le contrôleur de domaine émet un ticket de service
5. Le client utilise ce ticket pour s'authentifier au service sans avoir besoin d'un mot de passe

Démystifier les bases

Composants d'un SPN

SPN se compose de plusieurs composants qui, combinés, fournissent une identité complète pour un service spécifique :

1. Classe de service: Il s'agit du nom de l'instance de service, tel que “MSSQLSvc” pour Microsoft SQL Server ou “www” pour les services web.
2. Nom d'hôte: Indique le serveur ou l'hôte où le service est en cours d'exécution. Cela peut être le nom NetBIOS d'une machine Windows tel que “FilerServer” ou le nom de domaine pleinement qualifié comme “fileserver.company.com”
3. Account: The Active Directory account associated with the service. This is not part of the SPN string itself but is the account to which the service principal name is registered.
4. Port (Facultatif) : Si le service fonctionne sur un port non standard, il peut être spécifié dans le SPN.

Exemples de SPN communs dans Active Directory

• Services Web – HTTP/webserver.netwrix.com
• SQL Server – MSSQLSvc/myhost.redmond.microsoft.com:1433
• Partages de fichiers – CIFS/fileserver.contoso.com
• Services Bureau à Distance – TERMSRV/rdserver.abcdomain.com
• Authentification LDAP – LDAP/domaincontroller.fabricam.com

SPNs et Active Directory : La Connexion

Comment les SPN s'intègrent aux objets Active Directory

Les SPN sont des attributs associés à des objets AD tels que des comptes d'utilisateurs, des comptes de service ou des objets informatiques. Ils fonctionnent comme des étiquettes qui indiquent sous quels comptes s'exécutent quels services. Cette connexion permet aux ordinateurs d'utiliser Kerberos pour une authentification sécurisée sans envoyer de mots de passe à travers le réseau. Lorsqu'un service est installé ou configuré, il enregistre un SPN qui permet à Kerberos de mapper les demandes d'authentification au bon compte. Sans un SPN correctement configuré, l'authentification Kerberos échouera, ce qui pourrait provoquer des erreurs d'authentification et des perturbations de service.

Stockage SPN dans l'attribut servicePrincipalName

Les SPN sont stockés dans Active Directory en tant que partie de l'attribut servicePrincipalName d'un objet. Cet attribut existe sur les comptes d'ordinateurs et les comptes de service. Vous pouvez voir cet attribut dans les propriétés avancées d'un objet en utilisant Active Directory Users and Computers comme illustré dans la capture d'écran ci-dessous.

L'attribut contient une liste de SPN qui ont été attribués à l'objet. Chaque entrée SPN suit un format structuré qui inclut le type de service, l'hôte et le numéro de port optionnel.

Vous pouvez voir les SPN d'un objet AD en utilisant la commande : setspn –L hostname. Dans l'exemple ci-dessous, la commande a été utilisée pour voir la liste des SPN générés par un contrôleur de domaine pour un domaine appelé ABCDomain.com

Importance de l'unicité du SPN dans une forêt AD

Chaque nom de principal de service doit être unique dans toute la forêt Active Directory. Cette unicité garantit que Kerberos peut acheminer correctement les demandes de service vers le compte approprié. Des SPN dupliqués sur différents comptes provoquent des conflits d'authentification, entraînant un comportement imprévisible ou des échecs d'authentification.

Configuration des SPN : Guide étape par étape

Outils requis pour la configuration SPN

L'outil principal pour la configuration des SPN est setspn.exe, qui est intégré aux systèmes d'exploitation Windows Server. Cet outil en ligne de commande permet aux administrateurs de lire, modifier et supprimer les noms principaux de service pour les comptes de service Active Directory.

Dans un exemple précédent, nous avons utilisé la commande setspn -L pour afficher le SPN d'un objet ordinateur. Vous pouvez également utiliser setspn -S pour ajouter un SPN. Par exemple, pour ajouter un SPN HTTP à un ordinateur appelé webserver1, la commande serait :

setspn -S HTTP/webserver1.abcdomain.com abcdomain\serviceaccount

Notez que la commande setspn -S vérifie automatiquement l'existence d'identifiants SPN identiques avant d'en créer de nouveaux pour éviter les entrées en double.

Pour supprimer un SPN, utilisez la commande setspn -D. Vous pouvez également utiliser PowerShell de plusieurs manières pour les SPNs. Par exemple, la cmdlet PowerShell suivante trouvera tous les SPNs enregistrés dans Active Directory :

Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName | Select-Object Name, servicePrincipalName

Alors que celui-ci détectera tous les SPN en double.

$SPNs = Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName |

Select-Object -ExpandProperty servicePrincipalName

Meilleures pratiques pour l'enregistrement de SPN

• Accordez les permissions minimales nécessaires aux comptes de service pour l'enregistrement SPN
• Utilisez PowerShell pour vérifier les doublons avant d'enregistrer un nouveau SPN :
• Effectuez des audits périodiques des SPNs pour identifier et supprimer les entrées inutiles ou obsolètes
• Utilisez un format de nommage SPN standardisé lors de l'ajout de SPN

Dépannage des problèmes de SPN courants

Les SPN en double peuvent entraîner des échecs d'authentification et doivent être résolus. Soyez attentif aux utilisateurs signalant des problèmes d'accès intermittents, car cela pourrait indiquer des conflits de SPN. Vous pouvez utiliser la commande setspn -x pour trouver des doublons dans un seul domaine comme le montre la capture d'écran ci-dessous.

Utilisez la commande setspn -F pour rechercher dans toute la forêt. Pour résoudre les SPN en double :

1. Identifiez les comptes qui détiennent les SPN en double.
2. Déterminez quel compte devrait légitimement détenir le SPN.
3. Supprimez le SPN du compte incorrect en utilisant setspn -D <SPN> <AccountName>8.
4. Ajoutez le SPN au compte approprié en utilisant setspn -S <SPN> <AccountName>

En plus des doublons, certaines autres erreurs de configuration SPN courantes incluent :

• SPN manquants pour les services
• SPN enregistrés sur des comptes incorrects
• SPN obsolètes après les changements de nom de serveur

(Pas besoin de répertorier à nouveau les mêmes outils ici que nous avons déjà couverts)

Concepts avancés de SPN

Le rôle des SPNs dans les environnements multi-services et multi-hôtes

Les comptes de service sont des comptes d'utilisateur spécialisés créés pour les services fonctionnant sur Windows Server. Ils aident à isoler et protéger les comptes de domaine dans des applications critiques telles que Internet Information Services (IIS). Dans des environnements complexes, plusieurs services fonctionnent souvent sur la même machine, chacun nécessitant des Noms Principaux de Service (SPNs) distincts pour une authentification appropriée.

Un exemple courant est un serveur hébergeant une application web qui peut exécuter à la fois SQL Server et IIS. Chaque service nécessite son propre SPN pour garantir une authentification Kerberos correcte :

• Pour IIS : HTTP/servername.domain.com
• Pour SQL Server : MSSQLSvc/servername.domain.com:1433

Dans des environnements multi-hôtes, où un service fonctionne sur plusieurs serveurs pour l'équilibrage de charge ou le basculement, la configuration des SPN devient plus complexe. Considérez une application web hébergée sur plusieurs serveurs (Web01, Web02, Web03) sous un nom DNS partagé. Dans ce scénario, les SPN doivent être enregistrés sur un seul compte de service pour permettre une authentification transparente sur tous les hôtes :

Cas particuliers : les SPN HOST et leur comportement unique

Les SPN d'hôte sont un type spécial de SPN automatiquement enregistrés sur des objets ordinateur dans Active Directory. Ils agissent comme un identifiant universel pour les services fonctionnant sous un compte système local ou un compte de service réseau d'une machine. Cela simplifie la gestion pour de nombreux services Windows standards et réduit le besoin de configuration manuelle des SPN.

Le tableau suivant résume quand vous devriez utiliser les SPN HOST par rapport aux SPN personnalisés :

Conseil : Vous ne devriez jamais modifier manuellement les SPN HOST car ils sont gérés par AD.

SPNs et implications sécuritaires

Pourquoi sécuriser les SPN est critique dans un environnement AD

La raison pour laquelle la sécurité est importante pour les SPN est simple. Les comptes de service ont souvent des privilèges élevés. Ils ont également un accès continu aux systèmes critiques au sein du réseau et sont souvent oubliés une fois créés. Tout cela en fait des cibles de grande valeur pour les attaquants. Compromettre un SPN peut conduire à un accès non autorisé à des services critiques et potentiellement permettre aux attaquants de se déplacer latéralement dans le réseau et d'escalader leurs privilèges

Comment les SPNs faibles peuvent être exploités

Lorsque les SPNS sont configurés de manière peu sûre, ils peuvent être exploités via des attaques telles que le Kerberoasting. Voici comment un attaquant procéderait à une telle attaque :

• Un attaquant avec des privilèges de domaine minimaux peut demander des tickets de service pour n'importe quel SPN Demande des tickets de service pour ces SPN
• Le ticket de service, chiffré avec le hachage du mot de passe du compte de service, peut être extrait et emporté hors ligne pour être craqué
• Effectue du craquage de mot de passe hors ligne sur ceux-ci et si le mot de passe est faible, les attaquants peuvent potentiellement le craquer et obtenir l'accès au compte de service, souvent avec des privilèges élevés

Une fois que l'attaquant a craqué le mot de passe d'un compte de service et si ce compte dispose de privilèges élevés, il peut se déplacer latéralement à travers le réseau ou escalader son accès.

Meilleures pratiques pour sécuriser les SPNs et les comptes de service

Voici une liste des meilleures pratiques pour atténuer les risques de sécurité associés aux SPN :

• Utilisez des mots de passe longs et complexes pour les comptes avec SPN et faites-les tourner régulièrement
• Évitez d'attribuer des SPN aux comptes à privilèges élevés tels que les administrateurs de domaine
• Restreindre les comptes de service uniquement aux permissions nécessaires à leur fonction
• Désactivez la connexion interactive pour les comptes de service
• Surveillez l'utilisation inattendue des commandes liées à SPN dans PowerShell.
• Étant donné que tout utilisateur avec une authentification de domaine peut rechercher des SPN, vous devriez limiter qui peut effectuer ces requêtes en changeant les permissions dans Active Directory.

Détection et atténuation des abus de SPN

Surveillance et audit des activités liées aux SPN

La surveillance continue de votre environnement AD et l'audit des événements liés à Kerberos peuvent s'avérer très efficaces pour prévenir l'abus de SPN. Certaines des choses que vous devriez détecter incluent :

• Des demandes d'énumération de SPN inhabituelles car les attaquants peuvent interroger AD pour les SPN en utilisant des outils LDAP.
• Des demandes fréquentes de tickets Kerberos car une augmentation soudaine des demandes de tickets de service pourrait indiquer une attaque en cours.
• Connexions de comptes de service depuis des emplacements inattendus au lieu des emplacements désignés habituels.
• Les tentatives d'authentification échouées comme des échecs répétés suggèrent une attaque par force brute ou des password spraying tentatives.

Mise en œuvre de stratégies d'atténuation contre les attaques basées sur SPN

Si votre organisation fonctionne dans un environnement Windows Active Directory, vous devriez envisager les contrôles de sécurité préventifs suivants pour minimiser le risque d'abus de SPN et d'attaques de Kerberoasting.

• Utilisez des mots de passe longs et complexes (minimum absolu de 14 caractères) pour les comptes de service
• Empêchez la réutilisation des mots de passe sur différents comptes et faites tourner les mots de passe régulièrement
• Appliquez le principle of least privilege pour limiter les permissions des comptes.
• Appliquez des durées de vie de ticket Kerberos plus courtes pour minimiser la fenêtre d'attaque
• Examinez régulièrement et supprimez les SPNs obsolètes ou inutiles
• Adoptez une stratégie de défense multicouche combinant une gestion solide des comptes de service, une surveillance sophistiquée et des programmes de formation réguliers.

Utilisation de comptes de service gérés par groupe et de méthodes de chiffrement robustes

Mettez en œuvre des comptes de service gérés par groupe (gMSAs) pour bénéficier d'une gestion automatisée des mots de passe. Les comptes de service gérés par groupe (gMSAs) sont des comptes de service spécialisés dans Active Directory offrant des fonctionnalités de sécurité améliorées par rapport aux comptes de service traditionnels. Ils sont particulièrement utiles pour les serveurs joints à un domaine exécutant des services tels que SQL Server, les applications web IIS, les tâches planifiées et d'autres services nécessitant de fonctionner dans un contexte de sécurité avec des permissions spécifiques. L'utilisation des gMSAs permettra d'éliminer les attributions manuelles de mots de passe et de réduire le risque de vol d'identifiants. En ce qui concerne le chiffrement, appliquez un chiffrement Kerberos AES128/AES256 fort tout en désactivant les types de chiffrement DES et RC4 plus faibles dans Active Directory.

Applications pratiques et études de cas

Comme mentionné, les SPN sont utilisés dans l'authentification Kerberos pour les applications web et les bases de données. IIS utilise le SPN au format « HTTP/NomDuServeur » qui est mappé au compte de domaine exécutant le pool d'applications, tandis que « MSSQLSvc/hôte.domaine.com:1433 » est un exemple de compte de service SQL. Le rôle des Noms de Principal de Service (SPN) évolue au-delà des cas d'utilisation traditionnels cependant, à mesure que les entreprises adoptent de plus en plus des architectures de réseau hybrides. Aujourd'hui, nous voyons même les SPN faciliter l'authentification sécurisée entre les ressources sur site et les applications natives du cloud. D'autres exemples incluent :

• Les SPNs sont utilisés pour gérer les identités et l'accès aux applications et services conteneurisés situés dans des environnements conteneurisés.
• Les environnements périphériques utilisent des SPNs pour faciliter la communication sécurisée entre les dispositifs de bord et les ressources cloud centralisées.
• Azure AD Connect utilise des SPN pour les services de synchronisation entre AD on-prem et Azure AD.

Il y a également une utilisation croissante des SPN au sein des environnements d'entreprise aujourd'hui. Par exemple, les équipes de sécurité surveillent les journaux d'utilisation des SPN pour détecter les tentatives d'accès non autorisées ou les échecs de Kerberos. D'autres exemples incluent :

• Single Sign-On (SSO) : Les SPN permettent un SSO basé sur Kerberos à travers plusieurs applications et services.
• Intégration d'applications : les SPNs facilitent la communication sécurisée entre différentes applications et services d'entreprise.
• L'authentification déléguée : les SPN permettent aux services de s'authentifier au nom des utilisateurs pour les applications multi-niveaux.

Conclusion

Les Service Principal Names (SPNs) sont un pilier de l'authentification Kerberos depuis la création d'Active Directory. Ils ont été un élément essentiel pour de nombreux services classiques sur lesquels les utilisateurs du réseau comptent et les SPNs jouent un rôle crucial pour assurer des opérations sécurisées et fluides à travers de nombreux services en arrière-plan. Alors que les organisations continuent de s'étendre et d'évoluer, les applications des SPNs se diversifient dans des domaines tels que l'intégration au cloud et l'IoT. Avec l'accent croissant mis sur la sécurité dans les entreprises aujourd'hui, il est très probable que les SPNs joueront un rôle plus important, s'adaptant aux nouvelles technologies et aux défis de sécurité dans le paysage numérique en constante expansion.

Qu’est-ce que SPN ?

Un Service Principal Name (SPN) est un identifiant unique qui relie une instance de service spécifique au compte Active Directory qui l’exécute. Les SPN doivent être uniques dans toute la forêt Active Directory.

Si deux comptes possèdent le même SPN, le contrôleur de domaine ne peut pas déterminer lequel doit recevoir un ticket, et l'authentification échoue. Si aucun compte ne possède le SPN, la demande échoue complètement et le client revient généralement à NTLM, qui comporte ses propres risques.

Un SPN enregistré sur un compte utilisateur personnel plutôt que sur un compte de service géré rend cette attaque possible. La défense est l’hygiène des comptes de service. Utilisez Group Managed Service Accounts. Appliquez des mots de passe longs et générés aléatoirement sur tout compte détenant encore un SPN. Surveillez l’ID d’événement 4769 pour détecter les pics de demandes de tickets qui trahissent l’attaque.

Rôle des SPN dans l'authentification Kerberos

Ils sont également la surface d'attaque pour le Kerberoasting. Tout utilisateur authentifié sur le domaine peut demander un ticket de service Kerberos pour un compte portant un SPN et le craquer hors ligne pour obtenir le mot de passe du compte, sans déclencher de seuil de verrouillage.

1. Le client construit un SPN pour le service auquel il souhaite accéder.

Un environnement Active Directory exécutant SQL Server, IIS, Exchange et des applications personnalisées nécessite que chaque service s’authentifie sans demander aux utilisateurs leurs identifiants à chaque requête ni intégrer de mots de passe dans les fichiers de configuration. Les Service Principal Names rendent cela possible.

Lorsqu'un client demande l'accès à un service, le flux d'authentification Kerberos suit une séquence définie :

Les SPN existent sur les objets ordinateurs et les comptes de service en tant qu'attribut multivalué appelé servicePrincipalNameExpand. Chaque entrée de cet attribut représente un service enregistré. Un compte qui exécute plusieurs services, ou un service accessible via plusieurs noms d'hôtes, possède plusieurs entrées SPN.

1. Le client demande un ticket de service au contrôleur de domaine en utilisant ce SPN.
2. Le client présente le ticket au service pour l'authentification, et aucun mot de passe n'est transmis sur le réseau.
3. Le contrôleur de domaine recherche le SPN dans Active Directory.
4. Une fois trouvé, le contrôleur de domaine délivre un ticket de service chiffré avec les identifiants du compte de service.

Structure et composants de SPN

Cette séquence explique pourquoi la précision du SPN est importante. Un SPN manquant, dupliqué ou mal configuré interrompt la recherche à l’étape 3, provoquant l’échec de l’authentification ou un retour à NTLM.

Composants d’un SPN

Un SPN n’est pas une valeur unique, mais une chaîne structurée composée de plusieurs composants. Comprendre cette structure est essentiel pour un enregistrement correct, le dépannage et la revue de sécurité.

Chaque SPN suit un format défini qui identifie le service, l’hôte sur lequel il s’exécute, et éventuellement le port qu’il utilise. Les composants sont :

Formats SPN courants dans Active Directory

• Compte : le compte Active Directory associé au service. Ce n'est pas une partie de la chaîne SPN elle-même, mais c'est l'objet auquel le SPN est enregistré.
• Port (optionnel) : inclus lorsque le service fonctionne sur un port non standard (par exemple, MSSQLSvc/host.domain.com:1433Expand).
• Classe de service : le nom du type de service, tel que MSSQLSvcExpand pour Microsoft SQL Server ou HTTPExpand pour les services web.
• Nom d’hôte : le serveur ou l’hôte où le service s’exécute, exprimé soit comme un nom NetBIOS (par ex., FileServerExpand) ou un nom de domaine pleinement qualifié (par ex., fileserver.company.comExpand).

Le format ServiceClass/Hostname: PortExpand produit des chaînes prévisibles et reconnaissables selon les types de service. Les exemples courants incluent :

• Services web : HTTP/webserver.netwrix.comExpand
• SQL Server : MSSQLSvc/myhost.redmond.microsoft.com:1433Expand
• Partages de fichiers : CIFS/fileserver.contoso.comExpand
• Services de Bureau à Distance : TERMSRV/rdserver.abcdomain.comExpand

Comment Active Directory stocke et résout les SPN

• Authentification LDAP : LDAP/domaincontroller.fabrikam.comExpand

L'attribut servicePrincipalName

Les SPN sont des attributs associés aux objets AD tels que les comptes utilisateur, les comptes de service ou les objets ordinateur. Ils agissent comme des étiquettes indiquant quels services fonctionnent sous quels comptes. Cette connexion permet aux ordinateurs d’utiliser Kerberos pour une authentification sécurisée sans envoyer les mots de passe sur le réseau.

Lorsque vous installez ou configurez un service, il enregistre un SPN qui permet à Kerberos d’associer les demandes d’authentification au compte correct. Sans un SPN correctement configuré, l’authentification Kerberos échouera, ce qui peut entraîner des erreurs d’authentification et des interruptions de service.

Lorsqu'un client demande l'accès à un service, il construit un SPN pour ce service, le soumet au contrôleur de domaine, et le DC recherche ce SPN dans l'annuaire. S'il est trouvé, il délivre un ticket de service Kerberos. Aucun mot de passe n'est transmis sur le réseau.

Comment l’unicité du SPN permet une résolution correcte du service

Vous pouvez afficher les SPN d’un objet AD en utilisant la commande : setspn –L hostname. Dans l’exemple ci-dessous, la commande a été utilisée pour afficher la liste des SPN générés par un contrôleur de domaine pour un domaine appelé ABCDomain.com.

Les SPN sont stockés dans Active Directory en tant que partie de l'attribut servicePrincipalName d'un objet. Cet attribut existe sur les comptes ordinateurs et les comptes de service et contient une liste de tous les SPN enregistrés pour cet objet. Vous pouvez le voir via l'onglet des propriétés d'un objet dans Active Directory Users and Computers, comme montré dans la capture d'écran ci-dessous.

HOST SPNs et quand AD les gère automatiquement

Le tableau ci-dessous résume quand utiliser les HOST SPNs par rapport aux SPNs personnalisés :

Les HOST SPN sont une catégorie spéciale de SPN automatiquement enregistrés sur les objets ordinateurs par Active Directory. Ils servent d’identifiant universel pour les services s’exécutant sous le compte Local System ou Network Service sur une machine, couvrant de nombreux services Windows standard sans nécessiter d’entrées SPN manuelles.

Lors du dépannage des problèmes d’authentification, les SPN en double doivent être parmi les premières choses vérifiées. Utilisez setspn -XExpand pour détecter les doublons dans un domaine, et setspn -FExpand pour rechercher dans toute la forêt.

Chaque SPN doit être unique dans toute la forêt Active Directory. Cette unicité permet à Kerberos authentication de diriger les requêtes de service vers le bon compte. Si deux comptes ont le même SPN, le contrôleur de domaine ne peut pas déterminer lequel utiliser, ce qui entraîne des échecs d'authentification, des erreurs de connexion intermittentes et des connexions de service rompues.

Ne modifiez jamais manuellement les HOST SPN. Active Directory les gère automatiquement et les modifications peuvent perturber les services essentiels.

Comment configurer et gérer les SPN

Étape 1 : Identifiez le service et le compte cible

Étape 2 : Vérifiez les SPN existants ou en double

Une configuration correcte du SPN est une condition préalable au fonctionnement de l'authentification Kerberos. Le processus suit une séquence cohérente quel que soit le type de service, et sauter des étapes est la cause la plus fréquente de problèmes liés au SPN.

Avant de vous inscrire, confirmez que le SPN n'existe pas déjà sur un autre compte. Utilisez les commandes suivantes pour interroger l'annuaire :

L’enregistrement d’un SPN en double peut provoquer des échecs d’authentification et être difficile à diagnostiquer par la suite.

Étape 3 : Enregistrez le SPN avec setspn

Avant d’enregistrer un SPN, identifiez deux éléments : la classe et le format de service nécessaires, ainsi que le compte Active Directory qui exécutera le service. Pour les services standards (SQL Server, IIS, Exchange), la classe de service est bien documentée. Pour le compte, privilégiez un Active Directory service account dédié ou, si possible, une Group Managed Service Account (gMSA) plutôt qu’un compte partagé ou personnel.

Pour SQL Server fonctionnant sur un port non standard :

Utilisez setspn -SExpand (ajout sécurisé) pour enregistrer le SPN. Le flag -S vérifie automatiquement les doublons avant de créer l'entrée, ce qui est plus sûr que l'ancien flag -A :

Étape 4 : Vérifiez l’enregistrement

Vous pouvez également enregistrer des SPN via PowerShell en utilisant les cmdlets Set-ADUser ou Set-ADComputer, ce qui est utile pour les déploiements automatisés ou les enregistrements en masse.

Vous pouvez également vérifier en utilisant PowerShell :

Après l’enregistrement, confirmez que le SPN apparaît sur le compte correct :

La sortie doit lister le SPN nouvellement enregistré ainsi que tous les autres déjà attribués à ce compte.

Étape 5 : Tester l'authentification Kerberos

Correction des erreurs courantes de configuration SPN

La plupart des problèmes SPN se répartissent en un petit nombre de catégories. Chacune nécessite une correction ciblée :

Dans le Visualiseur d’événements Windows, une demande de ticket de service Kerberos réussie apparaît sous l’ID d’événement 4769. Si l’authentification revient à NTLM, il est probable que le SPN soit manquant, mal formé ou enregistré sur le mauvais compte.

Une fois le SPN enregistré, vérifiez que l'authentification Kerberos réussit. Connectez-vous au service avec des identifiants de domaine, puis exécutez klistExpand pour confirmer que le DC a délivré un ticket de service Kerberos (et non un ticket NTLM).

Bonnes pratiques pour l’enregistrement SPN

• SPN en double : Utilisez setspn -DExpand pour supprimer le SPN du compte incorrect, puis vérifiez qu’il reste sur le bon. Les doublons apparaissent souvent après un renommage de serveur ou une migration de compte.
• SPN obsolètes après un renommage de serveur : Les anciens SPN référant l'ancien nom d'hôte doivent être supprimés et de nouveaux enregistrés sous le nom actuel.
• SPN manquants : Si Kerberos échoue et revient à NTLM, vérifiez si le SPN existe en utilisant setspn -QExpand. Enregistrez-le s'il est absent.
• SPN enregistrés sur le mauvais compte : Supprimez-les avec setspn -DExpand et réenregistrez-les sur le compte de service correct.

Établir des pratiques cohérentes pour la gestion des SPN réduit à la fois les défaillances opérationnelles et les risques de sécurité :

• Effectuez des audits réguliers PowerShell pour identifier les SPN enregistrés sur des comptes inappropriés.
• Attribuez les SPN à des comptes de service dédiés, pas aux comptes utilisateur personnels ni aux comptes Domain Admin.
• Utilisez setspn -SExpand (pas -A) lors de l'enregistrement pour éviter les doublons accidentels.
• Utilisez un format de nommage standardisé dans tout votre environnement pour simplifier les audits.

Risques de sécurité des SPN mal configurés

Kerberoasting

• Attribuez aux comptes les autorisations minimales nécessaires. L'enregistrement SPN nécessite un accès en écriture à l'attribut servicePrincipalNameExpand, qui ne doit pas être accordé de manière large.

Les comptes de service associés aux SPN sont parmi les identités les plus ciblées dans Active Directory. Contrairement aux comptes utilisateurs standards, ils disposent souvent de privilèges élevés, conservent un accès persistant aux systèmes critiques et sont rarement révisés une fois créés. Cette combinaison crée des risques de sécurité liés aux SPN mal configurés.

Attaques par ticket argenté

Un attaquant peut demander le ticket, l’extraire et effectuer un craquage de mot de passe hors ligne sans déclencher de verrouillages ni générer de bruit réseau important.

Kerberoasting est la technique d'attaque basée sur SPN la plus répandue. Tout utilisateur authentifié sur le domaine, y compris les comptes à privilèges faibles, peut demander un ticket de service Kerberos pour n'importe quel SPN dans l'annuaire. Ce ticket est chiffré avec le hash du mot de passe du compte de service.

Le chiffrement RC4 rend cette attaque beaucoup plus rapide car les tickets Kerberos chiffrés en RC4 sont plus faciles à craquer que ceux modernes protégés par AES, c’est pourquoi Microsoft déprécie activement RC4 dans les environnements AD.

Si le compte de service utilise un mot de passe faible ou réutilisé, l'attaquant peut récupérer les identifiants en clair et accéder au service, souvent avec des privilèges élevés.

Mouvement latéral via des comptes de service compromis

Comment se défendre contre les attaques basées sur SPN

Escalade de privilèges via des SPN à privilèges élevés

Les SPN enregistrés sur des comptes avec des permissions excessives, en particulier les comptes avec des droits de Domain Admin ou un accès illimité aux systèmes critiques, représentent les configurations les plus risquées. Une attaque Kerberoasting réussie contre l’un de ces comptes ne compromet pas seulement un service ; elle peut donner à un attaquant un contrôle au niveau du domaine.

Détection de Kerberoasting et d’énumération SPN

Une suite naturelle au Kerberoasting est l'attaque par ticket argenté. Une fois qu'un attaquant craque le hash du mot de passe d'un compte de service, il peut l'utiliser pour forger des tickets de service Kerberos entièrement hors ligne, sans interaction supplémentaire avec le contrôleur de domaine. Ces tickets argentés offrent un accès persistant au service ciblé et sont particulièrement difficiles à détecter car ils contournent entièrement le DC.

Les comptes de service ont généralement accès à plusieurs systèmes. Lorsqu'un attaquant compromet l'un d'eux, il obtient un point d'appui qui permet un mouvement latéral dans l'environnement. Comme les comptes de service sont souvent exclus des règles standard de surveillance et de détection des anomalies, ce mouvement peut passer inaperçu pendant de longues périodes.

La surveillance continue de votre environnement AD est la première ligne de défense. Les indicateurs à surveiller incluent :

La défense contre les attaques basées sur SPN s'articule autour de trois axes : détecter rapidement les abus, répondre efficacement lorsqu'ils surviennent, et renforcer l'environnement pour réduire la surface d'attaque avant qu'un incident ne se produise.

• Requêtes inhabituelles d’énumération SPN. Les attaquants utilisent souvent des outils LDAP pour lister tous les SPN d’un domaine lors de la reconnaissance.
• Connexions de comptes de service depuis des hôtes inattendus ou à des heures inhabituelles.

Restreindre qui peut interroger les SPN en modifiant les permissions dans Active Directory réduit la fenêtre de reconnaissance disponible aux attaquants peu privilégiés.

Contenir et répondre aux abus de SPN

• Une augmentation soudaine de l’ID d’événement 4769 (demandes de tickets de service Kerberos), en particulier ceux utilisant le chiffrement RC4 (type de chiffrement 0x17), indique fortement un Kerberoasting, car les attaquants préfèrent les tickets RC4 pour un craquage plus rapide.
• Tentatives répétées d’authentification échouée, pouvant indiquer des attaques par force brute ou password-spraying contre des identifiants compromis.

Lorsqu’un abus basé sur SPN est détecté, la priorité est de limiter la capacité de l’attaquant à utiliser les identifiants compromis :

• Réinitialisez immédiatement le mot de passe du compte de service affecté avec un identifiant long généré aléatoirement.
• Vérifiez si le compte détient plus de privilèges que sa fonction ne l'exige et réduisez-les.
• Examinez tous les systèmes auxquels le compte de service a accès et auditez les activités récentes pour détecter des signes de mouvement latéral.

Renforcement des comptes de service activés SPN

Le durcissement proactif élimine bon nombre des conditions qui rendent les attaques basées sur SPN viables :

• Utilisez des mots de passe longs générés aléatoirement (minimum 25 caractères) pour les comptes de service et faites-les tourner selon un calendrier défini.
• Révoquez tous les tickets Kerberos actifs émis pour le compte en réinitialisant les clés de chiffrement Kerberos du compte (une réinitialisation krbtgt n’est pas nécessaire pour atténuer les silver tickets ; réinitialiser le mot de passe du compte de service invalide les tickets falsifiés).
• Désactivez la connexion interactive pour les comptes de service afin de limiter leur utilité en cas de compromission.
• Appliquez le principe du moindre privilège. Les comptes de service ne doivent avoir accès qu’aux systèmes et données nécessaires à leur fonction.

Utilisation de gMSA et du chiffrement AES pour éliminer le risque permanent

• Migrez vers Group Managed Service Accounts autant que possible, car ils automatisent la gestion des mots de passe et rendent le Kerberoasting beaucoup plus difficile.

Les Group Managed Service Accounts (gMSA) sont des comptes de service spécialisés qui éliminent totalement le besoin de gérer les mots de passe manuellement. Active Directory gère automatiquement les mots de passe gMSA, les faisant tourner selon un calendrier défini avec des identifiants longs et générés aléatoirement que les administrateurs de service et de domaine ne voient ni ne manipulent directement.

SPN dans les environnements hybrides et modernes

Par défaut, Windows fait pivoter les mots de passe gMSA tous les 30 jours, et l'intervalle est contrôlé par l'attribut msDS‑ManagedPasswordInterval (ou le paramètre ManagedPasswordIntervalInDays lors de la création du gMSA), qui ne peut être défini qu'au moment de la création.

Pour les services qui ne prennent pas en charge les gMSA, appliquez le chiffrement Kerberos AES-128 ou AES-256 et désactivez explicitement les types de chiffrement plus faibles RC4 et DES dans Active Directory. Le chiffrement RC4 est celui utilisé par défaut dans les attaques Kerberoasting ; le supprimer force l’utilisation d’AES, qui est beaucoup plus résistant au craquage hors ligne.

• N’attribuez jamais de SPN à des comptes membres de Domain Admin ou d’autres groupes à privilèges élevés.

SPN et Microsoft Entra Connect

Le rôle des SPNs s'est étendu au-delà de l'Active Directory traditionnel sur site, à mesure que les organisations adoptent des architectures hybrides et des charges de travail conteneurisées. Les SPNs restent pertinents partout où l'authentification Kerberos est utilisée et, dans certains contextes plus récents, ils permettent des schémas d'authentification qui n'existaient pas dans la conception originale d'AD.

SPN dans des environnements containerisés

Authentification déléguée dans les applications multi-niveaux

Microsoft Entra Connect utilise des SPN pour ses services de synchronisation entre Active Directory local et Entra ID (anciennement Azure AD). Le compte de service de synchronisation nécessite des SPN correctement configurés pour s'authentifier auprès des deux annuaires. Des SPN mal configurés ou manquants peuvent interrompre silencieusement la synchronisation des annuaires, provoquant l'obsolescence des données d'identité dans l'environnement hybride.

Délégation Kerberos permet à un service de s'authentifier auprès des ressources en aval au nom d'un utilisateur. Cela est courant dans les applications multi-niveaux où une interface web doit transmettre l'identité de l'utilisateur à une base de données backend.

Les charges de travail conteneurisées exécutées sur Windows Server peuvent utiliser les gMSA et, par extension, les SPN, pour Active Directory security. Les déploiements Kubernetes et Docker sur des hôtes joints au domaine peuvent être configurés pour demander des informations d'identification gMSA, permettant aux services conteneurisés de s'authentifier auprès des ressources intégrées à AD en utilisant Kerberos sans intégrer les informations d'identification dans les images des conteneurs.

Les SPN sont essentiels à cela : la délégation est configurée sur le compte de service détenant le SPN, et chaque étape dans la chaîne d'authentification dépend des SPN correctement enregistrés.

Les SPN sont fondamentaux et de plus en plus ciblés

La délégation sans contrainte, où un service peut usurper l’identité de n’importe quel utilisateur sur n’importe quelle ressource, représente une surface d’attaque importante et doit être remplacée par une délégation restreinte ou une délégation restreinte basée sur les ressources autant que possible.

Les Service Principal Names sont une pierre angulaire de l'authentification Kerberos depuis la création d'Active Directory. Ils permettent une authentification sécurisée des services sans mot de passe dans les environnements d'entreprise, mais uniquement lorsqu'ils sont correctement configurés, régulièrement audités et strictement contrôlés.

Netwrix propose des outils spécialement conçus pour les deux principaux défis de sécurité SPN : détecter les attaques en cours et maintenir la visibilité sur les modifications AD qui introduisent des risques.

Comment Netwrix peut aider

À mesure que les organisations s’étendent aux infrastructures hybrides, aux conteneurs et aux systèmes d’identité intégrés au cloud, les SPN apparaissent dans davantage d’endroits et sont liés à des comptes disposant d’un accès plus large que jamais.

Le calcul des menaces a changé en conséquence. Le Kerberoasting est devenu l'une des techniques de mouvement latéral les plus couramment observées lors des violations d'entreprise, précisément parce que les SPN sont à la fois omniprésents et peu surveillés. Les mauvaises configurations qui provoquaient autrefois des échecs d'authentification font désormais partie de la surface d'attaque.

Comprendre les SPN, leur structure, la façon dont AD les résout et comment les attaquants exploitent des configurations faibles est la première étape pour les sécuriser. Les étapes opérationnelles couvertes dans cet article fournissent une base. En s’appuyant sur cela, la surveillance continue, les audits réguliers des SPN et, lorsque cela est possible, la migration vers gMSA aident les organisations à anticiper la menace.

Netwrix Threat Manager détecte les attaques basées sur l’identité, y compris le Kerberoasting, les requêtes d’énumération SPN et les demandes suspectes de tickets de service dans Active Directory sur site et Entra ID.

Cela se corrèle avec une activité anormale au niveau du compte. Lorsqu’un utilisateur à faible privilège demande soudainement 50 tickets de service, les équipes de sécurité le considèrent comme une alerte consolidée unique plutôt que comme des entrées de journal isolées.

Demandez une démo pour voir comment Netwrix peut vous aider à détecter les abus de SPN, auditer les modifications AD en temps réel et réduire la surface d'attaque avant que les adversaires ne l'exploitent.

Netwrix Auditor suit chaque modification de l'attribut servicePrincipalName dans votre environnement AD, avec les valeurs avant et après ainsi que le compte responsable de chaque changement. Lorsqu'un SPN est enregistré sur un compte à privilèges élevés ou supprimé de manière inattendue d'un compte de service, Auditor affiche immédiatement ce changement.