mardi 26 décembre 2023

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

lundi 4 décembre 2023

Comment Windows arrive à localiser un contrôleur de domaine le plus proche

Dans une architecture AD multi-site, Il est recommandé de bien configurer les sites et le sous-réseau depuis la console  sites and services Active directory pour forcer les  serveurs et les ordinateurs  membres du domaine de contacter le contrôleur de domaine le plus proche afin d’éviter l’impact de la lenteur du réseau sur l’authentification.
Si un sous-réseau est ajouté dans la liste des sous-réseaux d’un site active directory, tous les serveurs et les ordinateurs Windows sont capables de localiser un contrôleur de domaine appartenant à ce site en utilisant le processus DCLocator.
Le DCLocator est capable grâce à des requêtes DNS de trouver un contrôleur de domaine quelconque pour lui demander le site le plus proche se basant sur l’adresse IP du serveur ou ordinateur et la configuration sites et sous réseaux active directory.
Une fois que le serveur ou l’ordinateur reçoit le nom de son site, cette information sera enregistrée dans la clé de registre  suivant :
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName

La figure ci-dessous résume  les échanges entre un ordinateur membre du domaine lab.lan, un serveur DNS et un contrôleur de domaine pour identifier le site AD :


Une fois que le site AD est bien identifié, le serveur ou ordinateur, vont toujours chercher contacter un des contrôleurs de domaine qui appartient à ce site.
La figure ci-dessous présente le reste de la communication entre un ordinateur membre d’un domaine lab.lan un serveur DNS pour trouver un contrôleur de domaine le plus proche:





Les sous-réseaux non déclarés dans la console Sites et servives active directory :


Si  le sous-réseau n'appartient pas à aucun site active directory, l'ordinateur ou le serveur membre du domaine va choisir dans ce cas un contrôleur de domaine de la liste fournie par le serveur DNS suite à sa  première requête SRV  _ldap._tcp.dc._msdcs.lab.lan.

Pour personnaliser cette liste afin de supprimer les contrôleurs de domaine qui rencontrent des problèmes de performance réseau ou/et système, sur le DC en question on ajoute la clé de registre suivant sous HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\:

Nom
DnsAvoidRegisterRecords
Type
REG_MULTI_SZ
Data
LdapIpAddress
Ldap
DcByGuid
kdc
Dc
Rfc1510kdc
Rfc1510Udpkdc
Rfc1510Kpwd
Rfc1510UdpKpwd
Gc
GcIpAddress
GenericGc

Le sous-réseau est bien ajouté à un site active directory mais aucun contrôleur de domaine de ce site disponible pour traiter les demandes des clients :


Dans ce cas il y a deux mécanisme qui peut aider le client pour trouver un active directory disponible en fonction de la configuration des liaisons de site:
  • ·Automatic Site Coverage : permet aux sites sans contrôleur de domaine d'être couvert par le contrôleur de domaine le plus proche ( en fonction du cout des liaison des sites). Veullez consulter ce lien pour avoir plus des détails : Automatic Site Coverage
  •      Si le site n'a aucune liaison de site ,le client va contacter l'un des contrôleure e domaine fournie par le DNS comme expliqué ci-dessous: _ldap._tcp.dc._msdcs.lab.lan





lundi 10 juillet 2023

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. 

dimanche 9 avril 2023

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:


samedi 1 avril 2023

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.