I.  Présentation

Maester est un projet communautaire créé en avril 2024 par Merill Fernando, chef de produit chez Microsoft et deux MVP Security Fabian Bader et Thomas Naunheim. C’est un outil PowerShell conçu pour vous aider à comprendre la configuration de votre tenant Microsoft 365.

Il vous permet d’avoir une vision de votre configuration par rapport aux bonnes pratiques de sécurité, et ainsi, surveiller la posture de sécurité de votre tenant Microsoft 365. Cet outil fournit un rapport, mais ne réalise aucune action de correction.

À l’heure actuelle, l’outil contient 92 vérifications de sécurité, toutes concentrées sur la partie Microsoft Entra. Ces vérifications proviennent de plusieurs sources :

• de l’équipe Maester
• du guide de sécurité SCubA par le CISA
• du guide Entra ID Security Config Analyzer (EIDSCA) de Cloud-Architekt

Maester réalise plusieurs vérifications de sécurité, incluant :

• Droits administrateurs (limiter le nombre d’utilisateur avec le rôle administrateurs global, utilisation de PIM)
• Les méthodes d'authentification, comme la configuration multi-facteur et FIDO2.
• La gestion des applications, incluant les permissions de création et le consentement OAuth.
• Les paramètres de mots de passe et les politiques de verrouillage des comptes.
• Les accès conditionnels, vérifiant l'exclusion de comptes de secours et la présence de stratégies répondant aux bonnes pratiques.

Avant de rentrer dans le vif du sujet, voici le lien vers le site officiel du projet :

• Site officiel de Maester

II. Installation et utilisation de Maester

A. Fonctionnement

Maester utilise l'API Microsoft Graph pour accéder aux informations de votre tenant Microsoft 365. Cet outil vérifie la conformité de votre configuration par rapport aux bonnes pratiques de sécurité. L’originalité de cet outil réside dans l’utilisation de Pester pour vérifier cette conformité.

Pester est un module PowerShell conçu pour les tests unitaires. Bien qu’il soit souvent utilisé pour valider des scripts ou des fonctions, son mode de fonctionnement permet à chacun d’écrire ses propres tests unitaires.

Dans le cas de Maester, Pester est employé pour s'assurer que la configuration de votre tenant Microsoft 365 correspond aux critères définis dans des fichiers. Ces fichiers, appelés fichiers de tests dans la suite de l’article, permettent de réaliser des vérifications sur la conformité de votre configuration. L’appellation tests provient du fait que Pester suit une nomenclature stricte concernant les fichiers qu’ils utilisent : xxxx.Tests.ps1.

Cela permet ainsi une vérification rigoureuse et continue de la sécurité d’un tenant.

Il est important de comprendre que Maester, utilisant Pester, ne fournit pas de valeurs directes de votre tenant, mais indique plutôt si vos configurations respectent les normes établies dans les fichiers Tests.

Par exemple, au lieu de spécifier le nombre d'administrateurs globaux, Maester vous informera si la configuration est conforme aux bonnes pratiques définies dans les tests. Cette méthode peut représenter une nouvelle approche pour certains qu’il est essentiel de comprendre.

B. Installation

Maester est publié dans la PowerShell Gallery, son installation peut être réalisée en seulement deux Cmdlets :

Install-Module Pester -SkipPublisherCheck -Force -Scope CurrentUser
Install-Module Maester -Scope CurrentUser

Sur votre PC, il faut ensuite créer un dossier et installer les fichiers de tests. Dans notre cas, nous installerons les fichiers Tests dans "C:\temp", mais tout autre chemin fonctionnera.

cd c:\temp
mkdir maester-tests
cd maester-tests
Install-MaesterTests .\tests

Les fichiers de tests sont installés dans C:\Temp\maester-tests\tests.

C. Utilisation

Dans un premier temps, il faut se connecter :

Connect-Maester

Comme indiqué plus haut, Maester s’appuie sur Microsoft Graph. Si vous n’avez pas les autorisations requises, il faudra autoriser les autorisations OAuth pour l’application Microsoft Graph Command Line Tools.

Ensuite, vous pouvez exécuter les tests :

Invoke-Maester

À la fin de l'exécution des tests par Maester, un bref résumé est affiché dans la console.

Ce résumé indique les résultats des tests avec le nombre de tests réussis, échoués ou ignorés, fournissant ainsi un aperçu rapide de l'état de la configuration de sécurité de votre tenant Microsoft 365.

Un fichier de rapport HTML est aussi créé, il est stocké dans le dossier "tests-results" et s’ouvre automatiquement dans votre navigateur :

Un élément en "Passed" indique que la configuration de votre tenant respecte le test en question.

Un élément en "Failed" indique que la configuration de votre tenant ne respecte le test. Cependant, selon les contraintes de votre entreprise, il convient de statuer si c’est un réel problème, ou bien un risque accepté.

Pour chaque élément du rapport, vous retrouverez :

• L’identifiant
• L’URL vers la documentation Maester concernant ce test
• Le résultat du test
• Les détails du test qui contiennent les actions à réaliser pour passer ce test
• Les catégories
• Les tags
• La source du fichier de test Pester

