Implementing an advanced Authentication Methods Dashboard
in Azure Active Directory
Problem:
Strong authentication is one of the core pillars of any (cloud) security strategy and various functions rely on the authenticity of the accessing users. So it makes a lot of sense to work on this topic continuously.
Azure Active Directory now offers various options for improving the strength of authentication, but one of the big challenges is rolling these out across the board with as little disruption as possible.
Stage 1: Any second factor
There are many good reasons to start an “MFA rollout”, but in my projects the triggers are often
- an upcoming rollout of new devices
New devices can at the same time paradoxically be both the cause and the solution for stronger authentication, since a register/join of the devices and a setup of Windows Hello require strong authentication on the one hand. On the other hand, the Authenticator app (on mobile devices) and Windows Hello (on notebooks) are core components for strong authentication. - a redesign of the conditional access ruleset
In addition to a good admin concept and enterprise app management, the key to a secure AAD is a strong conditional access ruleset. Often, an audit (or a breach) reveals that the current evolved ruleset is not optimal and redesign is necessary. I strongly believe that enforcement of MFA is an integral part of a good CA ruleset.
The first goal in an MFA rollout for me is coverage, as setting up a second factor dramatically increases the security of the account.
Stage 2: A really strong authentication
Experience shows us that it is not appropriate to stop after the initial rollout. It is too easy for an attacker to spam his victim with calls after a guessed or captured password (MFA fatigue) or to phish the token code directly.
An ambitious but achievable goal is to have only the Authenticator app with number matching, Windows Hello and FIDO2 keys for all users at the end of the rollout. In combination with a conditioanal access policy that requires device compliance, this is a (currently) robust foundation.
To achieve this goal, there are two components that help me a lot:
- Recently, Windows Hello can be set up with a Temporary Access Pass without any further MFA methods. This makes the rollout much easier.
- For registered devices (even without Windows Hello), a confirmation, e.g. via Authenticator App, does not have to take place for every login, since an MFA imprinting in the token usually happens even after successful strong authentication.
However, on the way to my goal, I ask myself a few questions:
- Which users have not registered any MFA method yet?
- Which Authentication Methods are used by your users?
- Which Authentication Methods are registered by your users?
Fortunately, the AAD already contains the Authentication methods report which answers the questions and in small environments the problem is largely solved.
In large environments, however, it is usually not sufficient to look at the totality of all users and so these questions arise for individual groups of users. Additionally the questions arise:
- How effective are my measures to improve the situation?
- How big is the impact if I prohibit weaker methods (for example with Authentication Strength)?
- In which locations / departments / … is my rollout going well?
- What is the percentage of accounts that require exceptions or special handling, such as service accounts or teams rooms systems?
Solution:
For a complex rollout, I need a flexible tool that allows me to examine the current situation for individual user groups and display trends.
The use of workbooks, instead of e.g. PowerBI, is ideal here, as the workbooks are already integrated into the existing admin interface and the existing administration concept takes effect.
Workbooks have the possibility to use APIs and Log Analytic Workspaces as data sources. In order to have a good performance even with a high number of users, I have decided to rely exclusively on log analytics and to have the necessary data written periodically by a logic app. This also enables a historization of the data, which allows us, for example, to display a progression over time.
Implementation:
The following components are needed for the solution:
- Log Analytics Workspace with ingested SignIn Log should already be there (requires AAD P1)
- Logic App of type consumption (not Standard) including an API connection and a Managed Identity.
- Workbook as Dashboard
Logic App:
For the required Logic app to work it also needs:
- for accessing the Graph API we need to create and authorize a managed identity. Read rights to users, groups and authentication methods are required.
- a connector to the Log Analytics Workspace with write permissions.
Since these two components need to be customized to the tenant, my instructions currently call for creating them manually before importing the Logic. If anyone knows how to automate this step, I would appreciate any tips.
Step 1: Create a new empty consumption based Logic App in your favorite Resource Group and give it a reasonable name according to your naming conventions, like PullAuthMethodsToLATablebyGroup
Step 2: Enable the System Assigned Managed Identity for the new Logic App and grant permissions. Use “Object (principal) ID” as $miObject.
Step 3: Create a new Log Analytics Connection via a Send Data Action, switch to Logic App Code View and copy the values of the azureloganalyticsdatacollector in the connections section of the parameters.
Step 4: Import the Logic from my repo, insert the copied values of the azureloganalyticsdatacollector, insert your first group ids and start the initial run.
Dashboard
While your Logic App is running you can just import and save the dashboard. In my previous blog I described how to do it.
