Le script de remédiation Intune ci-dessous permettait de fixer le bug d'upgrade de Windows Pro à Enterprise via licence 365.

Script de détection / remédiation :

# Define the registry key path and value
$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MfaRequiredInClipRenew"
$registryValueName = "Verify Multifactor Authentication in ClipRenew"
$registryValueData = 0  # DWORD value of 0
$sid = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-4")  # Interactive group SID

# Check if the registry key already exists
if (-not (Test-Path -Path $registryPath)) {
    # If the key doesn't exist, create it and set the DWORD value
    New-Item -Path $registryPath -Force | Out-Null
    Set-ItemProperty -Path $registryPath -Name $registryValueName -Value $registryValueData -Type DWORD
    Write-Output "Registry key created and DWORD value added."
} else {
    Write-Output "Registry key already exists. No changes made."
}

# Add read permissions for SID (S-1-5-4, interactive users) to the registry key with inheritance
$acl = Get-Acl -Path $registryPath
$ruleSID = New-Object System.Security.AccessControl.RegistryAccessRule($sid, "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($ruleSID)
Set-Acl -Path $registryPath -AclObject $acl
Write-Output "Added 'Interactive' group and SID ($sid) with read permissions (with inheritance) to the registry key."

# Start the scheduled task
Get-ScheduledTask -TaskName 'LicenseAcquisition' | Start-ScheduledTask
Write-Output "Scheduled task 'LicenseAcquisition' started."

Lorsque l'on délègue la permission Mail.Send avec le type Application Permission, cela permet à l'application d'envoyer des mails avec n'importe quelle boite aux lettres du Tenant.

Nous allons ici voir comment restreindre cette portée à une ou plusieurs boites aux lettres.

Creation d'un mail enabled security group

 Nous allons dans un premier temps créer un 'Mail Enabled Security Group' depuis le portail Exchange Online ou via Powershell.

Donnons lui un nom et une description.

Assignons lui un propriétaire.

Ce dernier aura pour membre la ou les boites aux lettres depuis lesquelles nous autoriserons l'envoie de Mail.

Donnons lui une adresse de messagerie

Et enfin on valide.

La création de la Policy via une petite ligne Powershell

Via Powershell nous allons créer un Policy afin de restreindre l'envoie de mail à notre App pour le groupe créé précédement.

# Connect to Exchange Online
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline

# Create App Policy
New-ApplicationAccessPolicy -AccessRight RestrictAccess -AppId "0bb96e35-dced-4569-aaec-1531a17157ad" -PolicyScopeGroupId RestrictToSalesOnly@monadressesmail.com -Description "Restrict this app's access to members of security group RestrictToSalesOnly."

Vérification

Une petite ligne Powershell pour vérifier que la policy fonctionne.

Test-ApplicationAccessPolicy -Identity RandomUser@monadressmail.com -AppId "0bb96e35-dced-4569-aaec-1531a17157ad"

Donc ici on peut vérifier que cela ne fonctionne pas pour l'utilisateur random, mais si on essaie avec l'adresse autorisée

Test-ApplicationAccessPolicy -Identity SalesTeam@monadressmail.com -AppId "0bb96e35-dced-4569-aaec-1531a17157ad"

Les permissions Microsoft Graph.

Les permissions attribuées au sein d'un Tenant Microsoft 365 (types et étendues) peuvent avoir un impact sur ce dernier, il est donc important de bien identifier votre besoin pour les attribuer.

Lorsque l'on délègue des permissions Microsoft Graph à une App dans un Tenant, celle-ci peut se voir attribuer deux types "Delegated" ou "Application", nous allons tenter de voir la différence entre les deux.

Pour illustrer ces deux types nous allons nous référer à la présentation de Microsoft ci dessous.

Delegated Permissions

Permet à une application, d'agir en tant que l'utilisateur pour une action spécifique.

Ces permissions sont orientées pour des applications qui accèdent en tant que l'utilisateur identifié et, ne pourront excéder la porté de l'utilisateur.

Prenons par exemple l'App "Demo-DelegatedPerm" cette dernière possède le droit "Mail.Send".

Ce qui implique que lorsque l'utilisateur va vouloir utiliser cette application un consentement va lui être demandé.

A partir du moment ou l'utilisateur aura donné son consentement l'application sera autorisé a envoyer des mails en son nom.

Attention : Dans ce type de délégation l'approbation peut être donnée soit :

• Par l'utilisateur lorsqu'il utilise l'application.
• Par l'Administrateur pour tous les utilisateurs du Tenant lorsqu'il donne les permissions. 

Application Permissions

Permet à une application d'agir en tant qu'elle même, au lieu d'un utilisateur spécifique.

Ces permissions sont orientées pour des applications qui accèdent en tant qu'application elles mêmes et, auront une porté d'action sur l'ensemble du Tenant.

Prenons ici l'App "Demo-ApplicationPerm" cette dernière possède le droit "Mail.Send".

Ce qui implique que lorsque l'Administrateur va approuver les droits, cette application sera en mesure d'envoyer des mails depuis n'importe quelle boite aux lettres du tenant.

Qu'est ce que ça implique ?

En terme d'accès nous pouvons constater que l'un est beaucoup plus permissif que l'autre (encore que cela soit discutable si c'est l'administrateur qui a consenti) et, qu'il faut à minima restreindre la porté de l'accès.

En effet dans un contexte de moindre privilèges, l'attribution des droits via "Application Permissions" doit être contenu / restreint afin d'en limiter sa portée; ainsi nous pourrons nous prémunir d'une application avec une trop grande portée d'action sur l'environnement.