Pour la majorité des tests, il est évident de comprendre pourquoi un test échoue, comme une fonctionnalité non activée ou un nombre excessif d'utilisateurs non conformes.

Cependant, il peut être plus complexe de déterminer la cause d'un échec dans certains cas, où le problème pourrait ne pas résider dans la non-conformité, mais plutôt dans un bug au sein du code PowerShell du test lui-même. Dans ces situations, il sera nécessaire d'examiner en détail les fichiers "*.Tests.ps1" pour identifier et résoudre l'erreur.

D. Création de ses propres tests

Le gros intérêt de Maester est que ce n’est qu’un framework, c’est-à-dire qu’il peut être étendu pour correspondre à vos besoins avec des tests personnalisé.

Pour créer un test personnalisé dans Maester, vous devez suivre une certaine structure. Par exemple, nous allons créer un test pour vérifier qu'un groupe contient exactement deux membres.

Pour cela, créez un fichier nommé "Test-CustomITConnect.Tests.ps1" dans le répertoire "<chemin>\maester-tests\Custom". Pester recherche les fichiers se terminant par ".Tests.ps1" pour les exécuter comme des tests.

Dans notre cas, nous créons un fichier" Test-CustomITConnect.Tests.ps1" dans "C:\temp\maester-tests".

Pour le contenu du fichier "Test-CustomITConnect.Tests.ps1", nous devons suivre la syntaxe Pester, ce qui donne :

Describe "Test-MyGroupMembership" -Tag "Group" {
    It "Check 'MyGroup1' Members" {

        $groupID = "cc831d2a-6e92-4988-903c-1799de3a9aa1"
        $members = Get-MgGroupMember -GroupId $groupID

        # Test if the group has exactly 2 members
        $members.Count | Should -BeExactly 2
    }
}

Il est alors possible d’exécuter Maester avec uniquement notre test :

cd c:\temp\maester-test
Invoke-Maester .\tests\Custom\

Le rapport contient uniquement notre test personnalisé.

À noter qu’il est aussi possible de simplement exécuter "Invoke-Maester", pour exécuter tous les tests, y compris les tests personnalisés.

E. Exécution régulière

Maester peut être configuré pour surveiller en permanence la configuration de votre tenant à l'aide de service DevOps comme Azure DevOps Pipeline, GitHub Actions et Azure Automation.

Avec ces solutions, il est possible de recevoir un e-mail régulier avec les informations concernant la sécurité du tenant.

La configuration de cette automatisation n’est pas détaillée dans cet article, mais vous pouvez retrouver toutes les informations dans la documentation de Maester.

III. Mise à jour des tests Maester

L'équipe Maester ajoute de nouveaux tests au fil du temps, il faut donc penser à mettre à jour le module et les tests de temps en temps.

cd <chemin>maester-tests\tests

Mettre à jour le module Maester :

Update-Module Maester -Force
Import-Module Maester

Mettre à jour les tests Maester :

Update-MaesterTests

Tous les tests personnalisés dans le dossier "/Custom" seront conservés.

Les fichiers de test des autres dossiers, notamment "/EIDSCA", "/Maester" et "/CISA", seront remplacés par les tests les plus récents :

IV. Contribuer à l’amélioration du produit

Maester est une solution récente et se focalise pour le moment uniquement sur les tests Microsoft Entra ID. Cependant, compte tenu de son fonctionnement et de sa flexibilité, il est tout à faire possible de créer ses propres tests et de participer à ce projet communautaire.

Pour approfondir le sujet de l'audit Microsoft 365, vous pouvez consulter cet article :

• Comment réaliser un audit de Microsoft 365 ?

The post Maester, l’outil pour automatiser vos tests de sécurité Microsoft 365 first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons exploiter PowerShell pour créer un journal personnalisé et des événements personnalisés dans l'Observateur d'événements de Windows ou Windows Server, à l'aide de deux cmdlets : New-EventLog et Write-EventLog. En complément, nous verrons comment utiliser la classe .NET "EventLog" pour créer des entrées avancées.

Sur Windows, le système d'exploitation, les composants et les applications peuvent générer des événements qui sont inscrits dans les différents journaux centralisés dans l'Observateur d'événements. Ces journaux sont une mine d'informations pour les administrateurs systèmes, mais aussi pour les équipes en charge de la sécurité : une action suspecte peut être consignée dans un événement, qui représentera alors une trace intéressante.

L'intérêt ensuite est de collecter ces événements dans un puits de logs ou un SIEM afin de les analyser et de détecter les comportements suspects ou les anomalies sur une infrastructure.

Grâce à la commande Write-EventLog ou à l'utilisation de la classe EventLog, nous pouvons alimenter les journaux de Windows avec des événements personnalisés qui, eux aussi, pourront être exploités par une solution telle qu'un SIEM. Autrement dit, votre script PowerShell pourra créer des événements contenant les informations de votre choix.

Remarque : avant de pouvoir utiliser Write-EventLog, cette action était possible sous Windows grâce à l'utilisation de l'utilitaire en ligne de commande EVENTCREATE.exe.

