PI Services

À moins que votre but ne soit d'essayer de causer une crise cardiaque à votre équipe sécurité et d'entre autres faciliter le travail des hackers, il est conseillé de conserver les mots de passe dans les scripts chiffrés.

La fonction de chiffrement

function New-EncryptedPasswordFile #Fonction qu'il faudra appeler pour générer un fichier txt qui contiendra le mot de passe chiffré
{
    [CmdletBinding()] #Déclaration des paramètres qu'il faudra fournir à la fonction pour qu'elle puisse s'exécuter
    Param
    (
        [Parameter(Mandatory=$true)] #Indique que ce paramètre est obligatoire
        [ValidateNotNullOrEmpty()] #Indique que ce champ ne peut pas être vide ou null
        [string]$User, #Paramètre qui attend le nom de l'utilisateur, il n'est utilisé que pour le nom du txt de sortie ainsi n'importe quelle valeur peut être renseigné

        [Parameter(Mandatory=$true)]
        [ValidateNotNullOrEmpty()]
        [securestring]$Password #Paramètre qui attend une secure string, 
    )

    Process
    {
        $EncryptedPasswordPath = $PSScriptRoot + "\" + $User + "_encrypted_password.txt" #Génére dynamiquement le chemin complet du txt qui contiendra le mot de passe chiffré
        $Password | ConvertFrom-SecureString | Out-File $EncryptedPasswordPath #Génére le txt qui contient le mot de passe chiffré
    }
}

Exemple d'utilisation de la fonction de chiffrement

Le script suivant appelle la fonction de chiffrement lorsque lui-même est appelé 

. .\New-EncryptedPasswordFile_article.ps1 #Permet de déclarer (dot source) la fonction de chiffrement pour qu'elle puisse être utilisée

New-EncryptedPasswordFile -User "Svc-test-01" #Appelle de la fonction de chiffrement et lui fournit volontairement uniquement le nom de l'utilisateur
#Le mot de passe sera demandé sous forme de secure string

Appel du script précédent

PS D:\A_folder> .\Call_me_maybe.ps1 #Appel du script précédent qui contient l'appelle de la fonction de chiffrement

cmdlet New-EncryptedPasswordFile at command pipeline position 1
Supply values for the following parameters: #La saisie du mot de passe sous forme de secure string est demandé
Password: ****

Le résultat

Le mot de passe contenu dans le fichier txt généré est chiffré

Remarque : lorsque le fichier est généré, une combinaison du compte utilisateur et du compte machine est utilisée. Cela implique que le mot de passe ne peut être déchiffré que par l'utilisateur qui l'a chiffré et sur la machine sur laquelle le chiffrement a eu lieu.

Si un jour vous souhaitez faire un état des lieux de ce qui est déjà en place en terme de partage, voici quelques liges de Powershell qui permettent de sortir la liste des OneDrive ayant un partage avec un invité.

Prenez soin de remplacer l'url de connexion au portail d'admin Sharepoint.

# Connect to Sharepoint Online
Connect-SPOService -Url https://MonTenant-admin.sharepoint.com/

# Collect all Sharepoint Sites and filter on OneDrive
$AllOneDrive = Get-SPOSite -IncludePersonalSite $true -Limit all -Filter "Url -like '-my.sharepoint.com/personal/'"

# Define variabes 
$ArrayOneDriveMembers = @()
$SortOneDrive = $AllOneDrive | sort Url

