Exécution d’évaluations avec des comptes de services administrés

Les comptes de services administrés (MSAs) constituent un type d’entités de sécurité dans les versions actuellement prises en charge des services de domaine Active Directory. Ils partagent les caractéristiques des entités de sécurité d’ordinateur et d’utilisateur. Ils peuvent être ajoutés à des groupes de sécurité, peuvent authentifier et accéder à des ressources sur un réseau. Ils sont destinés à être utilisés par les services, les pools d’applications IIS et les tâches planifiées.

Avantage des comptes de services administrés

Les comptes de service administrés répondent aux défis spécifiques liés à l’utilisation de comptes d’utilisateur pour l’exécution de services, de tâches planifiées et de pools d’applications IIS :

• Gestion automatique des mots de passe
• Gestion des noms d’entités de services simplifiés (SPN)
• Ne peuvent pas être utilisés pour une connexion interactive à Windows
• Contrôlent facilement quels ordinateurs sont autorisés à authentifier des MSA et à exécuter un code dans leur contexte

Évaluations à la demande pouvant utiliser des comptes de service administrés

Les comptes de service administrés peuvent être configurés pour exécuter les évaluations à la demande suivantes

• Active Directory
• Sécurité Active Directory
• System Center Configuration Manager
• SharePoint
• SQL Server
• Client Windows
• Windows Server

Remarque

Les comptes de service administrés ne sont pas officiellement pris en charge par le service clientèle Microsoft pour certaines configurations d’environnement. Bien qu’ils fonctionnent dans la plupart des scénarios, il peut être nécessaire d’utiliser un compte de domaine quand les configurations d’environnement empêchent l’utilisation de comptes de service administrés.

Provisionnement de comptes de services administrés

Une condition préalable à la configuration d’une tâche planifiée d’évaluation à exécuter en tant que MSA consiste à provisionner ou à créer le MSA dans les services de domaine Active Directory. Chaque évaluation prise en charge spécifie les exigences d’autorisation et d’accès du compte de tâche planifiée à exécuter avec succès. Consultez les documents de prise en main sur l’évaluation prise en charge et les documents de conditions préalables pour les détails des conditions préalables d’accès du compte de tâches planifiées.

Il existe deux types de comptes de services administrés. Ces deux types peuvent être configurés pour la tâche planifiée d’évaluation pour les évaluations prises en charge :

• Les Comptes de services administrés autonomes (également appelés comptes virtuels) peuvent être autorisés à procéder à une authentification sur un ordinateur ayant joint un domaine unique.
• Les Comptes de services administrés de groupe peuvent être autorisés à procéder à des authentifications sur plusieurs ordinateurs de domaine.

Le module Windows PowerShell Active Directory est requis pour le provisionnement et la configuration des deux types de MSA. Ce module PowerShell est généralement installé sur les contrôleurs de domaine lors de l’installation du rôle de contrôleur de domaine.

Le module, composant des outils d’administrateur de serveur distant, peut être ajouté aux SKU Windows Server via Server Manager. Le module peut également être ajouté à Windows 10.

Scénario 1 – Compte de services administrés autonome (sMSA)

Le schéma de forêt des services de domaine Active Directory doit être au minimum égal à Windows Server 2008 R2 pour pouvoir provisionner avec succès des comptes de service administrés autonomes. Les ordinateurs exécutant des tâches planifiées en tant que sMSA doivent exécuter Windows Server 2012 ou une version plus récente.

Il y a trois étapes de provisionnement d’un sMSA pour exécuter des évaluations à la demande :

1. Créer le sMSA à l’aide de l’applet de commande PowerShell New-ADServiceAccount.
2. Autoriser la machine de collecte de données à obtenir le mot de passe du sMSA à l’aide de l’applet de commande PowerShell Add-ADComputerServiceAccount.
3. Accorder au sMSA l’accès requis à l’environnement évalué par la documentation sur les conditions préalables pour l’évaluation configurée.

Créer un compte de services administrés autonome

Pour créer le sMSA, exécutez la commande suivante dans une session PowerShell depuis un contrôleur de domaine ou un membre de domaine où le module Windows PowerShell Active Directory est installé à l’aide d’un compte disposant des autorisations nécessaires pour créer des comptes dans Active Directory (les opérateurs de compte ou les administrateurs de domaine ont les autorisations nécessaires).

New-ADServiceAccount -Name <sMSAaccountname>  -RestrictToSingleComputer

Par exemple : PS C :> New-ADServiceAccount -Name sMSA-SVC -RestrictToSingleComputer

Autoriser la machine de collecte de données à utiliser un sMSA

Pour autoriser la machine de collecte de données à obtenir le mot de passe pour le sMSA, exécutez la commande suivante dans une session PowerShell depuis un contrôleur de domaine ou un membre de domaine où le module Windows PowerShell Active Directory est installé à l’aide d’un compte disposant des autorisations nécessaires pour créer des comptes dans Active Directory (les opérateurs de compte ou les administrateurs de domaine ont les autorisations nécessaires).

