FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Hier — 6 octobre 2022Flux principal

New group policies in Windows 11 2022: Start menu, taskbar, winget, printing, Defender, and IE

6 octobre 2022 à 20:10

The current release of Windows 11 includes over 70 new settings for group policies. Most of these serve as security improvements and have largely been included in the security baseline. In addition, there are new policies for the Windows UI, the package manager winget, and Internet Explorer.

The post New group policies in Windows 11 2022: Start menu, taskbar, winget, printing, Defender, and IE first appeared on 4sysops.

Active Directory : notification par e-mail pour l’expiration de mot de passe

6 octobre 2022 à 16:45

I. Présentation

Dans ce tutoriel, je vous propose de mettre en place un script PowerShell qui va envoyer une notification par e-mail aux utilisateurs X jours avant l'expiration de leur mot de passe Active Directory, afin de les inviter à changer le mot de passe avant la date butoir.

Selon les environnements, et sous réserve qu'il y ait une politique de mots de passe en place (ce qui, malheureusement, n'es pas si évident que ça), l'expiration du mot de passe sur un compte utilisateur peut poser des problèmes de connexion sur des services basés sur l'authentification Active Directory. D'ailleurs, j'ai abordé cette problématique plus en détail dans mon article "Active Directory et la mise en cache des identifiants".

L'une des "solutions" consiste à notifier les utilisateurs que leur mot de passe va expirer, quelques jours avant le jour J où ils devront impérativement changer le mot de passe. C'est ce que nous allons voir aujourd'hui, en passant par PowerShell.

II. Récupérer la date d'expiration du mot de passe avec PowerShell

Au sein de l'Active Directory, et plus particulièrement des comptes utilisateurs, chaque objet dispose d'un attribut qui contient la date et l'heure d'expiration du mot de passe. Cette valeur est calculée selon la politique de mots de passe appliquée sur l'utilisateur. Voici le nom de l'attribut auquel je fais référence :

msDS-UserPasswordExpiryTimeComputed

Cette valeur est visible avec l'interface graphique, avec la console "Utilisateurs et ordinateurs Active Directory" via l'onglet "Editeur d'attributs", ou via PowerShell. Voici un exemple :

Active Directory - msDS-UserPasswordExpiryTimeComputed

La valeur de cet attribut n'est pas directement modifiable, car il s'agit d'un attribut construit dont la valeur a la particularité d'être calculée à partir d'autres attributs (pwdLastSet) et objets. Tous les détails de cet attribut sont disponibles dans la documentation de Microsoft :

Cette information est également visible avec la commande historique "net user", en précisant un nom d'utilisateur, puis en regardant le champ "Le mot de passe expire". Voici un exemple avec l'utilisateur "guy.mauve" :

net user guy.mauve /domain

Toutefois, je trouve que la valeur de l'attribut Active Directory est plus fiable que celle renvoyée par cette commande.

Avec PowerShell, on peut afficher la date d'expiration des mots de passe pour un ensemble d'utilisateurs avec cette commande :

Get-ADUser -Filter { (Enabled -eq $True) -and (PasswordNeverExpires -eq $False)} –Properties "DisplayName", "mail", "msDS-UserPasswordExpiryTimeComputed" | 
           Select-Object -Property "Displayname","mail",@{Name="ExpiryDate";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}}

Cette commande retourne l'information pour tous les utilisateurs activés et dont le mot de passe a une date d'expiration. Voici un exemple de sortie :

Active Directory - Date expiration mots de passe

III. Expiration du mot de passe : notification par e-mail

L'e-mail est un canal de communication privilégié et efficace en entreprise, même s'il y a également d'autres solutions de communication comme Microsoft Teams. Le fait d'envoyer une notification par e-mail à l'utilisateur quelques jours avant l'expiration de son mot de passe va vous permettre de communiquer en direct avec lui, de façon automatique.

Désormais, intéressons-nous au script PowerShell, qui est disponible sur mon GitHub : vous pouvez le réutiliser en l'état ou l'adapter à votre guise. Pour utiliser ce script nommé "Send-ADPasswordExpirationNotifications.ps1", vous avez seulement besoin de modifier ces quelques variables :

# Nombre de jours avant l'expiration pour envoyer la notification
$DateThreshold = 7

# Serveur SMTP - Nom du serveur
$SMTPServer = "smtp.domaine.fr"

# Serveur SMTP - Numéro de port
$SMTPPort = 25

# Serveur SMTP - Adresse e-mail de l'expéditeur
$SMTPSender = "[email protected]"

# Serveur SMTP - Encodage Email
$SMTPEncoding =[System.Text.Encoding]::UTF8

# Envoyer une synthèse aux administrateurs
[boolean]$SendReportAdmin = $true

# Adresse e-mail du destinataire pour la synthèse
$SendReportAdminEmail = "[email protected]"

Vous pouvez adapter le script pour la prise en charge du SSL et/ou des Credentials dans les commandes Send-MailMessage (pour envoyer les e-mails) selon votre environnement. Vous pouvez aussi ajouter l'option "-Cc" avec votre adresse e-mail, si vous souhaitez recevoir une copie de l'e-mail envoyé à chaque utilisateur.

Lorsque ce script tourne, il va récupérer la date d'expiration du mot de passe pour tous les utilisateurs activés et dont l'option "Le mot de passe n'expire jamais" n'est pas cochée. Ensuite :

  • Dans le cas où le seuil de notification est définit à "7", un e-mail sera émis à l'utilisateur si son mot de passe expire dans 7 jours ou moins de 7 jours.
  • Dans le cas où le mot de passe est déjà expiré, la notification n'est pas envoyée.

Chaque utilisateur recevra une notification similaire à celle-ci :

Notification e-mail - Expiration mot de passe Active Directory

Le service informatique recevra une synthèse par e-mail avec la liste des utilisateurs dont le mot de passe expire bientôt. Cet e-mail est envoyé uniquement si "$SendReportAdmin = $true" donc vous pouvez activer ou non ce rapport supplémentaire.

Active Directory - Synthèse des notifications pour les admins

Le script est disponible ici :

Pour que ces notifications soient envoyées automatiquement, il convient d'exécuter ce script dans une tâche planifiée. Sur le contrôleur de domaine avec les rôles FSMO, ce sera très bien à mon sens. Quant au compte utilisé pour l'exécution de la tâche planifiée, un gMSA est conseillé.

L'action à lancer ressemblera à ceci :

powershell.exe -File "C:\Scripts\Send-ADPasswordExpirationNotifications.ps1"

Comme ceci :

Script PowerShell - Tâche planifiée

Si vous n'êtes pas très à l'aise avec cette partie de la configuration, consultez ces deux articles :

IV. Conclusion

Grâce à la mise en place de ce script, vos utilisateurs seront notifiés que leur mot de passe expire prochainement et pourront procéder à la réinitialisation de celui-ci avant l'échéance précisée dans l'e-mail.

Si vous avez des suggestions pour améliorer le script "Send-ADPasswordExpirationNotifications.ps1", n'hésitez pas à m'en faire part.

The post Active Directory : notification par e-mail pour l’expiration de mot de passe first appeared on IT-Connect.
À partir d’avant-hierFlux principal

Windows : comment corriger l’erreur de relation d’approbation ? Voici plusieurs méthodes !

3 octobre 2022 à 17:15

I. Présentation

Pour les administrateurs de parcs informatiques sous Windows avec des machines intégrées à un domaine Active Directory, le message d'erreur "La relation d’approbation entre cette station de travail et le domaine principal a échoué" est un grand classique. Le type d'erreur que l'on rencontre tous au moins une fois, même si l'on aimerait bien s'en passer ! Il existe diverses pistes et solutions pour se sortir de se pétrin... Notamment, manuellement via l'interface graphique, mais aussi en ligne de commande.

Dans ce tutoriel, je vais répondre à une question simple : comment corriger l'erreur "La relation d’approbation entre cette station de travail et le domaine principal a échoué" ? Sur une machine en anglais, le message d'erreur correspondant est "The trust relationship between this workstation and the primary domain failed".

La relation d’approbation entre cette station de travail et le domaine principal a échoué

Windows 11 - Relation approbation erreur

II. Le principe des mots de passe "ordinateurs"

Lorsqu'une machine Windows est intégrée à un domaine Active Directory, un objet appartenant à la classe "computer" est créé dans l'annuaire. Cet objet est alors un compte d'ordinateur pour la machine en question. Au-delà du nom, il y a un mot de passe qui est associé à ce compte : ce mot de passe est connu de la machine Windows et de l'annuaire Active Directory. Par défaut, ce mot de passe est valide pour une durée de 30 jours. Au bout de 30 jours, il est renouvelé automatiquement, sans aucune action de votre part.

En modifiant une stratégie de groupe sur votre environnement, par exemple la GPO "Default Domain Policy" qui est native, vous pourrez retrouver le paramètre "Membre de domaine : ancienneté maximale du mot de passe du compte ordinateur" qui montre que la valeur par défaut est de 30 jours.

Active Directory - Mot de passe des ordinateurs - 30 jours