$SortOneDrive | foreach {
    $OneDriveUrl = $_.Url
    $OneDriveOwner = $_.Owner
    $OneDriveStorageQuota = $_."Storage Quota"
    $OneDriveTitle = $_.Title
    # Get the list of members for the current OneDrive
    Try {
        $OneDriveMembers = Get-SPOUser -Site $OneDriveUrl -ErrorAction stop
        }
    Catch {
        Write-Output "$OneDriveUrl;$OneDriveTitle" | Add-Content C:\temp\Onedriveerrors.txt
        }
    
    # Define a new variable
    $OneDriveExternal = $OneDriveMembers.where({$_.Usertype -eq "Guest"})

    # Check if the new variable is empty, if not collect logs
    If ($OneDriveExternal.count -ne 0) {
        
        # Display some informations
        Write-Host "External Users are present in $OneDriveTitle" -ForegroundColor Green
        $OneDriveExternal.count

        # Store Data
        $OneDriveExternal | foreach {
            $DisplayName = $_.DisplayName
            $LoginName = $_.LoginName
            
            $ArrayOneDriveMembers += New-Object psobject -Property @{
                OneDriveUrl = $OneDriveUrl
                OneDriveOwner = $OneDriveOwner
                OneDriveStorageQuota = $OneDriveStorageQuota
                OneDriveTitle = $OneDriveTitle
                DisplayName = $DisplayName
                LoginName = $LoginName
                }
            # Release Variables
            $DisplayName = $null
            $LoginName = $null
            }
        }
    
    # Release variables
    $OneDriveUrl = $null
    $OneDriveOwner = $null
    $OneDriveStorageQuota = $null
    $OneDriveTitle = $null
    $OneDriveMembers = $null
    }

$ArrayOneDriveMembers | Export-Csv c:\temp\ExternalOneDriveMembers.csv -Encoding UTF8 -Delimiter ";" -NoTypeInformation

Lorsque vous synchronisez vos utilisateurs via "Azure AD Connect", que vos utilisateurs sont dans différents pays et que vous utilisez l'audioconférence dans Teams, il semblerait logique que vos utilisateurs se voient attribuer un numéro "locale", plutôt qu'un numéro "Français".

Pour ce faire il est important de définir le lieu d'utilisation (Usage Location) dans Azure Active Directory, il est donc important de remplir l'attribut "Country" dans votre Active Directory OnPremise.

La construction est basé sur deux lettres, vous pourrez trouver la correspondance des pays et des lettres dans le lien ci-dessous:

Attention : Vous devrez utiliser les deux lettres en majuscule de la colonne "Language Culture Name"

https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee825488(v=cs.20)?redirectedfrom=MSDN

Vous pouvez fixer cet attribut à l'aide de Powershell via la commande ci-dessous (en prenant soin de remplacer "Mathieu" par le nom de votre utilisateur) :

Get-ADUser Mathieu | Set-ADUser -Replace @{‘Country’=”US”}

Ou alors en important un fichier csv pour une modification en masse, exemple de code ci-dessous.

# Import Csv and Set PreferredLanguage Attribute for each user
Import-csv C:\Temp\ToFixed.csv | foreach {
    $SamAccountName = $_.SamAccountName
    $Attribute = $_.Attribute
    Try {
        # Modifying PreferredLanguage Attribute
        Set-ADUser -Identity $SamAccountName -Replace @{‘Country’=$Attribute} -ErrorAction Stop 
        }
    Catch {
        $SamAccountName | Add-Content C:\temp\ErrorUsageLocation.txt
        }
    # Release
    $SamAccountName = $null
    $Attribute = $null
    }

Lorsque vous synchronisez vos utilisateurs via "Azure Ad Connect" et, que vous avez des utilisateurs dans différents pays, la langue par défaut pour chacun des utilisateurs dépend d'un attribut de votre Active Directory OnPremise, cet attribut est le "preferredLanguage".

Il devra être construit en suivant la nomenclature "Language Culture Name" du lien ci-dessous :

https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee825488(v=cs.20)?redirectedfrom=MSDN

Vous pouvez fixer cet attribut à l'aide de Powershell via la commande ci-dessous (en prenant soin de remplacer "Mathieu" par le nom de votre utilisateur) :

Get-ADUser Mathieu | Set-ADUser -Replace @{‘preferredLanguage’=”en-US”}

Ou alors en important un fichier csv pour une modification en masse, exemple de code ci-dessous.

