Si vous ne le savez pas encore, les règles d’accès conditionnels dans Azure AD permettent de contrôler les connexions de vos utilisateurs mais aussi des comptes ayant des droits d’administration sur votre environnement Office 365.
Grace à elles, vous allez pouvoir mettre en place des profils de connexion que vous allez autoriser ou pas, en fonction de différents paramètres qui peuvent être ,la localisation, le type de poste de travail, l’appartenance à un groupe Azure AD etc.. Elles constituent un outils très efficace mais dont la prise en main n’est pas forcément très simple.
Lorsque que vous vous lancerez dans leurs écritures, pensez bien à couvrir tout le périmètre de vos utilisateurs. Ainsi, si vous définissez une règle pour autoriser les connexions des postes utilisateurs partout dans le monde sauf la Chine, la Corée du nord et l’Iran , pensez bien à rédiger la règle de « deny » pour les postes qui se présenteraient depuis ces régions. Les règles d’accès conditionnels ne fonctionnent pas comme un firewall, autrement dit il n’y a pas de règle Deny ALL à la fin.
Autrement dit, lorsque vous écrirez une règle qui ciblera une partie de la population de vos utilisateurs, il faudra penser à écrire les autres règles pour les autres catégories de population. Plus vos critères de sélections seront élaborés et restrictifs , plus il faudra écrire de règles pour prendre en compte l’ensemble des utilisateurs.
L’objectif est au final de mettre en place des règles d’accès conditionnels sans oublier personne. ce n’est pas toujours si simple à faire. Un petit conseil, si vous pensez avoir tout bon, faite relire votre modèle à deux trois collègues histoire de s’assurer que vous n’avez laissé personne sur le bord de la route.
Mais revenons au sujet principal qui est de savoir si les règles d’accès conditionnels relèvent plus du mur de Berlin que de la ligne Maginot. Pour ceux qui ne connaisse pas la ligne Maginot , il s’agissait d’un mur réputé infranchissable par les armées du Reich , qui faisait la fierté de la France et qui devait nous protéger en cas d’invasion. Mur que les allemands, ont simplement contourné. Fin de l’histoire.
Quel rapport avec les règles d’accès conditionnels me direz vous ? j’y viens.
If you don’t know it yet, the conditional access rules in Azure AD allow you to control the connections of your users but also of the accounts with administrative rights on your Office 365 environment.
Thanks to them, you will be able to set up connection profiles that you will authorize or not, depending on various parameters such as location, type of workstation, membership in an Azure AD group, etc. They are a very effective tool but not necessarily very easy to use.
When you start writing them, remember to cover the entire scope of your users. For example, if you define a rule to authorize connections from user workstations anywhere in the world except China, North Korea and Iran, remember to write the « deny » rule for workstations that come from these regions. Conditional access rules do not work like a firewall, i.e. there is no deny ALL rule at the end.
In other words, when you write a rule that will target a part of your user population, you will have to remember to write other rules for the other population categories. The more elaborate and restrictive your selection criteria, the more rules you will have to write to take into account all the users.
The goal is to set up conditional access rules without forgetting anyone. It is not always that easy to do. A little advice, if you think you’ve got it right, have two or three colleagues review your model to make sure you haven’t left anyone out.
But let’s get back to the main topic, which is whether conditional access rules are more like the Berlin Wall than the Maginot Line. For those who do not know the Maginot Line, it was a wall considered impassable by the armies of the Reich, which was the pride of France and was to protect us in case of invasion. The Germans simply bypassed this wall. End of the story.
What does this have to do with the rules of conditional access?
Rôles Azure AD
Alors le premier rapport concerne les règles d’accès conditionnels que vous allez appliquer à la partie des utilisateurs qui possèdent des rôles d’administration dans Azure AD. Aussi étrange que cela paraisse, vous ne pourrez pas sélectionnez l’option « Tout les rôles » car cette option n’existe pas. Il faudra sélectionner un par un (soit 87 clicks) chaque rôle d’administration comme le montre la figure suivante
So the first report is about the conditional access rules that you are going to apply to the part of the users that have administrative roles in Azure AD. As strange as it sounds, you will not be able to select the « All roles » option because this option does not exist. You will have to select one by one (87 clicks) each administration role as shown in the following figure
Vous me direz, c’est ennuyeux, mais fondamentalement ça ne change pas grand chose. La, ce n’est plus tout a fait vrai car des rôles d’administration, Microsoft en créé et en supprime de temps en temps. Donc avec le temps, votre règle basée sur les rôles ne va plus être exhaustive. Il faudra penser régulièrement à la mettre à jour si vous voulez qu’elle s’applique à tous les rôles du tenant. Avouez qu’une option dynamique comprenant tout les rôles serait la bienvenue non ?
You will tell me, it is boring, but basically it doesn’t change much. Well, that’s not quite true anymore because Microsoft creates and deletes administrative roles from time to time. So with time, your rule based on roles will not be exhaustive anymore. You will have to think about updating it regularly if you want it to apply to all the roles of the tenant. Admit that a dynamic option including all the roles would be welcome, no?
Autres rôles
Une autre faille dans votre modèle que vous pourriez penser comme étant infaillible, concerne par exemple Intune. Dans Intune, les administrateurs Intune peuvent créer des rôles spécifiques d’administration Intune qui ne seront pas listés comme rôle Azure AD et qui par définition ne seront pas concernés par vos règles d’accès conditionnels. pour mieux comprendre prenons un exemple.
La société Maginot veut imposer le fait que toute personne ayant un ou plusieurs droits d’administration du tenant , si elle veut se connecter doit se connecter depuis la France. Pour ce faire elle doit créer une « NamedLocation » comprenant tous les pays sauf la France comme le montre la figure suivante et bannir l’accès depuis ces pays.
Another flaw in your model that you might think is foolproof, for example, is Intune. In Intune, Intune administrators can create specific Intune administration roles that will not be listed as Azure AD roles and that by definition will not be affected by your conditional access rules.The company Maginot wants to impose the fact that anyone with one or more administration rights to the tenant, if he wants to connect, must connect from France. To do this, it must create a « NamedLocation » including all countries except France as shown in the following figure and ban access from these countries.
Cet emplacement que nous nommerons « TousSaufFrance » sera utilisée pour bloquer les connexions des utilisateurs possédant un rôle d’administration et qui tenteraient de se connecter hors de France comme le montre la figure suivante
This location that we will name « TousSaufFrance » will be used to block the connections of users with an administration role who would try to connect outside France as shown in the following figure
La règle dans Azure AD est donc simple à faire mais comme nous l’avons précisé, elle devra être révisée régulièrement car l’option ‘n’importe quel rôle » n’existe pas dans l’interface de gestion. première faille. Seconde faille dans le modèle que vous pensiez infranchissable, si un administrateur Intune donne un Rôle Intune à un compte utilisateur alors ce dernier ne sera pas concerné par la règle d’accès conditionnels originelle. Démonstration
The rule in Azure AD is therefore simple to make but as we said, it will have to be revised regularly because the option « any role » does not exist in the management interface. Second flaw in the model that you thought was impenetrable, if an Intune administrator gives an Intune Role to a user account then the latter will not be affected by the original conditional access rule. Demonstration
Contournement de la règle d’accès conditionnels
Dans notre exemple il s’agit de cet utilisateur que nous avons appelé intune.adm et sur lequel nous avons affecté le rôle d’administration « Intune Administrator«
In our example it is this user that we have called intune.adm and on which we have assigned the administration role « Intune Administrator
Si vous affecter le rôle intune Administrator à ce compte et que vous essayer de vous connecter depuis la Finlande par exemple sur https://endpoint.microsoft.com/ alors la connexion est refusée grâce à la règle d’accès conditionnels que nous avons créé et qui est illustrée ci dessous
If you assign the intune Administrator role to this account and try to connect from Finland for example on https://endpoint.microsoft.com/ then the connection is denied thanks to the conditional access rule we created and which is illustrated below
on peut d’ailleurs le vérifier dans les journaux de connexion d’azure AD ou l’on voit que c’est bien la règle d’accès conditionnels qui a refusé la connexion.
You can check it in the connection logs of Azure AD where you can see that it is the conditional access rule that refused the connection.
Si un administrateur Intune veut contourner la règle d’accès conditionnels, il existe cependant un moyen.
Reprenons le cas de notre utilisateurs intune.adm. Nous allons lui ôter le droit Intune Administrator mais nous allons le positionner dans un groupe de sécurité GRP-IntuneADM (voir ci dessous) qui lui va avoir le droit Intune Rôle Administrator mais cette fois ci positionné directement dans l’environnement Intune comme ceci
If an Intune administrator wants to bypass the conditional access rule, however, there is a way.
Let’s take the case of our intune.adm user. We are going to remove the Intune Administrator right but we are going to position it in a GRP-IntuneADM security group (see below) which will have the Intune Administrator right but this time positioned directly in the Intune environment like this
et maintenant testons la connexion avec ce même utilisateur toujours depuis la Finlande sur l’url https://endpoint.microsoft.com/
and now let’s test the connection with this same user still from Finland on the url https://endpoint.microsoft.com/
Bingo ! l’utilisateur désormais, administrateur d’Intune se connecte depuis la Finlande en outrepassant la règle d’accès conditionnels car celles ci ne prennent pas en compte les droits spécifiques donnés dans Intune. La, votre modèle de sécurité s’effrite un petit peu non ?
Bingo! the user now, administrator of Intune connects from Finland by overriding the rule of conditional access because these do not take into account the specific rights given in Intune. Your security model is crumbling a little bit, isn’t it?
Les règles d’accès conditionnels définies par les équipes de sécurité d’une organisation ne sont donc pas infaillibles et peuvent être contournées par les administrateur d’Intune par exemple, ou par des utilisateurs qui auraient reçu des assignations de rôles mis en place récemment par Microsoft, et qui n’auraient pas été ajoutées manuellement par les équipes de sécurité dans les règles d’accès conditionnels. A quelques jours d’un audit de sécurité mieux vaut le savoir. J’avoue ne pas avoir encore réfléchi à la manière de contrecarrer ce mode de fonctionnement. Mais je vous promet de le faire 😉
Excellentes fêtes
The conditional access rules defined by the security teams of an organization are not infallible and can be bypassed by Intune administrators for example, or by users who have received role assignments recently implemented by Microsoft, and which have not been added manually by the security teams in the conditional access rules. A few days before a security audit, it’s better to know. I admit that I haven’t thought about how to counteract this mode of operation yet. But I promise to do so 😉
Travailler ensemble 
1 commentaire