Quand ce message d'erreur se produit, c'est comme si la confiance entre les deux parties avait soudainement disparu. Dans de nombreux cas, cela s'explique par le fait que le mot de passe de l'ordinateur local (la machine Windows intégrée dans l'AD) ne correspond pas au mot de passe stocké dans l'Active Directory. Autrement dit, le renouvellement du mot de passe ne s'est pas passé comme prévu...

Le renouvellement du mot de passe est initié par la machine Windows, à partir du service Netlogon. Cette opération s'effectue au démarrage, ou au moment de s'authentifier auprès du contrôleur de domaine. Le mot de passe est alors stocké dans le Registre Windows sous "HKLM\SECURITY\Policy\Secrets". De son côté, l'Active Directory stocke également ce nouveau secret. Dans une très grande majorité des cas, ce processus s'effectue correctement : heureusement, sinon tous les 30 jours ce serait infernal.

Parfois, cette opération échoue et l'erreur "La relation d’approbation entre cette station de travail et le domaine principal a échoué" se produit ! Il arrive même que sur une même machine, cette erreur revienne assez régulièrement. Je pense qu'il y a plusieurs erreurs qui peuvent se produire, plusieurs cas différents, pour en arriver à ce message. Par exemple, si le mot de passe est bien actualisé dans l'Active Directory mais pas dans la base locale : on se retrouve avec un secret différent. Cela peut se produire aussi si l'objet correspondant à cet ordinateur est supprimé de l'Active Directory.

Voilà, le décor est posé, maintenant nous allons voir quelques méthodes basées sur PowerShell pour corriger cette erreur. Je préfère donner plusieurs pistes, au cas où une méthode ne s'applique pas, vous pouvez en essayer une autre.

III. Dépannage - "La relation d’approbation entre cette station de travail et le domaine principal a échoué"

A. La méthode manuelle

La méthode manuelle est connue de beaucoup d'administrateur système. Elle fonctionne, mais elle n'est pas pratique, car elle nécessite de déconnecter la machine du réseau. Elle consiste à réaliser les actions suivantes sachant que l'objectif est de retirer la machine du domaine et de la réintégrer :

1 - Déconnecter l'ordinateur du réseau

2 - Se connecter en administrateur local

3 - Retirer l'ordinateur du domaine

Remove-Computer -UnjoinDomaincredential IT-Connect\Admin -PassThru -Verbose -Restart

4 - Réinitialiser l'objet ordinateur dans l'Active Directory

5 - Redémarrer l'ordinateur

6 - Reconnecter le câble réseau

7 - Ajouter l'ordinateur au domaine

Add-Computer -DomainName it-connect.local -Restart

Le principal inconvénient de cette méthode, c'est qu'elle implique une présence physique puisqu'il faut déconnecter la machine du réseau. Pour sortir la machine du domaine et l'ajouter de nouveau, on peut utiliser l'interface graphique de Windows ou les commandes PowerShell "Remove-Computer" et "Add-Computer".

B. La méthode PowerShell : Test-ComputerSecureChannel

Depuis plusieurs années, il est possible de corriger cette erreur avec PowerShell ! Une très bonne nouvelle, car ça veut dire qu'on peut le faire à distance, donc c'est beaucoup plus pratique. La commande Test-ComputerSecureChannel existe depuis Windows 10, elle est toujours disponible sur Windows 11. Personnellement, je vous recommande cette méthode.

Sur une machine où la relation d'approbation est cassée, il faut se connecter et exécuter simplement cette commande dans une console PowerShell :

Test-ComputerSecureChannel

Il est également possible de cibler un contrôleur de domaine spécifique, comme on le fait avec les commandes du module Active Directory. Par exemple :

Test-ComputerSecureChannel -Server "SRV-ADDS.it-connect.local"

Cette commande retourne simplement true (vrai) ou false (faux) pour indiquer l'état de la relation d'approbation entre l'ordinateur et l'annuaire (avec le paramètre -Verbose). Dans le cas où vous avez l'erreur de relation d'approbation, la commande retournera "false". De ce fait, il faudra ajouter le paramètre -Repair qui permet de réparer la relation d'approbation ainsi que les identifiants.

Test-ComputerSecureChannel -Repair -Credential [email protected]

On peut aussi faire :

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

En ce qui concerne le compte utilisateur, il peut s'agir d'un compte Administrateur ou tout simplement d'un compte qui a le droit d'ajouter des machines au domaine Active Directory.

Puisque c'est du PowerShell, on peut aussi agir à distance sur une ou plusieurs machines avec Invoke-Command. Voici un exemple :

Invoke-Command -ComputerName PC-01 -ScriptBlock { Test-ComputerSecureChannel }

Note : que ce soit avec cette méthode ou la méthode qui va suivre, si l'objet ordinateur n'existe pas dans l'Active Directory, il vaut mieux le créer avant. Avec la console "Utilisateurs et ordinateurs Active Directory" (ou une autre méthode), effectuez un clic droit "Nouveau" puis "Ordinateur". Attribuez le même nom.

C. La méthode PowerShell bis : Reset-ComputerMachinePassword

Lorsque l'erreur se produit, il y a une seconde commande PowerShell qui peut rendre service pour se sortir d'affaire : Reset-ComputerMachinePassword, disponible avec Windows PowerShell 5.1. Cette commande permet de réinitialiser le mot de passe du compte ordinateur de la machine locale.

Là encore, cette commande s'exécute depuis l'ordinateur où se situe l'erreur.

Voici comment s'utilise cette commande :

Reset-ComputerMachinePassword -Credential [email protected]

On peut également préciser le nom du contrôleur de domaine cible :

Reset-ComputerMachinePassword -Credential [email protected] -Server "SRV-ADDS.it-connect.local"

L'opération sera automatique, ce n'est pas à vous de définir le mot de passe. Cette méthode permet aussi de corriger l'erreur d'approbation.

D. La méthode netdom

Netdom est un outil qui existe depuis très longtemps sur Windows, avant même que PowerShell pointe le bout de son nez. Il permet aussi de réinitialiser le mot de passe du compte ordinateur à partir de la ligne de commande.

Voici un exemple où je contacte le contrôleur de domaine "SRV-ADDS", en utilisant le compte "florian" et sans préciser le mot de passe en clair (d'où le "*").

netdom resetpwd /s:SRV-ADDS /ud:florian /pd:*

IV. Conclusion

Voilà, nous venons voir différentes manières de corriger l'erreur "La relation d’approbation entre cette station de travail et le domaine principal a échoué" sur vos machines Windows ! Avec PowerShell pour les machines récentes, et avec netdom (ou la méthode manuelle) pour les machines avec des systèmes plus anciens, car on le sait tous qu'il y en a encore en circulation !

Si vous connaissez une autre méthode, n'hésitez pas à nous en faire part avec un commentaire ! 🙂

The post Windows : comment corriger l’erreur de relation d’approbation ? Voici plusieurs méthodes ! first appeared on IT-Connect.

Security baseline for Windows 11 2022: New recommended settings for printing, Defender, NetBIOS, and VBS

3 octobre 2022 à 14:49

Together with the release of Windows 11 2022, Microsoft published the corresponding security baseline. It recommends activating a whole range of additional group policies, most of which are new with this OS version. One main focus is on safeguarding printers.

The post Security baseline for Windows 11 2022: New recommended settings for printing, Defender, NetBIOS, and VBS first appeared on 4sysops.

Populer un Active Directory vulnérable rapidement avec BadBlood

28 septembre 2022 à 10:00

I. Présentation

Dans cet article, nous allons voir comment automatiquement populer (= fournir des informations à une base de données) un Active Directory en intégrant des vulnérabilités. Cela peut être utile dans le cadre de formation ou pour apprendre à manipuler des outils offensifs ou défensifs autour de l'Active Directory.

II. Précautions d'emploi

Le script que nous allons utiliser doit être exécuté en tant qu'administrateur du domaine. En effet, son rôle est d'ajouter différents objets et relations entre ces objets au sein de l'Active Directory. Il va également installer des fonctionnalités comme LAPS qui peuvent être utiles au déploiement de vulnérabilités spécifiques.

Il va de soi qu'il ne faut absolument pas utiliser cet outil dans un environnement Active Directory de production. Veillez donc bien à n'être en aucun cas en possibilité de communiquer avec votre Active Directory de production lors de son exécution.

Pour ma part, j'ai installé un Active Directory sur une VM Windows de test, dans un réseau local dédié de mon VirtualBox. Mon objectif premier est d'étudier le comportement du script et de voir s'il permet d'introduire des vulnérabilités visibles par les outils comme Bloodhound, PingCastle, etc.

III. Utilisation de BadBlood

L'outil BadBlood est composé d'un script principal (Invoke-Badblood.ps1) ainsi que de plusieurs dossiers stockant des fichiers PS1, ADMX, MSI (par exemple pour installer et configurer LAPS.) Ainsi que de différentes listes de mots permettant de générer des objets aux noms aléatoires.

Il faut noter qu'à chaque exécution, BadBlood générera des objets AD différents, les noms et natures des relations entre les objets sont générés de façon aléatoire.

Le script PowerShell Invoke-Badblood.ps1 obtenu doit seulement être exécuté, pas besoin d'import-module. L'idée est donc de créer une population dans notre Active Directory contenant :

  • des utilisateurs,
  • des groupes/OU,
  • des postes de travail,
  • des relations de tout type entre ces différents objets.

Voici le compte des objets utilisateurs, ordinateurs et groupes avant exécution du script :

Compte des objets avant exécution de BadBlood (AD fraîchement installé)
Compte des objets avant exécution de BadBlood (AD fraîchement installé)

Après avoir téléchargé le contenu du dépôt Github en local, L'exécution du script se fait via les commandes PowerShell suivantes :

Set-ExecutionPolicy bypass
.\Invoke-BadBlood.ps1

Comme c'est une VM utilisée pour des tests, on peut se permettre de passer la politique d'exécution en "Bypass". Lors de l'exécution, les actions réalisées sont détaillées dans la sortie du terminal. Attention, certains messages d'erreurs peuvent apparaître : 

Retour terminal de l'exécution de BadBlood
Retour terminal de l'exécution de BadBlood

Il semble qu'en fonction de votre version de PowerShell, de votre environnement AD ou des commandes ADSI installées, certaines commandes ne soient pas accessibles. Dans les différents tests que j'ai pu faire, cela n'a pas vraiment eu d'impact sur le résultat final.

Voici les mêmes comptes après l'exécution du script :

Observation du nombre d'objets créés par BadBlood dans un Active DIrectory
Observation du nombre d'objets créés par BadBlood dans un Active DIrectory

On peut voir que plus de 2400 utilisateurs, 500 groupes et 100 ordinateurs ont été créés sur mon Active Directory, le tout en quelques minutes. Si l'on regarde avec attention le contenu du script principal, on remarque la possibilité de lui indiquer le nombre d'objets à créer pour chaque catégorie, il faut pour cela utiliser la position du paramètre souhaité :

param
(
[Parameter(Mandatory = $false,
Position = 1,
HelpMessage = 'Supply a count for user creation default 2500')]
[Int32]$UserCount = 2500,
[Parameter(Mandatory = $false,
Position = 2,
HelpMessage = 'Supply a count for user creation default 500')]
[int32]$GroupCount = 500,
[Parameter(Mandatory = $false,
Position = 3,
HelpMessage = 'Supply the script directory for where this script is stored')]
[int32]$ComputerCount = 100,
[Parameter(Mandatory = $false,
Position = 4,
HelpMessage = 'Skip the OU creation if you already have done it')]
[switch]$SkipOuCreation,
[Parameter(Mandatory = $false,
Position = 5,
HelpMessage = 'Skip the LAPS deployment if you already have done it')]
[switch]$SkipLapsInstall,
[Parameter(Mandatory = $false,
Position = 6,
HelpMessage = 'Make non-interactive for automation')]
[switch]$NonInteractive
)

IV. Exemple de résultat

À la suite de l'exécution du script, j'ai cherché à découvrir des vulnérabilités rapidement grâce à l'outil Bloodhound. Celui-ci permet de découvrir des chemins d'attaque complexes via les différentes relations pouvant exister entre les objets de l'AD :

Exemples de chemins d'attaque dans un AD populé via BadBlood
Exemples de chemins d'attaque dans un AD populé via BadBlood
Exemples de chemins d'attaque dans un AD populé via BadBlood
Exemples de chemins d'attaque dans un AD populé via BadBlood

J'ai rapidement constaté que de nombreux chemins d'attaque étaient présents, ce qui était largement suffisant pour confirmer le bon fonctionnement de cet outil :). J'ai également fait une analyse à l'aide de PingCastle :

Résultat d'une analyse PingCastle après exécution de Badblood
Résultat d'une analyse PingCastle après exécution de Badblood

Là aussi, plusieurs vulnérabilités sont remontées.

Badblood est selon moi de l'un des outils les plus rapide et simple d'utilisation pour le déploiement de vulnérabilités autour de l'Active Directory (en omettant le temps d'installation de la VM/du service ADDS). Parfait pour s’entraîner à utiliser des outils comme BloodHound :).