# Import Csv and Set PreferredLanguage Attribute for each user
Import-csv C:\Temp\ToFixed.csv | foreach {
    $SamAccountName = $_.SamAccountName
    $Attribute = $_.Attribute
    Try {
        # Modifying PreferredLanguage Attribute
        Set-ADUser -Identity $SamAccountName -Replace @{‘preferredLanguage’=$Attribute} -ErrorAction Stop 
        }
    Catch {
        $SamAccountName | Add-Content C:\temp\ErrorPreferredLanguage.txt
        }
    # Release
    $SamAccountName = $null
    $Attribute = $null
    }

La génération de mots de passe dans un script est un besoin fréquent lors de création de compte utilisateur. Au lieu d'appeler les cmdlets pour générer un mot de passe aléatoire à chaque besoin, il est plus esthétique de créer une fonction de génération de mots de passe dédiée et de l'utiliser quand le besoin se présente.

Le code suivant propose une fonction de génération de mots de passe qui essaye d'être simple, compréhensible et adaptative.

La fonction de génération de mots de passe

function New-RandomPassword #Fonction qu'il faudra appeler pour générer un mot de passe aléatoire
{
    [CmdletBinding()]
    Param
    (
        [Parameter(Mandatory=$false)] #Indique que ce paramètre n'est pas obligatoire
        [ValidateNotNullOrEmpty()] #Indique que ce champ ne peut pas être vide ou null
        [int]$PasswordLength = 16, #Paramètre optionel qui spécifie la longueur du mot de passe, valeur par défaut 16

        [Parameter(Mandatory=$false)]
        [ValidateNotNullOrEmpty()]
        [int]$NumberOfAlphaNumericCharacters = 2, #Paramètre optionnel qui spécifie le nombre de caractères alphanumériques que le mot de passe doit contenir, valeur par défaut 2

        [Parameter(Mandatory=$false)]
        [ValidateNotNullOrEmpty()]
        [switch]$ConvertToSecureString #Paramètre qui si présent convertit le mot de passe en secure string pour pouvoir construire un PSCredential Object utile par exemple pour exécuter des cmdlets avec un compte de service 
    )

    Begin
    {
        Add-Type -AssemblyName 'System.Web' # Ajout d'une classe .NET à la session PowerShell qui permet d'accéder aux fonctions nécessaires à la génération du mot de passe
        
        $Return = @{} #Tableau de retour qui contient le mot de passe en clair et le mot de passe sous forme de secure string 
    }

    Process
    {
        $Password = [System.Web.Security.Membership]::GeneratePassword($PasswordLength,$NumberOfAlphaNumericCharacters) #Génération du mot de passe en clair avec les paramètres fournis
        $Return.passwordObject = $Password #Attribution du mot de passe généré dans la variable de sortie de la fonction

        if ($ConvertToSecureString.IsPresent) #Si le paramètre ConvertToSecureString est présent, génère une secure string du mot de passe
        {
            $Password = ConvertTo-SecureString -String $Password -AsPlainText -Force #Génération de la secure string du mot de passe
            $Return.passwordSecureObject = $Password #Attribution de la secure string du mot de passe dans la variable de sortie de la fonction
        }

        Return $Return #Retourne le mot de passe ainsi que la secure string en sortie de la fonction
    }
}

Exemple d'utilisation de la fonction de génération de mots de passe

. .\New-RandomPassword_article.ps1 #Permet de déclarer (dot source) la fonction de génération de mots de passe pour qu'elle puisse être utilisée

$Password = New-RandomPassword -PasswordLength 20 -ConvertToSecureString #Appelle de la fonction de génération de mots de passe
#Avec génération d'une secure string du mot de passe et une longueur de mot de passe de 20 caractères

$Password.passwordObject #Le mot de passe en clair est dans l'attribut passwordObject de la variable de sortie définit ci-avant $Password
$Password.passwordSecureObject #Le mot de passe sous forme de secure string est dans l'attribut passwordSecureObject de la variable de sortie définit ci-avant $Password

Le résultat

Appel du script PowerShell Call_me_maybe.ps1 ci-avant

