Gestion des accès privilégiés et Active Directory sous Windows 2016

Introduction:

Parmi les nouvelles fonctionnalités proposées par l'active directory sous Windows 2016 ou plus , la possibilité d’ajouter un membre à un groupe active directory pour une durée bien déterminée. 

Pour activer cette fonctionnalité, il  faut que tous les contrôleurs de domaine de la forêt soient installés sous Windows 2016 ou plus et le niveau fonctionnel  de la forêt soit Windows 2016 :

Niveau fonctionnel Windows 2016:

Malgré la sortie du Windows 2019 et Windows 2022 , le niveau fonctionnel le plus élevé est le Windows 2016.

Pour pouvoir augmenter le niveau fonctionnel vers Windows 2016 , il faut que tous les contrôleurs de domaine de la forêt soient installés sous Windows 2016 et le niveau fonctionnel des domaines enfants soit Windows 2016.
Pour savoir comment augmenter un niveau fonctionnel veuillez consulter ce lien : Le niveau fonctionnel FFL/DFL.

Une fois que le niveau fonctionnel de la forêt est égal à Windows 2016, une nouvelle fonctionnalité sera ajoutée avec la corbeille s’appelant : Privileged Access Management Feature :

Get-ADOptionalFeature -Filter *

L'activation de la fonctionnalité Privileged Access Management :

L’activation de la fonctionnalité Privileged Access Management permet d’ajouter un objet active directory dans un groupe pour une durée bien déterminée.

L'activation de cette fonctionnalité modifie la partition Configuration de l'active directory. Si vous avez besoin de faire un retour en arrière pour désactiver cette fonctionnalité, il faut restaurer toute la forêt. 

Pour activer cette fonctionnalité , il suffit de lancer la commande ci-dessous avec un compte membre du groupe enterprise Admins :

Enable-ADOptionalFeature -Identity  "Priviliged Access Management Feature" –scope ForestOrConfigurationSet –Target "Lab.lan"

Pour vérifier l’activation, lancer la commande suivante:

Get-ADOptional –Filter *

et vérifier que EnabledScope n’est pas vide dans les propriétés de Priviliged Access Management:

Une fois que la vérification de l’activation est terminée, maintenant nous sommes capable d’ajouter un membre d'un groupe active directory pour une durée bien déterminée.

Ajouter un utilisateur dans la liste des membres d'un groupe temporairement:

Pour ajouter un objet active directory dans un groupe pour une durée bien déterminée , vous pouvez n'utilisez que les commandes Powershell:

Add-ADGroupMember -Identity "domain Admins" -Members "test" -MemberTimeToLive (New-TimeSpan -minutes 30)

Si l'audit est activé sur les modifications des objets active, vous allez trouver un évènement d'ID 5169 et source Microsoft Windows security généré dans le journal d'évènement après chaque ajout d'un objet dans un groupe temporairement:

La commande ci-dessous permet d’afficher les membres temporaires d’un groupe:

Get-ADGroup "Domain Admins" -Properties member -ShowMemberTimeToLive

La durée de vie d'un ticket Kerberos :

Si un utilisateur essaie d'accéder à une ressource via l'authentification kerberos, le ticket kerberos qui inclus par défaut tous les SIDs des groupes de l'utilisateur .

Si, un utilisateur est configuré comme membre à un groupe temporairement pour une durée inférieur à la valeur de la durée de vie configurée par défaut pour un ticket kerberos, le nouveau ticket Kerberos sera expiré quand l'utilisateur ne sera plus membre de ce groupe.
Si l'utilisateur appartient pour une durée limitée à plusieurs groupes la durée minimale sera la durée du vie du ticket kerberos.

Dans l’exemple ci-dessous, on va vérifier la durée de vie du ticket kerberos avant et après  l’ajout d’un utilisateur LAB\test dans deux groupes  temporairement.

Dans la figure ci-dessous, on constate bien que la durée de vie du ticket kerberos est égale à 10 heures :

Maintenant, nous allons ajouter l’utilisateur LAB\test dans le groupe Domain Admins pour une durée de 30 minutes et dans le groupe Entreprises Admins pour une durée de 20 minutes:

 Add-ADGroupMember -Identity "domain Admins" -Members "test" -MemberTimeToLive (New-TimeSpan -minutes 30)

 Add-ADGroupMember -Identity "Entreprise Admins" -Members "test" -MemberTimeToLive (New-TimeSpan -minutes 20)