The post Populer un Active Directory vulnérable rapidement avec BadBlood first appeared on IT-Connect.

Sécurité Active Directory : gestion des GPO sur l’OU Domain Controllers

27 septembre 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons parler des bonnes pratiques sur l’utilisation des GPOs au niveau des contrôleurs de domaine. Comme nous le savons tous, les GPOs permettent d’appliquer les paramètres de manière automatique sur les objets de l’annuaire. Une mauvaise gestion peut impacter le fonctionnement de notre infrastructure et mettre en péril sa sécurité. Nous allons voir ensemble comment éviter cela sur les contrôleurs du domaine qui jouent un rôle très important dans un environnement Microsoft.

Cet article a été écrit en collaboration avec Mehdi DAKHAMA, et c'est un retour d'expérience relevé chez plusieurs clients. Le but est d'améliorer et optimiser la gestion des GPOs pour les contrôleurs de domaine.

Relecture par Florian BURNEL.

II. Rappel sur l’application des GPOs

A. Hiérarchie d’application des mises à jour

Pour rappel, la hiérarchie d’application des OU est la suivante: stratégie locale > site >> domaine >> OU. Dans la hiérarchie précédente, le symbole ">>" signifie que l'héritage est appliqué.

Modèle LSDOU

Deux stratégies de groupes sont créées par défaut lors de l’installation du domaine :

  • Default Domain Policy liée à la racine du domaine
  • Default Domain Controller Policy liée sur l’OU "Domains Controllers"

B. Risques potentiels

Au vu de la hiérarchie présentée ci-dessus, nous constatons que si une GPO est appliquée au niveau du site ou à la racine d’un domaine, elle sera aussi appliquée aux contrôleurs de domaine via le conteneur "Domain controllers".

Est-ce une bonne ou une mauvaise pratique ? Voyons cela ensemble.

Intéressons-nous aux deux scénarios suivant:

  • Une première GPO machine est créée et liée à la racine du domaine
  • Une seconde GPO liée à une unité d’organisation comprenant un compte administrateur du domaine

C. Exemple n°1 - GPO liée à la racine

Nous allons créer une GPO qui désactive l’UAC (User Account Control) sur Windows. Vous savez, l'UAC c'est la fenêtre de confirmation qui s'affiche quand on a besoin de réaliser une action qui implique des privilèges élevés (administrateur).

Pour cela, nous créons une GPO à la racine du domaine en la nommant "Disabled UAC", nous allons ensuite la modifier via un clic droit "Modifier".

Edition de la stratégie de groupe
Édition de la stratégie de groupe

Dans la partie Configuration Ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Contrôle de compte d’utilisateur  nous avons modifié le paramètre "Contrôle de compte d'utilisateur : comportement de l'invite d'élévation pour les administrateurs en mode d'approbation Administrateur", comme indiqué sur les images ci-dessous :

Contrôle de compte d'utilisateur : comportement de l'invite d'élévation pour les administrateurs en mode d'approbation Administrateur 

Une fois que c'est fait, nous appliquons la GPO avec la commande gpupdate /force sur le contrôleur de domaine Active Directory. De par son positionnement, la GPO s'applique sur les contrôleurs de domaine et les autres machines du domaine.

Application de la GPO via gpupdate /force
Application de la GPO via gpupdate /force

Nous constatons que les paramètres ont été appliqués et changés sur le contrôleur du domaine.

UAC désactivé sur le contrôleur de domaine !
UAC désactivé sur le contrôleur de domaine !

Il est clair que ce paramètre est dangereux pour un contrôleur de domaine ! De ce fait, il faudrait éviter de lier les GPOs à la racine en vue de limiter les conséquences d’une telle action ! On peut considérer qu'il y a eu une mauvaise analyse de l'impact sur l’ensemble des objets concernés. Cependant, cette recommandation ne suffit pas, voyons pourquoi...

D. Exemple n°2 - GPO pour connecter un lecteur réseau

Réalisons le second exemple basé sur le mappage d'un lecteur réseau dans une session et analysons le résultat.

Sur l'OU IT-Connect, nous allons créer une GPO nommée "mapper_lecteur_user". Comme ceci :

Nous modifions les paramètres pour mapper un dossier partagé sur le DC comme lecteur perso "Z:". Ce qui donne :

GPO - Lecteur réseau

Pour rappel, notre OU contient des admins du domaine :

Comptes de l’OU IT-Connect
Comptes de l’OU IT-Connect

Après application de la GPO, nous constatons que le lecteur réseau remonte lors de la connexion sur le contrôleur de domaine avec un compte de cette OU. En effet, les paramètres utilisateurs suivent l’utilisateur et s’appliquent là où ils ouvrent leur session.

Lecteur réseau mappé sur le profil de l’utilisateur au niveau du contrôleur de domaine
Lecteur réseau mappé sur le profil de l’utilisateur au niveau du contrôleur de domaine

Imaginez que ce lecteur contient un fichier suspect et que ce dernier correspond à un ransomware ?! Était-il nécessaire d’avoir ce lecteur réseau "Perso" lors d’une connexion sur le contrôleur du domaine ? Ce cas peut s’appliquer sur plein de paramètres des GPOs, parfois un paramètre s’applique par récursivité à un groupe lointain, ce qui accroît le risque de dysfonctionnement ou d’erreur sur les DCs.

Maintenant, intéressons-nous aux recommandations.

III. Recommandations pour l'OU "Domain Controllers"

L'objectif va être de bloquer l'héritage sur l'OU "Domain Controllers" de notre annuaire Active Directory pour isoler, en quelque sorte, les contrôleurs de domaine puisqu'ils sont regroupés dans cette OU. De plus, pour mieux contrôler les paramètres utilisateurs qui s’appliquent sur les contrôleurs de domaine, il faudrait que les paramètres utilisateurs liés aux GPO liés à l’OU "Domains Controllers" prennent précédence sur le reste. Microsoft a prévu cette configuration : le traitement par boucle de rappel.

Le schéma ci-dessous résume les étapes :

Étapes de mise en conformité des stratégies de groupe sur les contrôleurs de domaine
Étapes de mise en conformité des stratégies de groupe sur les contrôleurs de domaine

Nos recommandations sont les suivantes:

  • Recommandation n°1 : bloquer l'héritage sur l’OU "Domain Controllers" : cela permettra d'éviter toutes configurations issues de la racine. Pour empêcher l’application des configurations utilisateurs des administrateurs qui se connectent, cette recommandation doit être effectuée
  • Recommandation n°2 : dupliquer la GPO "Default Domain Policy" et l’appliquer sur l’OU "Domain Controllers" : dans le but de conserver et d’appliquer les paramètres de mot de passe et Kerberos

Pour bloquer l'héritage, effectuer un clique droit sur l’OU "Domain Controllers", et choisissez "Bloquer l'héritage".

Bloquer l'héritage sur l'OU "Domain Controllers"
Bloquer l'héritage sur l'OU "Domain Controllers"

Ce qui donne :

Héritage bloqué sur l'OU "Domain Controllers"
Héritage bloqué sur l'OU "Domain Controllers"

Note : attention si vous "Appliqué" (Enforced en anglais) une GPO à la racine, cela forcera l’héritage et les paramètres seront configurés sur les Contrôleurs de domaine. Malheureusement, ce paramètre est trop souvent utilisé à mauvais escient.

GPO avec l'option "Appliquez" activée
GPO avec l'option "Appliqué" activée

  • Recommandation n°3 : activer le traitement par boucle de rappel

Pour configurer ce paramètre, suivez le chemin suivant dans une nouvelle GPO : Configuration de l'ordinateur > Modèles d'administration > Système > Stratégie de groupe

Ici, choisissez le paramètre nommé "Configurez le mode de traitement par bouclage de la stratégie de groupe utilisateur" et cochez "Activé" ainsi que "Remplacer".

  • Recommandation n°4 : renommer les GPOs appliquées sur les contrôleurs de domaine

Nous devons partir du principe que les GPOs appliqués sur l’OU "Domain Controllers" ne doivent pas être utilisées sur une autre OU. Pour les identifier, il convient d'utiliser un nom différent en respectant une nomenclature spécifique pour vos contrôleurs de domaine. Ainsi, pour une même GPO, vous pouvez faire la différence entre la version qui s'applique aux ordinateurs et autres serveurs, et la version pour les contrôleurs de domaine.

Pour en savoir plus sur ces différentes notions, vous pouvez consulter ces pages :

IV. Conclusion

Les contrôleurs de domaine doivent être extrêmement protégés, le blocage de l'héritage et des paramètres utilisateurs constituent une solution. A cela doit s’accompagner la surveillance, ce sera le focus de notre prochain article.

The post Sécurité Active Directory : gestion des GPO sur l’OU Domain Controllers first appeared on IT-Connect.

L’Active Directory et la mise en cache des identifiants

21 septembre 2022 à 16:45

I. Présentation

Quand un utilisateur d'un domaine Active Directory s'authentifie sur un ordinateur Windows (ou un serveur) membre du domaine, ses identifiants sont mis en cache en local, de manière automatique. On parle de Cached credentials. Ainsi, l'utilisateur peut se connecter à sa session, sur le même ordinateur, lorsque le contrôleur de domaine est injoignable, que l'ordinateur n'est pas connecté au réseau, ou lorsque l'ordinateur est connecté sur un réseau différent et qu'il ne peut pas contacter le contrôleur de domaine (télétravail, hôtel, train, etc.).

La mise en cache des identifiants s'avère très pratique pour les ordinateurs portables, car ils sont susceptibles d'être utilisés dans des conditions diverses et variées lors desquelles l'utilisateur aura besoin d'accéder à sa session et ses données.

Dans cet article, nous allons voir comment fonctionne la mise en cache des identifiants, comment elle se configure et quels sont les risques associés à cette fonctionnalité, autant d'un point de vue de la sécurité que de l'utilisation : la mise en cache à ses limites, comme nous le verrons, mais il existe des solutions.

II. Fonctionnement de la mise en cache des identifiants

Une entrée est ajoutée dans le cache des identifiants lorsqu'un utilisateur se connecte sur un ordinateur Windows ou un serveur Windows Server. C'est vraiment l'action de connexion qui alimente le cache. Si un utilisateur se connecte avec un nouveau mot de passe, l'entrée dans le cache sera également actualisée. Le cache entre en jeu lorsque l'utilisateur veut se connecter à sa session sans que Windows soit en mesure de contacter l'Active Directory. Ces informations sont stockées dans le Registre, sans limites de temps.

