Outlook & Exchange Online : restreindre ou autoriser la création de règles (OWA, Outlook, PowerShell)

Vous cherchez à empêcher certains utilisateurs de créer des règles dans Outlook tout en laissant d’autres le faire ? Voici une méthode claire et éprouvée pour encadrer la création de règles côté serveur (Exchange/OWA) et côté client (Outlook Windows/Mac), avec scripts PowerShell prêts à l’emploi et scénarios de déploiement.

Sommaire

Vue d’ensemble et objectifs

Les règles de messagerie servent à automatiser des actions (déplacer, transférer, classer, supprimer…). Elles existent sous deux formes :

Règles côté serveur (Inbox rules Exchange) : stockées et exécutées dans la boîte aux lettres Exchange. Elles s’appliquent même si Outlook est fermé, sur tous les appareils et clients (OWA, mobile, etc.).
Règles côté client (Outlook) : créées et exécutées par Outlook sur le poste de l’utilisateur. Elles ne se déclenchent que si Outlook est ouvert et peuvent dépendre du profil local (ex. déplacement vers un PST).

Objectifs couverts par cet article :

Empêcher certains utilisateurs de créer des règles dans OWA (Outlook sur le web) ;
Expliquer ce qui est (et n’est pas) possible pour bloquer la création de règles dans le client Outlook ;
Déployer ces contrôles de manière granulaire (par utilisateur, équipe ou groupe) ;
Surveiller et auditer les créations/modifications de règles.

Server vs client : les différences qui comptent

Aspect	Règles côté serveur (Exchange/OWA)	Règles côté client (Outlook Windows/Mac)
Lieu & exécution	Stockées et exécutées sur Exchange Online, 24/7.	Stockées localement (ou liées au profil) et exécutées quand Outlook est ouvert.
Création/gestion	OWA, Outlook, ECP/EAC, PowerShell (Get/Set/New/Remove-InboxRule).	Interface d’Outlook ; certaines actions non prises en charge côté serveur (ex. déplacer vers un PST, jouer un son…).
Contrôle admin	Oui : via les stratégies OWA (désactiver l’UI « Règles » dans OWA).	Non nativement : pas de verrouillage « bloquer la création » fourni par Microsoft.
Granularité	Par utilisateur/groupe via l’assignation de la stratégie OWA.	Mesures d’atténuation (GPO/OCPS, formation, supervision), mais pas de blocage strict.
Effet immédiat sur les règles existantes	Désactiver l’UI OWA n’efface ni n’arrête les règles existantes (elles continuent de s’exécuter).	Masquer l’UI n’empêche pas l’utilisateur motivé de créer/éditer via d’autres chemins s’ils existent.

Désactiver la création de règles côté serveur dans OWA

La méthode la plus fiable pour empêcher la création de nouvelles règles côté serveur consiste à désactiver la fonctionnalité « Règles » dans l’interface OWA via une stratégie OWA. Cela n’efface pas les règles existantes et n’empêche pas la création via le client Outlook, mais c’est le levier officiel et granulaire côté serveur.

Prérequis

Module Exchange Online PowerShell (EXO V3 recommandé).
Rôle d’administrateur Exchange suffisant pour gérer les stratégies OWA et les boîtes.

Étapes pas à pas

