Comptes de service, d’utilisateur et de sécurité

Important

Cette version d’Operations Manager a atteint la fin du support. Nous vous recommandons de mettre à niveau vers Operations Manager 2022.

Pendant la configuration et les opérations quotidiennes d’Operations Manager, vous serez invité à fournir des informations d’identification pour plusieurs comptes. Cet article fournit des informations sur chacun de ces comptes, notamment les comptes SDK et de service de configuration, Installation de l’agent, Écriture d’entrepôt de données et Lecteur de données.

Notes

L’installation d’Operations Manager provisionne toutes les autorisations SQL nécessaires.

Si vous utilisez des comptes de domaine et que votre objet de stratégie de groupe de domaine (GPO) a la stratégie d’expiration de mot de passe par défaut définie selon les besoins, vous devez soit modifier les mots de passe sur les comptes de service en fonction de la planification, utiliser des comptes système, soit configurer les comptes afin que les mots de passe n’expirent jamais.

Comptes d'action

Dans System Center Operations Manager, les serveurs d’administration, les serveurs de passerelle et les agents exécutent tous un processus appelé MonitoringHost.exe. MonitoringHost.exe permet d’effectuer des activités de surveillance, telles que l’exécution d’une analyse ou d’une tâche. Voici d’autres exemples d’actions que MonitoringHost.exe effectue :

  • Analyse et collecte des données des journaux d'événements Windows
  • Analyse et collecte des données des compteurs de performances Windows
  • Analyse et collecte des données WMI (Windows Management Instrumentation)
  • Exécution d’actions telles que des scripts ou des lots

Le compte qu'un processus MonitoringHost.exe identifie est appelé le compte d'action. MonitoringHost.exe est le processus qui exécute ces actions en utilisant les informations d'identification spécifiées dans le compte d'action. Une nouvelle instance de MonitoringHost.exe est créée pour chaque compte. Le compte d'action pour le processus MonitoringHost.exe qui s'exécute sur un agent est le compte d'action de l'agent. Le compte d'action utilisé par le processus MonitoringHost.exe sur un serveur d'administration est le compte d'action du serveur d'administration. Le compte d'action utilisé par le processus MonitoringHost.exe sur un serveur de passerelle est le compte d'action du serveur de passerelle. Sur tous les serveurs d’administration du groupe d’administration, nous vous recommandons d’accorder des droits d’administration locaux au compte, sauf si l’accès aux privilèges minimum est requis par la stratégie de sécurité informatique de votre organization.

Sauf si une action a été associée à un profil d’identification, les informations d’identification utilisées pour effectuer l’action seront celles que vous avez définies pour le compte d’action. Pour plus d'informations sur les comptes et les profils d'identification, consultez la section Comptes d'identification. Lorsqu’un agent exécute des actions en tant que compte d’action et/ou compte d’identification par défaut, une nouvelle instance de MonitoringHost.exe est créée pour chaque compte.

Quand vous installez Operations Manager, vous pouvez spécifier un compte de domaine ou utiliser LocalSystem. L’approche la plus sûre consiste à spécifier un compte de domaine, ce qui vous permet de sélectionner un utilisateur ayant les privilèges minimaux nécessaires pour votre environnement.

Vous pouvez utiliser un compte de privilège minimum pour le compte d’action de l’agent. Sur les ordinateurs exécutant Windows Server 2008 R2 ou une version ultérieure, le compte doit au minimum :

  • être membre du groupe Utilisateurs locaux ;
  • être membre du groupe local Utilisateurs de l'Analyseur de performances ;
  • permettre l’ouverture d’une session locale (autorisation SetInteractiveLogonRight), ce qui ne s’applique pas à Operations Manager 2019 et ultérieur.

Notes

Les droits minimaux décrits ci-dessus sont les droits les moins élevés pris en charge par Operations Manager pour le compte d'action. D'autres comptes d'identification peuvent avoir des droits moins élevés. Les privilèges réels requis pour le compte d’action et les comptes d’identification dépendent des packs d’administration qui s’exécutent sur l’ordinateur et de la façon dont ils sont configurés. Pour plus d’informations sur les droits spécifiques requis, consultez le guide du pack d’administration correspondant.

Le compte de domaine spécifié pour le compte d’action peut recevoir l’autorisation Se connecter en tant que service (SeServiceLogonRight) ou Se connecter en tant que batch (SeBatchLogonRight) si votre stratégie de sécurité n’autorise pas un compte de service à se voir accorder une session d’ouverture de session interactive, par exemple lorsque l’authentification smart carte est requise. Modifiez la valeur de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System Center\Health Service :

Le compte de domaine spécifié pour le compte d’action est autorisé à se connecter en tant que service (SeServiceLogonRight). Pour modifiez le type de connexion pour le service de contrôle d’intégrité,modifiez la valeur de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System Center\Health Service :

  • Nom : Worker Process Logon Type
  • Type : REG_DWORD
  • Valeurs : Quatre (4) - Se connecter en tant que traitement par lots, Deux (2) - Autoriser la connexion localement et Cinq (5) - Se connecter en tant que service. La valeur par défaut est 2.
  • Valeurs : Quatre (4) - Se connecter en tant que traitement par lots, Deux (2) - Autoriser la connexion localement et Cinq (5) - Se connecter en tant que service. La valeur par défaut est 5.

Vous pouvez gérer le paramètre à l’aide d’une stratégie de groupe. Pour ce faire, copiez le fichier ADMX healthservice.admx d’un serveur d’administration ou d’un système géré par agent, situé dans le dossier C:\Windows\PolicyDefinitions, puis configurez le paramètre healthservice.admx sous le dossier Computer Configuration\Administrative Templates\System Center - Operations Manager. Pour plus d’informations sur l’utilisation des fichiers ADMX de stratégie de groupe, consultez Gestion des fichiers ADMX de stratégie de groupe.

