Partager via

Utilisation du compte LocalSystem en tant que compte d’ouverture de session de service

  • Article

L’un des avantages de l’exécution sous le compte LocalSystem est que le service dispose d’un accès illimité aux ressources locales. Il s’agit également d’un inconvénient de LocalSystem, car un service LocalSystem peut faire des choses qui entraînent l’arrêt de l’ensemble du système. En particulier, un service s’exécutant en tant que LocalSystem sur un contrôleur de domaine (DC) a un accès illimité à services de domaine Active Directory. Cela signifie que les bogues dans le service, ou les attaques de sécurité sur le service, peuvent endommager le système ou, si le service se trouve sur un contrôleur de domaine, endommager l’ensemble du réseau d’entreprise.

Pour ces raisons, les administrateurs de domaine aux installations sensibles seront prudents quant à l’autorisation des services d’exécuter en tant que LocalSystem. En fait, ils peuvent avoir des politiques contre elle, en particulier sur les contrôleurs de domaine. Si votre service doit s’exécuter en tant que LocalSystem, la documentation de votre service doit justifier auprès des administrateurs de domaine les raisons pour lesquelles le service est autorisé à s’exécuter avec des privilèges élevés. Les services ne doivent jamais s’exécuter en tant que LocalSystem sur un contrôleur de domaine. Pour plus d’informations et un exemple de code montrant comment un programme d’installation de service ou de service peut déterminer s’il s’exécute sur un contrôleur de domaine, consultez Test de l’exécution sur un contrôleur de domaine.

Lorsqu’un service s’exécute sous le compte LocalSystem sur un ordinateur membre du domaine, le service dispose de tout accès réseau au compte d’ordinateur ou à tous les groupes dont le compte d’ordinateur est membre. Sachez que, dans Windows 2000, un compte d’ordinateur de domaine est un principal de service similaire à un compte d’utilisateur. Cela signifie qu’un compte d’ordinateur peut se trouver dans un groupe de sécurité et qu’un ACE dans un descripteur de sécurité peut accorder l’accès à un compte d’ordinateur.

N’oubliez pas que l’ajout de comptes d’ordinateur à des groupes n’est pas recommandé pour deux raisons :

  • Les comptes d’ordinateur sont soumis à la suppression et à la recréation si l’ordinateur quitte, puis rejoint le domaine.
  • Si vous ajoutez un compte d’ordinateur à un groupe, tous les services s’exécutant en tant que LocalSystem sur cet ordinateur sont autorisés à accéder aux droits d’accès du groupe. Cela est dû au fait que tous les services LocalSystem partagent le compte d’ordinateur de leur serveur hôte. Pour cette raison, il est particulièrement important que les comptes d’ordinateur ne soient pas membres d’un groupe d’administrateurs de domaine.

Les comptes d’ordinateur ont généralement peu de privilèges et n’appartiennent pas aux groupes. La protection ACL par défaut dans services de domaine Active Directory (AD DS) autorise un accès minimal pour les comptes d’ordinateur. Par conséquent, les services s’exécutant en tant que LocalSystem, sur des ordinateurs autres que des contrôleurs de domaine, n’ont qu’un accès minimal à AD DS.

Si votre service s’exécute sous LocalSystem, vous devez tester votre service sur un serveur membre pour vous assurer que votre service dispose de droits suffisants pour lire/écrire dans domaine Active Directory Contrôleurs. Un contrôleur de domaine ne doit pas être le seul ordinateur Windows sur lequel vous testez votre service. N’oubliez pas qu’un service exécuté sous LocalSystem sur un contrôleur de domaine Windows a un accès complet à AD DS et qu’un serveur membre s’exécute dans le contexte du compte d’ordinateur qui a beaucoup moins de droits.