Connexion à Exchange Online Connect-ExchangeOnline
Créer une stratégie OWA dédiée (optionnel mais recommandé) New-OwaMailboxPolicy -Name "OWA-NoRules"
Désactiver l’UI « Règles » sur cette stratégie Set-OwaMailboxPolicy -Identity "OWA-NoRules" -RulesEnabled $false Pour réactiver plus tard : Set-OwaMailboxPolicy -Identity "OWA-NoRules" -RulesEnabled $true
Assigner la stratégie à un utilisateur Set-CASMailbox -Identity alice@contoso.com -OWAMailboxPolicy "OWA-NoRules"
Assigner en masse via un groupe (mail‑enabled security group, distribution list ou groupe Microsoft 365). Exemple : $policyName = "OWA-NoRules" $groupName = "GRP-Interdiction-Regles-OWA" # Récupérer les membres du groupe $members = Get-DistributionGroupMember -Identity $groupName -ResultSize Unlimited | ` Where-Object {$_.RecipientType -like "*UserMailbox*"} # Appliquer la stratégie à chaque membre foreach ($m in $members) { try { Set-CASMailbox -Identity $m.PrimarySmtpAddress -OWAMailboxPolicy $policyName -ErrorAction Stop Write-Host "OK - $($m.PrimarySmtpAddress)" } catch { Write-Warning "NOK - $($m.PrimarySmtpAddress) : $($_.Exception.Message)" } } Astuce : planifiez ce script en tâche récurrente (ex. quotidien) pour garder la stratégie synchronisée avec la composition du groupe.
Vérifier la configuration # Vérifier la valeur RulesEnabled sur la stratégie Get-OwaMailboxPolicy -Identity "OWA-NoRules" | fl Name,RulesEnabled # Vérifier la stratégie assignée sur un utilisateur Get-CASMailbox -Identity [alice@contoso.com](mailto:alice@contoso.com) | fl PrimarySmtpAddress,OWAMailboxPolicy

À savoir : Si aucune stratégie OWA spécifique n’est assignée, la boîte hérite de la stratégie par défaut (souvent DefaultOwaMailboxPolicy). Vous pouvez soit créer une stratégie « NoRules » pour les populations ciblées, soit modifier la stratégie par défaut si l’interdiction doit être globale.

Impact et limites

L’option -RulesEnabled $false masque et bloque la gestion des règles dans OWA uniquement.
Les règles côté serveur déjà en place continuent de s’exécuter.
Un utilisateur peut toujours tenter de créer/éditer des règles depuis Outlook (client lourd) : voir section suivante pour les mesures d’atténuation.

Gérer (et contenir) les règles côté client dans Outlook

Microsoft ne fournit pas aujourd’hui de paramètre natif « bloquer la création de règles Outlook » au niveau client. En pratique, vous combinerez plusieurs leviers pour réduire la surface d’attaque et l’usage inapproprié :

Mesures d’atténuation recommandées

Masquer les commandes « Règles » dans le ruban via GPO (domain-joined) ou Office Cloud Policy Service (locaux hybrides / devices non rejoints). Politique : Disable items in user interface / Customize Ribbon pour masquer le groupe « Règles » (onglet Accueil > Déplacer > Règles) et l’entrée « Gérer les règles et alertes » du menu Fichier.
Interdire les fichiers PST (souvent utilisés par des règles client) : GPO « PST settings » > Prevent users from adding new PSTs et Prevent users from adding PSTs to their profile.
Limiter l’auto‑transfert vers l’externe au niveau remote domain et/ou avec des règles de transport (ex. bloquer/contraindre la redirection automatique hors domaine, exception par liste blanche).
Former les utilisateurs : expliquer la différence serveur/client, les risques de fuites et le bon usage des règles.
Superviser : auditer la création, modification et suppression des règles et investiguer les redirections suspectes (ex. attaques par « inbox rule »).

Surveillance et audit

Deux niveaux utiles :

Audit unifié Microsoft 365 : rechercher les opérations liées aux règles (New-InboxRule, Set-InboxRule, Remove-InboxRule) pour identifier qui a créé/modifié quoi et quand. # Exemple de recherche sur 7 jours pour une boîte $u = "alice@contoso.com" $start = (Get-Date).AddDays(-7) $end = Get-Date Search-UnifiedAuditLog -StartDate $start -EndDate $end -UserIds $u ` -Operations New-InboxRule,Set-InboxRule,Remove-InboxRule | Select-Object CreationDate,UserIds,Operations,AuditData
Inventaire des règles côté serveur : lister tout ou partie des boîtes et vérifier les règles existantes. # Lister les règles d'une boîte Get-InboxRule -Mailbox "alice@contoso.com" | Select-Object Name,Enabled,Priority,From,SentTo,RedirectTo,ForwardTo,MoveToFolder # Désactiver ou supprimer une règle ciblée Disable-InboxRule -Identity "NomDeRegle" -Mailbox "[alice@contoso.com](mailto:alice@contoso.com)" Remove-InboxRule -Identity "NomDeRegle" -Mailbox "[alice@contoso.com](mailto:alice@contoso.com)"

