Partage via


Sécuriser des comptes de service basés sur l’utilisateur dans Active Directory

Les comptes d’utilisateur locaux représentent l’approche traditionnelle pour sécuriser les services s’exécutant sous Windows. Utilisez ces comptes seulement si les comptes de service géré de groupe (gMSA) et les comptes de service géré autonomes (sMSA) ne sont pas pris en charge par votre service. Pour plus d’information sur le type de compte à utilisez, consultez Sécurisation des comptes de service locaux.

Examinez également si vous pouvez déplacer votre service pour utiliser un compte de service Azure comme identité managée ou principal de service.

En savoir plus :

Vous pouvez créer des comptes d’utilisateur locaux pour fournir un contexte de sécurité aux services et les autorisations dont les comptes ont besoin pour accéder aux ressources locales et réseau. Les comptes d’utilisateur locaux nécessitent une gestion manuelle des mots de passe, comme tout autre compte d’utilisateur Active Directory (AD). Les administrateurs de service et de domaine sont tenus d’observer des processus stricts de gestion des mots de passe afin de préserver la sécurité de ces comptes.

Lorsque vous créez un compte d’utilisateur en tant que compte de service, utilisez-le pour un seul service uniquement. Utilisez une convention d’affectation de noms qui précise s’il s’agit d’un compte de service et le service auquel il est associé.

Avantages et défis

Les comptes d’utilisateur locaux sont un type de compte polyvalent. Les comptes d’utilisateur utilisés comme comptes de service peuvent être contrôlés par toutes les stratégies qui régissent les comptes d’utilisateur. Utilisez-les si vous ne pouvez pas utiliser de MSA. Déterminez également si un compte d’ordinateur est une meilleure option.

Les défis associés à l’utilisation de comptes d’utilisateur locaux sont résumés dans le tableau suivant :

Problème Limitation des risques
La gestion des mots de passe est manuelle et entraîne un affaiblissement de la sécurité et des temps d’arrêt du service - Garantir une complexité régulière des mots de passe et que les modifications sont régies par un processus qui assure la sécurité des mots de passe
- Coordonner les modifications de mot de passe avec un mot de passe de service, ce qui permet de réduire les temps d’arrêt du service
Il peut s’avérer difficile d’identifier les comptes d’utilisateur locaux qui agissent en tant que comptes de service - Documenter les comptes de service déployés dans votre environnement
- Suivre le nom du compte et les ressources accessibles par celui-ci
- Envisagez d’ajouter le préfixe svc aux comptes d’utilisateur utilisés comme comptes de service

Rechercher les comptes d’utilisateur locaux utilisés comme comptes de service

Les comptes d’utilisateur locaux sont comme n’importe quel autre compte d’utilisateur AD. Il peut être difficile de trouver ces comptes, car aucun attribut unique d’un compte d’utilisateur ne l’identifie comme un compte de service. Nous vous recommandons de créer une convention d’affectation de noms pour les comptes d’utilisateur qui les utilisent en tant que comptes de service. Par exemple, ajoutez le préfixe svc à un nom de service : svc-HRDataConnector.

Vous pouvez utiliser certains des critères suivants pour trouver des comptes de service. Toutefois, cette approche risque de ne pas trouver tous les comptes, par exemple :

  • Approuvé pour délégation
  • Les comptes avec des noms des principaux du service
  • Les comptes avec des mots de passe qui n’expirent jamais

Vous pouvez exécuter les commandes PowerShell suivantes pour rechercher les comptes d’utilisateur locaux créés pour les services :

Pour rechercher les comptes approuvés pour la délégation :


Get-ADObject -Filter {(msDS-AllowedToDelegateTo -like '*') -or (UserAccountControl -band 0x0080000) -or (UserAccountControl -band 0x1000000)} -prop samAccountName,msDS-AllowedToDelegateTo,servicePrincipalName,userAccountControl | select DistinguishedName,ObjectClass,samAccountName,servicePrincipalName, @{name='DelegationStatus';expression={if($_.UserAccountControl -band 0x80000){'AllServices'}else{'SpecificServices'}}}, @{name='AllowedProtocols';expression={if($_.UserAccountControl -band 0x1000000){'Any'}else{'Kerberos'}}}, @{name='DestinationServices';expression={$_.'msDS-AllowedToDelegateTo'}}

Pour rechercher les comptes avec des noms de principal du service :


Get-ADUser -Filter * -Properties servicePrincipalName | where {$_.servicePrincipalName -ne $null}

Pour rechercher les comptes dont les mots de passe sont définis pour ne jamais expirer :


Get-ADUser -Filter * -Properties PasswordNeverExpires | where {$_.PasswordNeverExpires -eq $true}

Vous pouvez également auditer l’accès aux ressources sensibles et archiver les journaux d’audit dans un système SIEM (Informations de sécurité et gestion d’événements). En utilisant des systèmes tels qu’Azure Log Analytics ou Microsoft Sentinel, vous pouvez rechercher et analyser les comptes de service.

Évaluer la sécurité des comptes d’utilisateur locaux

Évaluez la sécurité de vos comptes d’utilisateur locaux utilisés comme comptes de service à l’aide des critères suivants :

  • Stratégie de gestion des mots de passe
  • Comptes avec appartenance à des groupes privilégiés
  • Autorisations en lecture/écriture pour les ressources importantes

Atténuer les problèmes de sécurité potentiels

Consultez le tableau suivant pour connaître les problèmes de sécurité potentiels liés aux comptes d’utilisateur locaux et leurs atténuations :

Problème de sécurité Limitation des risques
Gestion des mots de passe - Assurez-vous que la complexité des mots de passe et la modification des mots de passe sont régies par des mises à jour régulières et des exigences de mot de passe fortes.
- Coordonnez les modifications de mot de passe avec une mise à jour de mot de passe pour réduire les temps d’arrêt du service
Le compte est membre de groupes privilégiés - Vérifier l’appartenance au groupe
- Supprimer le compte des groupes privilégiés
- Accorder au compte des droits et autorisations pour exécuter son service (consulter le fournisseur de services)
- Par exemple, refuser la connexion locale ou interactive
Le compte dispose d’autorisations d’accès en lecture/écriture sur des ressources sensibles - Auditer l’accès aux ressources sensibles
- Archiver les journaux d’audit dans un SIEM (Azure Log Analytics ou Microsoft Sentinel)
- Corriger les autorisations d’accès aux ressources si un niveau d’accès indésirable est détecté

Types de comptes sécurisés

Microsoft vous déconseille d’utiliser des comptes d’utilisateur locaux comme comptes de service. Pour les services utilisant ce type de compte, évaluez si une configuration gMSA ou sMSA peut être envisageable. Évaluez également la possibilité de déplacer le service vers Azure pour permettre l’utilisation de types de comptes plus sûrs.

Étapes suivantes

Pour en savoir plus sur la sécurisation des comptes de service :