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

L’un des avantages de l’exécution sous le compte LocalSystem est que le service dispose d’un accès total sans restriction aux ressources locales. Il s’agit également de l’inconvénient de LocalSystem, car un service LocalSystem peut effectuer des opérations qui entraîneraient la panne de l’ensemble du système. En particulier, un service exécuté en tant que LocalSystem sur un contrôleur de domaine dispose d’un accès illimité à services de domaine Active Directory. Cela signifie que des bogues dans le service ou des 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 dans les installations sensibles seront prudents quant à l’autorisation des services de s’exécuter en tant que LocalSystem. En fait, ils peuvent avoir des stratégies 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 aux administrateurs de domaine les raisons pour lesquelles le service a accordé le droit de 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 qui montre comment un service ou un programme d’installation 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 d’un accès réseau quelconque accordé au compte d’ordinateur ou à tous les groupes dont le compte d’ordinateur est membre. N’oubliez pas 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 faire partie d’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 aux groupes n’est pas recommandé pour deux raisons :

• Les comptes d’ordinateur sont sujets à 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. En effet, 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 des groupes d’administrateurs de domaine.

Les comptes d’ordinateur ont généralement peu de privilèges et n’appartiennent pas à des groupes. La protection ACL par défaut dans services de domaine Active Directory 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 les contrôleurs de domaine, n’ont qu’un accès minimal à services de domaine Active Directory.

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 sur 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 dispose d’un accès complet à services de domaine Active Directory et qu’un serveur membre s’exécute dans le contexte du compte d’ordinateur qui dispose de beaucoup moins de droits.