De ce fait, si le domaine Active Directory n'est pas joignable au moment où un utilisateur tente de se connecter, Windows vérifie si le nom d'utilisateur et le mot de passe saisi sur la page de connexion du système correspondent à des identifiants disponibles dans le cache local. Si c'est le cas, il accède à sa session.

Puisque le cache permet de s'authentifier en étant déconnecté de l'Active Directory, on peut imaginer le cas suivant. Si un utilisateur se connecte sur un ordinateur intégré au domaine Active Directory, qu'il éteint cet ordinateur, le déconnecte du réseau, et qu'il change son mot de passe depuis un deuxième ordinateur, il pourra toujours s'authentifier sur le premier ordinateur avec son ancien mot de passe (à condition d'utiliser l'ordinateur en mode hors connexion).

A. Où est stocké le cache des identifiants Windows ?

Par défaut, quand on ouvre une session d'un utilisateur Active Directory sur Windows, le système d'exploitation met en cache les identifiants : le nom d'utilisateur et un hash du mot de passe. Ce cache est stocké directement dans le Registre Windows au sein de la clé suivante :

HKEY_LOCAL_MACHINE\Security\Cache

Même avec les droits administrateurs vous ne pourrez pas voir la clé "Cache" dans le Registre Windows. C'est compréhensible. Néanmoins, il est assez facile d'accéder à ces informations en utilisant PsExec qui va nous permettre d'ouvrir le Registre Windows avec les droits Système.

A titre d'information, voici la commande à exécuter :

.\PsExec.exe -s -i -d regedit.exe

Sur mon ordinateur, que ce soit un Windows 10, un Windows 11 ou une autre version de Windows, il me sera possible de visualiser le cache. Chaque valeur "NL$X" correspond à une entrée du cache et le hash de chaque entrée utilise le nom d'utilisateur comme donnée de salage. En supprimant les entrées de cette liste, on purge le cache.

Windows 10 - Cache des identifiants dans le Registre Windows

B. Cache des identifiants Windows : la limite d'identifiants

Windows ne va pas stocker dans son cache un nombre illimité d'identifiants. Dans sa configuration par défaut, Windows va stocker dans son cache les identifiants de 10 utilisateurs. C'est en tout cas le comportement depuis Windows 10 et Windows Server 2016, et c'est vrai aujourd'hui avec Windows 11 et Windows Server 2022. On peut même affirmer que Windows stocke dans son cache les identifiants des 10 derniers utilisateurs qui ont ouvert une session sur la machine en question.

Ce seuil de 10 est déterminé dans une valeur du Registre nommée "CachedLogonsCount" et qui se situe à cet emplacement :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Sur l'image ci-dessous, issue d'une machine Windows 10 dans sa configuration par défaut, on voit bien que la limite est définie sur 10.

Windows 10 - Registre CachedLogonsCount

Même en modifiant cette valeur, vous devez savoir aussi que Windows ne peut pas stocker plus de 50 entrées dans son cache d'identifiants. Ainsi, il faut considérer que la valeur maximale pour cette option est de 50 identifiants, mais personnellement je vous recommande plutôt de revoir cette valeur à la baisse (moins de 10). Je reviendrai sur ce point dans la suite de cet article.

C. Configuration du cache des identifiants par GPO

Que ce soit à partir d'une stratégie de groupe Active Directory ou de la stratégie de groupe locale (gpedit.msc), il y a un paramètre qui permet aux administrateurs de configurer le cache des identifiants sans devoir modifier directement le Registre. Si l'on prend l'exemple de la GPO Active Directory, il faut accéder à cet emplacement :

Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité

Ici, il sera nécessaire de configurer le paramètre "Ouvertures de sessions interactives : nombre d'ouvertures de sessions précédentes réalisées en utilisant le cache (lorsqu'aucun contrôleur de domaine n'est disponible)" en cochant l'option "Définir ce paramètre de stratégie" puis en définissant un seuil.

Configuration du cache des identifiants par GPO

III. Les risques liés au cache des identifiants Windows

A. Le télétravail et le risque d'être bloqué

Lorsqu'un utilisateur est en télétravail et qu'il se connecte à sa session, il exploite le cache des identifiants et accède à son environnement. Ensuite, dans une majorité de cas, il va chercher à monter une connexion VPN pour se connecter aux ressources de l'entreprise : applications, fichiers, etc... Lorsque l'authentification du VPN est basée sur l'Active Directory, on peut se retrouver bloqué malgré la présence du cache des identifiants. Pourquoi ?

En fait, le cache des identifiants n'empêche pas le compte utilisateur de vivre dans l'Active Directory. Ainsi, il va arriver un jour où l'utilisateur devra changer son mot de passe conformément à la stratégie de mots de passe de l'entreprise. Sauf que le client VPN de l'entreprise ne sera pas en mesure de lui proposer le changement, et l'utilisateur ne pourra pas se connecter.

J'ai pris l'exemple du VPN, mais cela s'applique aussi s'il doit s'authentifier à une application Web basée sur l'authentification Active Directory. Ces tentatives répétées seront considérées comme en échec auprès de l'annuaire Active Directory et cela pourrait déclencher un verrouillage du compte utilisateur. Disons que ce comportement dépend de la stratégie de mot de passe et de verrouillage de comptes, mais dans le cas d'une infrastructure sécurisée, ce sera normalement le cas.

Face à cette problématique, quelle solution pour les utilisateurs et le service informatique ? Tout d'abord, nous pouvons faire en sorte d'avertir les utilisateurs par e-mail quelques jours avant l'expiration du mot de passe afin qu'ils anticipent et procèdent au changement du mot de passe. Cela éliminera sûrement une partie des cas problématiques.

En complément, il est pertinent de s'orienter vers une solution de réinitialisation du mot de passe en libre-service pour l'Active Directory, ce qui permet à l'utilisateur d'être autonome pour changer son mot de passe, de manière sécurisée. Cette solution va permettre au service informatique de ne plus avoir (ou quasiment plus, soyons honnêtes) ces demandes et ces problèmes à gérer.

B. La compromission du cache d'identifiants Windows

Le cache des identifiants représente un risque en matière de sécurité. Un attaquant qui obtient un accès sur un ordinateur avec des identifiants en cache pourra tenter différentes attaques, notamment une attaque de type brute force sur le hash du mot de passe. Ainsi, il devient possible de réaliser une attaque brute force sans être détecté par l'Active Directory en lui-même (ce qui ne déclenchera pas le verrouillage du compte Active Directory), car on cible le cache local, et non ne s'authentifie pas directement auprès de l'annuaire Active Directory.

Si un utilisateur se connecte sur l'ordinateur portable qui lui est affecté, ses identifiants seront mis dans le cache. Ensuite, si un administrateur du domaine se connecte sur la machine (normalement, on ne doit pas se connecter directement avec un compte administrateur du domaine, mais c'est très fréquent), ses identifiants seront aussi inclus dans le cache. De ce fait, un attaquant qui obtient un accès physique sur cet ordinateur peut réaliser un brute force sur le cache des identifiants afin d'espérer récupérer le mot de passe Administrateur du domaine ! La tâche sera plus ou moins compliquée selon la robustesse du mot de passe.

Pour réduire les risques, il convient de limiter le cache des identifiants à "1". Ainsi, si un administrateur se connecte, ses identifiants seront mis en cache, et quand l'utilisateur va récupérer son ordinateur et se reconnecter, cela va écraser l'entrée correspondante aux identifiants de l'administrateur. On peut appliquer cette politique sur les ordinateurs portables et aller plus loin sur les ordinateurs de bureau en désactivant le cache (valeur à "0") : ce sont des machines qui sont utilisées uniquement au bureau, en mode "en ligne" on peut dire. Attention tout de même, cela signifie qu'en cas d'indisponibilité du contrôleur de domaine ou du réseau, l'utilisateur ne pourra pas ouvrir sa session pour travailler.

Néanmoins, il existe une méthode qui ne nécessite pas de réaliser une attaque brute force sur le cache, mais qui consiste à démarrer l'ordinateur en mode récupération du système Windows et à venir écraser une entrée du cache par un nouveau mot de passe, à l'aide de Mimikatz (voir cet article). Ainsi, on change le mot de passe du cache et on peut s'authentifier sur la machine avec le nom d'utilisateur et le mot de passe falsifié.

Pour protéger les comptes avec des privilèges élevés, il convient d'ajouter les comptes au groupe "Protected Users" de l'Active Directory pour activer certaines protections, dont la désactivation de la mise en cache des identifiants pour les membres de ce groupe. Vous pouvez lire ce tutoriel à ce sujet : Active Directory et Protected Users.

IV. Conclusion

Suite à la lecture de cet article, vous en savez plus sur le fonctionnement du cache des identifiants sous Windows, et vous connaissez également les problématiques associées, que ce soit au niveau de la sécurité ou fonctionnellement parlant.

The post L’Active Directory et la mise en cache des identifiants first appeared on IT-Connect.

Automation for Active Directory, Microsoft 365, and Google Workspace with ManageEngine ADManager Plus

20 septembre 2022 à 16:45

Learn how ManageEngine ADManager Plus allows easy management for on-premises Active Directory and cloud applications, such as Microsoft 365 and Google Workspace, as well as easy Active Directory automation and permission delegation.

The post Automation for Active Directory, Microsoft 365, and Google Workspace with ManageEngine ADManager Plus first appeared on 4sysops.

Recover Active Directory domain controllers with nonauthoritative restore

7 septembre 2022 à 17:42

Backing up domain controllers is a crucial part of any disaster recovery plan for organizations leveraging Active Directory on-premises. There are two types of restores: authoritative and nonauthoritative. Which one do you use where? We can perform both using Windows Server Backup. Let's look at this process with the nonauthoritative restore.

The post Recover Active Directory domain controllers with nonauthoritative restore first appeared on 4sysops.

Directory Services Restore Mode: DSRM password reset, recover Active Directory

1 septembre 2022 à 21:03

Have you ever received the following error message when you tried to sign in on a domain controller? We can't sign you in with this credential because your domain isn't available. Scary, huh? With the help of Active Directory's Directory Services Restore Mode (DSRM), you can recover Active Directory by booting up in safe mode to restore a working configuration of your Active Directory. I hope you still know your DSRM password. If not, I show you how to reset the DSRSM password in this article.

The post Directory Services Restore Mode: DSRM password reset, recover Active Directory first appeared on 4sysops.

Find AD accounts with ChangePasswordAtLogon, set and enforce password change with PowerShell

31 août 2022 à 16:06

Admins can prompt users to change their password at their next login. While it is easy to see the status of the corresponding attribute in AD Users and Computers, the procedure with PowerShell is a bit tricky. On the other hand, enforcing a password change with PowerShell is quite simple.