II. Utiliser le cmdlet New-EventLog

Au sein de l'Observateur d'événements, vous pouvez créer un journal personnalisé, associé au nom de votre choix, à condition que celui-ci ne soit pas déjà utilisé. Cette étape est facultative, car nous pouvons créer des enregistrements dans certains journaux natifs, notamment dans le journal "Applications" de Windows.

Néanmoins, le fait de créer un journal personnalisé et d'y inscrire par la suite nos propres événements, permet "d'isoler" nos événements personnalisés. Ceci peut vouloir dire également qu'il faudra adapter la configuration de votre outil de collecte de log pour qu'il prenne en charge ce nouveau journal.

La commande suivante permet de créer un journal nommé "PowerShell-Demo", qui accepte deux sources : "Script-1" et "Script-2". Vous pouvez en ajouter autant que vous le souhaitez, et, vous pouvez ajouter des sources supplémentaires à un journal existant. Ceci est indispensable, car chaque événement de journal doit être associé à une source.

New-EventLog -LogName "PowerShell-Demo" -Source "Script-1","Script-2"

Ce journal sera immédiatement visible dans l'Observateur d'événements sous "Journaux des applications et des services".

D'ailleurs, pour ajouter une source supplémentaire, il suffit d'exécuter une nouvelle fois New-EventLog en indiquant le nom du journal et le nom de la source supplémentaire à ajouter. Voici un exemple pour ajouter la source "Script-3" :

New-EventLog -LogName "PowerShell-Demo" -Source "Script-3"

Si vous effectuez une erreur, par exemple, dans le nom de votre journal, sachez que vous pouvez le supprimer avec cette commande :

Remove-EventLog -LogName "PowerShell-Demo"

Pour approfondir l'utilisation de ce cmdlet, vous pouvez consulter cette page :

• Microsoft Learn - New-EventLog

III. Utiliser le cmdlet Write-EventLog

Désormais, nous allons voir comment écrire un nouvel événement dans le journal d'événements que nous venons de créer. Nous pourrions aussi l'ajouter dans un autre journal (attention, certains sont protégés), tout se joue au niveau du paramètre "-LogName" de la commande Write-EventLog puisqu'il permet de préciser le journal cible.

Comme pour les autres cmdlets PowerShell, vous pouvez spécifier le nom du cmdlet suivi de chaque paramètre et de sa valeur, mais dans le cas présent, l'écriture proposée ci-dessous permet d'avoir une meilleure lisibilité.

$Event = @{
    LogName = "PowerShell-Demo"
    Source = "Script-1"
    EntryType = "Error"
    EventId = 10000
    Message = "Cette alerte a été généré depuis PowerShell"
}

Write-EventLog @Event

Ce bout de code va créer un événement de type "Erreur" dans notre journal, associé à la source "Script-1" et l'ID "10000". Il contiendra le message "Cette alerte a été généré depuis PowerShell", comme vous pouvez le voir sur l'image ci-dessous. Essayez d'utiliser des ID différents pour vos types d'événements, et évitez aussi d'utiliser des ID déjà utilisé par Windows.

À la place du type "Error" permettant de générer une erreur, vous pouvez utiliser les valeurs suivantes : Warning, Informational, SuccessAudit, et FailureAudit. Sachez que cette commande prend en charge le paramètre "-ComputerName", ce qui permet de créer un événement dans le journal d'un ordinateur distant.

Pour consulter ce journal personnalisé, ou un autre journal, vous pouvez utiliser le cmdlet PowerShell "Get-EventLog". Bien que ce cmdlet soit très pratique, il ne permet pas d'accéder à tous les journaux, donc sachez qu'il existe aussi un second cmdlet prévu pour consulter les journaux : "Get-WinEvent".

Voici la commande à utiliser pour récupérer les logs de notre journal :

Get-EventLog -LogName "PowerShell-Demo"

Pour approfondir l'utilisation de ces cmdlets, vous pouvez consulter ces pages :

• Microsoft Learn - Write-EventLog
• Microsoft Learn - Get-EventLog
• Microsoft Learn - Get-WinEvent

IV. Utiliser la classe EventLog avec PowerShell

Pour aller plus loin dans l'écriture d'événements dans un journal Windows, il convient d'exploiter la classe EventLog directement depuis PowerShell. Celle-ci va nous permettre d'ajouter des données mieux structurées dans notre événement, notamment dans la section "EventData" visible à partir de la vue XML. C'est utile pour stocker plusieurs informations tout en permettant de récupérer de façon indépendante chaque information.

Voici un exemple :

Nous avons mis en pratique cette méthode dans ce tutoriel :

• Sécurité de l’Active Directory : les mots de passe dans la description des objets utilisateur

Ceci complexifie l'inscription d'un nouvel événement, car nous devons créer nos propres objets et nous passer de l'utilisation de Write-EventLog. Un premier objet "System.Diagnostics.EventInstance" permettra d'indiquer le numéro d'ID et le type d'événements, tandis qu'un second objet "System.Diagnostics.EventLog" permettra de préciser les données de l'événement.

