Partager via

Installer SGH dans une forêt bastion existante

Joindre le serveur SGH au domaine racine

Dans une forêt bastion existante, SGH doit être ajouté au domaine racine. Utilisez Gestionnaire de serveur ou Add-Computer pour joindre votre serveur SGH au domaine racine.

Ajouter le rôle serveur SGH

Exécutez toutes les commandes de cette rubrique dans une session PowerShell avec élévation de privilèges.

Ajoutez le rôle Host Guardian Service en exécutant la commande suivante :

Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart

Si votre centre de données dispose d’une forêt bastion sécurisée dans laquelle vous souhaitez joindre des nœuds SGH, procédez comme suit. Vous pouvez également utiliser ces étapes pour configurer au moins 2 clusters SGH indépendants qui sont joints au même domaine.

Joignez le serveur SGH au domaine souhaité

Utilisez Gestionnaire de serveur ou Add-Computer pour joindre les serveurs SGH au domaine souhaité.

Préparer des objets Active Directory

Créez un compte de service managé de groupe et 2 groupes de sécurité. Vous pouvez également précéder les objets de cluster si le compte avec lequel vous initialisez SGH n’est pas autorisé à créer des objets ordinateur dans le domaine.

Compte de service géré de groupe

Le compte de service managé de groupe (gMSA) est l’identité utilisée par SGH pour récupérer et utiliser ses certificats. Utilisez New-ADServiceAccount pour créer un compte gMSA. S’il s’agit du premier compte gMSA dans le domaine, vous devez ajouter une clé racine du service de distribution de clés.

Chaque nœud SGH doit être autorisé à accéder au mot de passe gMSA. Le moyen le plus simple de configurer cela consiste à créer un groupe de sécurité qui contient tous vos nœuds SGH et à accorder à ce groupe de sécurité l’accès pour récupérer le mot de passe gMSA.

Vous devez redémarrer votre serveur SGH après l’avoir ajouté à un groupe de sécurité pour vous assurer qu’il obtienne sa nouvelle appartenance au groupe.

# Check if the KDS root key has been set up
if (-not (Get-KdsRootKey)) {
    # Adds a KDS root key effective immediately (ignores normal 10 hour waiting period)
    Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
}

# Create a security group for HGS nodes
$hgsNodes = New-ADGroup -Name 'HgsServers' -GroupScope DomainLocal -PassThru

# Add your HGS nodes to this group
# If your HGS server object is under an organizational unit, provide the full distinguished name instead of "HGS01"
Add-ADGroupMember -Identity $hgsNodes -Members "HGS01"

# Create the gMSA
New-ADServiceAccount -Name 'HGSgMSA' -DnsHostName 'HGSgMSA.yourdomain.com' -PrincipalsAllowedToRetrieveManagedPassword $hgsNodes

Le gMSA nécessite le droit de générer des événements dans le journal de sécurité sur chaque serveur SGH. Si vous utilisez stratégie de groupe pour configurer l’attribution des droits utilisateur, assurez-vous que le compte gMSA dispose du privilège Générer des événements d’audit sur vos serveurs SGH.

Notes

Les comptes de service managés de groupe sont disponibles à partir du schéma Active Directory Windows Server 2012. Pour plus d’informations, consultez Exigences des comptes de service managés de groupe.

Groupes de sécurité JEA

Lorsque vous configurez SGH, un point de terminaison PowerShell JEA (Just Enough Administration) est configuré pour permettre aux administrateurs de gérer SGH sans avoir besoin de privilèges d’administrateur local complets. Vous n’êtes pas obligé d’utiliser JEA pour gérer SGH, mais il doit toujours être configuré lors de l’exécution de Initialize-HgsServer. La configuration du point de terminaison JEA consiste à désigner 2 groupes de sécurité qui contiennent vos administrateurs SGH et les réviseurs SGH. Les utilisateurs qui appartiennent au groupe d’administration peuvent ajouter, modifier ou supprimer des stratégies sur SGH ; les réviseurs peuvent uniquement afficher la configuration actuelle.

Créez 2 groupes de sécurité pour ces groupes JEA à l’aide des outils d’administration Active Directory ou de New-ADGroup.

New-ADGroup -Name 'HgsJeaReviewers' -GroupScope DomainLocal
New-ADGroup -Name 'HgsJeaAdmins' -GroupScope DomainLocal

Objets de cluster

Si le compte que vous utilisez pour configurer SGH n’a pas l’autorisation de créer de nouveaux objets ordinateur dans le domaine, vous devez précéder les objets de cluster. Ces étapes sont expliquées dans Prestage Cluster Computer Objects in Active Directory Domain Services.

Pour configurer votre premier nœud SGH, vous devez créer un objet de nom de cluster (CNO) et un objet d’ordinateur virtuel (VCO). Le CNO représente le nom du cluster et est principalement utilisé en interne par le clustering de basculement. Le VCO représente le service SGH qui réside au-dessus du cluster et sera le nom inscrit auprès du serveur DNS.

Important

L’utilisateur qui s’exécutera Initialize-HgsServer nécessite un contrôle total sur les objets CNO et VCO dans Active Directory.

Pour préparer rapidement votre CNO et votre VCO, faites exécuter les commandes PowerShell suivantes par un administrateur Active Directory :

# Create the CNO
$cno = New-ADComputer -Name 'HgsCluster' -Description 'HGS CNO' -Enabled $false -Passthru

# Create the VCO
$vco = New-ADComputer -Name 'HgsService' -Description 'HGS VCO' -Passthru

# Give the CNO full control over the VCO
$vcoPath = Join-Path "AD:\" $vco.DistinguishedName
$acl = Get-Acl $vcoPath
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $cno.SID, "GenericAll", "Allow"
$acl.AddAccessRule($ace)
Set-Acl -Path $vcoPath -AclObject $acl

# Allow time for your new CNO and VCO to replicate to your other Domain Controllers before continuing

Exceptions de base de référence de sécurité

Si vous déployez SGH dans un environnement hautement verrouillé, certains paramètres stratégie de groupe peuvent empêcher SGH de fonctionner normalement. Vérifiez vos objets stratégie de groupe pour les paramètres suivants et suivez les instructions si vous êtes affecté :

Ouverture de session réseau

Chemin d’accès stratégie : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Attribution des droits utilisateur.

Nom de stratégie : interdire l’accès à cet ordinateur à partir du réseau

Valeur requise : vérifiez que la valeur ne bloque pas les connexions réseau pour tous les comptes locaux. Toutefois, vous pouvez bloquer en toute sécurité les comptes d’administrateur local.

Raison: le clustering de basculement s’appuie sur un compte local non administrateur appelé CLIUSR pour gérer les nœuds de cluster. Le blocage de l’ouverture de session réseau pour cet utilisateur empêche le cluster de fonctionner correctement.

Chiffrement Kerberos

Chemin d’accès stratégie : Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Options de sécurité

Nom de stratégie : sécurité réseau : configurer les types de chiffrement autorisés pour Kerberos

Action : si cette stratégie est configurée, vous devez mettre à jour le compte gMSA avec Set-ADServiceAccount pour utiliser uniquement les types de chiffrement pris en charge dans cette stratégie. Par exemple, si votre stratégie autorise uniquement AES128_HMAC_SHA1 et AES256_HMAC_SHA1, vous devez exécuter Set-ADServiceAccount -Identity HGSgMSA -KerberosEncryptionType AES128,AES256.

Étapes suivantes