The post Find AD accounts with ChangePasswordAtLogon, set and enforce password change with PowerShell first appeared on 4sysops.

Join Server Core to an Active Directory (AD) domain

26 août 2022 à 19:49

When you install Windows Server Core in your environment, there is no GUI or desktop experience to manage it. Admins who switch to Server Core from the desktop experience often face a slight learning curve. In this article, I will show you how to join a Server Core machine to an Active Directory (AD) domain with SConfig, PowerShell, or the command prompt.

The post Join Server Core to an Active Directory (AD) domain first appeared on 4sysops.

Active Directory : comment corriger les propriétaires inadaptés sur les objets ?

24 août 2022 à 10:00

I. Présentation

Dans un tutoriel précédent, nous avons découvert la vulnérabilité "Broken owner" de l'Active Directory liée aux délégations d’administration et de manipulations que nous effectuons au quotidien sur les objets de l'annuaire Active Directory.

Nous allons poursuivre l'aventure et voir dans cet article comment corriger cette vulnérabilité en ajustant les propriétaires des objets, puis nous verrons dans un troisième article, qui clôturera cette série, comment éviter que cela se produise.

II. Retour sur la vulnérabilité "Broken owner"

A. Rappel

D'après l'article précédent, cette vulnérabilité se produit lorsqu’un objet est créé dans l’AD par un compte à non-privilège (à l’issue d’une délégation) ou créé par un compte à privilège qui ne l’est plus (après le retrait de ce dernier des groupes à privilèges).

B. Recommandations

D'après l’ANSSI et Microsoft, il est recommandé de mettre en place un groupe à privilèges comme propriétaire des objets, parmi ceux-ci: Administrateurs du domaine, Administrateur  de l’entreprise, Administrateurs. Il s'agit d'éléments natifs, que vous connaissez probablement.

C. Pourquoi faut-il corriger le propriétaire ?

Il est indispensable de corriger l’objet afin d'ajuster le propriétaire dans l'objectif d'atténuer la surface d’attaque et les chemins d'accès. Pour rappel, une personne malveillante ne cherche pas absolument à être admin du domaine, mais plutôt à compromettre les données ou les extraire. De ce fait, garder les objets sans propriétaire (owner) ou avec un owner sensible expose votre entreprise à des risques de sécurité permanent, en plus d'alourdir la tâche de l’équipe SOC.

Dans le schéma ci-dessous, après la correction, la personne malveillante ne pourra plus se procurer les objets dont le HelpDesk est propriétaire, ce qui l'empêchera de s'octroyer les droits et d'accéder aux ressources de l’objet (Utilisateur RSI ou Secrétaire dans notre cas).

Active Directory - Corriger la vulnérabilité bad owner

D. Comment corriger le propriétaire de l'objet ? 

Deux méthodes s’offrent à nous : faire le changement manuellement à partir de l’onglet "Sécurité" et choisir un groupe à privilège par défaut (par exemple "Admin du domaine"), ou utiliser un script. Cette seconde option sera traitée dans un second temps, dans cet article.

Voici un exemple de modification sur le compte "Florian". Actuellement le propriétaire est "helpdesk1".

Active Directory - Changement du propriétaire

On le change pour définir le groupe "Admins du domaine" à la place.

Note : Si vous choisissez un groupe étant membre d’un groupe à privilèges, mais qu’il n’est pas natif (exemple "GG_admins" membre de admins du domaine), la correction sur les objets Owner ne se fera pas automatiquement, et c’est ce groupe qui résidera comme Owner. Dans le cas où il ne fera plus partie du groupe à privilèges ("Admin du domaine"), les objets seront une nouvelle fois vulnérables.

Après correction, nous constatons qu’il n’est plus possible à l’utilisateur "HelpDesk1" de faire des modifications sur l'objet "Florian". Les ACLs sont grisées :

Active Directory - ACL grisée

E. Les Exceptions

Avant de faire tout changement, prenez le temps d’analyser le résultat du premier script, dont on a déjà parlé dans l'article précédent. En effet, certaines applications manipulent des objets AD au cours de leur cycle de vie, devenant ainsi propriétaire de certains. Le changement de propriétaire sur les objets dont elles sont propriétaires pourrait les empêcher de réaliser totalement leurs tâches.

Pour cette raison, il convient d'auditer votre configuration avant de réaliser la correction.

F. Persistance

Bien que la correction constitue un premier remède, cela n’est pas suffisant. Si le propriétaire s'est déjà procuré les droits "Contrôle total" (CT) ou de modification des permissions sur un objet, la correction n’apportera pas grande chose au niveau de la sécurité. Cette subtilité sera abordée dans le prochain article.

III. Corriger les propriétaires avec un script PowerShell

Pour automatiser la correction des propriétaires des objets, nous avons développé un script simple d’utilisation (et open source) pour nous faciliter la tâche ! Voici le lien du script PowerShell : Script CABOO (Correct Broken Owner)

Le projet porte le nom de CABOO (Correct-AD-Broken-Owner-Object). Pour l'utiliser, il vous suffit de le télécharger et de l'ouvrir avec PowerShell ISE ou VSCode.

L'exécution de ce script nécessite les prérequis ci-dessous :

  • Une machine membre du domaine
  • Un compte utilisateur membre du groupe "Administrateur du domaine"

Pourquoi faut-il l'exécuter en mode administrateur ? Cela se justifie par le fait que les deux commandes pour remplacer le propriétaire ne passent pas avec les droits standards.

$ownerinfo.PsBase.ObjectSecurity.SetOwner($NewOwner)
$ownerinfo.PsBase.CommitChanges()

Le script utilise le même principe que le script d’audit SCABOO.

A. Corriger les propriétaires sur une OU

Lancez le script et choisissez l’option "2". Ensuite indiquez votre OU et valider par OK.

Active Directory - Script CABOO - Exemple 1

1 - Sélectionnez l’OU

Active Directory - Script CABOO - Exemple 2

2 - Choisissez le nouveau propriétaire (pour suivre les recommandations, cochez "Admins du domaine")

CABOO - Choix Admins du domaine

3 - Vérifiez que le bon groupe est sélectionné, puis appuyez sur OK

Active Directory - Script CABOO - Exemple 4

Le traitement est alors lancé ! En cas d’erreur, cela sera affiché sur le résultat final ou en cours du scan. De toute façon, il est possible d'arrêter le script à tout moment.

Active Directory - Script CABOO - Exemple 5

Une fois l'exécution terminée, une page HTML s'affiche en guise de rapport pour indiquer indiquer les objets changés, ainsi que l’ancien propriétaire. Le nouveau, vous le connaissez.

Active Directory - Script CABOO - Exemple 6

B. Exclure un utilisateur ou un groupe

Si vous voulez exclure un compte ou un groupe du processus de correction, il suffit d’ajouter ce dernier à la variable "$skipdefaultgroups" présente à la ligne 50 du script. Indiquez bien le nom du groupe, sans le nom du domaine.

Exemple : pour ne pas corriger les objets ayant "SCCM$" ou "Exchange" comme propriétaire, faites ceci :

Active Directory - Script CABOO - Exemple 10

C. Scanner sur un type d’objet

Si votre OU contient des utilisateurs, groupes et machines, et que vous ne souhaitez faire la correction que sur les utilisateurs, il suffit de commenter la ligne "$newowner" sur le type que vous souhaitez ignorer. Dans notre cas, nous allons ignorer le traitement sur les types "OU" et "groupes".

Active Directory - Script CABOO - Exemple 8

Si vous obtenez une erreur lors du traitement, c’est que le script n’est pas lancé en mode admin. Sinon, lisez le code d’erreur afficher sur la console PowerShell ISE (ou VSCode) lors du traitement. Dans notre cas "error" signifie que le traitement n’est pas abouti, et aucune modification n’a été faite. Vous pouvez contribuer à ce script ou le modifier à votre convenance !

Active Directory - Script CABOO - Exemple 9

Rendez-vous prochainement pour la suite de cet article, où nous verrons comment éviter de se retrouver avec des propriétaires inadaptés sur les objets de l'Active Directory.

The post Active Directory : comment corriger les propriétaires inadaptés sur les objets ? first appeared on IT-Connect.

Support informatique : vérifiez l’identité des utilisateurs avec Specops Secure Service Desk

22 août 2022 à 16:45

I. Présentation

Dans cet article, je vous propose de découvrir une solution de sécurisation pour le support informatique dont l'objectif est de faciliter l'identification des utilisateurs : Specops Secure Service Desk. L'objectif est clair : éviter l'usurpation d'identité, ce qui peut mener à la compromission de l'infrastructure de l'entreprise.

Pour comprendre l'intérêt de Secure Service Desk, prenons un exemple très simple. Vous travaillez au sein du service support informatique d'une entreprise qui compte 100 salariés répartis sur plusieurs sites, et vous assurez le support auprès des utilisateurs. Ce jour-là, un utilisateur vous contacte par téléphone pour une demande de support : il a besoin que son mot de passe Active Directory soit réinitialisé, car il ne s'en souvient plus. Cela est dans vos attributions, vous avez les compétences et les accès pour effectuer cette action.

Néanmoins, comment êtes-vous sûr que c'est bien la bonne personne au bout du fil ? Comment êtes-vous sûr que ce n'est pas une personne malveillante qui essaie d'usurper l'identité de l'utilisateur pour récupérer un accès à son compte ? Vous ne connaissez pas forcément l'ensemble des utilisateurs, surtout si certains sont à l'autre bout de la France ou d'un autre pays, et quand bien même vous connaissez bien l'un de ces utilisateurs, il pourrait être victime d'une tentative d'usurpation d'identité.

Ce jour-là, si vous faites l'erreur de réinitialiser le mot de passe alors qu'il s'agit d'une personne malveillante, l'entreprise pour laquelle vous travaillez risque d'être victime d'une attaque informatique pouvant mener jusqu'à une attaque par ransomware. La solution Secure Service Desk répond à cette problématique puisqu'elle permet de vérifier l'identité d'un utilisateur avant de procéder à la réinitialisation de son mot de passe Active Directory, de déverrouiller son compte, ou toute autre action, car en soit il n'y a pas de limites. Nous verrons également que Secure Service Desk sert à authentifier la personne du support informatique.

A. Specops Secure Service Desk en quelques mots

Avant de passer à l'installation et l'utilisation de la solution, faisons le point sur les fonctionnalités principales :

  • Vérification de l'identité de l'utilisateur avant la réinitialisation du mot de passe ou le déblocage du compte.
  • Prise en charge de différentes méthodes de vérification, du simple code par SMS ou e-mail à l'utilisation de solutions comme Okta et Duo Security.
  • Prise en charge de différentes langues, aussi bien pour les personnes du support informatique que pour les utilisateurs.
  • Audit de l'utilisation du système grâce à des rapports
  • Récupération des clés BitLocker lorsque la solution complémentaire Specops Key Recovery est en place