Néanmoins, pour que l'utilisation reste simple, nous vous proposons d'utiliser cette fonction :

function Write-EventLogV2 {
    <#
    .SYNOPSIS
        Crée un évènement dans l'observateur d'évènement
    .DESCRIPTION
        La fonction utilise la CmdLet WriteEvent pour créer un évènement à partir des paramètres d'entrée. 
    .PARAMETER dataUser
        Nom utilisateur qui sera inscrit dans le contenu de l'évènement à créer
    .PARAMETER dataDescription
        Contenu de la description qui sera inscrite dans le contenu de l'évènement à créer
    .PARAMETER ID
        Event ID de l'évènement à créer
    .PARAMETER evtLog
        Journal de l'évènement à créer
    .PARAMETER evtSource
        Source de l'évènement à créer
    .EXAMPLE
        New-EventLog -dataUser "John" -dataDescription "new description"
    .OUTPUTS
        None
    #>
    param(
          [Parameter(Mandatory=$true)]$dataUser,
          $dataDescription="",
          $ID=10000,
          $evtLog="PowerShell-Demo",
          $evtSource="Script-2"
          )

    # Charge la source d'événement dans le journal si elle n'est pas déjà chargée.
    # Cette opération échouera si la source d'événement est déjà affectée à un autre journal.
    if ([System.Diagnostics.EventLog]::SourceExists($evtSource) -eq $false) {
        [System.Diagnostics.EventLog]::CreateEventSource($evtSource, $evtLog)
    }

    # Construire l'événement et l'enregistrer
    $evtID = New-Object System.Diagnostics.EventInstance($ID,1)
    $evtObject = New-Object System.Diagnostics.EventLog
    $evtObject.Log = $evtLog
    $evtObject.Source = $evtSource
    $evtObject.WriteEvent($evtID, @($dataUser,"Description : $dataDescription"))
  }

En entrée, cette fonction accepte deux messages ($dataUser et $dataDescription - vous pouvez renommer ces paramètres dont le nom a été choisi vis-à-vis du script d'origine), un numéro d'ID (par défaut, ce sera 10000), le nom d'un journal d'événement (par défaut, ce sera "PowerShell-Demo") ainsi qu'une source (par défaut, ce sera "Script-2").

De plus, par défaut, cette fonction génère des événements de type "Information". Si vous souhaitez changer le type d'événement, vous devez ajuster la valeur présente sur cette ligne :

$evtID = New-Object System.Diagnostics.EventInstance($ID,1)

En effet, la première valeur correspond à l'ID souhaité, ici associé à la variable $ID, tandis que la seconde valeur correspond au type d'événement. Le 1 correspond au type "Information".

Ce qui permettra de générer des événements similaires à celui-ci :

Si besoin, vous pouvez ajouter d'autres valeurs dans la seconde partie de "$evtObject.WriteEvent" pour avoir des lignes "<Data>" supplémentaires.

V. Conclusion

En suivant ce tutoriel, vous devriez être en mesure de créer vos propres événements personnalisés dans les journaux Windows, que ce soit dans un journal existant ou dans votre propre journal à l'aide de PowerShell ! Libre à vous d'utiliser ces cmdlets ou cette fonction dans vos scripts, et de les adapter à vos besoins ! En tout cas, ceci ouvre des possibilités très intéressantes !

The post Comment utiliser PowerShell pour créer un événement dans un journal Windows ? first appeared on IT-Connect.

Des chercheurs en sécurité soupçonnent les cybercriminels d'avoir utilisé l'IA générative dans le cadre d'une attaque pour générer un script PowerShell. Il a été utilisé pour distribuer un malware infostealer. Faisons le point !

En mars 2024, les chercheurs en sécurité de chez Proofpoint ont identifié une campagne malveillante ciblant des dizaines d'organisations allemandes et associées au groupe de pirates suivi sous le nom de TA547, et connu également sous le nom de Scully Spider. Il s'agirait d'un groupe actif depuis 2017 et appartenant à la catégorie des "initial access broker" (courtier d'accès initial).

"Outre les campagnes menées en Allemagne, d'autres organisations ont été ciblées récemment en Espagne, en Suisse, en Autriche et aux États-Unis.", peut-on lire dans le rapport de Proofpoint.

Lors de cette campagne, les pirates ont tenté d'usurper l'identité de la marque allemande Metro en envoyant des e-mails malveillants avec une facture, au format ZIP, en pièce jointe. Pour échapper aux analyses de sécurité, ce fichier ZIP est protégé par le mot de passe "MAR26". Il contient un fichier de raccourci malveillant (.LNK) qui, lorsqu'il est exécuté, déclenche l'exécution d'un script distant via PowerShell.

L'objectif final est d'infecter la machine avec le logiciel malveillant "Rhadamanthys", de type infostealer. Ce malware a pour objectif de voler des données sur chaque machine infectée, notamment des identifiants et des cookies.

Un script PowerShell généré avec une IA ?

Les chercheurs en sécurité ont procédé à l'analyse du script PowerShell utilisé par les cybercriminels. Et, ils ont été surpris de constater que chaque ligne de code était précédée par un commentaire, très bien rédigé, comme ceux intégrés par l'IA lorsqu'on lui demande de l'aide pour un bout de code.

