Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

[Microsoft Graph] – Restreindre la portée de l’Application Permission Mail.Send

par | 2 Août 2024 |

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"

 

[Microsoft Graph] – Delegated permissions vs Application permissions

par | 2 Août 2024 | ,

 

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.

 

Intune : Désactiver le compte Administrateur local par défaut

par | 24 Juil 2024 | ,

Afin de désactiver le compte Administrateur local par défaut dans Windows, ceci peut être simple en utilisant un script de remédiation Intune.

Script de détection :

$user = (Get-WmiObject -Class Win32_UserAccount -Filter 'LocalAccount = True ' | Where-Object SID -Like 'S-1-5-*-500').Name
$Status= (Get-WmiObject -Class Win32_UserAccount -Filter 'LocalAccount = True ' | Where-Object SID -Like 'S-1-5-*-500').Disabled 
if ($Status -eq $false)
{
  Write-Host "$user is Enabled" 
  Exit 1
} 
Else {
  Write-Host "$user is not Enabled"
  Exit 0
}

Script de remédiation :

$user = (Get-WmiObject -Class Win32_UserAccount -Filter 'LocalAccount = True ' | Where-Object SID -Like 'S-1-5-*-500').Name
$Status= (Get-WmiObject -Class Win32_UserAccount -Filter 'LocalAccount = True ' | Where-Object SID -Like 'S-1-5-*-500').Disabled
if ($Status -eq $false)
{
try{

NET USER $user /active:No
Exit 0
}
Catch {
Write-Host "$user is already Disabled"
Write-error $_
Exit 1
}
}
Else {
Write-Host "$user is already Disabled"
Exit 1
}



Derniers articles

Catégories

Archives

Auteurs/Autrices