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.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour