Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Comment utiliser PowerShell pour créer un événement dans un journal Windows ?

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".

PowerShell - New-EventLog

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 :

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.

PowerShell - Write-EventLog

À 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 :

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 :

PowerShell - EventLog - EventData

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

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.

Un script PowerShell surement codé par l’IA a été utilisé pour distribuer un malware infostealer

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 :

Source : Proofpoint

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.

[Windows] Fermer toutes les sessions RDP mal fermées

Il arrive qu'il y ait un grand nombre de sessions RDP sur un serveur Windows (environnement TSE/RDS ou non). Chaque connexion déconnectée continue de consommer des ressources comme CPU et RAM.

Voici comment fermer les sessions déconnecter en une ligne de commande PowerShell.

La ligne de commande avec "quser"

C'est grâce à quser que nous pouvons identifier les sessions déconnectées qui ne sont pas fermées :

quser | Where-Object { $_ -notmatch (Get-Date).ToString("dd/MM/yyyy") } | Select-String "Déco" | ForEach {logoff ($_.tostring() -split ' +')[2]}

Que fait cette commande ?

Cette commande ferme toutes les sessions déconnectées qui ne datent pas d'aujourd'hui. En effet je considère qu'une session déconnectées depuis plus d'un jour n'a rien à faire sur une serveur.

⚠ Cela peut engendrer une perte de données si vos utilisateurs ont un logiciel ouvert (comme Word) parce que la session sera fermée en mode forcé (les modifications non enregistrées seront perdues).

Il est vrai que sur Windows Server la traduction française ne permet à l'utilisateur de comprendre la différence entre :

  • Déconnecter
  • Se déconnecter

La première option laisse la session ouverte en arrière plan tandis que la seconde la ferme complètement. Microsoft aurait pu choisir "fermer la session" pour ce soit plus clair pour tout le monde.

Si vous êtes sur une machine Windows Server en langue anglais la ligne de commande ne fonctionnera pas.

Voici une version qui fonctionne en anglais et en français :

quser | Where-Object { ($_ -like '*Déco*' -or $_ -like '*Disc*') -and $_ -notmatch (Get-Date).ToString("dd/MM/yyyy") } | ForEach { logoff ($_.ToString() -split ' +')[2] }

La limite de cette ligne de commande est que le nom d'utilisateur ne devra jamais contenir "déco" ou "Disc" car c'est cet élément qui permet d'identifier une session déconnectée, sinon la session sera systématiquement fermée.

La bonne pratique : définir un délai maximum

Je vous conseille de définir une politique pour limiter la durée des sessions, qu'elles soient actives ou inactives. Vous pouvez le faire par GPO ou bien directement dans les propriétés de votre collection RDS.

Ainsi vous n'aurez même pas besoin d'utiliser cette astuce.

Pour créer une limite de connexion sur votre ferme RDS suivez ce tutoriel.

Conclusion

Si vous faites partie de ceux qui doivent fermer les sessions RDP d'un serveur sur lequel beaucoup de monde "oublie" de se déconnecter, cela devrait vous faire gagner du temps. Que l'on parle d'une ferme RDS, d'un serveur RDS avec ou sans CAL.

Si vous souhaitez que ce script fonctionne en automatique ne le faites pas via le planificateur de tâches, mais par GPO. Et cela ne vous empêche pas de faire une communication *avant* pour avertir les utilisateurs, be smart 🙂

 

 

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 10/04/2024 | 2 commentaires |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons

Cet article [Windows] Fermer toutes les sessions RDP mal fermées provient de : on Blogmotion.

Comment utiliser la méthode Trim de PowerShell pour nettoyer une chaîne de caractères ?

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 :

PowerShell - Supprimer espaces inutiles avec Trim

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 :

PowerShell - Supprimer les caractères inutiles avec Trim

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.

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

Intune – Comment exécuter un script PowerShell sur Windows ?

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.

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).

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 :

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 :

Bouton - Accéder à la ressource sur GitHub
<#
.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.

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.

Intune - Ajouter un script PowerShell - Scripts de plateforme 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.

Windows Pro - Script - Configurer fond d'écran et écran verrouillage

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
Intune - Exécuter un script PowerShell sur Windows

À 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.

Intune - Affecter un script PowerShell à des appareils

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

Intune - Ajouter d'un script PowerShell pour Windows 11

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.

Intune - Wallpaper Windows Pro - Registre

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 :

Intune Management Extension - CMTrace

À 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.

Intune - Logs - Exécution Script PowerShell

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.

CMTrace - Analyser log Intune - Script PowerShell

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.

An example of using PowerShell to manage system and user-assigned managed identities in Azure

Managed identities provide secure authentication for resources accessing other resources in Azure without requiring sensitive information such as secrets, credentials, and certificates to be handled. Microsoft Entra ID manages these identities, enabling applications to obtain tokens for authentication. In this post, I will provide an example that illustrates how to use system and user-assigned managed identities with PowerShell.

Connect an Azure Function or Web App to a Key Vault to retrieve secrets with PowerShell

Azure Functions often require access to sensitive information. It is a security risk to store credentials in code or configuration files. Thus, protecting sensitive information like connection strings, API keys, or passwords is crucial. This is where Azure Key Vault comes in, offering secure and centralized storage for all your secrets. In this article, I will explain how to retrieve secrets from the Key Vault within an Azure Function using PowerShell.

Azure REST API: Manage Azure resources with the PowerShell cmdlet Invoke-AzRestMethod

Sometimes, managing certain Azure resources using PowerShell can be challenging due to the absence of specific cmdlets for those operations or services. This is where the Invoke-AzRestMethod cmdlet comes into play, which allows PowerShell scripts to communicate with Azure services by sending HTTP requests to Azure's REST API. It acts as a bridge between PowerShell and Azure services that still need to be integrated with cmdlets.

Copying files between Windows and Linux with SCP and PowerShell

There are various mechanisms for copying files between Windows and Linux. A proven tool for this purpose is Secure Copy (SCP), and with the porting of PowerShell to Linux, it is suitable for this task, too. The connection runs over SSH in both cases, ensuring that files are transferred encrypted.

The post Copying files between Windows and Linux with SCP and PowerShell first appeared on 4sysops.
❌