Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

New Group Policy settings in Windows 11 23H2

20 novembre 2023 à 10:41

Windows 11 23H2 introduces a range of new Group Policy settings. These target new features like Dev Drive and extend the management options for existing components. The corresponding ADMX templates are already available for download, as is the setting reference spreadsheet.

The post New Group Policy settings in Windows 11 23H2 first appeared on 4sysops.

What’s your ENow AppGov Score? Free Microsoft Entra ID app security assessment

Par : Brandon Lee
30 novembre 2023 à 13:24

Many organizations are behind the curve in understanding their SaaS applications and governance. In fact, for many IT admins, SaaS applications and SaaS app governance can be very challenging in terms of visibility and control. ENow has introduced a free assessment tool called AppGov Score that quantifies the governance state of Microsoft Entra ID apps and gives admins visibility into SaaS apps in the Microsoft cloud.

The post What’s your ENow AppGov Score? Free Microsoft Entra ID app security assessment first appeared on 4sysops.

SystoLOCK in review: Logging in to Active Directory with multi-factor authentication without passwords

5 décembre 2023 à 14:33

SystoLOCK offers a robust solution for enhancing security through multi-factor authentication (MFA) without passwords in an Active Directory environment. Unlike other methods, SystoLOCK does not rely on cloud services. The solution introduces the convenience similar to smartcard-based authentication, eliminating the need for complex password management. Moreover, SystoLOCK allows users to log in securely via VPN connections and supports offline login functionality.

The post SystoLOCK in review: Logging in to Active Directory with multi-factor authentication without passwords first appeared on 4sysops.

Migrate Microsoft Entra Connect (Azure AD Connect) to a new server

Par : Leos Marek
7 décembre 2023 à 09:16

Microsoft Entra Connect, formerly named Azure AD Connect, is an on-premises application used to synchronize your local Active Directory objects to Microsoft Entra ID, also known as Azure AD. This post will guide you through the process of migrating Microsoft Entra Connect to a new server.

The post Migrate Microsoft Entra Connect (Azure AD Connect) to a new server first appeared on 4sysops.

Cybersécurité : durcir la configuration de Windows et Windows Server avec HardeningKitty

11 mars 2024 à 18:00

I. Présentation

Dans ce tutoriel, nous allons effectuer le durcissement de configuration de machines sous Windows à l'aide d'un outil open source nommé HardeningKitty. Autrement dit, nous allons analyser la configuration de notre machine pour voir si elle répond aux bonnes pratiques en matière de sécurité.

Ceci est nécessaire car la configuration par défaut d'un système d'exploitation, que ce soit Linux ou Windows, n'est pas en adéquation avec les bonnes pratiques de sécurité. Certaines recommandations peuvent être trop contraignantes et la configuration doit être adaptée en tenant compte du contexte et des besoins de l'entreprise. Ainsi, c'est à l'administrateur système de faire le nécessaire pour améliorer la sécurité des postes de travail et des serveurs. Le hardening, ou durcissement, va permettre de réduire la surface d'attaque d'une machine.

Dans cet exemple, nous allons durcir la configuration d'un serveur Windows Server 2022, mais la procédure est identique pour une machine Windows 10 ou Windows 11 (d'ailleurs Windows 11 est utilisé pour la vidéo), ainsi que pour des versions plus anciennes de Windows Server. L'essentiel étant de récupérer l'image ISO d'installation depuis le site officiel de l'éditeur, en l'occurrence ici : Microsoft.

II. Les guides de bonnes pratiques pour Windows

Vers qui se tourner pour obtenir des informations sur ces fameuses bonnes pratiques de configuration pour améliorer la sécurité de Windows ?

A. Microsoft Security Baselines

Tout d'abord, il faut savoir que Microsoft propose un ensemble de documents baptisés "Microsoft Security baseline" et correspondants à chaque version de Windows, Windows Server, et certaines applications comme le navigateur Microsoft Edge.

À chaque fois, Microsoft propose une documentation pour lister chaque paramètre à configurer et de quelle façon. Celle-ci est accompagnée par des modèles de GPO, ainsi que des modèles d'administration pour ces mêmes GPO (ADMX), et des scripts PowerShell.

Windows Server 2022 - Security Baselines
Security Baseline pour Windows Server 2022 - Aperçu

Vous pouvez télécharger ces documents via ce lien.

B. Les guides du CIS Benchmark

Le CIS (Center for Internet Security) propose un ensemble de guides de bonnes pratiques pour de nombreux produits et services : Windows, Windows Server, Debian, Cisco, Apache, Fortinet, Google Chrome, Google Workspace, Kubernetes, SQL Server, VMware, Azure, etc... Ces guides, maintenus à jour au fil des versions, ont une excellente réputation. Ils sont très souvent utilisés comme référence lorsque l'on souhaite durcir la configuration d'un système ou d'une application.

Vous pouvez télécharger ces guides gratuitement, après avoir complété un formulaire où l'on vous demandera quelques informations vous concernant.

Si l'on prend l'exemple du guide dédié à Windows Server 2022, il contient 1065 pages. Pour chaque paramètre de configuration à modifier, vous avez une description, des notes, une explication (quel est l'intérêt d'activer / configurer tel paramètre), et les impacts potentiels. Il existe également des versions estampillées STIG (Security Technical Implementation Guide) où il y a un focus supplémentaire sur la partie cybersécurité.

Très intéressant, mais rapidement chronophage.

CIS Benchmark - Windows Server 2022

Vous pouvez télécharger ces guides via cette page.

C. Les autres ressources

Au-delà des ressources proposées par Microsoft et les guides du CIS, nous pouvons compter sur ceux d'autres organisations et entités : l'ANSSI en France, la BSI en Allemagne (l'équivalent de l'ANSSI), la CISA aux Etats-Unis, etc...

Mais à chaque fois, vous ferez surement le même constat :

  • Comment comparer les recommandations d'un guide avec la configuration d'un serveur ou d'un poste de travail ?
  • Comment configurer un serveur ou un poste de travail afin de respecter les bonnes pratiques sans devoir y passer "un temps fou" ?

C'est exactement pour répondre à ces deux problématiques que vous devez vous intéresser à HardeningKitty.

III. Découverte de HardeningKitty

A. HardeningKitty, c'est quoi ?

HardeningKitty est un outil gratuit que vous pouvez utiliser à la fois pour auditer la configuration de votre système et effectuer le durcissement de celle-ci. HardeningKitty est capable de s'appuyer sur la liste de recommandations de l'auteur de l'outil, mais également d'autres "security baselines" comme celles de Microsoft et du CIS. Ainsi, vous allez pouvoir automatiser le hardening de Windows 10, Windows 11, Windows Server, etc.

Le durcissement va modifier différents composants et services de votre système d'exploitation dans le but de réduire la surface d'attaque (ASR), configurer les journaux d'audit de Windows, configurer le pare-feu Windows Defender, activer / désactiver / configurer certaines fonctionnalités, etc. Dans une grande majorité des cas, HardeningKitty modifie le Registre pour effectuer la configuration.

Pour accéder au projet HardeningKitty sur GitHub, il y a deux liens. Un lien vers le projet source d'origine, et un lien vers un autre dépôt où vous pouvez retrouver chaque version stable signée par le certificat de scip AG. Ceci signifie que le script PowerShell d'HardeningKitty peut être exécuté sur une machine Windows même si elle autorise uniquement l'exécution de scripts signés (ceci fait écho à la stratégie d'exécution PowerShell).

B. Prenez des précautions

Avant d'effectuer des modifications en masse sur votre machine Windows, il est primordial d'assurer vos arrières. Autrement dit, prenez les précautions habituelles : testez les modifications sur un environnement de tests et vérifiez vos sauvegardes.

Au-delà de permettre l'audit de la configuration d'une machine, HardeningKitty peut déployer la nouvelle configuration durcie. Forcément, ceci peut être à l'origine d'un ou plusieurs effets de bords. Nous verrons également qu'il y a une fonction de "backup" dans HardeningKitty.

Remarque : vous pouvez aussi envisager d'effectuer une sauvegarde de la base de Registre Windows, et même créer un snapshot s'il s'agit d'une machine virtuelle.

IV. Utilisation d'HardeningKitty sur Windows

A. Télécharger HardeningKitty

Commencez par télécharger la dernière version signée depuis GitHub. Pour ma part, il s'agit de la version 0.9.2. Vous obtenez une archive ZIP qu'il suffit de décompresser afin d'obtenir un ensemble de fichiers, notamment le module PowerShell correspondant à HardeningKitty.

Télécharger HardeningKitty Windows

Notez également la présence du dossier "lists" qui contient un ensemble de fichiers CSV : un fichier CSV par liste de bonnes pratiques supportées par l'outil.

HardeningKitty - Dossier lists

Nous avons à chaque fois deux fichiers CSV : un pour les paramètres de l'ordinateur (machine) et un pour les paramètres de l'utilisateur (user).

B. Sauvegarde de la configuration actuelle

Avant même d'auditer notre configuration ou d'effectuer la moindre modification sur le système, nous allons sauvegarder l'état actuel. Attention, quand vous utilisez HardeningKitty, vous devez effectuer une sauvegarde correspond à la liste ou aux listes que vous envisagez de "déployer" par la suite.