PS D:\Hey_Im_a_folder> .\Call_me_maybe.ps1
LmcfY>5O$-GZ^z/fvfB1 #Affichage du mot de passe en clair
System.Security.SecureString #Mot de passe sous forme de secure string

SSPR et MFA

Face aux nombreuses attaques informatique ces dernières années, les entreprises répondent en renforçant la sécurité de leur système d'information (SI).

SSPR (Self-Service Password Reset) et MFA (Multi-factor authentication) y contribuent.

SSPR permet à un utilisateur de réinitialiser son mot de passe dans Azure de façon autonome via des méthodes de récupération qu'il aura configuré préalablement, SMS, appel téléphonique, questions secrètes..

MFA demande à un utilisateur un deuxième moyen de prouver son identité, c'est par exemple parfois le cas suite à un achat en ligne, un code à usage unique (OTP) pour valider la transaction est envoyé par SMS à un téléphone dont le numéro a été communiqué au fournisseur de service en amont. D'autres méthodes existent tel que l'application Microsoft Authenticator ou l'appel d'un numéro de téléphone.

On observe donc que certaines méthodes d'authentification sont communes entre SSPR et MFA, les utilisateurs seront donc invités à renseigner plusieurs fois les mêmes informations ce qui détériore leurs expériences et par conséquent amoindris leurs adhésions à ces outils.

Combiner les informations de sécurité SSPR et MFA

Il existe dans Azure un paramètre qui permet de combiner les informations de sécurité SSPR et MFA.
Se connecter avec un compte administrateur global à portal.azure.com > User settings > Manage user feature settings

Choisir ensuite All dans User can use the combined security information registration experience

Selected permet d'activer ce paramètre pour des utilisateurs nominatif

Pour aller plus loin

Documentation officielle Microsoft sur la combinaison des informations de sécurité SSPR et MFA

Oh, la belle bleue (même si elle est verte) !

Modifier les paramètres Internet Explorer (IE) via GPO permet de simplifier grandement le déploiement d'un paramètre spécifique IE, si tenté que la GPO soit intuitive à configurer..

Rappelons dans un premier temps comment accèder aux settings IE, une fois la GPO ouverte pour modification : User Configuration > Preferences > Control Panel Settings > Internet Settings > New

La même fenêtre des options IE que sur une machine local s'affiche avec la particularité d'avoir des paramètres soulignés en vert d'un trait plein et d'autre souligné en rouge d'un trait en pointillé.

Signification et modification

Les codes couleurs fonctionnent comme ceci :

• Les traits verts correspondent aux paramètres qui sont activés et s'appliqueront sur les machines
• Les traits rouges correspondent aux paramètres non désactivés et qui ne s'appliqueront pas sur les machines

Comment faire pour basculer un paramètre activé à désactivé puisque les raccourcis habituels ne semblent pas fonctionner ?

C'est grâce aux touches F5, F6, F7 et F8 qu'il est possible de changer le statut d'un paramètre :

• F5 : active tous les paramètres de l'onglet
• F6 : active uniquement le paramètre qui a été modifié en dernier
• F7 : désactive uniquement le paramètre qui a été modifié en dernier
• F8 : désactive tous les paramètres de l'onglet

À l'image du chien qui est le meilleur ami de l'homme, le fichier de log est le meilleur ami de l'informaticien qui débug.

Générer des logs lorsqu'un code PowerShell s'exécute permet de savoir si une fonction a été correctement exécutée et si ce n'est pas le cas de savoir précisément à quel endroit un problème est survenu, ce qui va sans dire est d'une aide considérable lors d'un débug.

La fonction de log

function Get-CurrentLineNumber #Fonction qui permet de récupérer la ligne actuelle dans un script, elle sera utilisée par le script qui appelle la fonction de log
{ 
    Return $MyInvocation.ScriptLineNumber
}