Add-ADComputerServiceAccount -Identity “datacollectionmachine$” -ServiceAccount “sMSA samaccountname”

Par exemple : Add-ADComputerServiceAccount -Identity "OMS-AD-Tools$" -ServiceAccount "sMSA-SVC$"

Installer sMSA sur la machine de collecte de données

La mise en cache préalable de sMSA sur la machine de collecte de données constitue une étape de validation importante pour garantir que le compte est correctement configuré et que la machine de collecte de données peut récupérer le mot de passe sMSA et utiliser le compte. À partir de la machine de collecte de données sur laquelle le module Active Directory Powershell est installé, exécutez la procédure suivante.

Install-ADServiceAccount -Identity “sMSA samaccountname”

Par exemple : Install-ADServiceAccount -Identity "sMSA-SVC$"

Remarque

Si une erreur indiquant cmdlet non trouvé est renvoyée, installez le module Active Directory Powershell comme expliqué dans Provision Managed Service Accounts ci-dessus.

Pour les autres erreurs, consultez le canal Microsoft-Windows-Security-Netlogon/Operational du journal des événements pour les événements de catégorie MSA.

Scénario 2 – Compte de services administrés de groupe (gMSA)

Le schéma de forêt des services de domaine Active Directory doit être au minimum égal à Windows Server 2012 pour pouvoir provisionner avec succès des comptes de service administrés de groupe. Les ordinateurs exécutant des tâches planifiées en tant que gMSA doivent exécuter Windows Server 2012 ou une version plus récente.

Il y a 3 étapes de provisionnement d’un gMSA pour exécuter des évaluations à la demande :

1. Créer la clé racine KDS (service de distribution de clés) dans Active Directory à l’aide de Add-KDSRootKey
2. Créer gMSA et autoriser la machine de collecte de données à obtenir le mot de passe pour gMSA à l’aide de l’applet de commande PowerShell New-ADServiceAccount.
3. Accorder au gMSA l’accès requis à l’environnement évalué par la documentation sur les conditions préalables pour l’évaluation configurée.

Provisionner une clé racine KDS

La clé racine KDS doit d’abord être créée si elle n’a jamais été créée dans la forêt Active Directory.  Pour déterminer s’il existe une clé racine KDS, exécutez la commande suivante dans une session PowerShell.

Get-KdsRootKey

Remarque

Si cette commande ne renvoie rien, aucune clé racine existe dans la forêt Active Directory.

Pour créer la clé racine KDS, exécutez la commande suivante dans une session PowerShell depuis un contrôleur de domaine ou un membre de domaine où le module Windows PowerShell Active Directory est installé à l’aide d’un compte disposant des autorisations nécessaires pour créer des comptes dans Active Directory (les administrateurs d’entreprise et les administrateurs de domaine dans le domaine racine de la forêt disposent par défaut des autorisations nécessaires).

Add-KdsRootKey -EffectiveImmediately 

Add-KdsRootKey -EffectiveImmediately permet la création de gMSA après 10 heures pour garantir que la réplication a convergé vers tous les contrôleurs de domaine.

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) 

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) permet la création de gMSA immédiatement.

Cette approche comporte des risques d'échec de création ou d'utilisation de gMSA si la forêt de convergence de réplication AD nécessite plusieurs heures dans des conditions normales.

Créer un compte de services administrés de groupe

Pour créer le gMSA, exécutez la commande suivante dans une session PowerShell depuis un contrôleur de domaine ou un membre de domaine où le module Windows PowerShell Active Directory est installé à l’aide d’un compte disposant des autorisations nécessaires pour créer des comptes dans Active Directory (les opérateurs de compte ou les administrateurs de domaine ont les autorisations nécessaires).

New-ADServiceAccount -Name <gMSAaccountname> -DNSHostname <gMSAaccountname.FQDN> -PrincipalsAllowedToRetrieveManagedPassword “data collection machine samaccountname”

Par exemple : PS C :> New-ADServiceAccount -Name gMSA-SVC -DNSHostName gMSA-SVC.contoso.local -PrincipalsAllowedToRetrieveManagedPassword "oms-ad-tools$"

Installer gMSA sur la machine de collecte de données

La mise en cache préalable de gMSA sur la machine de collecte de données constitue une étape de validation importante pour garantir que le compte est correctement configuré et que la machine de collecte de données peut récupérer le mot de passe gMSA et utiliser le compte. À partir de la machine de collecte de données sur laquelle le module Active Directory Powershell est installé, exécutez la procédure suivante.

Install-ADServiceAccount -Identity “gMSA samaccountname”

Par exemple : Install-ADServiceAccount -Identity "gMSA-SVC$"

Remarque

Si une erreur indiquant cmdlet non trouvé est renvoyée, installez le module Active Directory Powershell comme expliqué dans Provision Managed Service Accounts ci-dessus.

Pour les autres erreurs, consultez le canal Microsoft-Windows-Security-Netlogon/Operational du journal des événements pour les événements de catégorie MSA.