Dans cet exemple, nous allons utiliser ces deux listes :

  • CIS Microsoft Windows Server 2022 (Machine) - 22H2 - 2.0.0
    • Soit le fichier : finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_machine.csv
  • CIS Microsoft Windows Server 2022 (User) - 22H2 - 2.0.0
    • Soit le fichier : finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_user.csv

Ouvrez une console PowerShell en tant qu'administrateur afin de pouvoir utiliser l'outil.

Positionnez-vous dans le répertoire d'HardeningKitty et importez le module :

cd C:\users\Administrateur\Downloads\HardeningKitty-v.0.9.2\
Import-Module .\HardeningKitty.psm1

Pour effectuer la sauvegarde des paramètres machines et utilisateurs pour les listes évoquées ci-dessus, utilisez ces commandes :

# Paramètres machine
Invoke-HardeningKitty -Mode Config -Backup -BackupFile ".\Backup_$($env:COMPUTERNAME)_$(Get-Date -Format yyyyMMdd-hhmm)_Machine.csv" -FileFindingList ".\lists\finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_machine.csv"
# Paramètres utilisateur
Invoke-HardeningKitty -Mode Config -Backup -BackupFile ".\Backup_$($env:COMPUTERNAME)_$(Get-Date -Format yyyyMMdd-hhmm)_User.csv" -FileFindingList ".\lists\finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_user.csv"

À chaque fois, nous obtiendrons un fichier de "sauvegarde" au format CSV dont le nom sera constitué de la façon suivante :

  • Backup_<nom de l'ordinateur>_<Date et heure actuelle>_<Machine ou User>.csv

Quelques secondes ou minutes sont nécessaires pour effectuer la sauvegarde.

HardeningKitty - Sauvegarde de la configuration

Quand c'est fait, nous obtenons deux fichiers :

HardeningKitty - Fichiers CSV de backup

C. Auditer la configuration de la machine

La sauvegarde de la configuration étant effectuée, nous allons pouvoir auditer notre machine. Là encore, nous allons bien spécifier les noms des listes que nous souhaitons utiliser comme référence.

HardeningKitty doit être utilisé en mode "Audit" :

# Audit des paramètres machine
Invoke-HardeningKitty -Mode Audit -Log -Report -FileFindingList ".\lists\finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_machine.csv"
# Audit des paramètres utilisateur
Invoke-HardeningKitty -Mode Audit -Log -Report -FileFindingList ".\lists\finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_user.csv"

À chaque fois, HardeningKitty indique une note globale ainsi que le nombre de paramètres vérifiés et les résultats associés. Ici, nous pouvons qu'il y a eu 459 paramètres vérifiés et qu'il y en a 312 points de configuration à améliorer. L'idée étant de se concentrer en priorité sur ceux considérés comme "Medium" et "High". Imaginez un instant effectuer toutes ces corrections manuellement...

Your HardeningKitty score is: 3.57. HardeningKitty Statistics: Total checks: 459 - Passed: 147, Low: 43, Medium: 269, High: 0.

Le résultat dépend clairement de la liste utilisée. En effet, sur une même machine, mais avec la liste de vérification par défaut de l'outil (qui est le fruit de l'expertise de l'auteur de cet outil - Elle est estampillée Windows 10 !), le score obtenu est totalement différent :

Your HardeningKitty score is: 3.22. HardeningKitty Statistics: Total checks: 391 - Passed: 79, Low: 68, Medium: 243, High: 1.