Bon à savoir : Les règles « client-only » ne sont pas visibles avec Get-InboxRule si elles reposent sur des actions 100 % locales (ex. vers un PST). Concentrez l’audit sur les règles serveur et surveillez les signaux d’alerte (transferts automatiques, redirections, désactivation de règles, etc.).

Déploiement granulaire : par utilisateur, équipe ou groupe

Pour gérer finement l’activation/désactivation de la création de règles côté serveur, utilisez plusieurs stratégies OWA :

OWA-Standard : -RulesEnabled $true (aucune restriction OWA) ;
OWA-NoRules : -RulesEnabled $false (interdiction des règles dans OWA).

Ensuite :

Assignez OWA-NoRules aux populations sensibles (exécutifs, finances, RH, VIP, boîtes partagées critiques).
Assignez OWA-Standard au reste, ou laissez la stratégie par défaut.

Automatisation de l’assignation par groupes (ex. GRP-Interdiction-Regles-OWA) : voir le script plus haut. Vous pouvez aussi piloter via CSV si vous n’utilisez pas de groupes.

Application en masse via CSV

# users.csv avec une colonne UserPrincipalName
# Exemple de contenu :
# UserPrincipalName
# alice@contoso.com
# bob@contoso.com

$policyName = "OWA-NoRules"
$users = Import-Csv ".\users.csv"

foreach ($u in $users) {
Set-CASMailbox -Identity $u.UserPrincipalName -OWAMailboxPolicy $policyName
}

Rapport de conformité : qui a quelle stratégie et est‑ce conforme ?

# Cartographier la valeur RulesEnabled par stratégie
$policies = Get-OwaMailboxPolicy | Select-Object Name,RulesEnabled
$map = @{}
$policies | ForEach-Object { $map[$_.Name] = $_.RulesEnabled }

# Récupérer les boîtes et leur stratégie OWA

$result = @()
Get-ExoMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox,SharedMailbox | ForEach-Object {
$cas = Get-CASMailbox -Identity $*.PrimarySmtpAddress
$pName = $cas.OWAMailboxPolicy
$rulesEnabled = $null
if ($pName -and $map.ContainsKey($pName)) { $rulesEnabled = $map[$pName] }
$result += [pscustomobject]@{
User              = $*.PrimarySmtpAddress
OWAMailboxPolicy  = $pName
RulesEnabledInOWA = $rulesEnabled
}
}

$result | Sort-Object User | Export-Csv ".\rapport-owarules.csv" -NoTypeInformation
Write-Host "Rapport généré : .\rapport-owarules.csv"

Scénarios de déploiement conseillés

Scénario	Population	Stratégie	Commentaire
Standard	Majorité des collaborateurs	OWA-Standard	Laisser la flexibilité, tout en supervisant et en bloquant l’auto‑forward externe au transport.
Renforcé	VIP, finances, RH, boîtes partagées critiques	OWA-NoRules	Réduit le risque d’exfiltration par règles serveur ; compléter par GPO/OCPS côté client.
Gel temporaire	Toutes les boîtes	OWA-NoRules (temporaire)	Utile en réponse à incident (campagne de compromission via règles). Lever le gel après remédiation.

Ce que la stratégie OWA ne fait pas (et comment y répondre)

Elle n’arrête pas les règles existantes : utilisez Disable-InboxRule ou Remove-InboxRule pour les neutraliser/retirer si nécessaire.
Elle n’empêche pas Outlook de créer des règles : masquez l’UI (GPO/OCPS), limitez les PST, et bloquez l’auto‑forward externe côté transport.
Elle ne supprime pas les règles client-only : ces dernières ne sont pas visibles côté serveur si elles agissent localement (ex. vers PST).

