Qu'est-ce que SPN et quel est 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.