Si l'on s'appuie sur la liste de Security Baseline de Microsoft pour Windows Server 2022, en prenant la configuration adaptée pour les contrôleurs de domaine (ici, l'outil est utilisé sur un DC), le résultat est encore différent :

# Exécuter l'audit :
Invoke-HardeningKitty -Mode Audit -Log -Report -FileFindingList ".\lists\finding_list_msft_security_baseline_windows_server_2022_21h2_dc_machine.csv"

# Résultat obtenu :
Your HardeningKitty score is: 3.2. HardeningKitty Statistics: Total checks: 328 - Passed: 74, Low: 27, Medium: 227, High: 0.
  • Nommer le rapport d'audit

Afin de pouvoir effectuer une analyse et avoir un bon aperçu de l'état actuel de la configuration du serveur, il est préférable de générer un rapport d'audit. Ceci est déjà le cas avec le paramètre "-Report". HardeningKitty va générer un fichier CSV que l'on pourra exploiter dans Excel.

Pour créer un rapport avec le nom de votre choix, ajoutez le paramètre "-ReportFile" suivi du nom du fichier. Nous allons réutiliser la même logique pour le nom du fichier de rapport. Voici un exemple :

Invoke-HardeningKitty -Mode Audit -Log -Report -FileFindingList ".\lists\finding_list_msft_security_baseline_windows_server_2022_21h2_dc_machine.csv" -ReportFile ".\Audit_$($env:COMPUTERNAME)_$(Get-Date -Format yyyyMMdd-hhmm)_Machine.csv"

En sortie, le fichier suivant est obtenu :

Audit_SRV-ADDS-01_20240228-1259_Machine.csv

Si nous l'ouvrons avec Excel, nous pouvons appliquer différents filtres, un tri, etc... pour analyser les résultats.

HardeningKitty - Rapport audit CSV dans Excel
  • Affiner l'audit avec un filtre

Si vous souhaitez effectuer un audit en tenant compte uniquement des points dont la sévérité est élevée, vous pouvez ajouter un filtre comme ceci :

Invoke-HardeningKitty -Filter { $_.Severity -eq "High" } -FileFindingList ".\lists\finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_machine.csv"

Lorsque la phase d'audit est terminée, vous pouvez passer à l'action : demander à HardeningKitty de durcir la configuration de votre machine.

Remarque : comment est calculé le score d'audit ? Sachez que la formule utilisée pour calculer le score d'HardeningKitty est la suivante : (Points obtenus / Maximum de points) * 5 + 1.

D. Durcir la configuration de la machine

Pour durcir la configuration de la machine Windows Server 2022, nous utilisons le mode "HailMary" (Ave Maria). A ce sujet, la documentation officielle précise : "La méthode HailMary est très puissante. Elle peut être utilisée pour déployer une liste de résultats sur un système. Tous les résultats sont placés sur ce système selon les recommandations de la liste. Le pouvoir s'accompagne de la responsabilité. N'utilisez ce mode que si vous savez ce que vous faites. Assurez-vous d'avoir une copie de sauvegarde du système."

Le mode HailMary va nous permettre de déployer tous les paramètres de configuration contenus dans les deux listes que nous avons choisi d'utiliser.

  • Voici la commande à exécuter pour déployer les paramètres ordinateurs :
Invoke-HardeningKitty -Mode HailMary -Log -Report -FileFindingList ".\lists\finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_machine.csv"
  • Voici la commande à exécuter pour déployer les paramètres utilisateurs :
Invoke-HardeningKitty -Mode HailMary -Log -Report -FileFindingList ".\lists\finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_user.csv"

Sachez qu'avant d'effectuer des modifications sur votre machine, HardeningKitty va créer un point de restauration. Si le point de restauration ne peut pas être créé, ce qui sera le cas sur Windows Server car il faut utiliser la Sauvegarde Windows à la place, l'opération est arrêtée immédiatement. Nous devons donc réexécuter les commandes avec le paramètre "-SkipRestorePoint".

Invoke-HardeningKitty -Mode HailMary -Log -Report -FileFindingList ".\lists\finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_machine.csv" -SkipRestorePoint

À chaque fois, et puisque nous avons précisé les paramètres "-Log" et "-Report", un fichier journal et un fichier de rapport (CSV) seront générés. Le fichier de log reprend toutes les lignes visibles dans la console. Voici un extrait du fichier journal "hardeningkitty_log_srv-adds-01_finding_list_cis_microsoft_windows_server_2022_22h2_2.0.0_machine-20240228-113957.log" :

[*] 28/02/2024 11:40:15 - Starting Category Administrative Templates: Windows Components
ID 18.10.89.1.1, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Client, AllowBasic, Registry key created
ID 18.10.89.1.1, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Client, AllowBasic, Registry value created/modified
ID 18.10.89.1.2, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Client, AllowUnencryptedTraffic, Registry value created/modified
ID 18.10.89.1.3, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Client, AllowDigest, Registry value created/modified
ID 18.10.89.2.1, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service, AllowBasic, Registry key created
ID 18.10.89.2.1, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service, AllowBasic, Registry value created/modified
ID 18.10.89.2.2, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service, AllowAutoConfig, Registry value created/modified
ID 18.10.89.2.3, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service, AllowUnencryptedTraffic, Registry value created/modified
ID 18.10.89.2.4, HKLM:\Software\Policies\Microsoft\Windows\WinRM\Service, DisableRunAs, Registry value created/modified

Mais, priorisez la lecture du rapport avec Excel, ou un autre outil, pour l'analyse post-hardening. Ce rapport permet d'avoir une liste exhaustive des changements de configuration effectués.

Par la suite, si vous avez besoin de revenir en arrière, vous pouvez restaurer la configuration via cette commande (en adaptant le nom du fichier CSV) :

Invoke-HardeningKitty -Mode HailMary -Log -Report -FileFindingList ".\Backup_SRV-ADDS-01_20240228-1128_user.csv" -SkipRestorePoint

V. Conclusion

Si vous souhaitez durcir la configuration de vos machines en vous appuyant sur les recommandations de Microsoft, du CIS, du BSI, ou du DoD, alors HardeningKitty est probablement l'outil qu'il vous faut ! L'utilisation de cet outil devrait vous permettre de gagner énormément de temps. Néanmoins, vous devez prendre le temps d'analyser le contenu de ces guides et devez avoir une bonne connaissance de votre infrastructure et de ses particularités. Ceci vous permettra d'anticiper les éventuels effets de bords.

D'ailleurs, si vous envisagez de déployer la configuration recommandée par le CIS Benchmark, vous devez parcourir chaque guide afin d'avoir un aperçu des fonctions et services de Windows qui seront affectés lorsque le déploiement sera fait avec HardeningKitty. Cette recommandation s'applique également pour les autres guides.

Le seul bémol, c'est le fait qu'il soit nécessaire de l'exécuter machine par machine : ce qui pourra s'avérer utile lors de la création d'un master (image de référence) pour vos postes de travail ou serveur. En effet, ceci vous permettra de créer une image durcie.

HardeningKitty intègre bien un paramètre mode "GPO" (-Mode GPO) permettant de convertir une liste de résultats en une stratégie de groupe (GPO). Toutefois, ceci semble encore expérimental : "Pour l'instant, seuls les paramètres de registre peuvent être convertis et tout n'a pas encore été testé."

The post Cybersécurité : durcir la configuration de Windows et Windows Server avec HardeningKitty first appeared on IT-Connect.

Comment automatiser la gestion des comptes Active Directory et Microsoft 365 dans les écoles et les CFA ?

14 mars 2024 à 07:55

Dans les centres de formation professionnelle, tels que les CFA, la gestion des apprenants est un véritable défi au quotidien, que ce soit pour la direction, l’équipe pédagogique ou le service informatique. En effet, les outils numériques étant de plus en plus présents et intégrés dans les programmes de formation, le service informatique doit être impliqué et il doit apporter des réponses concrètes aux besoins des étudiants et des formateurs.

Afin de pouvoir donner accès aux outils numériques, tels que les postes de travail, aux apprenants, tout en respectant les bonnes pratiques en matière de sécurité ainsi que le règlement RGPD, le centre de formation doit se rendre à l’évidence : chaque apprenant doit disposer de son propre compte utilisateur et ce compte lui est dédié. Se pose alors une question : comment gérer des centaines ou des milliers de comptes apprenants de façon efficace ? Ceci tout en tenant compte du fait que les effectifs évoluent toutes les semaines ou presque.

La société DELIBERATA a développé des outils pour répondre à ces besoins, notamment pour automatiser la gestion des comptes apprenants. Cet article a pour objectif de présenter de façon synthétique les outils mis au point par les équipes de DELIBERATA.

Quelques mots sur l’entreprise DELIBERATA

DELIBERATA, société de conseil et d’accompagnement informatique qui a développé une forte compétence depuis quelques années dans le domaine des centres de formation professionnelle, dont les CFA (centres de formation d’apprentis). Avec une connaissance approfondie de leurs environnements techniques, organisationnels et fonctionnels.

L’originalité de l’équipe DELIBERATA est sa polyvalence : les profils variés des 10 collaborateurs couvrent l’ensemble des outils et usages numériques des centres de formation (gouvernance informatique, administration des systèmes et réseaux, intégration logicielle, support aux utilisateurs, …).

DELIBERATA assure depuis 10 ans le service informatique de centres de formation. L’une des problématiques rencontrées est l’administration des comptes informatiques des apprenants : avec plusieurs milliers de comptes et de sessions informatiques à créer, modifier, désactiver chaque année, dans un contexte d’inscriptions et de clôtures d’inscription à traiter tout au long de l’année scolaire.

DELIBERATA a imaginé et développé plusieurs outils logiciels d’automatisation de la gestion des comptes informatiques, qui sont éprouvés quotidiennement par plusieurs dizaines de centres de formation au bénéfice de 25 000 apprenants.

Les outils de DELIBERATA

Dans la suite de cet article, nous allons évoquer les articles développés en interne par les équipes de DELIBERATA. D’ailleurs, ayant travaillé dans cette société pendant plusieurs années, sachez que je suis à l’origine des deux premiers outils qui sont présentés ci-dessous.

SYNC-YAO

Commençons par le premier outil nommé SYNC-YAO. Ce logiciel a pour objectif de gérer les comptes et les sessions de travail informatiques des apprenants, tout au long de leur cycle de formation.

L’outil s’appuie sur plusieurs services de chez Microsoft : l’annuaire Active Directory en tant que base de comptes principale, le rôle de serveur de fichiers pour le stockage des données des sections, et Microsoft 365 pour les adresses électroniques.

SYNC-YAO est capable de s’interfacer avec le progiciel YPAREO (éditeur YMAG) ou tout autre progiciel de gestion de la formation, en tant que source de données. Il prend en charge les configurations basées sur plusieurs sites.

En premier lieu, SYNC-YAO va procéder à la création des comptes Active Directory, Microsoft 365 et de l’adresse électronique associée, pour chaque apprenant du centre de formation.

Pendant la formation, SYNC-YAO va actualiser les comptes des apprenants pour tenir compte des changements : changement de groupe, correction orthographique du nom de famille, etc.

En sortie de formation, SYNC-YAO va procéder à la désactivation du compte Active Directory, à l’archivage des données de l’apprenant et effectuer l’attribution de la licence « Exchange Online pour les anciens élèves » au compte Microsoft 365. L’objectif étant de pouvoir garder contact avec les apprenants, notamment les apprenants diplômés.

A chaque exécution de l’application, un rapport est généré et il est transmis par e-mail à un ensemble de destinataires (service informatique, équipe pédagogique, etc.). Voici un exemple :

Exemple de rapport SYNC-YAO

En résumé, SYNC-YAO va gérer les accès informatiques de chaque apprenant de son arrivée à son départ du centre de formation, en prenant en considération les éventuels changements. Chaque apprenant est traité de façon indépendante, et ce, quotidiennement.

SYNC-AD TEAMS

Autre logiciel intéressant, complémentaire à SYNC YAO : SYNC-AD TEAMS. Il gère les équipes Microsoft Teams pédagogiques et leurs membres. Son objectif est de créer et gérer une équipe Teams par section, tout en associant les apprenants et les formateurs rattachés au groupe.

À l’instar de SYNC-YAO, ce logiciel est capable de s’interfacer avec le progiciel YPAREO (éditeur YMAG) ou tout autre progiciel de gestion de la formation, en tant que source de données.

SYNC-AD TEAMS va créer une équipe Microsoft Teams « apprenants + formateurs » pour chaque groupe de formation enregistré dans le progiciel, intégrant en tant que « propriétaires » les formateurs ayant été associés ou planifiés pour ce groupe et comme « membres » les apprenants inscrits dans ce groupe.

Quotidienne, chaque équipe Teams sera mise à jour afin de prendre en compte les modifications de planning, les inscriptions et clôtures d’inscription d’apprenants ainsi que l’éventuelle modification de nom du groupe de formation.

En complément de l’équipe Teams, le logiciel crée et maintient à jour un groupe Microsoft 365 « apprenants » associé à chaque équipe Teams, regroupant uniquement les apprenants de l’équipe (sans les formateurs).

Plusieurs modes de fonctionnement sont proposés, dont la possibilité de rendre l’équipe pluriannuelle (c’est à dire associée à une promotion). A chaque exécution de l’application, un rapport est généré et il est transmis par e-mail à un ensemble de destinataires (service informatique, équipe pédagogique, etc.).

AD-EXAM

Troisième exemple d’application : AD-EXAM. Ce logiciel permet aux directions et services administratifs des CFA de créer les sessions informatiques dédiées aux examens, et qui seront exploitées par les candidats et les membres du jury.

Ainsi, sans solliciter le service informatique, le centre de formation peut générer ces sessions spéciales qui bénéficieront ensuite des restrictions nécessaires permettant d’être en conformité avec les consignes de l’examen.

Les services sur-mesure de DELIBERATA pour les centres de formation

Comme évoqué précédemment, l’offre de services de DELIBERATA s’applique également à d’autres composantes du système d’information des centres de formation, parmi lesquelles :

  • L’analyse décisionnelle (business intelligence) :
    • Objectifs :
      • Récupérer automatiquement les données utiles des progiciels exploités par les centres de formation (Ypareo, Hub3E, Sage…)
      • Disposer d’une base de données interrogeable facilement
      • Automatiser la production d’indicateurs
      • Construire des tableaux de bords et du reporting sous Excel et tout autre outil (Power BI, MyReport…)
    • Exemples de tableaux de bord et indicateurs automatisables :
      • Tableau de bord de facturation prévisionnelle fondé sur les échéanciers
      • Tableau de bord de réalisation/facturation du chiffre d’affaires avec projection sur les exercices passés et à venir
      • Extraction des présences pour facturation des repas et hébergements
      • Effectifs par statut, formation, niveau, diplôme, année, situation, opco, entreprise, provenance, statut, qualité…
      • Indicateurs de suivi des heures apprenant (prévu/réalisé) et des heures formateurs par groupe, formation, …
      • Indicateur du taux d’apprenants entrés sans contrat ayant trouvé une entreprise
      • Indicateurs de ruptures brutes/nettes

  • La spécification, l’intégration et l’exploitation de progiciels et applications métier sur mesure :
    • Aide à l’administration et l’utilisation du progiciel Ypareo (éditeur Ymag)
    • Développement d’interfaces applicatives (Ypareo-ARD, Ypareo-Moneweb, Ypareo-Hub3E, Ypareo-360Learning…)
    • Conception et développement d’applications sur mesure complémentaires au progiciel Ypareo (éditeur Ymag), interfacées de façon bidirectionnelle avec le progiciel
    • Définition de schéma directeur numérique, étude de faisabilité, chefferie de projet, accompagnement au changement, etc.

Retrouvez plus d’informations sur la page « Notre accompagnement des centres de formation » disponible sur le site officiel de DELIBERATA.

Vous pouvez également contacter DELIBERATA :

  • Par e-mail : contact [@] deliberata.com
  • Par téléphone : 02.44.84.90.91

Vous pouvez également commenter cet article si vous avez des questions.

Remarque : il ne s'agit pas d'un article sponsorisé, mais simplement la mise en avant d'une PME Caennaise (qui est par ailleurs mon ancien employeur).

The post Comment automatiser la gestion des comptes Active Directory et Microsoft 365 dans les écoles et les CFA ? first appeared on IT-Connect.

Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast

26 mars 2024 à 08:00

I. Présentation

Dans cet article, nous allons comprendre, exploiter et corriger une vulnérabilité fréquente sur les environnements Active Directory : ASREPRoast.

Ce nom ne vous dit peut-être rien, mais il s'agit d'un défaut de configuration fréquent dans l'Active Directory. L'attaque ASREPRoast permet à un attaquant situé sur un réseau d'entreprise possédant un domaine de compromettre rapidement un compte utilisateur, et ainsi de passer d'un mode opératoire boite noire (attaque sans identifiants valides, juste une connexion au réseau) à un mode boite grise (attaque depuis un compte valide sur le domaine). Le passage d'un mode boite noire à boite grise change en général la donne de façon très importante lors d'une cyberattaque, car l'accès authentifié au domaine permet d'en extraire beaucoup d'informations.

L'objectif de cet article est de vous expliquer en détail cette vulnérabilité. Nous allons notamment voir comment elle peut être introduite sur un Active Directory, comment un attaquant peut l'exploiter et comment un défenseur peut l'identifier et la corriger.

C'est parti !

II. Qu'est-ce que l'attaque ASREPRoast ?

A. Dans les grandes lignes

Commençons par essayer de comprendre le nom de l'attaque. "ASREP" fait référence au message "KRB-AS-REP" du service Kerberos lors d'une authentification (réponse à un message KRB-AS-REQ, une requête d'authentification Kerberos). "Roast" renvoi simplement au mot "rôtir" ou "cuisiner" car l'on devra ensuite travailler un peu sur la donnée obtenue pour pouvoir l'utiliser.

Au sein d'un domaine, l'authentification Kerberos est assurée par le composant Key Distribution Center (KDC) des contrôleurs de domaine. Lorsqu'un utilisateur souhaite accéder à un service ou à une ressource réseau, il doit d'abord obtenir un Ticket Granting Ticket (TGT) auprès du KDC. Pour cela, l'utilisateur envoie une requête de type "KRB-AS-REQ" (Kerberos Authentication Service Request) au KDC, elle contient notamment des informations d'identification de l'utilisateur et une clé liée à son mot de passe.

Le KDC vérifie alors les informations d'identification fournies par l'utilisateur. Si celles-ci sont correctes et que l'utilisateur existe dans le domaine, le KDC lui délivre un TGT. Ce TGT est ensuite utilisé par l'utilisateur pour obtenir des tickets de session (TGS) auprès des services du domaine, lui permettant d'accéder à ceux-ci sans avoir à fournir à nouveau ses informations d'identification. Ce processus s'appelle pre-authentification.

Schéma d'une authentification Kerberos et de l'émission d'un TGT.
Schéma d'une authentification Kerberos et de l'émission d'un TGT.

Cependant, il existe une configuration spécifique représentée par un attribut sur les comptes utilisateurs appelé "Do not require Kerberos preauthentication". Cet attribut autorise l'envoi d'un TGT pour un compte sans que le demandeur n'ait prouvé son identité au préalable.

Schéma de l'émission d'un TGT pour un utilisteur ayant l'attribut "Do not require Kerberos preauthentication".
Schéma de l'émission d'un TGT pour un utilisteur ayant l'attribut "Do not require Kerberos preauthentication".

En conséquence, n'importe qui sur le réseau peut obtenir un TGT représentant ce compte utilisateur et tenter d'usurper son identité. Il est important de noter que le TGT obtenu ne peut être utilisé que si la personne qui le détient connaît le mot de passe du compte associé. Cependant, en cas d'utilisation d'un mot de passe faible, le contenu du TGT peut être utilisé pour retrouver le mot de passe du compte utilisateur.

Le TGT ne contient pas directement le mot de passe de l'utilisateur. Mais, il contient des informations chiffrées grâce au secret de l'utilisateur, qui sont utilisés pour prouver l'identité de l'utilisateur lorsqu'il demande des tickets de session ultérieurs. Ainsi, des "traces" du mot de passe s'y trouve, ce qui permet de tenter de casser le TGT pour retrouver le mot de passe en clair.

Cette attaque est très connue des attaquants, si bien qu'elle dispose de son propre TTP (Tactics, Technics and Procedures) dans le framework MITRE ATT&CK : T1558.004- Steal or Forge Kerberos Tickets: AS-REP Roasting.

B. Dans le détail

Regardons à présent dans le détail ce qu'il se passe lors d'une authentification via Kerberos. Pour cela, j'ai effectué une capture réseau des échanges dans différents cas de figures.

  • AS-REQ pour un login inexistant

Lorsqu'un utilisateur souhaite s'authentifier auprès du service Kerberos, le client envoi dans un premier temps un message de demande d'authentification ("KRB-AS-REQ"), voici à quoi il ressemble sur une capture réseau (cliquez sur l'image pour zoomer) :

"AS-REQ" suivi d'une erreur "ERR_C_PRINCIPAL_UNKNOWN".
"AS-REQ" suivi d'une erreur "ERR_C_PRINCIPAL_UNKNOWN".

Dans le cas d'une demande d'authentification avec un login incorrect, c'est-à-dire qui n'existe pas dans l'Active Directory, le service Kerberos renvoi un message de type "KRB-ERROR : C-PRINCIPAL-UNKNOWN" en réponse à l'AS-REQ" du client. Le message est clair : l'utilisateur "MMARTIN1" n'existe pas dans l'Active Directory.

  • AS-REQ pour un login existant avec pré-authentification

Si le login est correct, le service renvoi une réponse de type "KRB-ERROR : PREAUTH REQUIRED". Cette réponse du service Kerberos indique que pour obtenir un TGT pour cet utilisateur, il faut au préalable s'authentifier, ce qui est plutôt une bonne nouvelle d'un point de vue sécurité. Rappelons que les TGT sont des tickets qui permettent de demander des TGS (Ticket Granting Service) pour accéder à un service au nom de l'utilisateur présenté dans le ticket. Il est donc préférable de prouver son identité (s'authentifier) au préalable.