Voici un extrait du script PowerShell en question :

Les chercheurs affirment que c'est une caractéristique typique d'un code PowerShell généré avec l'aide d'une IA générative, que ce soit ChatGPT, Gemini ou Microsoft Copilot. Bien que ce ne soit pas certain à 100%, il y a de fortes chances pour que les cybercriminels aient utilisé l'IA pour écrire ou réécrire le code.

Cela signifierait que dans le cadre de cette campagne malveillante, les pirates du groupe TA547 ont recouru à l'IA. Bien entendu, cela n'est qu'un exemple parmi d'autres et dans le cas présent, l'IA pouvait difficilement se douter qu'il s'agissait d'un code PowerShell utilisé à des fins malveillantes.

Source

The post Un script PowerShell surement codé par l’IA a été utilisé pour distribuer un malware infostealer first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à utiliser la méthode de Trim() de PowerShell qui va s'avérer très utile pour nettoyer une chaine de caractères, que ce soit pour supprimer les espaces inutiles, ou un autre type de caractères.

La méthode Trim() est intégrée nativement dans PowerShell, ainsi que dans d'autres langages, et elle est généralement utilisée pour supprimer les espaces au début et à la fin d'une chaîne de caractères. Ces espaces indésirables peuvent correspondre à un espace unique, mais aussi à une tabulation.

Elle est utile dans différents scénarios, notamment quand le script demande à l'utilisateur de saisir quelque chose (via un Read-Host) ou que vous traitez des données récupérées à partir d'un fichier source.

II. Exemples d'utilisation de Trim()

A. Supprimer les espaces

Nous allons commencer par utiliser la méthode Trim() de PowerShell pour éliminer les espaces en début et en fin de chaînes de caractères.

Voici la chaine de caractères que nous allons manipuler :

$Texte = "  Tutoriel pour IT-Connect  "

Nous pouvons constater qu'il y a des espaces à trois endroits : avant le texte (2), après le texte (2), et entre chaque mot. Puisque les espaces sont en quelque sorte "invisibles", nous allons obtenir la longueur de cette chaine de caractères via la propriété "Length".

$Texte.Length
# Résultat actuel :
28

Maintenant, nous allons appliquer la méthode Trim() sur cette chaine de caractères, stocker, le résultat dans une variable et calculer la longueur de la nouvelle chaine obtenue.

$TexteTrim = $Texte.Trim()
$TexteTrim.Length

Cette fois-ci, nous obtenons une valeur différente : 24 au lieu de 28. En effet, la méthode Trim() a supprimé les espaces avant et après le texte, qui sont inutiles, tout en conservant les espaces entre les mots, qui eux sont utiles !

Testez par vous-même avec ces quelques lignes de code :

Write-Host "Sans la méthode Trim()" -ForegroundColor Green

$Texte = "  Tutoriel pour IT-Connect  "
$Texte
$Texte.Length

Write-Host "Avec la méthode Trim()" -ForegroundColor Green

$TexteTrim = $Texte.Trim()
$TexteTrim
$TexteTrim.Length

Ce qui donne :

B. Supprimer le caractère de votre choix

Par défaut, Trim() supprime les espaces inutiles (espace, tabulation). Sachez que vous pouvez l'utiliser pour supprimer un caractère spécial de votre choix. Imaginons que nous souhaitons éliminer les "#" en début et fin de chaînes de caractères. Il suffirait d'utiliser la méthode Trim() de cette façon :

$Texte.Trim("#")

Vous pouvez tester avec ce bout de code où les espaces sont remplacés par le symbole "#" pour cette démonstration.

Write-Host "Sans la méthode Trim()" -ForegroundColor Green

$Texte = "##Tutoriel pour IT-Connect##"
$Texte
$Texte.Length

Write-Host "Avec la méthode Trim()" -ForegroundColor Green

$TexteTrim = $Texte.Trim("#")
$TexteTrim
$TexteTrim.Length

Ce qui donne bien le résultat attendu :

Il est important de préciser que dans ce cas, Trim() va supprimer les caractères "#" mais il va conserver les espaces éventuels.

C. Supprimer plusieurs types de caractères

Si vous souhaitez utiliser la méthode Trim() pour supprimer les espaces, ainsi que d'autres caractères, sachez que c'est possible. Dans ce cas, vous devez simplement ajouter dans les parenthèses cette liste de caractères.

Dans l'exemple ci-dessous, nous allons chercher à éliminer les espaces, les "#" et les "?". Voici un bout de code pour tester :

Write-Host "Sans la méthode Trim()" -ForegroundColor Green

$Texte = "## Tutoriel pour IT-Connect ?"
$Texte
$Texte.Length

Write-Host "Avec la méthode Trim()" -ForegroundColor Green

$TexteTrim = $Texte.Trim("#? ")
$TexteTrim
$TexteTrim.Length

Ce qui donne :