function Write-Log #Fonction qu'il faudra appeler lorsque l'on voudra faire du logging
{
    [CmdletBinding()] #Déclaration des paramètres qu'il faudra fournir à la fonction pour qu'elle puisse s'exécuter
    param
    (
        [Parameter(Mandatory=$true)] #Indique que ce paramètre est obligatoire
        [ValidateNotNullOrEmpty()] #Indique que ce champ ne peut pas être vide ou null
        [string]$LogFile, #Paramètre qui contient le chemin complet du script qui appelle la fonction de log

        [Parameter(Mandatory=$true)]
        [ValidateNotNullOrEmpty()]
        [string]$LogLine, #Paramètre qui contient la ligne à laquelle la fonction de log est appelée

        [Parameter(Mandatory=$true)]
        [ValidateNotNullOrEmpty()]
        [string]$LogMessage, #Paramètre qui contient le log 

        [Parameter(Mandatory=$false)]
        [ValidateNotNullOrEmpty()]
        [string]$LogPath, #Paramètre qui contient le chemin complet du fichier de log
 
        [Parameter(Mandatory=$true)]
        [ValidateNotNullOrEmpty()]
        [ValidateSet('Information','Warning','Error')] #Valeurs disponibles pour qualifier le log
        [string]$LogSeverity #Paramètre qui va quantifier la nature du log parmi les valeurs disponibles
    )

    Begin
    {
        if (!$LogPath) #Code qui permet de générer un dossier de log ainsi que le fichier de log de façon dynamique si le paramètre LogPath est vide
        {
            $CurrentDateFormatForLog = Get-Date -Format "yyyy-MM-dd_HH" #Recupère la date du jour pour la mettre à la fin du nom de fichier de log
            $LogFolderName = "Logs" #Nom du fichier de log
            $LogFolderPath = $PSScriptRoot + "\" + $LogFolderName #Détermine dynamiquement la localisation du dossier de log qui doit se trouver dans le même dossier que le script PowerShell qui appelle la fonction de log
            
            if (!(Test-Path -Path $LogFolderPath))#Vérifie l'existence d'un dossier de log dans le même dossier que le script qui appelle la fonction de log
            {
                New-Item -ItemType Directory -Path $LogFolderPath | Out-Null #Si le dossier de log n'existe pas, le créé
            }
            
            $LogPath = $LogFolderPath + "\" + "Log_" + $CurrentDateFormatForLog + ".csv" #Détermine le nom du chemin complet du fichier de log
        }
    }
    
    Process
    {
        [pscustomobject]@{ #Génére un objet PowerShell dont chaque ligne représente une colonne du fichier de log
            Date = Get-Date -Format "yyyy-MM-dd HH:mm:ss" #Première colonne qui contient la date à laquelle la fonction de log s'est exécuté
            Severity = $LogSeverity #Deuxième colonne qui contient la nature du log
            File = $LogFile #Troisième colonne qui contient le nom du script PowerShell qui appelle la fonction de log
            Line = $LogLine #Quatrième colonne qui contient la ligne à laquelle la fonction de log a été appelée
            Message = $LogMessage #Cinquième colonne qui contient le log
            
        } | Export-Csv -Path $LogPath -Append -NoTypeInformation -Delimiter ";" -Encoding UTF8 #Code qui permet de transformer l'objet PowerShell en fichier de log (csv)
    }
}

Exemple d'utilisation de la fonction de log

. .\Write-Log_article.ps1 #Permet de déclarer (dot source) la fonction de log pour qu'elle puisse être utilisée

try #Appelle de la fonction de log pour indique l'utilisateur a bien été trouvé 
{
    $User = Get-ADUser -Identity "maybe" #Cherche un utilisateur dont le samAccountName est maybe
    Write-Log -LogSeverity "Information" -LogMessage "L'utilisateur a bien été récupéré" -LogFile $PSCommandPath -LogLine $(Get-CurrentLineNumber)
    #$PSCommandPath permet de trouver le chemin complet du script qui est en train de s'exécuter
    #Get-CurrentLineNumber fonction déclarée dans le script de log qui permet de récupérer la ligne courante du script qui appelle la fonction de log
}