À noter que cette différence de comportement dans la réponse du service ("PRINCIPAL_UNKNOWN "ou "PREAUTH REQUIRED") permet une énumération des utilisateurs basée sur un dictionnaire. Sans même connaitre le mot de passe associé à un compte, on peut savoir s'il existe dans l'annuaire, car le service Kerberos nous indiquera clairement cette information dans sa réponse.

Voici à quoi rassemble une réponse "PREAUTH_REQUIRED". Suite à cette réponse, notre client s'authentifie envoyant un message "AS-REQ", encore ? (cliquez sur l'image pour zoomer) :

Réponse "ERR_PREAUTH_REQUIRED" indiquant que le compte utilisateur existe dans l'annuaire.
Réponse "ERR_PREAUTH_REQUIRED" indiquant que le compte utilisateur existe dans l'annuaire.

Ce second message "AS-REQ" contient cependant un nouvel item, il s'agit d'une donnée chiffrée à l'aide d'une clé liée au mot de passe utilisateur. Si le service Kerberos parvient à déchiffrer ce message avec le mot de passe de l'utilisateur (qu'il possède de son côté grâce à l'annuaire et sa base NTDS.DIT) alors, il aura la preuve qu'il s'agit du bon mot de passe, et donc du vrai utilisateur. Tout cela sans que le mot de passe n'ait transité en clair sur le réseau. Pour plus de détails, sachez que la donnée chiffrée est un timestamp : c'est-à-dire la date et l'heure actuelle dans un format précis (notez le "pA-ENC-TIMESTAMP" dans la seconde AS-REQ).