Voilà, nous obtenons bien le résultat attendu ! Sachez que Trim() fonctionne aussi avec les lettres et les chiffres. Cette méthode n'est pas réservée aux caractères spéciaux même si nous l'utilisons souvent dans ce but.

Remarque : la méthode Trim() peut également être utilisée pour supprimer un caractère à partir de son code Unicode. Dans ce cas, et si vous avez ce besoin particulier, il faut adopter la syntaxe suivante : $Texte.Trim([char]0x0061). Ce code correspond à la lettre "a".

D. TrimStart() et TrimEnd()

La méthode Trim() est très pratique, mais elle effectue systématiquement le nettoyage au début et à la fin de la chaîne de caractères. Si vous avez besoin de supprimer uniquement les espaces ou les caractères inutiles au début de la chaîne, ou à l'inverse, à la fin de la chaîne, sachez que vous pouvez utiliser ces deux méthodes :

• TrimStart() pour les caractères au début de la chaîne
• TrimEnd() pour les caractères à la fin de la chaine

La méthode TrimEnd() est utile lorsque l'on manipule des chemins pour supprimer le dernier "\" qui peut être ajouté à la suite du dernier répertoire, ce qui permettra facilement de venir ajouter le nom d'un autre répertoire en le préfixant par "\" sans risquer de se retrouver avec un double "\\". Ceci nous permet de contrôler que le chemin aura bien le format attendu : si ce chemin est fourni par une saisie utilisateurs, vous avez une chance sur deux que le "\" à la fin soit présent. Avec TrimEnd(), ce problème potentiel est éliminé.

Voici un exemple où l'on élimine le caractère "\", ce qui oblige à rajouter un caractère d'échappement :