Add-ADGroupMember -Identity "Entreprise Admins" -Members "test" -MemberTimeToLive (New-TimeSpan -minutes 20)

La commande ci-dessous permet d’afficher la liste des groupes de l’utilisateur LAB\test :

 whoami /groups

Pour supprimer les tickets kerberos de l'utilisateur dans le cache nous lançons la commande suivante:

klist purge

Nous exécutons la commande ci-dessous pour afficher les nouveaux tickets kerberos TGT :

klist

La figure ci-dessous, montre bien que la durée de vie du ticket kerberos ne dépasse pas 20 minutes.

Quelques recommandations:

• Contrôler régulièrement la liste des groupes avec pouvoir dans l'active directory: un utilisateur ajouté temporairement dans un groupe domain Admins par exemple , est capable de créer un autre utilisateur et de l'ajouter dans ce groupe et garder les privilèges Domain Admins
• Avec l'authentification NTLM, il n'y a pas la notion du TTL, pour cela il est recommandé de demander à l'utilisateur de fermer sa session s'il n'est plus membre d'un groupe 
• Avant d'activer cette fonctionnalité , il faut s'assurer que tous les domaines de la forêt sont bien sauvegardés. Si vous désirez désactiver cette fonctionnalité il faut restaurer toute la forêt comme la corbeille active directory. 

What's new to promote the first domain controller on Windows Server 2019 or Windows 2022

In this article I would like to share with you ,how to prepare a existing forest to promote the first domain controller on Windows 2019 or Windows 2022 :

•  The Forest Functional Level must be 2008 R2 or higher:
  If you still have a domain controller in Windows 2003 you have to demote it before:

• If you still using FRS for SYSVOL replication , you must migrate to DFS before:

• The new schema version for Windows 2019 is 88 and it's the same for Windows 2022:

Les nouveautés de l'active directory sous Windows 2019 et Windows 2022

Dans cet article, nous allons partager quelques informations et quelques nouveautés de l'active directory, en se basant sur les tests que nous avons réalisés dans notre environnement de test et quelques informations publiées sur des Blog publiques.

La mise à jour du schémas:

Windows 2019:

La mise à jour du schéma est une étape indispensable qui doit être lancée avant la promotion du premier contrôleur de domaine sous Windows 2019 avec un compte membre des groupes suivants:

• Administrateurs du schéma
• Administrateurs de l'entreprise
• Domain Admin du domaine root

Windows 2019 a gardé les mêmes méthodes utilisées depuis l'arrivé du Windows 2012 pour la préparation de la forêt et la mise à jour du schéma. Pour avoir plus de détails veuillez consulter le lien suivant:
 Préparer une forêt et un domaine pour l'installation du premier contrôleur de domaine sous Windows 2016

Après la préparation de la forêt pour la promotion du premier contrôleur du domaine sous Windows 2019,voici les changement constatés:

•  Un nouveau attribut nommé msDS-preferredDataLocation est créé et attaché à tous les objets utilisateurs, groupes et contacts.  
• La nouvelle version du schéma est 88:

Windows 2022

L'upgrade du schéma n'est pas requis pour la promotion du premier contrôleur de domaine sous Windows 2022 . Windows 2022 garde la même version du Windows 2019.

Les nouveautés du niveau fonctionnel FFL et DFL:

Windows 2016 est le niveau fonctionnel le plus élevé :

Nous avons constaté que le niveau fonctionnel le plus élevé disponible dans une foret avec des contrôleurs de domaine sous Windows 2019 ou Windows 2022 est Windows Server 2016  :

Donc, jusqu'à présent nous ne pouvons pas empêcher la promotion des contrôleurs de domaine sous Windows 2016, étant donné le niveau fonctionnel le plus élevé est Windows 2016

Le niveau fonctionnel requis pour la promotion du premier contrôleur de domaine sous Windows 2019 ou Windows 2022:

Les contrôleurs de domaine sous Windows 2019 et Windows 2022 ne peuvent supporter que les niveaux fonctionnels  Windows 2008 ou plus:

Par conséquence, pour pouvoir promouvoir le premier contrôleur de domaine sous Windows 2019 ou Windows 2022 , il faut s'assurer que le niveau fonctionnel du domaine et de la forêt est au minimum Windows 2008 .
Le lien ci-dessous, vous explique comment augmenter le niveau fonctionnel:
Le niveau fonctionnel FFL/DFL

Les nouveautés au niveau de la réplication SYSVOL:

Pour la réplication du répertoire SYSVOL, les contrôleurs de domaine sous Windows 2019 et Windows 2022 ne supportent que le système de réplication de fichier DFS-R pour le répertoire sysvol:

Si un domaine utilise encore FRS pour la réplication SYSVOL, dans ce cas il faut le migrer  vers DFS-R pour pouvoir promouvoir le premier contrôleur de domaine sous Windows 2019 ou Windows 2022.
Le lien ci-dessous explique les étapes de cette migration:
How to migrate the SYSVOL replication system from FRS to DFS-R

Promotion et Upgrade-inplace

Promotion via Powershell ou interface graphique:

Il est possible de promouvoir un contrôleur de domaine sous Windows 2019 ou Windows 2022 à travers l'interface graphique ou les commandes Powershell. 

C'est la même procédure utilisées pour Windows 2016:
Déployer le premier contrôleur de domaine sous Windows 2016

La mise à niveau sur place (Upgrade In-place):

L'upgrade In-place des contrôleurs de domaine est supportée à partir du Windows 2012 mais n'est pas recommandée comme l'explique ce lien : Mise à niveau sur place d'un contrôleur de domaine.

Pour Windows 2019 et Windows 2022, l'Upgrade in-place est supporté depuis un contrôleur de domaine Windows 2016.

Avant de lancer l'upgrade in-place, il faut préparer les prérequis suivants:

• Le niveau fonctionnel de la forêt soit Windows 2008 ou plus
• Le système de réplication SYSVOL est DFS
• La préparation de la forêt et du domaine est lancé manuellement via la commande adprep.

Clonage d'un contrôleur de domaine virtuel

A partir du Windows 2012, le clonage d'un contrôleur de domaine virtuel est possible et supporté par Microsoft.

Dans cet article, nous allons expliquer comment cloner un contrôleur de domaine virtuel.

Prérequis:

Pour cloner un contrôleur de domaine, voici les prérequis à préparer:

• Un hyperviseur qui supporte VM-GenerationID.
• Un PDC sur un contrôleur de domaine sous Windows 2012 ou plus.
• Un contrôleur de domaine virtuel sous Windows 2012 ou plus pour être utilisé comme un contrôleur de domaine source
• Un compte membre du groupe Admin du domaine, pour l'utiliser pendant l'opération du clonage.

Le groupe "Cloneable Domain Controllers":  

Ce groupe est créé automatiquement avec les bonnes permissions lors du déplacement du PDC vers un contrôleur de domaine sous Windows 2012 ou plus.
En cas de suppression, il est possible de le créer avec les permissions requises.
Pour plus de détails je vous invite à consulter ce lien:
 Comment restaurer les permissions du groupe "Cloneable Domain Controllers"
Il est également possible d'autoriser au contrôleur de domaine source d'être cloné même sans l'ajouter dans ce groupe.
Si vous utilisez cette méthode ,il ne faut pas oublier d'enlever le droit "Allow a DC to create a clone of itself" après la fin de l'opération:

Vérifier la configuration du PDC:

Le PDC a un rôle important dans le processus du clonage. Il faut le placer sur un DC sous Windows 2012 ou sous une version plus récente et s'assurer qu'il est toujours joignable pendant l'opération de clonage.

Pour déplacer le PDC vers un contrôleur de domaine sous Windows 2012 ou plus, je vous invite à consulter ce lien : Gérer l'emplacement des rôles FSMO

Vérifier la version de l'hyperviseur:

Pour valider si un hyperviseur supporte VM-GenerationID, depuis une machine virtuelle ,il faut vérifier dans le gestionnaire de périphériques la présence du pilote Compteur de génération Microsoft Hyper-v si l'OS est anglais il a le nom suivant: Microsoft Hyper-V Generation Counter:

Préparer le contrôleur de domaine source:

• Le contrôleur de domaine source doit être installé sur Windows 2012 ou plus

• Ajouter le compte ordinateur du contrôleur source dans le groupe "Cloneable Domain Controllers". Cela est possible à travers la console utilisateurs et ordinateurs active directory:

Et aussi via Powershell via la commande suivante :

Add-ADGroupMember "Cloneable domain controllers " "DC-source-Name"

• Afficher la liste des programmes et les rôles incompatibles via la commande : 

Get-ADDCCloningExcludeApplicationList

Désinstaller les services et les rôles qui ne supportent pas le clonage ,ensuite ,valider le reste à travers la commande suivante:

Get-ADDCCloningExcludeApplicationList -GenerateXml

La commande ci-dessous permet de créer un fichier xml pour inclure les services autorisés.

Maintenant, aucune application n'est exclue, valider via la commande suivante :

Get-ADDCCloningExcludeApplicationList

• Créer le fichier DCCloneConfig.xml qui contient les paramètres du nouveau contrôleur de domaine via la commande suivante:

New-ADDCCloneConfigFile -Static -CloneComputerName "Cloned_DC_Name" 
-SiteName "Target-AD-SiteNAme" -IPv4Address "New-IP" -IPvDNSResolver "DNS-IP"
-IPv4SubnetMask "255.255.255.0"

• Arrêter le contrôleur de domaine source.

Créer la machine virtuelle du nouveau contrôleur de domaine cloné:

Pour créer la nouvelle machine virtuelle qui va héberger le nouveau contrôleur de domaine cloné,  nous avons deux possibilités:

1. Copier les disques de la machine source
2. Utiliser l'option export et import de l'hyper-v (méthode recommandée)

Dans notre LAB, nous allons utiliser l'option EXPORT qui permet de copier tous les fichiers de la machine virtuelle source dans un autre emplacement.

Ci-dessous les différentes étapes à suivre:

• Depuis la console hyper-v, cliquer avec le bouton droit de la souris sur la machine virtuelle du contrôleur de domaine source et appuyer sur Export:

• Spécifier l'emplacement de la nouvelle machine virtuelle du nouveau contrôleur de domaine cloné:

• Il est possible aussi de lancer l'exportaion via Powershell:

Export-VM "Source-DC-2016" -path "C:\VM-TEST\VM\ClonedDC\"

• Importer la nouvelle machine en cliquant sur l'option Import Virtual Machine dans la console Hyper-v:

• La fenêtre ci-dessous s'affiche, cliquer sur Next:

• Spécifier l'emplacement de la machine à importer et cliquer sur Next:

• Sélectionner la machine virtuelle à importer et cliquer sur Next:

• Spécifier le type de l'import, pour éviter le conflit avec la machine source il est recommandé de créer un nouveau unique ID:

• Spécifier l'emplacement des fichiers de la nouvelle machine virtuelle et cliquer sur Next:

• Spécifier l'emplacement des fichiers VHD de la nouvelle machine et cliquer sur Next:

• Cliquer sur Finish:

• Maintenant,pour lancer l'opération du clonage, vérifier que le PDC est bien en ligne ,ensuite ,démarrer la nouvelle machine virtuelle du contrôleur de domaine cloné en gardant la machine source arrêtée: le clonage va se lancer automatiquement:

Une fois que l'opération du clonage est terminée, vérifier l'état de santé du nouveau contrôleur du domaine et la réplication entre ses partenaires de réplication.
En cas de problème, il faut examiner le contenu du fichier dcpromo.log qui existe sous le répertoire  C:\Windows\Debug

Réinitialiser le mot de passe KRBTGT

 Le compte krbtgt est créé par défaut lors de l'installation du premier contrôleur de domaine dans le domaine et après la promotion d'un RODC.

On ne peut pas modifier ou supprimer le compte KRBTGT.

Le compte krbtgt doit être toujours désactivé.

Le mot  de passe du compte krbtgt est utiliser par le Key Distribution Center (contrôleur de domaine) comme une clé pour crypter les ticket kerberos.

Le mot de passe krbtgt est répliqué uniquement sur les DC R/W, chaque RODC possède son propre compte krbtgt pour gérer les demandes hereros.

Tous les tickets kerberos TGT déjà délivrés avant le changement de mot de passe krbtgt seront invalide, il faut que le client reçoit un autre ticket TGT pour accéder à une ressource via l'authentification kerberos.

Si le niveau fonctionnel du domaine est 2003 et vous l'augmenter vers 2008 ou plus ,Le mot de passe krbtgt sera initialiser automatiquement.

Avant de réinitialiser le mot de passe krbtgt,:

• Il faut que le niveau fonctionnel du domaine soir 2008 ou plus.
• Aucun problème e de réplication entre les contrôleur de domaine R/W
• krbtgt garde les deux derniers mots dans l'historique , pour cela il est recommandé de changer le mot de passe deux fois , et avant de changer le mot de passe la deuxième fois , il faut attendre que le premièr changement soit répliqué sur tous les contrôleurs de domaine
• choisir un mot de passe compliqué