Vous pouvez obtenir plus d'informations ou demander une version d'essai sur le site officiel :

B. Nos autres articles sur les solutions Specops Software

Découvrez également nos autres articles au sujet des solutions Specops Software :

II. L'installation de Specops Secure Service Desk

Cet article ne s'attarde pas sur l'intégralité de l'installation de la solution en elle-même, mais uniquement sur certaines parties. Cette solution ne nécessite pas énormément de ressources pour fonctionner puisqu'elle s'appuie sur une console Cloud gérée par Specops Software. Néanmoins, vous devez disposer d'un Active Directory opérationnel et d'un serveur sur lequel le rôle "Gatekeeper" va être mis en place, car on part du principe que le contrôleur de domaine ne communique pas directement avec Internet, ce serveur avec le rôle "Gatekeeper" sert de relais. Il est à noter que ce serveur peut avoir d'autres fonctions et qu'il n'est pas nécessaire de le réserver à la fonction de Gatekeeper.

La récupération des sources d'installation s'effectue à partir du portail Specops. Lorsque la solution Specops uReset est en place, le même serveur Gatekeeper peut être utilisé et les fonctions de Secure Service Desk viendront en complément de celles de Specops uReset.

L'installation s'effectue assez rapidement, en quelques clics, disons.

Pour l'utilisation de Secure Service Desk (SSD), la section "Active Directory Settings" sera particulièrement intéressante. Le reste de la configuration s'effectue en ligne à partir du portail Specops. Durant l'installation, un compte gMSA est mis en place pour l'exécution du service.

Au-delà des choisir les utilisateurs qui entrent dans le périmètre de la solution, il faut configurer les membres du groupe "Service Desk Agent group" afin de choisir un ou plusieurs groupes de sécurité Active Directory qui contiennent les techniciens du support qui ont un accès à la console Secure Service Desk. Il faut être membre de ce groupe pour exploiter la solution SSD. Cela signifie aussi qu'un technicien peut avoir accès à la solution Secure Service Desk sans pour autant avoir les droits directement sur l'annuaire Active Directory en lui-même.

Dans cet exemple, le groupe "Admins du domaine" est membre de "Service Desk Agent", ainsi que l'utilisateur "florian" du domaine "it-connect.local".

L'installation de base est terminée. Nous reviendrons sur d'autres paramètres un peu plus loin dans cet article. En attendant, nous allons pouvoir effectuer un premier test pour vérifier l'identité d'un utilisateur.

III. Support informatique : vérifier l'identité d'un utilisateur

Voilà, nous y sommes, nous allons vérifier l'identité d'un utilisateur. Pour cela, on se remet dans le même contexte que tout à l'heure : un utilisateur appelle le support informatique, car il souhaite que l'on réinitialise son mot de passe.

A. Exemple concret

Tout d'abord, il faut se connecter sur la console Specops. Un lien rapide est disponible dans la console sur le serveur Gatekeeper.

Sur cette interface, il faut s'authentifier. Ici, je me connecte avec le compte "florian" (qui est un compte standard sur mon domaine AD). Puisque j'ai utilisé le lien personnalisé, je peux préciser uniquement "florian" sans mettre l'e-mail : l'utilisateur sera reconnu.

Me voici connecté sur la console Service Desk. La zone de recherche en haut à droite permet de rechercher l'utilisateur pour lequel on souhaite vérifier l'identité. Prenons le cobaye habituel : Guy Mauve. En le recherchant, j'arrive sur la page de son profil avec la mention en haut à droite "Non vérifié" : c'est normal, je n'ai pas encore vérifié son identité. Désormais, il faut cliquer sur le bouton "Vérifier l'identité".

Specops Secure Service Desk

Plusieurs méthodes de vérification sont disponibles, notamment la vérification par SMS que je prends ici comme exemple. En cliquant sur "Envoyer" sous "Message texte", cela va envoyer un code par SMS à l'utilisateur. Comment Secure Service Desk parvient-il à récupérer le numéro de téléphone ? Simplement à partir de l'Active Directory donc cela implique que la fiche de l'utilisateur soit correctement renseignée.

C'est à ce moment-là que l'utilisateur à l'autre bout du téléphone doit vérifier son téléphone pour vous communiquer le code reçu par SMS. C'est ce code qui va servir à identifier l'utilisateur ! Si le code est bon, on considère que c'est le bon interlocuteur. On saisit le code et on appuie sur "Vérifier".

Voilà, Guy Mauve vient de s'authentifier auprès du service informatique, donc sa demande de support peut être prise en charge, car elle est légitime.

Ensuite, en basculant sur l'onglet "Réinitialiser le mot de passe", on va pouvoir changer le mot de passe de l'utilisateur Guy Mauve et lui communiquer par e-mail ou SMS. Il devra, ou non, le modifier à la prochaine ouverture de session selon l'option "<utilisateur> doit changer de mot de passe à sa prochaine connexion" (il est possible de préconfigurer et verrouiller cette option dans les paramètres de SSD).

B. Configuration de Secure Service Desk

Vous n'avez peut-être pas fait attention, mais avant même d'avoir authentifié l'utilisateur, le technicien pouvait accéder à l'option de réinitialisation du mot de passe de cet utilisateur. Cela signifie que si le compte du technicien est compromis, qu'une personne malveillante dispose d'un accès à ce compte (ce qui implique de connaître l'identifiant, le mot de passe et de valider un second facteur d'authentification), elle pourrait réinitialiser le mot de passe d'un autre compte et l'utiliser.

Si vous souhaitez que le technicien soit en mesure d'agir sur le compte de l'utilisateur uniquement après la phase de vérification de l'identité, il faut cocher l'option "Forcer la vérification d'identité" dans les options de Secure Service Desk. Ainsi, il y a comme une sorte d'authentification mutuelle : d'une part on vérifie l'identité de l'utilisateur final, et d'autre part, on s'assure que le technicien ne puisse pas agir sur le compte de l'utilisateur sans avoir eu "l'accord" de l'utilisateur.

Tuto Specops Secure Service Desk

Suite à l'activation de cette option, lorsque l'identité n'est pas vérifiée, on peut voir que l'option est grisée. On peut également ajuster la durée pendant laquelle on considère que l'identité est vérifiée : 15 minutes par défaut.

Specops Secure Service Desk offre des options pour personnaliser les SMS et e-mails, mais également ajuster les options de notifications et réinitialisation du mot de passe comme le montre l'exemple ci-dessous.

C. Identifier l'utilisateur via son responsable

Dans certains cas, il peut être nécessaire de s'appuyer sur une autre personne pour vérifier l'identité de quelqu'un. Imaginons que l'utilisateur n'ait pas accès à ses e-mails et qu'il n'a pas son téléphone, comment faire ? On peut prendre un autre exemple : le responsable de service souhaite donner son accord avant la réinitialisation d'une action spécifique, on le sollicite, en plus de vérifier l'identité de l'utilisateur en lui-même.

Secure Service Desk offre la possibilité de solliciter le responsable de cette personne, selon la configuration définie dans l'Active Directory. Dans l'exemple ci-dessous, l'utilisateur "florian" est défini comme étant le gestionnaire de "Guy Mauve".

Afin d'utiliser cette fonction, il suffit de cliquer sur le bouton "Identification du gestionnaire" dans l'interface de SSD au sein de la fiche de l'utilisateur.

Ensuite, sur le même principe que pour vérifier l'identité de l'utilisateur, on peut envoyer un e-mail ou un SMS au gestionnaire.

IV. Conclusion

Specops Secure Service Desk est une solution très intéressante et pertinente pour sécuriser les activités du support informatique et lutter contre l'usurpation d'identité. Par ailleurs, c'est aussi un moyen d'être certain qu'un mot de passe est réinitialisé par le support informatique uniquement lorsque l'utilisateur a donné son accord, via le processus de vérification.

Selon l'organisation de votre entreprise, le nombre de salariés et l'emplacement géographique de ces salariés (télétravail à prendre en compte également), une solution comme celle-ci prend tout son sens. Pour renforcer la sécurité de son système d'information, SSD est une réelle solution qui s'attaque à une vraie problématique, mais on peut imaginer plusieurs scénarios un peu plus spécifiques :

  • Une PME avec un service informatique situé sur un site unique et une multitude de sites distants à gérer
  • Une PME ou une grande entreprise avec un nombre important de salariés
  • Une société de service qui assure le support informatique de plusieurs clients
  • Etc.

Vous pouvez obtenir plus d'informations ou demander une version d'essai sur le site officiel :

The post Support informatique : vérifiez l’identité des utilisateurs avec Specops Secure Service Desk first appeared on IT-Connect.

Get AD user group membership with Get-ADPrincipalGroupMembership

5 août 2022 à 18:56

The Get-ADPrincipalGroupMembership PowerShell cmdlet enables you to query all the Active Directory group memberships of a user. In this tutorial, you'll learn to work with Get-ADPrincipalGroupMembership, and see how you can use this useful cmdlet to quickly and easily use a PowerShell one-liner to search and see whether a user is a member of a particular Active Directory group. Simply put, if your organization uses Active Directory security groups, the ability to use this cmdlet is an absolute must.

The post Get AD user group membership with Get-ADPrincipalGroupMembership first appeared on 4sysops.

Comment auditer l’Active Directory avec Purple Knight ?

2 août 2022 à 16:15

I. Présentation

La sécurité de l'Active Directory est un véritable enjeu pour les entreprises et il n'est pas forcément simple de garder un œil sur l'état général de son annuaire Active Directory sans utiliser des outils adaptés. Fort heureusement, ces outils existent, que ce soit pour surveiller l'activité de l'Active Directory ou pour l'auditer comme nous l'avons vu récemment avec PingCastle.

Aujourd'hui, je vais vous présenter un autre outil gratuit pour auditer l'Active Directory : Purple Knight, édité par l'entreprise Semperis. Ce logiciel s'utilise gratuitement et il n'y a pas de commercialisation de licences, car Semperis commercialise un autre produit : Semperis Directory Services Protector (DSP). Dans cet article, je m'intéresse à l'audit de l'Active Directory, mais ce logiciel est capable d'auditer Azure Active Directory également.

Environ 100 points liés à la sécurité de l'Active Directory sont vérifiés par Purple Knight, aussi bien sur la sécurité des comptes, la délégation Active Directory, les stratégies de groupe, l'infrastructure Active Directory en elle-même, que les options liées à Kerberos.

II. Télécharger et installer Purple Knight

Pour télécharger Purple Knight, il est nécessaire de compléter un formulaire sur le site officiel afin de recevoir un e-mail avec un lien de téléchargement. Contrairement à PingCastle, il faut fournir quelques informations pour télécharger Purple Knight. Rendez-vous sur cette page :