$Chemin = "C:\TEMP\"
$Chemin.TrimEnd("/\")
# Résultat : 
C:\TEMP

Ces deux méthodes fonctionnent sur le même principe et apportent un peu plus de souplesse.

III. Conclusion

Avec PowerShell, la méthode Trim() fait partie des incontournables, au même type que d'autres méthodes que j'ai l'habitude d'utiliser fréquemment : Split(), Substring(), etc.

• PowerShell - Utiliser la méthode Substring()
• PowerShell - Utiliser la méthode Split()

The post Comment utiliser la méthode Trim de PowerShell pour nettoyer une chaîne de caractères ? first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à exécuter un script PowerShell sur des appareils Windows à l'aide de Microsoft Intune. Ainsi, un script PowerShell chargé sur Intune pourra être exécuté sur un ensemble de machines sous Windows 10 ou Windows 11.

• Voir la vidéo sur YouTube

Nous allons commencer par évoquer les prérequis et le fonctionnement de cette fonctionnalité, avant la mise en pratique qui consistera à exécuter un script PowerShell qui va configurer une image de fond d'écran et de verrouillage sur Windows 10 Pro et Windows 11 Pro (pour les éditions Enterprise et Education, il y a des paramètres natifs dans Intune).

• Comment débuter avec Microsoft Intune ?

II. Prérequis

Pour exécuter un script PowerShell sur des appareils Windows, sachez que Microsoft Intune Management Extension doit être installé sur l'appareil. Ce composant s'installe automatiquement à partir du moment où un script ou une application Win32 est attribué à un appareil.

Pour Microsoft Intune Management Extension, et donc exécuter un script PowerShell, il y a plusieurs prérequis à respecter :

• Appareils joints dans Entra ID : Microsoft Entra Joined (Azure AD Joined) et Microsoft Entra Hybrid Joined (Azure AD Hybrid Joined)
• Appareils inscrits dans Intune
• Windows 10 à partir de la version 1709 ou Windows 11 (sauf les éditions Famille / Home)
• L'horloge de l'appareil doit être correctement configurée (date et heure correctes)

En ce qui concerne les scripts PowerShell en eux-mêmes, voici ce qu'il faut savoir :

• Le poids du script ne doit pas dépasser 200 Ko
• L'utilisateur n'a pas besoin de se connecter à l'appareil pour que le script PowerShell soit exécuté
• Lorsque le script est configuré dans Intune pour s'exécuter dans le contexte de l'utilisateur et que cet utilisateur dispose de droits d'administrateur, alors le script PowerShell s'exécute par défaut avec les privilèges de l'administrateur.
• Il y a un timeout de 30 minutes sur l'exécution des scripts PowerShell
• Au niveau de l'ordre d'exécution des tâches, sachez que les scripts PowerShell sont exécutés avant les applications Win32.
• Sur les appareils partagés, le script PowerShell s'exécute pour chaque nouvel utilisateur qui se connecte.

Nous pouvons aussi rappeler l'importance d'éviter (autant que possible) de stocker des informations sensibles dans ces scripts, à commencer par des mots de passe.

À ce sujet, vous pouvez vous référer à la documentation officielle de Microsoft :

• Microsoft Learn - Intune - Script PowerShell

III. Déployer un script PowerShell avec Intune

A. Le script PowerShell

Le script PowerShell que l'on va déployer via Intune va effectuer les actions suivantes :

• Télécharger en local deux fichiers : une image de fond d'écran et une image d'écran de verrouillage. L'objectif étant de télécharger les fichiers à partir d'une URL Internet vers un répertoire local (C:\Windows\Web\Wallpaper\).

Voici le script PowerShell complet :

<#
.SYNOPSIS
        Définir une image de fond d'écran et une image d'écran de verrouillage via les clés de Registre Windows

.DESCRIPTION
        Sur Windows 10 Pro et Windows 11 Pro, il n'est pas possible de configurer une image de fond d'écran et/ou de verrouillage avec les paramètres natifs Intune.
        La solution de contournement consiste à utiliser des valeurs dans le Registre Windows, comme par GPO Active Directory.
        Les images sont téléchargées en local sur la machine dans "C:\Windows\Web\Wallpaper\"
        Indiquez les URL vers vos images en modifiant ces deux variables : $DesktopImageURL et $LockscreenImageURL.

.PARAMETER
.EXAMPLE  
.INPUTS
.OUTPUTS
	
.NOTES
	NAME:	Windows-Pro-Background-Lockscreen-Images.ps1
	AUTHOR:	Florian Burnel
	EMAIL:	[email protected]
	WWW:	www.it-connect.fr

	VERSION HISTORY:

	1.0 	2024.03.06
		    Initial Version

#>
# Fond ecran - URL en ligne et en local
$DesktopImageURL = "https://itconnectintunedemo.blob.core.windows.net/images/IT-Connect_Wallpaper_052020-V2.png"
$DesktopLocalImage = "C:\Windows\Web\Wallpaper\ITC_Wallpaper.png"

# Ecran verrouillage - URL en ligne et en local
$LockscreenImageURL = "https://itconnectintunedemo.blob.core.windows.net/images/IT-Connect_Wallpaper_052020-V2.png"
$LockscreenLocalImage = "C:\Windows\Web\Wallpaper\ITC_Lockscreen.png"

# Registre - Chemin vers la cle (qui doit accueillir les valeurs)
$RegKeyPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\PersonalizationCSP"

# Telecharger les images en local
if(!(Test-Path $DesktopLocalImage)){
    Start-BitsTransfer -Source $DesktopImageURL -Destination $DesktopLocalImage
}

if(!(Test-Path $LockscreenLocalImage)){
    Start-BitsTransfer -Source $LockscreenImageURL -Destination $LockscreenLocalImage
}

# Modifier les cles de Registre (seulement si l'on parvient a acceder aux images en local)
if((Test-Path $DesktopLocalImage) -and (Test-Path $LockscreenLocalImage)){

    # Creer la cle PersonalizationCSP si elle n'existe pas
    if (!(Test-Path $RegKeyPath))
    {
        New-Item -Path $RegKeyPath -Force | Out-Null
    }

    # Registre Windows - Configurer l'image de fond d'ecran (wallpaper)
    New-ItemProperty -Path $RegKeyPath -Name DesktopImageStatus -Value 0 -PropertyType DWORD -Force | Out-Null
    New-ItemProperty -Path $RegKeyPath -Name DesktopImagePath -Value $DesktopLocalImage -PropertyType String -Force | Out-Null
    New-ItemProperty -Path $RegKeyPath -Name DesktopImageUrl -Value $DesktopLocalImage -PropertyType String -Force | Out-Null

    # Registre Windows - Configurer l'image de l'ecran de verrouillage (lockscreen)
    New-ItemProperty -Path $RegKeyPath -Name LockScreenImageStatus -Value 0 -PropertyType DWORD -Force | Out-Null
    New-ItemProperty -Path $RegKeyPath -Name LockScreenImagePath -Value $LockscreenLocalImage -PropertyType String -Force | Out-Null
    New-ItemProperty -Path $RegKeyPath -Name LockScreenImageUrl -Value $LockscreenLocalImage -PropertyType String -Force | Out-Null

}

Adaptez les deux variables suivantes : $DesktopImageURL (URL vers l'image de fond d'écran) et $LockscreenImageURL (URL vers l'image de l'écran de verrouillage)

Vous pouvez réutiliser ce script et à l'adapter à vos besoins. Sachez que la procédure est identique, peu importe ce que fait votre script PowerShell.

Note : ce script reprend le principe de création de valeurs dans le Registre, comme nous pouvons le faire par GPO et comme je l'avais expliqué dans un précédent article.

• Windows Pro : configurer l'image de l'écran de verrouillage par GPO

B. Ajouter un script dans Intune

Connectez-vous au Centre d'administration Microsoft Intune, cliquez sur "Appareils" (1), puis sur "Scripts et corrections" (2). Ensuite, cliquez sur l'onglet "Scripts de plateforme" (3) afin de pouvoir cliquer sur le bouton "Ajouter" (4) et choisissez "Windows 10 et ultérieur" (5) puisque nous voulons exécuter un script PowerShell sur des machines Windows.

Donnez un nom à ce script, ou plutôt à cette tâche qui apparaîtra dans Intune. Je vous encourage également à indiquer une description. Poursuivez.

A l'étape "Paramètres du script", vous devez commencer par charger votre script sur Intune. En fait, vous devez charger un fichier présent sur votre ordinateur pour l'envoyer sur Microsoft Intune. Ensuite, nous avons plusieurs options à notre disposition :

• Exécuter ce script en utilisant les informations d'identification de l'utilisateur connecté : cette option doit être sur "Oui" pour que le script soit exécuté en héritant des droits de l'utilisateur qui se connecte. Choisissez "Non" pour exécuter une action qui nécessite des droits plus élevés : c'est le cas ici compte tenu de l'emplacement cible où l'image doit être téléchargée.
• Appliquer la vérification de la signature du script : cette option doit être sur "Non" sauf si vous avez un certificat de signature de code sur vos appareils et qu'il est utilisé pour signer vos scripts (ce qui est l'idéal !).
• Exécuter le script dans un hôte PowerShell 64 bits : cette option doit être sur "Oui" pour utiliser PowerShell 64 bits sur les machines 64 bits

