Security filtering quésaco ?
Les GPO ou group policy management permettent de modifier le comportement des ordinateurs d'un parc Active Directory (AD), allant du simple changement d'écran à l'installation d'un logiciel.
Les GPO sont liés (link) à des Organizational Unit (OU) qui contiennent des objets utilisateurs et/ou ordinateurs.
Il existe des cas ou on souhaiterait appliquer une GPO à une population restreinte d'ordinateurs contenu dans une OU qui contient des ordinateurs qui ne doivent pas recevoir la GPO. C'est la que le filtre de sécurité (security filtering) entre en jeu, à travers l'appartenance à un groupe AD, on peut restreindre l'application d'une GPO aux membres du groupe.
Configurer une GPO pour faire du security filtering
Les étapes suivantes ne seront pas évoquées :
- Création d'une GPO
- Linker la GPO sur une OU
- Ajout d'un objet utilisateur/ordinateur dans un groupe de sécurité
Etape 1 : modifier les security filtering de la GPO dans l'onglet Scope
Voici la configuration par défaut du security filtering d'une nouvelle GPO :
Authenticated Users indique que la GPO s'appliquera à n'importe tout objet utilisateur et/ou ordinateur qui sont contenus dans les OU ou la GPO est linkés.
On va donc supprimer Authenticated Users et ajouter notre propre groupe de sécurité (Group-Security-Filtering-Test) dans lequel on aura placé un object utilisateur/ordinateur.
A noter que la GPO n'a pas besoin d'être linké sur l'OU qui contient le groupe, elle doit cependant être linkée à l'OU qui contient les utilisateurs/ordinateurs du groupe.
Etape 2 : modifier les security filtering de la GPO dans l'onglet Delegation
Il faut ensuite se rendre dans l'onglet Delegation et ajouter Authenticated Users (ou Utilisateurs Authentifiés), pour rappel Authenticated Users inclut les utilisateurs et les ordinateurs, inutile donc de chercher un groupe Authenticated Computers inexistant.
Il nous est ensuite demander quelle permission on souhaite donner au groupe Authenticated Users on choisit Read
Dans l'onglet Delegation on a indiqué à quelle population a le droit de lire la GPO, c'est la configuration effectuée dans l'onglet Scope qui détermine si la GPO doit s'appliquer ou non à l'utilisateur/ordinateur
Un peu de contexte
Dans certains environnements la connexion réseau vers Internet et notamment vers Azure peut présenter des défaillances.
Lorsque qu'un administrateur se connecte de façon interactive en PowerShell à Azure, un simple échec importe peu et une nouvelle tentative est souvent fructueuse, lorsque c'est une tâche automatisée qui est exécutée c'est une autre histoire, toutes les actions qui dépendent de cette connexion échouerons si la connexion vers Azure AD est un échec.
Le code
$i = 0 #Variable qui sera incrémentée à chaque nouvelle tentative de connexion à Azure
$ConnectAzureAD = "Fail" #Variable qui permet de sortir de la boucle si une tentative de connexion vers Azure AD est réussite
do #Do until permet d'exécuter un script en boucle tant qu'une condition n'est pas atteinte
{
try #Try catch permet de choisir comment les erreurs de cmdlet seront gérés, ici on s'en sert pour attendre avant la prochaine tentative de connexion et potentiellement faire du logging
{
$i++ #Permet d'incrémenter la variable $i
Connect-AzureAD #Cmdlet qui permet de se connecter à Azure AD, dans un script automatisé, les identifiants d'un compte de service seront utilisé à l'aide du paramètre -Credential $Credentials (objet PSCredential à créer)
$ConnectAzureAD = "Success" #La connexion à Azure AD est un succès puisque nous sommes dans le try, on peut donc modifier la variable $ConnectAzureAD pour pouvoir sortir de la boucle, code qui fonctionne de paire avec la condition dans le until
#Il est recommandé de consacrer une ligne pour faire du logging
}
catch
{
#A nouveau il est recommandé de consacrer une ligne pour faire du logging
Start-Sleep 10 #Permet de faire une pause de 10 secondes avant la nouvelle tentative de connexion
}
}
until ($ConnectAzureAD -eq "Success" -or $i -eq 6) #Si une connexion vers Azure AD est réussie ou si 6 tentatives infructueuses ont été observées, le script arrêtera d'essayer de se connecter à Azure AD
En résumé, le script tentera de se connecter à Azure AD en powershell jusqu'à ce qu'une connexion soit établie ou que 6 tentatives de connexions aient échouées.
Vous avez créé un accès conditionnel pour bloquer toutes les applications à l'exception de Teams mais Teams est toujours bloqué ?
Vous êtes au bon endroit, cet article vous explique tout ce qu'il y a à savoir sur les dépendances de Teams dans l'accès conditionnel Azure.
La configuration de l'accès conditionnel
Commençons par rappeler la configuration de l'accès conditionnel dont il est question:
Ci-dessous l'utilitaire qui permet de créer un accès conditionnel :
- Block access
- Cet accès conditionnel applique un refus de connexion (en opposition à grant/autoriser)
- All cloud apps included and 1 app excluded
- Cet accès conditionnel concerne toutes les applications Azure à l'exception d'une application
- Exclude
- Permet d'exclure des applications de l'accès conditionnel
- Microsoft Teams
- Teams est exclu de l'accès conditionnel
Les dépendances de Teams
Teams est dépendant d'autres applications Microsoft : SharePoint, Exchange, Planner, etc.
Ces applications doivent être également exclues dans l'accès conditionnel pour que Teams puisse fonctionner pleinement.
A noter qu'il existe deux types de dépendances :
- Des applications qui sont Early-bound policy enforcement
- Cela signifie que la vérification que l'application dont dépend Teams est présente dans l'accès conditionnel se fait avant la connexion de l'utilisateur. En d'autres termes si l'application n'est pas dans la liste d'exclusion de l'accès conditionnel l'utilisateur ne pourra pas se connecter.
- Des applications qui sont Late-bound policy enforcement
- En opposition au Early-bound policy enforcement, l'utilisateur pourra se connecter à Teams mais ne pourra pas bénéficier des services d'une application non exclue dans l'accès conditionnel
Voici un schéma récapitulatif :
- Les traits pleins sont des Early-bound policy enforcement
- Les traits en pointillés sont des Late-bound policy enforcement
Pour aller plus loin
Article officiel de Microsoft sur les dépendances de Teams dans l'accès conditionnel
Dans certains cas, on nous demande de déterminer quel type de client a été utilisé pour envoyer un mail particulier.
Pour ce faire, utiliser les journaux de suivi des messages dans Exchange 2010, Exchange 2013 ou Exchange 2016.
Dans les journaux de suivi des messages, il existe un champ SourceContext qui signale la propriété ClientType pour les événements SUBMIT. Les événements SUBMIT sont générés quand le service de soumission de transport de boîte aux lettres transmet un message au service de transport, c’est-à-dire lorsque le serveur Exchange récupère le courrier électronique de la boîte d’envoi de la boîte aux lettres et le transmet pour remise.
A noter qu'il n’y a pas d’événement SUBMIT lorsqu’un expéditeur externe envoie un e-mail à un utilisateur interne. Cela signifie qu’il n’y a pas de propriété ClientType pour ces e-mails.
- Pour vérifier le type de client pour un e-mail envoyé, exécuter la commande suivante dans un environnement Exchange powershell et regarder le champ SourceContext pour l’e-mail en question:
Get-MessageTrackingLog -ResultSize Unlimited -Start "10/20/2021 10:00" -EventID SUBMIT | fl TimeStamp,Sender,Recipients,MessageSubject,SourceContext
- La valeur du champ SourceContext peut être :
- AirSync--> il s’agit du client ActiveSync : le mail est envoyé depuis un périphérique mobile
- OWA--> il s’agit du client Webmail : le mail est envoyé depuis l’interface exchange web mail
- MOMT--> il s’agit des clients qui se connectent à l'aide d'Outlook ou toute autre application via RPC/HTTP ou MAPI/HTTP
Les e-mails de surveillance ont également un type de client qui est Monitoring