lundi 26 décembre 2022

Gérer le mot de passe du compte d'administrateur local via LAPS

LAPS est un outil gratuit de Microsoft qui permet d'assurer la sécurité du mot de passe du compte administrateur local intégré (Build-in) d'une machine membre du domaine et réduire la surface d'attaque grâce à:

  • Génération d'un mot de passe aléatoire
  • Génération d'un mot de passe complexe 
  • Renouvellement du mot de passe automatiquement
  • Génération d'un mot de passe unique sur chaque machine membre du domaine
  • Enregistrement du mot de passe dans l'annuaire qui est un endroit sécurisé et accessible uniquement par les utilisateurs autorisés.
Il est possible de le télécharger depuis ce lien  Local Administrator Password Solution (LAPS).

La mise en place du LAPS nécessite une mise à jour du schéma, afin d'ajouter deux attributs confidentiels sur le compte active directory de la machine: un pour le mot de passe et l'autre pour sa date d'expiration.

Cet article explique les différentes étapes d'installation et de configuration du LAPS.
Dans notre environnement de test ,nous avons créé un domaine qui s'appelle lab.lan et une OU nommé LAPS qui sera le conteneur pour tous les comptes ordinateurs gérés par l'outils LAPS.

Ajouter le modèle d'administration GPO de LAPS dans le magasin central:


Les paramètres LAPS au niveau client sont gérés via GPO, pour cela il est indispensable d'ajouter le modèle d'administration LAPS dans le magasin central.
Ci-dessous, nous allons expliquer étape par étape la méthode d'ajout des modèles d'administration GPO du LAPS dans le magasin central:

  • Cochez la case et cliquez sur suivant:
  • Choisir le module GPO Editor templates:
  • Cliquer sur Install:
  • Cliquez sur Finish:


Maintenant, les fichiers admx et adml du modèle LAPS sont ajoutés automatiquement sous le répertoire C:\Windows\PolicyDefenitions\:



Donc, il suffit de les copier dans le magasin central, pour avoir plus de détails je vous invite à consulter le lien suivant: Créer un magasin central pour gérer les modèles d'administration.
Une fois que cela est terminé, les paramètres GPO du LAPS sont bien présents:


Mise à jour du schéma active directory:


La mise à jour du schéma est indispensable afin d'ajouter deux attributs confidentiels nommés: ADmPwdExpirationTime et AdmPwd.
Pour lancer cette mise à jour, il faut utiliser un serveur avec Powershell version 4.0 et le module Powershell du LAPS déjà installé:


Ci-dessous, nous allons expliquer les différentes étapes de la mise à jour du schéma:
  • Avant de lancer  la mise à jour du schéma, vérifier la version du Powershell via la commande ci-dessous:
Get-Host
  • Lancer la fenêtre PowerShell en tant qu'administrateur et exécuter les deux commandes ci-dessous avec un compte membre du groupe administrateurs du schéma:
import-module admPwd.PS
Update-AdmPwdADSchema


Configurer les permissions requises:


Avant de commencer, il est important de vérifier qu'aucun compte non autorisé possède déjà le droit sur les attributs confidentiels.
Donc, il faut vérifier dans les paramètres de sécurité de l'OU en question que l'option Tous les droits étendus (Extended rights) est bien décochée sur les utilisateurs non autorisés :


Maintenant, nous allons détailler comment donner le droit à une machine de réinitialiser son mot de passe et aussi comment déléguer à un utilisateur ou groupe de lire ou initialiser le mot de passe de l'administrateur local:
  • Lancer la commande ci-dessous, pour donner le droit à chaque machine de réinitialiser le mot de passe du compte administrateur local:
Set-AdmPwdComputerSelfPermission -OrgUnit OU_Name
  • Lancer la commande ci-dessous pour autoriser à un groupe de lire les mots de passe des machines sous l'OU nommé LAPS dans notre LAB:
Set-AdmPwdReadPasswordPermission -OrgUnit OU_Name -AllowedPrincipals Group_Name
  • Lancer la commande ci-dessous pour autoriser à un groupe de réinitialiser le mot de passe:
Set-AdmPwdResetPasswordPermission -OrgUnit OU_Name -AllowedPrincipals Group_Name

  • Lancer la commande ci-dessous pour vérifier qui a le droit sur les attributs confidentiels:


Find-AdmPwdExtendedRights -Identity OU_Name | fl

Déployer LAPS sur les machines clientes:


LAPS doit être aussi installé sur toutes machines clientes.
Il est possible de le déployer via GPO:


 Ensuite, il sera installé automatiquement après le redémarrage de la machine cliente:


Et voila LAPS est maintenant bien installé:


Configurer les paramètres LAPS via GPO:


La dernière étape consiste à configurer les paramètres LAPS via GPO.
Après l'ajout du modèle d'administration GPO de LAPS, il y a quatre paramètres LAPS qui sont ajoutés dans la GPO:


Passoword settings: 

Ce paramètre permet d'activer la complexité , définir la longueur et la durée de vie du mot de passe.

Name of administrator account to manage:

Pour gérer un autre compte via LAPS , il est possible de le spécifier dans cette option. Sinon c'est le compte administrateur avec SID-500 créé par défaut qui sera géré via LAPS.

Do not allow password expiration time than required by policy:

Ce paramètre permet de ne pas autoriser un mot de passe expire selon la valeur déjà définit via GPO.

Enable local admin password management:

Ce paramètre permet d'activer ou désactiver LAPS.


Comment récupérer le mot de passe local en cas de besoin:


Pour récupérer le mot de passe, il faut avoir un compte qui possède déjà la délégation de lecture du mot de passe.
Il existe deux méthodes pour afficher le mot de passe et la date de son expiration.
La première méthode via la console active directory en allant dans les propriétés du compte active directory de la machine en question :



La deuxième méthode consiste à utiliser l'outil graphique client proposé par LAPS, pour l'installer il faut choisir cette option:


Une fois que l'installation est terminée, vous pouvez lancer l'interface client LAPS pour consulter le mot de passe et même le réinitialiser si vous en avez le droit:



Windows LAPS au lieu de Microsoft LAPS:

Microsoft a annoncé la disponibilité de la nouvelle version  Windows LAPS qui est disponible uniquement dans la version d'évaluation de Windows 11.
Des nouvelles fonctionnalités seront disponible dans cette nouvelle version :
  • Le client Windows LAPS sera intégré par défaut dans les nouvelles version de système d'exploitation
  • Sauvegarder le mot de passe DSRM dans l'active directory
  • La possibilité de sauvegarder le mot de passe locale dans Azure Active directory et dans l'active directory dans le cas d'un environnement hybrid

dimanche 10 juillet 2022

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. 

samedi 9 avril 2022

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:


vendredi 1 avril 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.

dimanche 23 janvier 2022

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