À l'étape suivante, nommée "Affectations", vous devez affecter ce script PowerShell à des utilisateurs ou des appareils. Ici, mes machines Windows sont ciblées donc je sélectionne un groupe nommé "PC_Win_Pro" présent dans Microsoft Entra ID.

Poursuivez... A la fin, vérifiez l'ensemble des paramètres et si tout est OK, cliquez sur "Ajouter".

Voilà, votre script PowerShell va être exécuté sur les appareils / les utilisateurs ciblés.

IV. Tester le déploiement

Pour tester le déploiement, il convient de synchroniser un appareil pour qu'il actualise ses paramètres et "comprenne" qu'il doit exécuter un script PowerShell.

A. Microsoft Intune Management Extension

Pour que le script soit exécuté, nous avons besoin que Microsoft Intune Management Extension soit présent sur les appareils. Par défaut, ce n'est pas le cas : ce n'est pas un composant natif à Windows. Cependant, il va être installé automatiquement sur les appareils où le script PowerShell doit être exécuté.

Sur la machine "PC-ITC-01", présente dans le groupe "PC_Win_Pro", le composant s'est installé tout seul et dans la foulée, le script PowerShell a été exécuté. Le tout sans avoir besoin de redémarrer l'ordinateur.

B. Vérifier le bon fonctionnement du script

Pour vérifier le bon fonctionnement du script, nous pouvons investiguer sur la machine Windows. Ici, c'est facile : il suffit de vérifier si le fichier est bien présent à l'emplacement souhaité. Nous pouvons aussi regarder si les valeurs de Registre sont bien créées.

Du côté de la console Intune, si vous cliquez sur le script et que vous accédez à "État de l'appareil", vous pouvez obtenir un statut pour chaque machine impactée par la politique. C'est une façon de voir à distance s'il y a eu des soucis sur une ou plusieurs machines.

C. Les logs

S'il y a un souci avec l'exécution de votre script PowerShell, vous devez investiguer en local sur une machine. Sachez que les logs d'Intune Management Extension sont stockés dans ce répertoire :

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Dans ce répertoire, il y a un fichier de log très intéressant au sujet de l'activité d'Intune Management Extension : IntuneManagementExtension.log.

Il s'agit d'un fichier texte que l'on peut ouvrir avec un éditeur de texte classique (Bloc-notes, etc.). Toutefois, il est préférable d'utiliser l'outil gratuit CMTrace que les administrateurs de SCCM ont l'habitude d'utiliser.

Si besoin, vous pouvez l'obtenir en téléchargeant l'exécutable ci-dessous (un peu plus de 1 Go). Ensuite, l'exécutable va décompresser son contenu sur votre PC, ce qui vous permettra d'obtenir l'exécutable "CMTrace.exe". Il est présent ici :

• Télécharger CMTrace.exe (via le package Configuration Manager)

À partir de cet utilitaire, vous pouvez charger un fichier de log. C'est l'occasion d'ouvrir le fichier "IntuneManagementExtension.log" pour analyser son contenu. Ce fichier est très verbeux. Vous pouvez effectuer une recherche pour gagner du temps, avec le mot clé "PowerShell", par exemple.

Dans l'exemple ci-dessous (correspondants à d'autres tests effectués), nous pouvons voir qu'il y a eu un problème lors de l'exécution du script : un argument a une valeur invalide. Effectivement, il y a une erreur sur le nom d'une variable, ce qui renvoie une valeur nulle et perturbe l'exécution de la commande. Grâce à ce fichier de log et CMTrace, vous pouvez identifier plus facilement (et plus rapidement) l'origine du problème.

V. Conclusion

Après avoir suivi ce tutoriel, vous êtes en mesure d'exécuter des scripts PowerShell sur vos machines Windows à l'aide de Microsoft Intune ! Ce tutoriel sera également utile à toutes les personnes qui souhaitent configurer une image de fond d'écran et/ou de verrouillage sur les machines Windows 10 Pro et Windows 11 Pro.

Au sein de Microsoft Intune, PowerShell est également utile pour le déploiement d'applications et les fonctionnalités de remédiation. Nous aborderons ces points dans de futurs articles.

The post Intune – Comment exécuter un script PowerShell sur Windows ? first appeared on IT-Connect.