Compte Service de configuration de System Center et service d'accès aux données de System Center

Le compte Service de configuration de System Center et service d'accès aux données de System Center est utilisé par les services d'accès aux données de System Center et de configuration de l'administration de System Center pour mettre à jour les informations de la base de données opérationnelle. Les informations d'identification utilisées pour le compte d'action seront attribuées au rôle sdk_user dans la base de données opérationnelle.

Il doit s’agir d’un compte d’utilisateur de domaine ou d’un compte LocalSystem. Le compte utilisé pour le compte SDK et de service de configuration doit avoir des droits d’administration locaux sur tous les serveurs d’administration du groupe d’administration. L’utilisation du compte d’utilisateur local n’est pas prise en charge. Pour renforcer la sécurité, nous vous recommandons d’utiliser un compte d’utilisateur de domaine, et il s’agit d’un compte différent de celui utilisé pour le compte d’action du serveur d’administration. Le compte LocalSystem est le compte qui a le plus grand nombre de privilèges sur un ordinateur Windows. Il en a même plus que le compte Administrateur local. Lorsqu’un service s’exécute dans le contexte de LocalSystem, le service a un contrôle total sur les ressources locales de l’ordinateur, et l’identité de l’ordinateur est utilisée lors de l’authentification auprès des ressources distantes et de l’accès à celles-ci. L’utilisation d’un compte LocalSystem constitue un risque de sécurité, car il ne respecte pas le principe des privilèges minimum. En raison des droits exigés sur l’instance SQL Server qui héberge la base de données Operations Manager, il est nécessaire de disposer d’un compte de domaine avec des autorisations conformes au principe des privilèges minimaux pour éviter tout risque de sécurité, au cas où le serveur d’administration du groupe d’administration serait compromis. Les raisons sont les suivantes :

  • LocalSystem n’a aucun mot de passe
  • Il n’a pas son propre profil
  • Il a des privilèges étendus sur l’ordinateur local
  • Il présente les informations d’identification de l’ordinateur aux ordinateurs distants

Notes

Si la base de données Operations Manager est installée sur un ordinateur distinct du serveur d’administration et si LocalSystem est sélectionné en tant que compte de service Accès aux données et configuration, le compte d’ordinateur du serveur d’administration se voit attribuer le rôle sdk_user sur l’ordinateur hébergeant la base de données Operations Manager.

Pour plus d’informations, consultez à propos de LocalSystem.

Compte d'écriture de l'entrepôt de données

Le compte d'écriture de l'entrepôt de données est utilisé pour écrire des données depuis le serveur d'administration vers l'entrepôt de données Reporting, et pour lire des données à partir de la base de données Operations Manager. Le tableau suivant décrit les rôles et les appartenances attribués au compte de l’utilisateur du domaine lors de l’installation.

Application Base de données/rôle Rôle/compte
Microsoft SQL Server OperationsManager db_datareader
Microsoft SQL Server OperationsManager dwsync_user
Microsoft SQL Server OperationsManagerDW OpsMgrWriter
Microsoft SQL Server OperationsManagerDW db_owner
Operations Manager Rôle utilisateur Administrateurs de sécurité des rapports Operations Manager
Operations Manager compte d'identification Compte d'action d'entrepôt de données
Operations Manager compte d'identification Compte de lecteur de synchronisation de la configuration des entrepôts de données

Compte du lecteur de données

Le compte Lecteur de données est utilisé pour déployer des rapports, pour définir l’utilisateur que SQL Server Reporting Services utilise pour exécuter des requêtes dans l'entrepôt de données Reporting, et pour définir le compte SQL Reporting Services qui doit être connecté au serveur d'administration. Ce compte d’utilisateur du domaine est ajouté au profil utilisateur Administrateur de rapport. Le tableau suivant décrit les rôles et les appartenances attribués au compte lors de l’installation.

Application Base de données/rôle Rôle/compte
Microsoft SQL Server Instance d’installation de Reporting Services Compte d'exécution de Report Server
Microsoft SQL Server OperationsManagerDW OpsMgrReader
Operations Manager Rôle utilisateur Opérateurs de rapports Operations Manager
Operations Manager Rôle utilisateur Administrateurs de sécurité des rapports Operations Manager
Operations Manager compte d'identification Compte de déploiement des rapports des entrepôts de données
Service Windows SQL Server Reporting Services Compte d’ouverture de session

Vérifiez que le compte que vous envisagez d’utiliser comme compte de lecteur de données dispose du droit Se connecter en tant que service (pour 2019 et les versions ultérieures) ou Se connecter en tant que service et Autoriser la connexion localement (pour les versions antérieures) pour chaque serveur d’administration et pour l’instance SQL Server qui héberge le rôle de serveur de rapports.

Compte d'installation des agents

Quand vous effectuez un déploiement d’agent basé sur la découverte, vous devez avoir un compte ayant des privilèges d’administrateur sur les ordinateurs ciblés pour l’installation de l’agent. Le compte d'action du serveur d'administration est le compte par défaut pour l'installation de l'agent. Si le compte d’action du serveur d’administration ne dispose pas de droits d’administrateur, l’opérateur doit fournir un compte d’utilisateur et un mot de passe avec des droits d’administration sur les ordinateurs cibles. Ce compte est crypté avant son utilisation et il est ensuite ignoré.

Compte d'action de notification

Le compte d'action de notification est utilisé pour la création et l'envoi de notifications. Ces informations d’identification doivent disposer de droits suffisants pour le serveur SMTP, le serveur de messagerie instantanée ou le serveur SIP qui est utilisé pour les notifications.