Powershell : comment modifier les messages de connexion sous Windows

Principaux points à retenir

• La personnalisation des messages de connexion dans Windows améliore la sécurité et l’expérience de l’utilisateur.
• Le script PowerShell fourni offre une méthode rapide pour mettre à jour les titres et les messages de connexion.
• Des privilèges d’administrateur sont requis en raison des modifications apportées au registre du système.
• Le script est compatible avec Windows 10 et Windows Server 2016.
• Bien que les objets de stratégie de groupe puissent effectuer des tâches similaires, ce script permet des ajustements plus rapides et plus souples.
• Une utilisation abusive, comme le partage d’informations sensibles par le biais de messages de connexion, peut constituer une menace pour la sécurité.
• Testez toujours le script dans un environnement de test (sandbox) avant de le déployer à grande échelle.
• Des plateformes comme NinjaOne facilitent encore davantage la gestion et le déploiement de ces scripts sur de vastes réseaux.

Face à l’évolution constante des besoins en matière de sécurité et d’amélioration de l’expérience des utilisateurs, les administrateurs informatiques sont à la recherche d’outils plus perfectionnés pour gérer efficacement les systèmes. La personnalisation des messages de connexion dans Windows est un domaine souvent négligé alors qu’il est pourtant essentiel. En effet, la possibilité modifier les messages de connexion dans Windows  permet de communiquer les informations nécessaires aux utilisateurs, de renforcer la sécurité et de personnaliser un peu plus un environnement d’entreprise.

Contexte

Aujourd’hui, notre discussion s’articule autour d’un script PowerShell conçu pour mettre à jour le message de connexion sur les systèmes Windows. Ce script, court mais puissant, souligne un mélange de sécurité et d’amélioration de l’expérience de l’utilisateur. En contrôlant le titre et le message que les utilisateurs voient lorsqu’ils se connectent, les professionnels de l’informatique et les fournisseurs de services gérés (MSP) peuvent relayer des mises à jour critiques, des avertissements ou simplement assurer la cohésion de la marque sur l’ensemble du parc de machines dont ils ont la charge.

Le script PowerShell

#Requires -Version 5.1

<#
.SYNOPSIS
    Changes the logon title and message.
.DESCRIPTION
    Changes the logon title and message.
.EXAMPLE
     -Title "My Title" -Message "My Logon Message"
    Set the title and message.
.EXAMPLE
    PS C:> Set-LogonMessage.ps1 -Title "My Title" -Message "My Logon Message"
    Set the title and message.
.OUTPUTS
    None
.NOTES
    Minimum OS Architecture Supported: Windows 10, Windows Server 2016
    Release Notes: Renamed script and added Script Variable support, updated Set-ItemProp
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).
.COMPONENT
    OSSecurity
#>

[CmdletBinding()]
param (
    [Parameter()]
    [String]$Title,
    [Parameter()]
    [String]$Message
)

begin {
    if ($env:title -and $env:title -notlike "null") {
        $Title = $env:title
    }

    if ($env:message -and $env:message -notlike "null") {
        $Message = $env:Message
    }
    function Test-IsElevated {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        $p = New-Object System.Security.Principal.WindowsPrincipal($id)
        if ($p.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator))
        { Write-Output $true }
        else
        { Write-Output $false }
    }
    function Set-ItemProp {
        param (
            $Path,
            $Name,
            $Value,
            [ValidateSet("DWord", "QWord", "String", "ExpandedString", "Binary", "MultiString", "Unknown")]
            $PropertyType = "DWord"
        )
        # Do not output errors and continue
        $ErrorActionPreference = [System.Management.Automation.ActionPreference]::SilentlyContinue
        if (-not $(Test-Path -Path $Path)) {
            # Check if path does not exist and create the path
            New-Item -Path $Path -Force | Out-Null
        }
        if ((Get-ItemProperty -Path $Path -Name $Name)) {
        # Update property and print out what it was changed from and changed to
            $CurrentValue = Get-ItemProperty -Path $Path -Name $Name
            try {
                Set-ItemProperty -Path $Path -Name $Name -Value $Value -Force -Confirm:$false -ErrorAction Stop | Out-Null
            }
            catch {
                Write-Error $_
            }
            Write-Host "$Path$Name changed from $CurrentValue to $(Get-ItemProperty -Path $Path -Name $Name)"
        }
        else {
            # Create property with value
            try {
                New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType $PropertyType -Force -Confirm:$false -ErrorAction Stop | Out-Null
            }
            catch {
                Write-Error $_
            }
            Write-Host "Set $Path$Name to $(Get-ItemProperty -Path $Path -Name $Name)"
        }
        $ErrorActionPreference = [System.Management.Automation.ActionPreference]::Continue
    }
}
process {
    if (-not (Test-IsElevated)) {
        Write-Error -Message "Access Denied. Please run with Administrator privileges."
        exit 1
    }
    try {
        Set-ItemProp -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" -Name "legalnoticecaption" -Value $Title -PropertyType String
        Set-ItemProp -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" -Name "legalnoticetext" -Value $Message -PropertyType String
    }
    catch {
        Write-Error $_
        exit 1
    }
}
end {
    
    
    
}

 

