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
Qu'est-ce que SSPR ?
SSPR ou Self-service password reset est une fonctionnalité d'Azure Active Directory permettant aux utilisateurs de réinitialiser eux-même leur mot de passe.
Quels sont les avantages de SSPR ?
- Autonomie des utilisateurs pour réinitialiser leur mot de passe et par conséquent réduction du nombre de sollicitations des IT
- Les méthodes de récupérations proposées par SSPR sont connus et facile à prendre en main : question secrètes, vérification par SMS etc
- Les options de configuration de SSPR peuvent être aisément changées
- L'utilisation de SSPR est loguée et ces logs sont facilement accessible
Comment configurer SSPR ?
1. Rendez-vous dans portal.azure.com et connectez-vous avec un compte qui possède le rôle Global Administrator
2. Cliquez sur l'icone des triples barres horizontales pour afficher le menu du portail Azure puis cliquer sur Azure Active Directory
3. Dans le menu cliquez sur Password Reset
4. Vous arrivez directement dans l'onglet Properties, choisissez si vous voulez que SSPR soit activé pour l'ensemble des utilisateurs All ou pour un nombre restreint Selected
5. Cliquez sur Authentication methods et choisissez les paramètres voulus : méthodes de récupération disponible pour les utilisateurs, nombre de méthodes de récupération minimum nécessaire etc
6. Cliquez sur l'onglet Registration, vous pouvez forcer l'inscription des utilisateurs à SSPR lors de leur prochaine connexion au portail office. Vous devez également choisir au bout de combien de jours les utilisateurs doivent confirmer leurs informations de méthodes de récupération.
7. Vous avez d'autres options de configurations dans les onglets Notifications et Customization. L'onglet On-premises integration est quant à lui utilisé dans les environnements hybrides.
Quelle est l'expérience utilisateur lors de l'inscription à SSPR ?
1. Si vous n'avez pas obligé l'utilisateur à s'inscrire, vous devez lui fournir ce lien : aka.ms/ssprsetup sinon il aura l'image suivante à sa prochaine connexion
2. L'utilisateur devra ensuite confirmer son mot de passe actuel puis sera invité à s'inscrire à SSPR, les méthodes de récupération que vous avez choisi précédemment seront proposées à l'utilisateur. Il peut les configurer en cliquant sur set up now à coté de la méthode de récupération
3. Après avoir configuré le nombre minimum de méthodes de récupération, il peut alors cliquer sur looks good pour finir son inscription à SSPR
Comment l'utilisateur peut utiliser SSPR pour réinitialiser son mot de passe ?
1. L'utilisateur peut soit utiliser le lien suivant : aka.ms/sspr soit se rendre sur portal.office.com et cliquer sur Can't access your account?
2. Il lui sera alors demandé d'entrer l'UPN de son compte et de valider un captcha. Il pourra ensuite choisir parmi les méthodes de récupération qu'il a configuré pour réinitialiser son mot de passe
3. L'utilisateur sera alors invité à saisir un nouveau mot de passe
