Comptes de service, d’utilisateur et de sécurité
Pendant l’installation et les opérations quotidiennes d’Operations Manager, vous êtes invité à fournir des informations d’identification pour plusieurs comptes. Cet article fournit des informations sur chacun de ces comptes, notamment le sdk et le service de configuration, l’installation de l’agent, l’écriture de l’entrepôt de données et les comptes lecteur de données.
Remarque
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 en fonction des besoins, vous devrez modifier les mots de passe sur les comptes de service en fonction de la planification, utiliser des comptes système ou 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 est utilisé pour accomplir des activités de surveillance telles que l’exécution d’un moniteur ou l’exécution d’une tâche. Les autres exemples d’actions MonitoringHost.exe effectuent les opérations suivantes :
- 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 à l’aide des 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 du processus MonitoringHost.exe s’exécutant sur un agent est appelé compte d’action de l’agent. Le compte d’action utilisé par le processus de MonitoringHost.exe sur un serveur d’administration est appelé compte d’action du serveur d’administration. Le compte d’action utilisé par le processus de MonitoringHost.exe sur un serveur de passerelle est appelé compte d’action du serveur de passerelle. Sur tous les serveurs d’administration du groupe d’administration, nous vous recommandons d’accorder les droits d’administration locaux du compte, sauf si l’accès à privilèges minimum est requis par la stratégie de sécurité informatique de votre organisation.
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 d’identification et les profils d’identification, consultez la section Comptes d’identification. Lorsqu’un agent exécute des actions en tant que compte d’action par défaut et/ou compte d’identification, une nouvelle instance de MonitoringHost.exe est créée pour chaque compte.
Lorsque vous installez Operations Manager, vous avez la possibilité de spécifier un compte de domaine ou d’utiliser LocalSystem. L’approche plus sécurisée consiste à spécifier un compte de domaine, ce qui vous permet de sélectionner un utilisateur disposant des privilèges minimum nécessaires pour votre environnement.
Vous pouvez utiliser un compte avec privilège minimum pour le compte d’action de l’agent. Sur les ordinateurs exécutant Windows Server 2008 R2 ou version ultérieure, le compte doit disposer des privilèges minimaux suivants :
- ê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.
Remarque
Les privilèges minimaux décrits ci-dessus sont les privilèges les plus bas 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 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 être accordé soit se connecter en tant que service (SeServiceLogonRight) soit se connecter en tant qu’autorisation Batch (SeBatchLogonRight) si votre stratégie de sécurité n’autorise pas l’octroi d’un compte de service à une session interactive, par exemple lorsque l’authentification par carte à puce 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 accordé avec l’autorisation SeServiceLogonRight (Log on as a Service). Pour modifier le type d’ouverture de session pour le service 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 Monitoring du type de connexion du compte d’action 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.
Service de configuration System Center et compte de service d’accès aux données System Center
Le service System Center Configuration et le compte de service d’accès aux données System Center sont utilisés par les services System Center Data Access et System Center Management Configuration pour mettre à jour les informations dans la base de données opérationnelle. Les informations d’identification utilisées pour le compte d’action sont affectées au rôle sdk_user dans la base de données opérationnelle.
Le compte doit être un utilisateur de domaine ou LocalSystem. Le compte utilisé pour le compte sdk et le compte de service de configuration doit recevoir 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 de privilège le plus élevé sur un ordinateur Windows, encore plus élevé que l’administrateur local. Lorsqu’un service s’exécute dans le contexte de LocalSystem, le service a un contrôle total des ressources locales de l’ordinateur et l’identité de l’ordinateur est utilisée lors de l’authentification auprès et de l’accès aux ressources distantes. L’utilisation du compte LocalSystem est un risque de sécurité, car elle ne respecte pas le principe du privilège minimum. En raison des droits requis sur l’instance SQL Server hébergeant la base de données Operations Manager, un compte de domaine disposant des autorisations de privilège minimum est nécessaire pour éviter tout risque de sécurité si le serveur d’administration du groupe d’administration est compromis. Les raisons sont les suivantes :
- LocalSystem n’a pas de mot de passe
- Il n’a pas son propre profil
- Il dispose de privilèges étendus sur l’ordinateur local
- Il présente les informations d’identification de l’ordinateur aux ordinateurs distants
Remarque
Si la base de données Operations Manager est installée sur un ordinateur distinct du serveur d’administration et que LocalSystem est sélectionné pour le compte de service d’accès aux données et de configuration, le compte d’ordinateur de l’ordinateur du serveur d’administration est affecté au rôle sdk_user sur l’ordinateur de base de données Operations Manager.
Pour plus d’informations, consultez LocalSystem.
Compte d'écriture de l'entrepôt de données
Le compte d’écriture de l’entrepôt de données est le compte utilisé pour écrire des données du serveur d’administration dans l’entrepôt de données reporting, et il lit les données de la base de données Operations Manager. Le tableau suivant décrit les rôles et l’appartenance attribués au compte d’utilisateur de domaine pendant 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, définir l’utilisateur utilisé par SQL Server Reporting Services pour exécuter des requêtes sur l’entrepôt de données Reporting et définir le compte SQL Reporting Services pour se connecter au serveur d’administration. Ce compte d’utilisateur de domaine est ajouté au profil utilisateur administrateur de rapports. Le tableau suivant décrit les rôles et l’appartenance attribués au compte pendant 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 du serveur de rapports |
| 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 prévoyez d’utiliser pour le compte Lecteur de données reçoit l’ouverture de session en tant que service (pour 2019 et versions ultérieures) ou ouvrez une session en tant que service et autorisez l’ouverture de session localement (pour une version antérieure), le droit pour chaque serveur d’administration et sql Server hébergeant le rôle Reporting Server.
Compte d’installation de l’agent
Lorsque vous effectuez un déploiement d’agent basé sur la découverte, un compte est requis avec 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 n’a 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 Action de notification est le compte utilisé pour créer et envoyer des notifications. Ces informations d’identification doivent disposer de droits suffisants pour le serveur SMTP, le serveur de messagerie instantanée ou le serveur SIP utilisé pour les notifications.