Bonnes pratiques de sécurité autour des règles

Bloquez l’auto‑transfert externe par défaut, n’autorisez que des exceptions contrôlées.
Surveillez la création de nouvelles règles et les changements soudains (ex. règle qui marque tout comme lu, supprime ou redirige vers un externe).
Activez l’alerte SOC sur la « création de règles suspectes » et les en-têtes de suivi (surtout après réinitialisation MFA/mot de passe).
Appliquez le principe du moindre privilège : limiter l’accès aux boîtes partagées sensibles et contrôler l’usage des délégations.

FAQ

Pouvons‑nous bloquer la création de règles uniquement pour un sous‑ensemble d’utilisateurs ?

Oui pour OWA : créez plusieurs stratégies OWA (ex. OWA-Standard et OWA-NoRules) et assignez‑les par utilisateur/groupe via Set-CASMailbox. Pour Outlook (client), il n’existe pas de blocage natif ; vous appliquerez des mesures d’atténuation (GPO/OCPS, formation, supervision).

Comment revenir en arrière ?

Réactivez la gestion des règles dans OWA via :

Set-OwaMailboxPolicy -Identity "OWA-NoRules" -RulesEnabled $true

ou réassignez une stratégie qui a RulesEnabled $true.

Que deviennent les règles existantes si j’interdis la création dans OWA ?

Elles restent actives. Pour les désactiver ou supprimer :

Get-InboxRule -Mailbox "alice@contoso.com" | Disable-InboxRule
# OU suppression ciblée :
Remove-InboxRule -Identity "NomDeRegle" -Mailbox "alice@contoso.com"

Bloquer l’auto‑forward externe à l’échelle du tenant, c’est possible ?

Oui, en ajustant la configuration des domaines distants et/ou des règles de transport pour interdire la redirection automatique vers l’externe, avec des exceptions par liste blanche selon les besoins métier.

Checklist d’implémentation

Décider des populations (qui peut créer des règles côté serveur).
Créer deux stratégies OWA : OWA-Standard (RulesEnabled = True) et OWA-NoRules (RulesEnabled = False).
Assigner les stratégies aux boîtes ciblées (script par groupe/CSV).
Mettre en place GPO/OCPS pour masquer l’UI des règles dans Outlook lorsque nécessaire.
Bloquer l’auto‑forward externe par défaut et documenter les exceptions.
Activer l’audit et les alertes sur la création/modification de règles.
Former les utilisateurs et communiquer le changement.
Programmer des rapports récurrents (inventaire des règles et conformité des stratégies OWA).

Exemples rapides : commandes clés

Objectif	Commande
Connexion à Exchange Online	`Connect-ExchangeOnline`
Créer la stratégie OWA « NoRules »	`New-OwaMailboxPolicy -Name "OWA-NoRules"`
Désactiver les règles dans OWA	`Set-OwaMailboxPolicy -Identity "OWA-NoRules" -RulesEnabled $false`
Assigner la stratégie à un utilisateur	`Set-CASMailbox -Identity user@contoso.com -OWAMailboxPolicy "OWA-NoRules"`
Lister les règles d’une boîte	`Get-InboxRule -Mailbox user@contoso.com`
Désactiver une règle	`Disable-InboxRule -Identity "NomDeRegle" -Mailbox user@contoso.com`
Supprimer une règle	`Remove-InboxRule -Identity "NomDeRegle" -Mailbox user@contoso.com`

Conclusion

Pour encadrer efficacement la création de règles dans Outlook : appuyez‑vous sur les stratégies OWA pour maîtriser la création côté serveur au niveau le plus fin (par utilisateur/groupe), combinez‑les avec des mesures d’atténuation côté client (GPO/OCPS, interdiction PST), et mettez en place une surveillance continue (audit unifié + inventaires réguliers). Cette approche garantit un bon équilibre entre productivité et sécurité, sans immobiliser les usages légitimes.

Outlook & Exchange Online : restreindre ou autoriser la création de règles (OWA, Outlook, PowerShell)