Enfin, si les identifiants sont corrects, le service envoi un message de réponse "AS-REP" contenant notamment un TGT, qui permet de demander ensuite des TGS (cliquez sur l'image pour zoomer) à différents services :

Transmission d'un TGT par le service Keberos suite à une authentification réussie.
Transmission d'un TGT par le service Keberos suite à une authentification réussie.

Voilà à quoi ressemble une authentification "classique" via Kerberos en vue d'obtenir un TGT.

  • AS-REQ pour un login existant sans pré-authentification

Cependant, Microsoft a ajouté un attribut aux objets utilisateur qui permet d'autoriser le service Kerberos à fournir un TGT à quiconque le demande, sans authentification : l'attribut "Do not require Kerberos preauthentication". Dans ce cas, un attaquant peut demander un TGT pour un tel compte sans avoir besoin de fournir de preuve d'identité valide. Voilà alors ce qu'il se passe (cliquez sur l'image pour zoomer) :

Obtention d'un TGT sans authentification préalable pour un utilisateur ayant l'attribut "No preauthentication required".
Obtention d'un TGT sans authentification préalable pour un utilisateur ayant l'attribut "No preauthentication required".

Une "AS-REQ", demandant un TGT pour l'utilisateur "RDUBOIS", puis une "AS-REP" du KDC délivrant TGT, le tout sans preuve d'identité (authentification). N'importe qui peut donc usurper l'identité de l'utilisateur "RDUBOIS" en demandant un TGT à son nom, puis utiliser ce TGT pour demander des TGS aux services du domaine et y accéder.

Pour être plus précis, rappelons que le TGT obtenu dans les messages "AS-REP" est chiffré et ne peut être utilisé sans connaître le mot de passe du compte utilisateur. Cependant, étant donné qu'il est chiffré avec un dérivé du mot de passe utilisateur, l'attaquant pourra tenter de casser ce mot de passe en Offline (localement, sans interactions supplémentaires avec le KDC ou le domaine), pour retrouver le mot de passe de l'utilisateur.

En résumé, quand cet attribut est présent sur un compte utilisateur, n'importe qui peut obtenir une donnée (le TGT) qui utilise un dérivé du mot de passe du compte utilisateur, et donc tenter de retrouver le mot de passe en clair. Même en étant confiant sur l'algorithme de chiffrement et la robustesse du mot de passe utilisé, reconnaissons qu'il est plutôt périlleux de fournir ce genre d'informations à un simple visiteur non authentifié sur notre système d'information.

J'espère que cette vue en détail des échanges Kerberos vous aura permis de mieux comprendre le fonctionnement de l'attaque ASREPRoast.

C. Pourquoi cet attribut ?

Certaines applications ne prennent pas en charge la pré-authentification Kerberos, il est ainsi courant de trouver des utilisateurs avec la pré-authentification Kerberos désactivée, permettant ainsi aux attaquants de demander des TGT pour ces utilisateurs. C'est la raison principale de l'existence de ce paramètre d'après la documentation Microsoft. La pré-authentification Kerberos peut également être désactivée pour d'autres raisons liées à des besoins spécifiques de sécurité ou de compatibilité avec d'autres systèmes.

Dans la réalité, il n'est pas rare de trouver de tels comptes, notamment sur des systèmes d'information qui ont un certain historique...

III. Configuration d'un Lab vulnérable

Attention, dans ce chapitre, nous allons configurer de manière volontaire un Lab vulnérable pour vous exposer le but et le fonctionnement de l'attaque.

NE PAS REPRODUIRE SUR UN ENVIRONNEMENT DE PRODUCTION.

Dans mon Lab de démonstration, j'ouvre la console "Utilisateurs et ordinateurs Active Directory", puis je sélectionne un de mes utilisateurs, ici l'utilisateur "RDUBOIS". Il faut ensuite faire un clic droit "Propriétés" sur cet objet et se rendre dans "Compte" :

Configuration de l'attribut "Do not require Kerberos preauthentication" sur un compte utilisateur.
Configuration de l'attribut "Do not require Kerberos preauthentication" sur un compte utilisateur.

Dans les "Options de compte", il faut trouver et cocher "La pré-authentification Kerberos n'est pas nécessaire" comme sur l'image ci-dessus.

Si vous vous souvenez des explications précédentes, l'attaque ASREPROAST est d'autant plus dangereuse si le mot de passe utilisé est faible, pour avoir un cas d'école, nous allons paramétrer le mot de passe de l'utilisateur "RDUBOIS" à "#1p@ssword" (ce n'est pas un mot de passe faible ? Vous allez voir que si 🙂 ). Il faut à nouveau faire un clic droit sur l'objet puis "Réinitialiser le mot de passe" :

Paramétrage d'un mot de passe faible sur le compte utilisateur.
Paramétrage d'un mot de passe faible sur le compte utilisateur.

Voilà, notre Lab d'entrainement est prêt !

IV. Point de vue de l'attaquant

Soyez vigilant à n'exploiter ou même tenter de découvrir cette vulnérabilité que si vous y êtes autorisé. Pour rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données

A. Trouver une liste de noms

Vous l'aurez compris, pour effectuer une attaque ASREPRoast, il faut un login utilisateur à tester, voire plusieurs. Dans un premier temps, l'attaquant doit donc se constituer une liste de login (dictionnaire) qu'il soumettra ensuite au service Kerberos.

  • Dans le cas où l'attaquant n'est pas authentifié sur le domaine (boite noire) :

Si l'attaquant n'a pas de compte sur l'Active Directory, il peut utiliser différentes méthodes pour récupérer des logins valides. L'OSINT (Open Source Intelligence) est une méthode assez commune puisqu'avec quelques requêtes Google ou recherches Linkedin, on peut assez facilement retrouver une liste de personnes travaillant dans une entreprise. La recherche dans des fuites de données, basée sur le nom de l'entreprise ou l'adresse mail, est aussi fréquente.

Depuis l'intérieur du réseau (toujours sans compte valide sur le domaine), il existe un grand nombre de techniques également. Les imprimantes sont mon moyen favori, souvent mal protégées avec des interfaces d'administration exposées et verbeuses, elles stockent des carnets d'adresses qui exposent souvent des logins utilisateur. Les applications web internes, services SNMP, SMB et RPC mal configurés (authentification anonyme) ou même l'interception réseau sont également très efficaces.

Également, il est possible pour l'attaquant d'utiliser des dictionnaires pré-conçus utilisant des couples prénom-noms communs, voir des noms de comptes techniques comme "svc-ldap", "backup", "formation", "accueil", etc. Les dictionnaires que j'utilise souvent sont publics et fonctionnent en général très bien, bien qu'utilisant majoritairement des noms anglophones : https://github.com/insidetrust/statistically-likely-usernames.

Avec toutes ces méthodes, il est souvent très facile de se constituer une liste bien fournie de logins utilisateur potentiels. Il faut enfin savoir les formater grâce à la nomenclature actuelle de l'Active Directory ciblé : est-ce "marc.martin", marc_martin, "m.martin", "mmartin" ? etc.

  • Dans le cas où l'attaquant est authentifié sur le domaine (boite grise) :

Si l'attaquant possède déjà un compte sur le domaine, rien de plus facile. Une simple requête LDAP permettra de récupérer la totalité des logins utilisateur de l'annuaire, il aura alors une liste exhaustive des comptes à cibler, augmentant ses chances d'en trouver un avec l'attribut "Do not require Kerberos preauthentication".

Depuis Linux, une requête "ldapsearch" fera l'affaire :

ldapsearch -v -x -D "[email protected]" -W -b "DC=it-connect,DC=tech"  -H "ldap://ad01.it-connect.tech" "(&(objectClass=user))" sAMAccountName |grep "sAMAccountName:" |cut -d " " -f 2 > /tmp/userlist

J'utilise ici la commande "ldapsearch" pour récupérer les attributs "sAMAccountName" des utilisateurs du domaine, puis la commande "grep" pour isoler les lignes qui m'intéressent et enfin "cut" pour isoler uniquement le login de l'utilisateur. Si vous peinez à comprendre cette commande, n'hésitez pas à la décomposer dans votre environnement et à exécuter les commandes une à une. Le tout est enregistré dans le fichier "/tmp/userlist". Voici un exemple du résultat attendu :

Extraction des utilisateurs de l'Active Directory avec un compte valide sur le domaine via "ldapsearch".
Extraction des utilisateurs de l'Active Directory avec un compte valide sur le domaine via "ldapsearch".

Je me retrouve donc avec une liste de 1000 logins utilisateur valides dans le fichier "/tmp/userlist".

L'outil BloodHound va également récupérer la liste des utilisateurs pour les stocker dans un fichier JSON, qui pourra facilement être parcouru pour en extraire les logins. Je vous oriente sur mon cours sur BloodHound si vous souhaitez en savoir plus : Identifiez les faiblesses de votre Active Directory avec Bloodhound

Une fois cette liste, hypothétique, partielle ou complète à disposition, l'attaquant va pouvoir interroger sur le service Kerberos du domaine afin de voir si :

  • L'utilisateur existe dans l'annuaire;
  • Il dispose de l'attribut "Do not require Kerberos preauthentication".

B. Exploiter ASREPRoast depuis Linux

Depuis Linux, une multitude d'outils offensifs existent pour effectuer cette attaque. Je vais ici vous présenter les outils les plus classiques : "impacket" et "netexec".

Impacket est une bibliothèque Python utilisée pour interagir avec des protocoles de réseau tels que SMB, LDAP et Kerberos. Elle offre des outils pour la manipulation de paquets réseau, la création de serveurs et de clients pour ces protocoles, ainsi que des fonctionnalités avancées pour l'analyse et l'exploitation de vulnérabilités. Impacket est très largement utilisé pour les opérations offensives et de nombreux outils utilisent cette librairie.

En plus d'être une librairie très puissante, les créateurs d'Impacket fournissent des scripts qui l'utilisent afin d'automatiser certaines opérations et attaques, comme ASREPRoast. Je ne peux pas détailler ici la procédure d'installation de "Impacket" et de ses "examples scripts", je vous renvoie pour cela à la documentation officielle : Github - Impacket.

  • ASREPRoast en boite noire

Nous allons notamment utiliser le script "impacket-GetNPUsers" ("NP" pour "NoPreauth"). Dans le cas où nous sommes en boite noire, nous avons au préalable construit notre dictionnaire à partir de différentes sources. Nous pouvons utiliser ce dictionnaire pour réaliser une attaque ASREPRoast. Ici,"192.168.56.102" est l'adresse IP de mon contrôleur de domaine, qui héberge le service Kerberos (KDC)) :

impacket-GetNPUsers -usersfile /tmp/userlist -request -format hashcat -outputfile /tmp/IMPACKET_asreproast_blackbox.txt -dc-ip 192.168.56.102 'it-connect.tech/'

L'outil netexec (NXC), également très présent dans les opérations offensives, peut aussi être utilisé :

netexec ldap 192.168.56.102 -u /tmp/userlist -p '' -d it-connect.tech --asreproast /tmp/NXC-asreproast_blackbox.out
  • ASREPRoast en boite grise

Si l'on dispose d'un accès authentifié au domaine, encore mieux, "impacket-GetNPUsers" peut automatiser à la fois la récupération des utilisateurs dans la base LDAP, et l'envoi d'un "AS-REQ" en leur nom pour voir s'ils sont vulnérables à l'ASREPRoast :

impacket-GetNPUsers -request -format hashcat -outputfile ASREProastables.txt -dc-ip 192.168.56.102 'it-connect.tech/mmartin:MyPassword1!'  -outputfile /tmp/IMPACKET_asreproast_greybox.txt

Même principe pour "netexec", il suffira de spécifier l'utilisateur ("-u") et son mot de passe de ("-p") pour s'authentifier auprès du service LDAP afin de récupérer la liste des utilisateurs :

netexec ldap 192.168.56.102 -u mmartin -p 'MyPassword1!' --asreproast /tmp/NXC-asreproast_greybox.txt

Voici le résultat attendu pour "impacket-GetNPUsers" et "netexec" :

Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast.
Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast authentifiée.

On voit donc que plusieurs logins sont tentés sur le service Kerberos et que, pour certains, un hash au format "$krb5asrep$23$" est obtenu. Il s'agit d'une donnée extraite du TGT obtenu pour chaque utilisateur vulnérable, spécialement formaté pour être interprété par des outils de cassage de mot de passe.

Maintenant que nous avons ces hashs, nous pouvons tenter de les casser, par exemple, à l'aide de "JohnTheRipper" ou "hashcat" et de listes de mots de passe communs comme le dictionnaire de mot de passe "rockyou.txt" :

hashcat -m 18200 -a 0 ASREProastables.txt rockyou.txt
john --wordlist=rockyou.txt ASREProastables.txt

Ce cassage s'effectue totalement en local, sans interactions avec l'Active Directory ou le service Kerberos. Ainsi, aucune détection n'est possible. Également, l'utilisateur a ici tout son temps et la rapidité de l'opération dépendra de la robustesse du mot de passe et des ressources de calcul qu'il a à disposition. Si des mots de passe faibles ont été utilisés par les comptes utilisateurs vulnérables, ils seront retrouvés par ces outils :

Cassage du hash "krb5asrep" extrait du TGT de l'utilisateur obtenu via ASREPRoast.
Cassage du hash "krb5asrep" extrait du TGT de l'utilisateur obtenu via ASREPRoast.

Si les mots de passe sont très robustes, alors il faudra déployer des moyens considérables pour les casser. Ici, le mot de passe semble plutôt correct avec 3 alphabets et une longueur de 10 caractères, mais il se trouve dans le dictionnaire public et très connu "rockyou.txt". Nous venons de retrouver le mot de passe d'un utilisateur de l'Active Directory par l'intermédiaire d'un TGT signé grâce à un dérivé de son mot de passe par le service Kerberos.

C. Exploiter ASREPRoast depuis Windows

Sous Windows, l'outil le plus classique pour effectuer cette attaque est "Rubeus.exe", écrit en C#. Le plus simple est de l'exécuter sur une machine intégrée au domaine ou via un "runas.exe" :

.\Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast

Voici le résultat attendu :

Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.
Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.

Comme pour les outils Linux, le fichier "hashes.asreproast" contiendra les hashs contenus dans les TGT récupérés et pourra être passé à "hashcat" ou "JohnTheRipper" pour cassage.

V. Point de vue du défenseur

A. Lister les comptes utilisateurs avec preauth-notreq

Nous allons maintenant adopter le point de vue du défenseur ou blue team qui souhaite savoir si des utilisateurs vulnérables à ASREPROAST sont présents sur son domaine.

Lorsque nous sommes sur notre propre domaine et contrôleur de domaine, le plus simple est d'utiliser le module PowerShell "ActiveDirectory" qui permet de communiquer avec ADSI (Active Directory Services Interface). Nous pouvons notamment cibler l'attribut "useraccountcontrol" pour extraire les utilisateurs disposant de l'attribut "Do not require Kerberos preauthentication", exemple :

Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol | Format-Table name, DistinguisedName, Enabled

Voici le résultat attendu :

Nous avons la même liste utilisateur qu'obtenue via notre requête "ldapsearch" bien entendu, avec un filtre sur ceux qui ont déjà l'attribut "Do not require Kerberos authentication", mais nous utilisons ici des outils légitimes et plus accessibles pour les administrateurs système. J'ai notamment ajouté le "DN" et l'attribut "Enabled" en sortie de la commande (via le "Format-Table" ou "ft").

B. Corriger les comptes vulnérables

Une fois cette liste à disposition, il convient tout d'abord de déterminer :

  • Pourquoi ils sont/ont été utilisés, pour quels besoins, services et systèmes ?
  • Est-ce ce qu'ils sont toujours utilisés aujourd'hui ? (date de dernière authentification, dernier changement de mot de passe, journaux d'évènements)
  • Est-ce que l'attribut "Do not require Kerberos authentication" est vraiment utile et répond à un besoin fonctionnel ?

Une fois que ces questions ont toutes une réponse claire pour chaque compte, la décision de désactiver cet attribut peut être prise.

  • Corriger ASREPRoast via l'interface graphique

Depuis la console "Utilisateurs et ordinateurs Active Directory", effectuez un clic droit sur le compte utilisateur concerné, puis "Propriétés. Il faut ensuite se rendre dans "Compte" et localiser l'option suivante :

Désactivation de l'attribut "Do not require Kerberos preauthentication" sur l'Active Directory.
Désactivation de l'attribut "Do not require Kerberos preauthentication" sur l'Active Directory.

Une fois décochée, nous pouvons appliquer nos changements. La modification prend effet immédiatement.

  • Corriger ASPREPRoast via Powershell

Il est aussi possible de modifier la valeur de cet attribut en PowerShell via ADSI. Le cmdlet "Set-ADAccountControl" est fournie par le module PowerShell "ActiveDirectory" :

PS C:\> Set-ADAccountControl -Identity rdubois -DoesNotRequirePreAuth $false

À nouveau, la modification est prise en compte immédiatement.

  • Mesure complémentaire en cas de besoin fonctionnel

Si l'attribut "Do not require Kerberos preauthentication" est nécessaire et répond à un besoin identifié et justifié, alors il convient de mettre un mot de passe très, très robuste à ce compte. L'idée est que même si un TGT est récupéré, l'attaquant ne puisse pas casser le hash qu'il contient en vue de récupérer le mot de passe en clair de l'utilisateur. Optez donc pour un mot de passe à plus de 30 caractères.

Dans l'idéal, il est également nécessaire de prévoir un renouvellement périodique de ces mots de passe afin de réduire leur exposition dans le temps. Si l'attaquant dispose de tout le temps disponible devant lui pour casser le hash contenu dans le TGT, alors il finira peut-être par y arriver (peut-être au bout de plusieurs années). Mais si le mot de passe du compte est changé tous les six mois, il n'aura potentiellement pas le temps de l'exploiter une fois qu'il l'aura cassé. Il s'agit d'une mesure de sécurité supplémentaire.

  • Limiter la propagation suite à une compromission

Il convient également de s'assurer que le compte qui dispose légitimement de l'attribut "Dot not require Kerberos preauthentication" possède des droits limités sur le domaine et le système d'information. La revue des ACL, appartenances aux groupes et l'application du principe de moindre privilège (configuration fine et minimaliste des droits pour répondre uniquement aux fonctions métiers) permettra de limiter au maximum les actions possibles de l'attaquant en cas de compromission du compte.

  • Changement de mot de passe

Enfin, il est à noter que si le compte a eu jusque-là cet attribut, n'importe quel utilisateur de votre domaine a peut être déjà récupéré un TGT et obtenu son mot de passe, ou est en train de tenter de le casser. Ces mesures de correction doivent donc s'accompagner d'un changement de mot de passe afin qu'un attaquant exploitant ou ayant exploité cette faiblesse ne puisse pas réutiliser le mot de passe compromis pour ce compte, ce qui sera possible même si l'attribut en question a été décoché.

C. Détecter une attaque ASREPRoast

Du point de vue du défenseur, nous allons également nous intéresser aux possibilités de détection d'une attaque ASREPRoast passée ou en cours sur le système d'information.

  • Détection via les journaux d'évènements

L'exploitation de l'ASREPRoast génère, comme toute interaction avec l'Active Directory, des évènements. Cependant, il n'est pas aisé de les distinguer clairement des activités légitimes et quotidiennes des utilisateurs du domaine. Il faut savoir que lorsqu'un "AS-REQ" est effectué sur un compte non vulnérable à l'ASREPRoast (et donc, échoue), aucun évènement de sécurité n'est généré. Seule l'émission d'un ticket Kerberos génère un évènement avec l'eventID 4768.

L'event ID 4768 est enregistré sur le contrôleur de domaine chaque fois qu'un TGT est émis. Il indique que le KDC a reçu une demande de TGT (AS-REQ) et qu'il a émis un TGT en réponse. L'évènement journalisé contient alors quelques détails intéressants sur la demande.

https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768

Cet évènement apparait donc si :

  • La requête est émise avec une authentification valide, auquel cas un TGT est émis en réponse à l'"AS-REQ".
  • La requête porte sur un utilisateur ayant l'attribut "Do not require Kerberos authentication", auquel cas pas besoin d'authentification, le TGT est tout de même émis en réponse à l'"AS-REQ".

Voici l'évènement tel qu'il apparaitra dans l'observateur d'évènement lors d'une demande de TGT classique, avec authentification (utilisation ici de "impacket-getTGT") :

EventID 4768 suite à une demande et émission de TGT classique, avec authentification.
EventID 4768 suite à une demande et émission de TGT classique, avec authentification.

On voit clairement qu'un TGT a été demandé et émis pour l'utilisateur "IT-CONNECT\mmartin" par le client "192.168.56.104". Nous allons également garder dans un coin de notre mémoire les informations relatives au "Type de pré-authentification" et "Type de chiffrement du ticket". Je réalise maintenant la même opération à destination du compte "IT-CONNECT\rdubois" et avec un outil offensif qui va directement demander un TGT sans authentification préalable (utilisation de "netexec") :

EventID 4768 suite à une demande et émission de TGT à la suite d'une attaque ASREPROast via "netexec"
EventID 4768 suite à une demande et émission de TGT à la suite d'une attaque ASREPROast via "netexec".

Les informations journalisées sont globalement les mêmes lors d'une demande et émission d'un TGT sur un compte ne nécessitant pas la pré-authentification. Cependant, on peut noter deux exceptions (à noter que le résultat est le même lors d'une exploitation avec "impacket-getNPUsers") :

  • Le "Type de chiffrement du ticket" est passé à "0x17" au lieu de "0x12".
  • Le "Type de pré-authentification" est passé à "0" au lieu de "2".

L'utilisation d'un chiffrement à "0x17" (RC4-HMAC) est un comportement typique des outils d'attaque qui downgrade (abaissent) le niveau de chiffrement utilisé pour le chiffrement du TGT afin de rendre le cassage de son contenu plus aisé. Par défaut, le niveau de chiffrement "0x12" entraine l'utilisation du AES256-CTS-HMAC-SHA1-96 (Source : 4768(S, F): A Kerberos authentication ticket (TGT) was requested). Voilà un premier élément caractéristique d'une attaque ASREPRoast avec des méthodes et outils classiques.

Egalement, la documentation Microsoft est limpide concernant les valeurs du "Type de pré-authentification" :

La demande de TGT avec une valeur "0" à "Type de pré-authentification" est donc également un signal intéressant à surveiller. Pour finir sur cette détection, je vous propose une requête KQL (pour ELK) qui permet d'identifier les événements de demande/émission d'un TGT avec un chiffrement faible (RC4) ou sans pré-authentification :

event.code:4768 AND (winlog.event_data.TicketEncryptionType: 0x17 OR winlog.event_data.PreAuthType: 0)

Pour détailler un peu la requête. Il s'agit d'un filtre sur les évènements Windows ayant un évènement ID 4768 et qui ont, soit un "TicketEncryptionType" à "0x17" (RC4), soit un "PreAuthType" à "0". Voici le résultat sur l'ELK de mon lab (avec moins d'activité qu'un vrai SI, bien sûr) :

Visualisation dans ELK des évèenemtn caractértistique d'une attaque ASREPRoast

Pas de doute, il y a eu une activité suspecte sur mon SI entre 17h45 et 18h15, des TGT sans pre-authentification et avec un algorithme de chiffrement faible ont été demandés.

Surveiller les modifications des attributs utilisateurs

Pour aller plus loin, vous pouvez également chercher et surveiller les event ID 4738 (A user account was changed) et 5136 (A directory service object was modified) qui apparaissent lorsqu'un attribut utilisateur est modifié :

Journalisation de la modification d'un attribut utilisateur via l'eventID 4738.
Journalisation de la modification d'un attribut utilisateur via l'eventID 4738.

Plutôt que la compromission, vous visualiserez alors tous les évènements d'activation/désactivation de l'attribut concerné sur des comptes utilisateurs, ce qui permettra de retrouver le moment où la vulnérabilité a été introduite sur le compte concerné. Là aussi, il faudra aller plus loin pour réellement identifier le nom de l'attribut modifié et s'assurer de n'obtenir que les alertes relatives à l'attribut "Do not require Kerberos preauthentication". Egalement, voici un exemple de requête filtre KQL pour cet évènement :

event.code:4738 AND winlog.event_data.UserAccountControl:*2096*

Voici l'aperçu d'un tel évènement dans la console ElasticSearch :

Visualisation de l'eventID 4738 relatif à l'ajout de l'attribut "Do not requiere kebreroas pre-authentication" dans ElasticSearch.
Visualisation de l'eventID 4738 relatif à l'ajout de l'attribut "Do not requiere kebreroas pre-authentication" dans ElasticSearch.
  • Utilisation d'un honey account

Si vous maitrisez correctement la sécurité de votre système d'information, notamment avec un SIEM et un SOC (Security Operation Center) efficaces, alors vous pouvez envisager la mise en place d'un honey account, ou "compte pot de miel". L'idée est de créer un compte utilisateur volontairement vulnérable à ASREPRoast afin que sa compromission génère un évènement de sécurité activement surveillé par la blue team.

Pour cela, il faut notamment être sûr que ce compte ne sera jamais utilisé de façon légitime par un utilisateur ou un service du SI. Ainsi, si une demande de TGT pour ce compte spécifique apparait dans les journaux d'évènement, ce sera forcément dû à une attaque ASREPRoast en cours.

Attention : La création et la gestion d'un compte pot de miel nécessitent une attention particulière. Il faut s'assurer que les politiques de sécurité et les procédures de surveillance sont bien établies pour garantir que le compte reste contrôlé et qu'il ne devienne pas une vulnérabilité supplémentaire. Il faut notamment s'assurer que l'honey account ait un mot de passe très robuste afin que le hash contenu dans son TGT ne soit jamais cassé, ce qui permettrait à l'attaquant d'obtenir un compte valide sur le domaine.

VI. Conclusion

J'espère que cet article vous a plu et que vous avez maintenant une meilleure idée des risques liés à cette attaque et de la façon de s'en protéger. J'ai essayé de faire en sorte qu'il soit complet en abordant le point de vue des attaquants comme des défenseurs.

N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

The post Sécurité de l’Active Directory : comprendre et se protéger de l’attaque ASREPRoast first appeared on IT-Connect.

Hier — 27 mars 2024Flux principal

GLPI : comment configurer l’authentification LDAP via l’Active Directory ?

27 mars 2024 à 16:00

I. Présentation

Dans ce tutoriel, nous allons avoir comment configurer l'authentification LDAP de GLPI pour pouvoir se connecter à l'application GLPI à partir des comptes utilisateurs présents dans un annuaire Active Directory. Ainsi, un utilisateur pourra accéder à GLPI à l'aide de son nom d'utilisateur et son mot de passe habituel (puisque ce seront les informations de son compte dans l'Active Directory).

GLPI propose nativement un modèle d'authentification LDAP, ce qui lui permet de s'appuyer sur un annuaire de comptes externe, comme l'Active Directory de Microsoft. Il faut savoir que les comptes utilisateurs de l'Active Directory seront importés dans la base de données de GLPI, grâce à un processus de synchronisation. Lorsqu'un utilisateur Active Directory se connecte pour la première fois, son compte est créé dans GLPI. Avant cela, il n'est pas visible, sauf si vous décidez d'effectuer un "import en masse" des comptes AD dans GLPI.

Par ailleurs, en complément de ce tutoriel, voici le lien vers la documentation officielle :

II. Configuration cible

Avant de passer à la configuration, voici quelques informations sur l'environnement utilisé.

Pour cette démonstration, le domaine Active Directory "it-connect.local" sera utilisé et le contrôleur de domaine SRV-ADDS-02 sera utilisé. Ce serveur dispose de l'adresse IP "10.10.100.11" et la connexion sera effectuée en LDAP, sur le port par défaut (389).

- Le compte utilisateur qui sera utilisé comme "connecteur" pour permettre à GLPI de se connecter à l'Active Directory se nomme "Sync_GLPI". Il est stocké dans l'unité d'organisation "Connecteurs" de l'annuaire (voir image ci-dessous). Il s'agit d'un compte utilisateur standard, sans aucun droit particulier sur l'annuaire Active Directory. Faites-moi plaisir : n'utilisez pas de compte Administrateur.

- Tous les utilisateurs qui doivent pouvoir se connecter à GLPI à l'aide de leur compte Active Directory sont stockés dans l'unité d'organisation "Personnel" visible ci-dessous. Elle correspond à ce que l'on appelle la "Base DN" vis-à-vis du connecteur LDAP de GLPI. Les autres utilisateurs ne pourront pas se connecter. En fait, ce n'est pas utile de mettre la racine du domaine comme base DN : essayez de restreindre autant que possible pour limiter la découverte de l'annuaire Active Directory au strict nécessaire.

- Les utilisateurs de l'Active Directory pourront se connecter à GLPI à l'aide de leur identifiant correspondant à l'attribut "UserPrincipalName" (mis en évidence, en jaune, sur l'image ci-dessous). Cet identifiant, sous la forme "identifiant + nom de domaine", leur permettra se connecter à GLPI avec un identifiant qui correspond à leur e-mail. L'alternative consisterait à utiliser l'attribut "SamAccountName" (soit l'identifiant sous la forme "DOMAINE\identifiant").

GLPI - Arborescence Active Directory

Voilà, maintenant, nous allons pouvoir dérouler la configuration !

II. Installer l'extension LDAP de PHP

L'extension LDAP de PHP doit être installée sur votre serveur pour que GLPI soit capable de communiquer avec votre serveur contrôleur de domaine Active Directory (ou tout autre annuaire LDAP).

Connectez-vous à votre serveur GLPI et exécutez les deux commandes suivantes pour mettre à jour le cache des paquets et procéder à l'installation de l'extension.

sudo apt-get update
sudo apt-get install php-ldap

Cette extension sera installée et activée dans la foulée. Vous n'avez pas besoin de relancer le serveur.

III. Ajouter un annuaire LDAP dans GLPI

Désormais, nous allons ajouter notre annuaire Active Directory à GLPI. Connectez-vous à GLPI avec un compte administrateur, puis dans le menu "Configuration", cliquez sur "Authentification".

GLPI - Configuration - Authentification

Au centre de l'écran, cliquez sur "Annuaire LDAP".

GLPI - Authentification - Annuaire LDAP

Puis, cliquez sur le bouton "Ajouter".

GLPI - Ajouter un nouvel annuaire LDAP

Un formulaire s'affiche à l'écran. Comment le renseigner ? À quoi correspondent tous ces champs ? C'est que nous allons voir ensemble.

  • Nom : le nom de cet annuaire LDAP, vous pouvez utiliser un nom convivial, ce n'est pas obligatoirement le nom du domaine, ni le nom du serveur.
  • Serveur par défaut : faut-il s'appuyer sur ce serveur par défaut pour l'authentification LDAP ? Il ne peut y avoir qu'un seul serveur LDAP défini par défaut.
  • Actif : nous allons indiquer "Oui", sinon ce sera déclaré, mais non utilisé.
  • Serveur : adresse IP du contrôleur de domaine à interroger. Avec le nom DNS, cela ne semble pas fonctionner (malheureusement).
  • Port : 389, qui est le port par défaut du protocole LDAP. Si vous utilisez TLS, il faudra le préciser à postériori, dans l'onglet "Informations avancées", du nouveau serveur LDAP.
  • Filtre de connexion : requête LDAP pour rechercher les objets dans l'annuaire Active Directory. Généralement, nous faisons en sorte de récupérer les objets utilisateurs ("objectClass=user") en prenant uniquement les utilisateurs actifs (via un filtre sur l'attribut UserAccountControl).
  • BaseDN : où faut-il se positionner dans l'annuaire pour rechercher les utilisateurs ? Ce n'est pas nécessaire la racine du domaine, tout dépend comment est organisé votre annuaire et où se situent les utilisateurs qui doivent pouvoir se connecter. Il faut indiquer le DistinguishedName de l'OU.
  • Utiliser bind : à positionner sur "Oui" pour du LDAP classique (sans TLS)
  • DN du compte : le nom du compte à utiliser pour se connecter à l'Active Directory. En principe, vous ne pouvez pas utiliser de connexion anonyme ! Ici, il ne faut pas indiquer uniquement le nom du compte, mais la valeur de son attribut DistinguishedName.
  • Mot de passe du compte : le mot de passe du compte renseigné ci-dessus
  • Champ de l'identifiant : dans l'Active Directory, quel attribut doit être utilisé comme identifiant de connexion pour le futur compte GLPI ? Généralement, UserPrincipalName ou SamAccountName, selon vos besoins.
  • Champ de synchronisation : GLPI a besoin d'un champ sur lequel s'appuyer pour synchroniser les objets. Ici, nous allons utiliser l'objectGuid de façon à avoir une valeur unique pour chaque utilisateur. Ainsi, si un utilisateur est modifié dans l'Active Directory, GLPI pourra se repérer grâce à cet attribut qui lui n'évoluera pas (sauf si le compte est supprimé puis recréé dans l'AD).
GLPI - Formulaire configuration annuaire LDAP

Ci-dessous, la configuration utilisée pour cette démonstration et qui correspond à la "configuration cible" évoquée précédemment.

  • Nom : Active Directory - it-connect.local
  • Serveur par défaut : Oui
  • Actif : Oui
  • Serveur : 10.10.100.11
  • Port : 389
  • Filtre de connexion : (&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
  • BaseDN : OU=Personnel,DC=it-connect,DC=local
  • Utiliser bind : Oui
  • DN du compte : CN=Sync_GLPI,OU=Connecteurs,OU=Tiering,OU=IT,DC=it-connect,DC=local
  • Mot de passe du compte : Mot de passe du compte "Sync_GLPI"
  • Champ de l'identifiant : userprincipalname
  • Champ de synchronisation : objectguid

Quand votre configuration est prête, cliquez sur "Ajouter".

GLPI - Configurer Active Directory

Dans la foulée, GLPI va effectuer un test de connexion LDAP et vous indiquer s'il est parvenu, ou non, à se connecter à votre annuaire. Si ce n'est pas le cas (comme moi, la première fois), cliquez sur le nom de votre annuaire, vérifiez la configuration, puis retournez dans "Tester" sur la gauche afin de lancer un nouveau test. Pour ma part, le problème venait du champ "Serveur" : j'avais mis le nom DNS du serveur à la place de l'adresse IP, mais cela ne fonctionnait pas. Pourtant, mon serveur GLPI parvient bien à résoudre le nom DNS.

GLPI - Tester authentification LDAP

Par ailleurs, vous pouvez explorer les différents onglets : Utilisateurs, Groupes, Réplicats, etc... Pour affiner la configuration. L'onglet "Utilisateurs" est intéressant pour configurer le mappage entre les champs d'une fiche utilisateur dans GLPI et les attributs d'un compte dans l'Active Directory. Quant à l'onglet "Réplicats", vous pouvez l'utiliser pour déclarer un ou plusieurs contrôleurs de domaine "de secours" à contacter si le serveur principal n'est plus joignable.

IV. Tester la connexion Active Directory

Si GLPI valide la connexion à votre annuaire Active Directory, vous pouvez tenter de vous authentifier à l'application avec un compte utilisateur. Pour ma part, c'est l'utilisateur Guy Mauve qui va servir de cobaye. Son login GLPI sera donc "[email protected]" puisque je m'appuie sur l'attribut UserPrincipalName. Pour le mot de passe, je dois indiquer celui de son compte Active Directory.

Remarque : la source d'authentification doit être l'Active Directory.

Connexion à GLPI avec un compte Active Directory

Voilà, l'authentification fonctionne ! L'utilisateur a pu se connecter avec son compte Active Directory et il hérite du rôle "Self-service".

GLPI - Exemple - Connexion avec un utilisateur AD

Dans le même temps, à partir du compte admin de GLPI, je peux remarquer la présence d'un nouveau compte utilisateur dont l'identifiant est "[email protected]" ! GLPI a également récupéré le nom, le prénom et l'adresse e-mail à partir de différents attributs de l'objet LDAP.

Synchronisation GLPI et utilisateur Active Directory

V. Forcer une synchronisation Active Directory

A partir de GLPI, vous pouvez forcer une synchronisation LDAP de façon à mettre à jour les comptes dans GLPI "liés" à des comptes Active Directory, mais aussi pour importer en masse tous les comptes des utilisateurs Active Directory. Ceci vous évite d'attendre la première connexion et vous permet de préparer le compte : attribution du bon rôle, etc.

Cliquez sur "Administration" dans le menu, puis "Utilisateurs". Ici, vous avez accès au bouton "Liaison annuaire LDAP".

Vous avez ensuite le choix entre deux actions différentes, selon vos besoins.

Si vous cliquez sur "Importation de nouveaux utilisateurs", vous pourrez importer en masse les comptes dans l'Active Directory. Il vous suffit de lancer une recherche, de sélectionner les comptes à importer et de lancer l'import grâce au bouton "Actions".

Importer des comptes AD dans GLPI.jpg

Remarque : vous pouvez aussi importer des groupes Active Directory. Pour cela, suivez la même procédure, mais en allant dans "Groupes" sous "Administration".

VI. Conclusion

En suivant ce tutoriel, vous devriez être en mesure d'importer les comptes utilisateurs d'un annuaire Active Directory dans GLPI, pour faciliter la connexion de vos utilisateurs. Sachez que si un utilisateur change son mot de passe dans l'Active Directory, ce n'est pas un problème : GLPI vérifie les informations lors de la connexion.

The post GLPI : comment configurer l’authentification LDAP via l’Active Directory ? first appeared on IT-Connect.

❌
❌