Description détaillée

Penchons-nous sur les mécanismes du script :

• Liaison et paramètres de la cmdlet : Le script est conçu comme une fonction PowerShell utilisant l’attribut CmdletBinding. Cela signifie que le script peut être utilisé comme une fonction réutilisable et qu’il peut accepter des paramètres, et notamment le titre et le message de l’invite de connexion.
• Contrôle administrateur : Deux fonctions intégrées sont utilisées, Test-IsElevated et Set-ItemProp. Le premier vérifie si le script est exécuté avec des privilèges d’administrateur, ce qui est vital puisque la modification des clés de registre (ce que fait le script) nécessite des autorisations élevées.
• Modifications du registre : La fonction Set-ItemProp modifie les valeurs de registre existantes ou en crée de nouvelles. Le script cible deux clés primaires, legalnoticecaption (pour le titre) et legalnoticetext (pour le message), qui régissent le message de connexion sous Windows.

Cas d’utilisation potentiels

Imaginez qu’un administrateur informatique d’une entreprise internationale veuille avertir tous les utilisateurs d’une maintenance serveur à venir. Plutôt que de s’en remettre à des courriels qui risquent d’être ignorés, il déploie ce script sur tous les postes de travail. Lorsque les employés se connectent le lendemain, ils sont accueillis par l’alerte, ce qui garantit une visibilité maximale.

Comparaisons

Bien que les objets de stratégie de groupe (GPO) puissent également être utilisés pour définir les messages de connexion, ce script offre une approche plus souple. Les GPO peuvent mettre du temps à se propager et ne pas être adaptés à des changements rapides. Le script PowerShell, quant à lui, peut être rapidement exécuté machine par machine ou déployé à grande échelle via un outil de gestion de système.

FAQ

• Ce script peut-il être exécuté sur n’importe quelle machine Windows ? 
  Il est conçu pour Windows 10 et Windows Server 2016 et ultérieur. Les versions antérieures peuvent ne pas prendre en charge les cmdlets concernés.
• Est-il nécessaire d’exécuter le script avec des droits d’administrateur ? 
  Oui, étant donné qu’il modifie le registre du système, des autorisations élevées sont nécessaires.

Implications

Si le script facilite la communication et l’image de marque, son utilisation abusive peut entraîner de la confusion, voire des problèmes de sécurité. Il est déconseillé de diffuser des informations sensibles dans un message de connexion. En outre, des changements fréquents peuvent désensibiliser les utilisateurs à ces messages, ce qui risque d’en diminuer l’impact.

Recommandations

• Veillez à la clarté et à la concision de vos messages de connexion.
• Testez le script dans un environnement contrôlé avant de le déployer à grande échelle.
• Conservez des sauvegardes régulières du registre de votre système.

Conclusion

L’utilisation d’outils tels que ce script ne représente qu’une fraction de la boîte à outils complète de la gestion informatique. Des plateformes comme NinjaOne décuplent ces efforts en fournissant un environnement intégré pour le déploiement, la gestion et la surveillance de scripts de ce type sur de vastes réseaux, garantissant ainsi la cohérence, la sécurité et l’amélioration de l’expérience de l’utilisateur.