Personnellement, j'ai reçu l'e-mail avec le lien de téléchargement dans la foulée après avoir complété le formulaire. On obtient une archive ZIP d'environ 100 Mo. Le contenu de cette archive ZIP doit être extrait sur votre machine. On obtient ceci :

Les deux PDF font office de documentation sur l'utilisation du logiciel et le répertoire "Scripts" contient un ensemble de scripts PowerShell signés que l'outil va exécuter pour réaliser son audit :

III. Lancer un audit avec Purple Knight

Pour lancer un audit avec Purple Knight, c'est tout simple : il faut exécuter le fichier "PurpleKnight.exe". Un assistant s'ouvre. Commençons par accepter les conditions d'utilisation avant de poursuivre.

La seconde étape consiste à sélectionner l'environnement cible, à auditer donc. Ici, c'est l'Active Directory du domaine "it-connect.local" qui va nous intéresser, donc il faut cocher la case à côté de "Active Directory" puis cliquer sur le bouton "Select" pour sélectionner le domaine. On peut sélectionner plusieurs domaines. Quand c'est fait, on peut cliquer sur "Next".

La troisième étape consiste à sélectionner les éléments à analyser, au cas par cas ou par catégorie. Pour que l'audit soit complet, il vaut mieux tout sélectionner afin d'avoir un résultat pertinent qui reflète réellement l'état actuel de votre annuaire Active Directory.

Nous pouvons voir que, sous chaque catégorie, il y a la liste des éléments qui seront évalués. Il faut cliquer sur "Run tests" pour démarrer l'audit.

L'audit en lui-même est rapide et ne nécessite que 1 ou 2 minutes pour vérifier environ 100 points différents.

Quand l'audit est terminé, l'idéal est de cliquer sur "View report" pour afficher le rapport HTML dans un navigateur. Ce même rapport peut être exporté au format PDF ou au format CSV, comme le montre le bouton "Save as" en bas de l'interface.

Passons à la prochaine étape où nous allons nous intéresser au rapport en lui-même.

IV. Interpréter le rapport d'audit

C'est l'heure du verdict : nous allons parcourir le rapport d'audit pour voir quelles sont les faiblesses de notre Active Directory relevée par Purple Knight.

En ce qui me concerne, l'Active Directory de mon lab a obtenu la lettre B et le score de 88%. Ici, plus le score est élevé, mieux c'est ! 