Je vous invite également à consulter un lien sur le forum technet sur le même sujet: Réinitialiser KRBTGT

Mettre à niveau de l'algorithme de hachage d'une autorité de certification sous Windows

 Introduction

Dans cet article nous allons vous montrer comment nous pouvons mettre à niveau l'algorithme de hachage d'une autorité de certification.

Un petit rappel, l'algorithme de hachage , est une fonction mathématique qui permet de créer une empreinte numérique pour vérifier l'intégrité des données.

Si votre PKI utilise encore des algorithmes de hachage vulnérable comme SHA1,MD4 et MD5,c'est le moment de penser à migrer le plutôt possible vers SHA256 ou plus.

Pour mettre à niveau l'algorithme de hachage vers SHA256, il faut suivre les étapes suivantes:

1. Mettre à niveau l'algorithme de hachage vers SHA256 du fournisseur du chiffrement
2. Régénérer un nouveau certificat racine avec le nouveau algorithme de hachage pour l'autorité de certification
3. Régénérer tous les certificats déjà délivrés

Avant de commencer la migration de l'algorithme de hachage , il est recommandé de sauvegarder la PKI pour assurer la possibilité d'un retour en arrière en cas de problème.

Dans notre environnement de test nous avons installé un domaine LAB.LAN et une autorité de certification entreprise PKI2008 qui  utilise l'algorithme SHA1 comme algorithme de hachage.

1. Mettre à niveau l'algorithme de hachage du fournisseur du chiffrement:

Pour afficher l'algorithme utilisé par le fournisseur de chiffrement "Software Key Storage Provider" pour notre cas:

•  Depuis la console certsrv.msc , cliquer sur le nom de la PKI (PKI2008) avec le bouton droit de la souris ensuite cliquet sur Propriétés : 

• Dans les propriétés de la PKI allez vers l'onglet général et vous allez trouver l'algorithme de hachage utilisé par le fournisseur Microsoft Software Key Storage Provider:

• Dans les propriétés de la PKI , onglet général ,cliquer sur Afficher le certificat pour vérifier l'algorithme de hachage utilisé pour signer le certificat racine :
  
  
  
  

• Pour modifier l'algorithme de hachage du fournisseur "Software Key Storage Provider", il suffit de taper la commande suivante:
  

Certutil -setreg ca\csp\CNGHashAlgorithm SHA256

• Une fois que la commande est bien exécutée, un message s'affiche pour vous demander de redémarrer le service CertSvc:

• Pour redémarrer le service Certsvc, depuis la console certsrv.msc cliquer avec le bouton droit de la souris sur le nom de la PKI ensuite allez vers Toutes les tâches pour trouver l'option Démarrer et arrêter le service:
  
  
  
  
  
  
• Maintenant vérifiez que le nouvel algorithme de hachage utilisé par le fournisseur "Software Key Storage Provider" est bien SHA256:

2. Régénérer un nouveau certificat racine pour l'autorité de certification:

Pour générer un nouveau certificat racine, vous pouvez suivre les étapes suivantes:

• Depuis la console certsrv.msc ,cliquer avec le bouton droit de a souris sur le nom de la PKI ensuite cliquer sur toutes les tâches puis sur l'option Renouveler le certificat d'autorité de certification:

• Une fenêtre s'affiche pour vous avertir que le service de certificats active directory va s'arrêter, cliquez sur oui

• Dans cette étape si vous avez la possibilité de générer un nouveau pair de clé privé et publique avant la génération du nouveau certificat:

• Une fois que la génération du certificat est terminé, vous pouvez affciher le certificat en allant dans les propriétés de la PKI et sous l'onglet General sélectionner le nouveau certificat et cliquer sur Afficher le certificat:

• Dans les propriétés du certificat , allez vers l'onglet Détails et vérifier l'algorithme de Hachage:

3. Régénérer tous les certificats déjà délivrés:

La dernière étape consiste à regénérer tous les certificats déjà livrés par l'autorité de certification, afin  de mettre à jour le hache de chaque certificat calculé par l'autorité de certification en question  à travers le nouveau algorithme de hachage. Pour rappel, lors de la génération du certificat le hache est calculé et signé par la l'autorité de certification pour assurer son intégrité .

Cette étape dépend de la méthode d'enregistrement utilisée pour générer le certificat.
Pour les certificat générés automatiquement à travers GPO, ils seront regénérer automatiquement après l'expiration ou la suppression de l'ancien certificat.