catch #Appelle la fonction de log si l'utilisateur n'a pas été trouvé et envoie en tant que message de log l'erreur généré par la cmdlet Get-ADUser
{
    Write-Log -LogSeverity "Error" -LogMessage $_.Exception.Message -LogFile $PSCommandPath -LogLine $(Get-CurrentLineNumber) 
}

Le résultat

Une fois le script PowerShell Call_me_maybe.ps1 appelé, le dossier de log est généré

Le fichier de log est généré

Le log est généré

Scenario:

L'utilisateur avait Office 2016 32 bits installé et souhaite faire une mise à niveau vers le client M365 v2008 (semi-annual channel).

Problème:

Lors de la mise à niveau, l'erreur 0x80077562 (-2146994846) s'affiche dans le centre logiciel MECM --> Tous les produits office ont cessé de fonctionner et Office 2016 n'a pas été supprimé des programmes.

Lorsque vous essayez de désinstaller manuellement l'ancienne version d'Office 2016, cette erreur s'affiche :

"La langue de ce package d'installation n'est pas prise en charge par le système"

Explication:

Cette erreur est parfois causée par l'échec des précédentes tentatives d'installation/désinstallation du produit Office.

Solution:

1. Réinstallez Office 2016 32 bits à l'aide des sources d'installation d'Office

2. Réessayez l'installation d'Office 365 à partir du centre logiciel

Le rôle NPS (Network Policy Server) reste le seul moyen natif d’utiliser un serveur Windows pour réaliser des authentifications RADIUS, ce qui est très utile notamment pour gérer l’authentification à des appliances réseau, des bornes Wifi ou même des utilisations plus avancées comme de l’authentification par certificat avec AlwaysOn VPN.

Bien qu’il n’ait pas évolué depuis plusieurs versions de Windows et que sa partie NAP (Network Access Protection) soit dépréciée depuis Windows 2012 R2, il reste parfaitement fonctionnel pour son rôle de serveur RADIUS.

J’ai donc récemment déployé un serveur NPS sous Windows 2019 sur un serveur flambant neuf, configuré mon client Radius (une appliance NTP) ainsi qu’une stratégie d’authentification basique pour pouvoir utiliser des identifiants de l’AD pour me connecter à l’appliance.

Malheureusement, le premier essai de connexion fut un échec. Pas d’affolement, les stratégies NPS sont souvent assez obscures et il est vite arrivé de manquer un paramètre, me dis-je… mais pas cette fois.

J’active donc les logs d’audit de connexion, ils permettent souvent d’en apprendre plus sur les raisons de l’échec. Sauf que cette fois, ils sont intégralement vides : non seulement il n’y a pas d’erreur, mais il n’y a en réalité pas le moindre évènement, comme si la requête RADIUS n’arrivait jamais au serveur.

Les règles de firewall Windows créée automatiquement lors de l’installation du rôle NPS (groupe Network Policy Server) sont pourtant bien présentes et actives, et l’administrateur réseau me confirme que les paquets arrivent bien jusqu’au serveur.

Il est donc temps de sortir Wireshark : effectivement, les paquets RADIUS arrivent bien au serveur mais ensuite rien, aucune réaction; encore une fois comme si la requête n’arrivait jamais au rôle NPS…

Après bien des tentatives infructueuses, j’essaye en désespoir de cause de désactiver le firewall Windows; et miracle, tout tombe en marche.

Le problème se situe donc au niveau du firewall. Après quelques recherches, il apparaît que les règles natives sont configurées pour ne fonctionner que pour le service IAS, ce qui est normal. Par contre, dans Windows 2019, ce service utilise un identifiant de sécurité (service SID) qui l’empêche d’être la cible d’une règle de firewall… et donc la règle ne fonctionne pas et les flux sont bloqués.

Deux solutions s’offrent donc à nous :

• Reconfigurer le service pour retirer cette restriction à l’aide de la commande sc.exe sidtype IAS unrestricted
• Reconfigurer les règles de firewall pour qu’elles fonctionnent avec n’importe quel service :  Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any

Après avoir exécuté une de ces deux solutions, tout devrait rentrer dans l’ordre !