Politique d’accès Conditionnels automatique, Microsoft . Quelques questions à Microsoft

English version below

Comme vous le savez ou pas, Microsoft va activer en votre nom des stratégies d’accès conditionnels sur votre Tenant, ceci afin de « protéger tous les accès des utilisateurs aux portails d’administration tels que https://portal.azure.com, le centre d’administration Microsoft 365 et le centre d’administration Exchange.« 

Si vous n’avez pas pris connaissance de cette information je vous invite à relire l’article suivant

Les politiques d’accès conditionnel automatique de Microsoft Entra rationalisent la protection de l’identité

Cette activation devrait se dérouler dans peu de temps et « une fois que les politiques seront visibles dans votre tenant, vous aurez 90 jours pour les examiner et les personnaliser (ou les désactiver) avant que Microsoft les activent. »

Si l’initiative sécuritaire de Microsoft est à saluer, quelques questions se posent néanmoins

Tenants et identités fédérées

Dans certains cas , les comptes d’administration (comptes qui possèdent des rôles dans Entra ID) sont des comptes synchronisés depuis l’Onpremise et appartiennent à un domaine fédéré dont l’authentification et le MFA n’est donc pas géré par Entra ID. Ces comptes d’administration apparaissent donc dans le tenant comme compte d’admin avec le MFA Microsoft non activé.

Malgré cela, ces comptes possèdent bien la fonction MFA mais elle reste gérée par une solution tierce comme Ping Federate ou OKTA.

Devons nous nous attendre à ce que ces comptes soient impactés par la première action que Microsoft va déclencher, à savoir la mise en place du MFA pour tout les comptes possédant des rôle d’administration du Tenant ?

Au quel cas, deux MFA sur un seul compte …. cela risque de poser quelques soucis.

Compte Break the glass

Rien de plus banal qu’un compte Break The glass, c’est un compte parmi tant d’autre , non synchronisé depuis l’onPremise qui dispose du rôle Global Admin sur le tenant en question et qui ne doit pas posséder de MFA. Ce compte dispose d’un mot de passe très complexe, généralement stocké au coffre et ne doit être utilisé qu’en cas d’urgence.

Comment le processus d’activation automatique de Microsoft va t’il faire la différence entre un compte Break the Glass qui ne doit pas être impacté par la mesure sécuritaire et un compte d’administration Global Admin standard. Dans Entra ID rien de permet de marquer un compte comme étant un compte break the Glass.

Cela signifie t’il que les comptes Break the glass vont être touchés par l’activation du MFA ?

Tenant avec l’accès conditionnel activé

Certaines entreprises ont développée des stratégies d’accès conditionnels très élaborées, dont le modèle en place fait l’objet d’homologation et de suivis réguliers par les équipes en charge de la sécurité. La venue de règles d’accès conditionnels additionnelles à de grande chance de perturber la cohérence des règles en place.

Que se passera t’il si les clients refusent (suppriment) ces règles, « Imposées/ proposées » par Microsoft ?

************************************************************

As you may or may not be aware, Microsoft will be enabling conditional access policies on your Tenant on your behalf, this in order to « protect all user access to administration portals such as https://portal.azure.com, the Microsoft 365 Administration Center and the Exchange Administration Center. »

If you haven’t taken note of this information, I invite you to reread the following article

Les politiques d’accès conditionnel automatique de Microsoft Entra rationalisent la protection de l’identité

This activation should take place shortly, and « once the policies are visible in your tenant, you’ll have 90 days to review and customize (or disable) them before Microsoft activates them. »

While Microsoft’s security initiative is to be applauded, a few questions remain.

Tenants and federated identities

In some cases, administration accounts (accounts with roles in Entra ID) are accounts synchronized from Onpremise and belong to a federated domain whose authentication and MFA is not managed by Entra ID. These administration accounts therefore appear as admin accounts with the Microsoft MFA not activated.

Despite this, these accounts do have the MFA function, but it remains managed by a third-party solution such as Ping Federate or OKTA.

Should we expect these accounts to be impacted by the first action Microsoft triggers, i.e. the implementation of MFA for all accounts with Tenant administration roles?

In which case, two MFAs on a single …. account could cause a few problems.

Break the glass account

There’s nothing more banal than a Break the glass account. It’s one of many accounts not synchronized from the onPremise that has the Global Admin role on the tenant in question, and which must not have an MFA. This account has a very complex password, usually stored in the safe, and should only be used in an emergency.

How will Microsoft’s automatic activation process differentiate between a Break the Glass account, which should not be affected by the security measure, and a standard Global Admin account? In Entra ID, there’s nothing to mark an account as a Break the Glass account.

Does this mean that Break the Glass accounts will be affected by MFA activation?

Tenant with conditional access enabled

Some companies have developed highly sophisticated conditional access strategies, with the model in place subject to approval and regular monitoring by security teams. The introduction of additional conditional access rules is likely to disrupt the coherence of existing rules.

What will happen if customers refuse (delete) these rules, « imposed/proposed » by Microsoft?