Ce qui m'intéresse dans un premier temps, c'est le résultat pour la ligne "IOEs found", 15 dans mon cas. En fait, IOE signifie Indicators of Exposure (Indicateurs d'exposition) et cela correspond au nombre de règles pour lesquelles mon Active Directory n'est pas conforme aux recommandations.

En descendant dans la page, nous pouvons ceux qui sont critiques et qu'il faut traiter en priorité. En cliquant sur le lien "Read More" on est envoyé directement à la section du rapport qui donne des détails techniques sur la règle, mais aussi les éléments de l'Active Directory concernés.

Toujours un peu plus bas dans le rapport, il y a un score par catégorie cette fois-ci. Sur son site, Semperis précise : "Le score global moyen de Purple Knight est de 61 %, la sécurité de Kerberos étant en moyenne de 43 % et celle de Group Policy de 58 %.", ce qui vous permettra de vous situer. En naviguant dans le menu à gauche du rapport, on peut parcourir chaque section et voir l'ensemble des points vérifiés avec le résultat associé.

Selon les résultats et le contenu du rapport, il conviendra d'analyser chaque point afin de mettre un plan d'action pour y remédier. Selon votre score initial, fixez-vous l'objectif d'atteindre un score minimum de 90% même si l'idéal c'est bien sûr 100%.

A chaque fois, différentes informations sont fournies comme le niveau de sévérité, une description, la probabilité de compromission en exploitant cette faiblesse, des détails sur les éléments de votre Active Directory concernés par la règle, ainsi que des informations sur les étapes à réaliser pour résoudre ce défaut de sécurité.

La règle ci-dessous m'indique que j'ai un compte administrateur sur mon Active Directory qui est actif (utilisable, disons), mais qui n'a pas été utilisé depuis longtemps.

Le compte en question, nommé "wapt.wads", est listé par l'outil pour m'aider à résoudre le problème. Son emplacement dans l'annuaire est indiqué, tout comme la date de dernière connexion.

Après avoir résolu le problème, l'élément passe en vert (bien sûr, il faut relancer une analyse) :

Tuto Purple Knight

Ce qui est plaisant avec Purple Knight, c'est qu'il fait le lien entre les points vérifiés et les recommandations du MITRE et de l'ANSSI. Du coup, si l'on prend l'exemple de l'ANSSI, chaque élément vérifié à un "ANSSI ID", par exemple "vuln1_user_accounts_dormant", que l'on peut retrouver dans le guide "Point de contrôle de l'Active Directory" de l'ANSSI disponible iciC'est très pratique, car Purple Knight permet de voir rapidement si notre Active Directory respecte les recommandations de l'ANSSI.

Enfin, sachez que vous pouvez retrouver l'ensemble de vos rapports d'audit dans le répertoire "Output" de Purple Knight :

V. Conclusion

Pour auditer l'Active Directory, Purple Knight est une très bonne solution complémentaire à Ping Castle. Même s'il y a des règles communes, les éléments sont présentés différemment donc cela peut vous aider à mieux comprendre certains points à corriger. Les deux outils étant gratuits, il me semble pertinent d'auditer son annuaire Active Directory avec les deux outils d'autant plus que les scans s'effectuent rapidement.

Pour terminer, voici une liste de tutoriels qui pourront vous aider à corriger certains points :

The post Comment auditer l’Active Directory avec Purple Knight ? first appeared on IT-Connect.

Troubleshooting “a domain controller could not be contacted”

27 juillet 2022 à 17:39

When you open tools such as Group Policy Management or AD Users and Computers, it might happen that these tools do not find the domain. Network problems in general and DNS problems in particular are almost always responsible for this. The IPv6 configuration plays a special role here.

The post Troubleshooting “a domain controller could not be contacted” first appeared on 4sysops.

Sécurité de l’Active Directory : attention aux objets avec un propriétaire inadapté

25 juillet 2022 à 10:00

I. Présentation

Bien que certaines entreprises misent désormais sur Azure Active Directory et se passent d'un Active Directory en local, il reste un système très répandu. Certaines des entreprises qui exploitent un annuaire Active Directory sont exposées à la vulnérabilité "Broken owner" sans le savoir, ce qui rend les comptes à faible privilège sensibles. Ces comptes peuvent devenir la cible d'attaques informatiques.

Dans cet article, nous allons vous montrer comment cela se produit, vous expliquer les risques encourus, et vous expliquer comment détecter ces objets ayant un propriétaire inadapté (broken owner, en anglais) à l'aide d'un script PowerShell afin de protéger l’annuaire des potentielles attaques basées sur ce vecteur de compromission (par exemple, les attaques par délégation Kerberos).

La sécurité informatique est devenue un enjeu majeur pour les entreprises, l’AD suscite une attention particulière dans une infrastructure système Microsoft, ce dernier a pour rôle principal d’autoriser les accès aux différentes ressources, de repérer les services et de gérer les identités et permissions.

Un Active Directory propre, une obligation.

Toute mauvaise configuration ou mauvais usage de l’AD est une porte d’entrée pour une future attaque. C’est pour cette raison qu’il est essentiel de respecter les bonnes pratiques et veiller continuellement sur leurs applications. N’oublions pas qu’un AD maîtrisé et organisé constitue la base de la sécurité.

II. La notion de propriétaire des objets Active Directory

Chaque objet dans l’Active Directory possède un propriétaire qui lui confère tous les droits, notamment les droits de modifier la valeur des attributs et des autorisations. Ces droits sont représentés par des ACL (Access Control List) et sont dupliqués à partir du compte (Self) de l’objet.

Il est donc très dangereux d’accorder ce droit à des utilisateurs ou groupes à non-privilèges, que ce soit d’une façon volontaire ou intentionnelle.

A. Comment cela se produit-il?

Un utilisateur ou groupe autorisé à créer un objet dans l’AD (par délégation, par exemple) deviendra le propriétaire de cet objet à moins que ce dernier fasse partie d’un groupe à privilège, comme par exemple "Admin du domaine";  dans ce cas, le propriétaire de l’objet sera corrigé et remplacé automatiquement par l’Active Directory.

Propriétaire d'un objet créé à partir d’un compte qui fait partie d’un groupe à privilèges

III. La problématique associée aux propriétaires d'objets

Vous devez savoir que si l’utilisateur ou le groupe n’est pas membre du groupe à privilège, il sera le propriétaire de l’objet. Lors de la création de l’objet, ce dernier hérite des droits du compte système par défaut Self présent dans la table ACL.

utilisateur user2 créé par user3 (user3 étant un compte à non-privilège)

 

Le propriétaire user3 possède les droits de modifications des attributs sur l’objet user2

Si le compte “Self” avait le contrôle total, le propriétaire dans notre cas “User3” aura aussi le contrôle total. Si ce n’est pas le cas, il peut toujours se le procurer et faire des modifications à tout moment sur ces objets (car il a les permissions de modification des attributs), ces utilisateurs ou groupes deviennent ainsi une cible potentielle lors d’attaques donc il faudra les protéger et  les surveiller.

A. Exemple avec la délégation pour créer des comptes

Dans cet exemple, nous allons déléguer la tâche de création de comptes à un simple utilisateur nommé "HelpDesk1".

Sur l’OU "IT-Connect", nous allons déléguer le droit de création d'utilisateurs à "HelpDesk 1" qui n'aura aucun autre droit dans l’AD ni sur les machines locales.

Sélection du compte Helpdesk1 pour délégation d’administration  sur l’OU IT-CONNECT

Pour faire simple, nous allons lui accorder le droit de créer des comptes utilisateurs.

Ajout des droits de création, suppression et gestion de comptes dans la délégation

Nous allons ensuite créer avec l’utilisateur "HelpDesk1", les comptes "Florian" et "Dakhama", à partir d’une machine dans le domaine. Pour cela, l'utilisateur utilisera les outils "RSAT", la commande "DSADD" ou PowerShell.

Création des comptes Florian et Dakhama par Helpdesk1

Les deux objets sont bien présents dans notre Annuaire et ils ont comme propriétaire notre utilisateur "helpdesk1".

Comptes créés par Helpdesk1

Voici les détails de sécurité du compte "Florian" :

Helpdesk1 est propriétaire du compte Florian

B. Retrait des droits

Nous allons maintenant retirer les droits à l’utilisateur "HelpDesk1". Autrement dit, on supprime la délégation créée précédemment.

Dans l’onglet "Sécurité" de l'OU "IT-Connect", nous allons supprimer l’utilisateur "HelpDesk1" de la table ACL pour lui retirer les droits. L'utilisateur, quant à lui, existe toujours.

Retrait délégation de Helpdesk1  sur l’OU IT-Connect

Nous constatons ensuite que l’utilisateur "HelpDesk1" ne peut plus créer de compte. C'est normal.

Helpdesk1 ne peut plus créer de comptes après la suppression de la délégation

Les droits sont grisés :

Helpdesk1 ne peut pas effectuer de modifications sur IT-Connect

C. Risques et menaces

L’utilisateur "HelpDesk1" n’a plus aucun droit sur notre AD, à part sur les objets dont il est le propriétaire.

Nous allons nous procurer le contrôle total sur nos anciens objets créés quand la délégation de contrôle était effective. Pour faire simple, on ouvre la console utilisateur AD (dsa.msc), on effectue un clic droit sur l’utilisateur "Florian" afin d'ajouter "HelpDesk1" (lui-même).

Helpdesk1 modifie les permissions et obtient le contrôle total sur l'objet utilisateur "Florian"

Maintenant que nous avons le contrôle total sur notre objet (pour rappel, l’utilisateur HelpDesk1 n’a plus aucun droit sur l’AD, les délégations ont été supprimées) on pourra tout faire sur ce compte ! Pour être précis, on peut effectuer le changement du MDP, récupérer le Hash, faire des attaques sur des attributs par délégation (ms-ds-allowedhosted), etc…..

Ici nous allons changer la valeur de l’attribut "Description", à titre d'exemple.

Helpdesk1 change l’attribut Description de Florian

Je vous laisse imaginer ce qu’il est possible de faire avec ces objets, vous pouvez trouver plein d'exemples sur le Net... Ci-dessous, un autre exemple d’exploit de cette vulnérabilité. L'attaque Délégation Kerberos peut aussi être utilisée.

Active Directory Broken owner

Voici un autre exemple de l’exploit de la vulnérabilité "Broken Owner".

Dans ce scénario, si le compte HelpDesk1 est compromis à partir d’un hash présent sur une machine sur laquelle il intervient (support niveau 1), la personne malveillante pourra se procurer ses objets dans l’AD, les rendre indétectables (en refusant la lecture de certains éléments à des groupes à privilèges) et passer en cachette pour extraire des données ou injecter des ransomwares sur des ressources partagées.

D’autres scénarios sont envisageables, A noter que même si HelpDesk1 ne possède plus de droit dans l’AD, son compte reste sensible en raison des objets dont il est le propriétaire.

IV.  Comment détecter les comptes avec un propriétaire inadapté ?

Maintenant que nous sommes conscients de ce risque et de ces menaces, nous allons voir comment lister et détecter les mauvais propriétaires des objets afin de les corriger.

A. Le script PowerShell "SCABOO"

Pour cela, nous avons développé un script simple d’utilisation (et open source) pour nous faciliter la tâche.

Ci-dessous, le lien du script PowerShell. Il existe aussi en interface graphique :

Le projet porte le nom de SCABOO (Scan-AD-Broken-Owner-Object). Pour l'utiliser, il vous suffit de le télécharger et de l'ouvrir avec PowerShell ISE ou VSCode.

La bonne nouvelle, c'est que ce script ne nécessite pas de prérequis spécifique pour fonctionner :

  • Aucun module ni les droits avancés ne sont nécessaires
  • Une machine et un utilisateur du domaine, tout simplement

Le script pourra être lancé à partir de n’importe quelle machine dans le domaine, avec n’importe quel compte. Il ne nécessite aucun module PowerShell complémentaire, ce qui est un avantage, et ne garde rien dans la mémoire "Variable avec les informations". Le traitement est spontané et sécurisé.

Note : utilisez le GUI si vous avez des restrictions pour exécuter le script PowerShell...

Ce que vous devez savoir sur ce script...

Le script effectue des requêtes LDAP grâce au module ADSI, il ne fait que des requêtes de types GET donc aucune modification n’est faite sur l’annuaire. Le script n’utilise pas de variable en dur comme "admins du domaine", etc…. Mais plutôt des SID, ce qui le rend compatible avec toutes les versions d’AD de toutes langues.

Une fois lancée, nous avons le choix entre un scan de l’AD entier ou de choisir une OU spécifique, nous allons commencer par ce second choix.

  • Entrez le numéro 2.

  • Ensuite, entrez le nom de votre OU, dans mon cas IT-Connect. Vous pouvez entrer seulement l’initiale, le script fera une recherche et proposera le choix entre les OU portant une partie du nom.
  • Sélectionnez votre OU, puis entrez OK.

  • Le scan est lancé

Une fois que le scan est terminé, une page HTML sera créée au même emplacement que le script. Elle sera lancée automatiquement et affiche un résumé des objets scannés et ceux présentant une anomalie.

Active Directory propriétaire inadapté sur un objet

Pour scanner tout l’AD, nous allons relancer le script et choisir l’option 1.

Remarque : attention, si votre AD contient plus de 1000 objets, le scan risque d'être un peu long (2 à 3 minutes). Si besoin, vous pouvez stopper le script à tout moment.

Voici le résultat pour un scan sur l'ensemble de notre AD :

Le script nous liste aussi les éléments sans propriétaire Owner qu'il faudra corriger en urgence, car ils peuvent être la cible d’attaques.

B. Personnalisation du script

Selon vos besoins, vous pouvez adapter certaines parties du script.

  • Nombre d’éléments affiché

Par défaut, le script liste 50 éléments à corriger dans le tableau, ce choix a été fait pour ne pas ralentir le traitement et l’affichage de la page HTML, si vous avez plus de 50 éléments vous pouvez les afficher en changeant cette ligne numéro 222.

Remplacez le 50, par le nombre d’objets par catégorie souhaité.

  • Affichage dans un autre format

Vous pouvez afficher le résultat dans un fichier Excel ou dans une fenêtre GridView. Pour le faire, commentez les lignes 246 et 248, et décommentez la dernière ligne.

Exemple du résultat :

  • Exclure un compte

Si vous souhaitez exclure un groupe ou un compte (par exemple, le compte d’intégration MDT ou SCCM, ou un compte quelconque du résultat), ajoutez ce dernier à la variable Skipdefaultgroups. Dans notre exemple, on exclut le groupe "MDT-account".

V. Recommandations

Face à cette potentielle vulnérabilité permanente, Microsoft et ANSSI nous recommandent de changer les propriétaires des objets qui ont un propriétaire à non-privilège ou qui n’ont pas de propriétaire (Broken Owner) par l'un de ces groupes

  • « Administrateurs du domaine » ;
  • « Administrateurs de l'entreprise » ;
  • « Administrateurs » ;
  • « Système local »

Vous pouvez consulter les liens ci-dessous en complément :

VI. Conclusion

Le propriétaire des objets Active Directory est un élément très important pour la sécurité de l’annuaire. Il convient d’adapter nos usages en tenant compte de cet aspect. Nous reviendrons en détail dans un prochain article sur les méthodes de préventions et de corrections.

Merci à Mehdi Dakhama pour sa collaboration sur cet article.

The post Sécurité de l’Active Directory : attention aux objets avec un propriétaire inadapté first appeared on IT-Connect.

[PowerShell] Joindre un domaine AD dans une OU précise

2 juin 2022 à 08:00
Par : Mr Xhark

S'il est possible de rejoindre un domaine Active Directory depuis le panneau "win+R > systempropertiescomputername" il est possible de le faire en PowerShell.

2 avantages à cela :

  • l'ordinateur arrive directement dans la bonne OU
  • réalisable sur Windows Server version Core

Récupérer le DN de l'OU cible

Avant tout il faut connaître le chemin de l'OU de destination.

C'est le container dans lequel le compte ordinateur de la machine qui va rejoindre le domaine va arriver. On parle alors de DN (distinguished name), c'est un chemin dans l'arborescence de l'annuaire LDAP.

Pour le trouver, depuis votre contrôleur de domaine :

  • lancer dsa.msc (utilisateurs et ordinateurs AD)
  • menu Affichage > Fonctionnalités avancées
  • Localiser l'OU cible puis clic droit > propriétés
  • onglet "éditeur d'attributs"
  • cliquer sur distinguishedName > afficher
  • copier la valeur (ctrl+c)

Si vous utilisez Hyena vous trouverez également l'info facilement.

Rejoindre le domaine en PowerShell

Lancer une invite PowerShell en tant qu'administrateur puis :

Add-Computer -DomainName "bm.lab" -OUPath "OU=SRV-PROD,DC=BM,DC=LAB"
  • -DomainName = nom FQDN de votre domaine AD
  • -OUPath = DN de l'OU récupérée à l'étape précédente

Une popup apparaît ensuite vous demandant les identifiants d'un compte autorisé à rejoindre le domaine (administrateur ou autre).

Si la jointure a fonctionné le message suivant apparaît :

AVERTISSEMENT : Les modifications seront prises en compte après le redémarrage de l'ordinateur CLIENT-2016.

Il ne reste plus qu'à redémarrer la machine: restart-computer

Pour enfin pouvoir vous connecter avec un compte de domaine.

A partir de Windows Server 2012 vous pouvez ajouter le switch "-restart" pour enchainer le reboot immédiat après la jointure :

Add-Computer -DomainName "bm.lab" -OUPath "OU=SRV-PROD,DC=BM,DC=LAB" -restart

En cas de problème ajoutez le switch "-verbose" pour avoir plus de détails sur les potentielles erreurs.

Joindre le domaine sans saisir le mot de passe

Pour ne pas avoir à saisir de mot de passe (à éviter en environnement de production - lien) :

$login= "bm\administrateur"
$mdp= "MonSuperPassword" | ConvertTo-SecureString -AsPlainText -Force
$cred= New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $login,$mdp
Add-Computer -DomainName "bm.lab" -DomainCredential $cred -Restart -Verbose

Attention : votre mot de passe sera stocké en clair et ce sera d'autant plus problématique s'il s'agit d'un compte avec des droits étendus tel que le compte admin du domaine.

Quitter le domaine (revenir en workgroup)

Pour quitter le domaine et repasser en WORKGROUP :

Add-Computer -WorkgroupName WORKGROUP -restart

Conclusion

Vous savez maintenant comment facilement rejoindre ou quitter un domaine AD, sans avoir à déplacer le compte ordinateur.

Sachez aussi que l'utilitaire sconfig est particulièrement utile pour faire la même chose, mais il faudra déplacement manuellement le compte ordinateur après la jointure.

Si tous vos comptes ordinateurs arrivent au même endroit vous pouvez changer le chemin de l'OU de destination avec redicmp. C'est une question d'organisation, à vous de voir 😉

 

 

 

Vous n'aimez pas le RSS : abonnez-vous par email 📥
Vous devriez me suivre sur Twitter : @xhark

Article original écrit par Mr Xhark publié sur Blogmotion le 02/06/2022 | Pas de commentaire |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons

Cet article [PowerShell] Joindre un domaine AD dans une OU précise provient de : on Blogmotion.
❌