Using Log Analytics to identify Multifactor Authentication Gaps

-

On August 15 2024, Microsoft released a communication stating that enabling multifactor authentication (MFA) will be enforced by October 15 2024, in order to access Microsoft Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center. 


The enforcement is planned to be rolled out in 2 phases:

Phase 1: Starting in the second half of 2024, MFA will be required to sign in to the Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center. The enforcement will gradually roll out to all tenants worldwide. This phase won't impact other Azure clients such as Azure CLI, Azure PowerShell, Azure mobile app, or IaC tools. 

Phase 2: Beginning in early 2025, MFA enforcement gradually begins for sign in to Azure CLI, Azure PowerShell, Azure mobile app, and IaC tools. Some customers may use a user account in Microsoft Entra ID as a service account. It's recommended to migrate these user-based service accounts to secure cloud based service accounts with workload identities.

Microsoft is allowing the option postpone the enforcement of MFA until March 15 2025 which organizations can implement until they are fully ready to enforce MFA for all users.


To prepare for this change, organizations can leverage the Multifactor Authentication Gaps workbook that can help in identifying user sign-ins and applications that aren't protected by multifactor authentication (MFA) requirements. I wanted to familiarise myself with this so went ahead and implemented the solution in my own tenant. Here are all the details -

A couple of things to note - 

1. End users who access application, websites, or services hosted on Azure, but don't sign into the listed applications, aren't required to use MFA. The authentication requirements for end users are controlled by the application, website, or service owner.

2. Workload identities, such as managed identities and service principals, aren't impacted by MFA enforcement. If user identities sign in as a service account to run automation (including scripts or other automated tasks), those user identities need to sign in with MFA once enforcement begins.

3. Break glass or emergency access accounts are also required to sign in with MFA once enforcement begins.

Setting up the MFA Authentication Gap workbook

First and foremost, following requirements need to be put in place -

- A Microsoft Entra tenant with a Premium P1 license
- A Log Analytics workspace and access to that workspace
- The appropriate roles for Azure Monitor and Microsoft Entra ID

If you have not setup a log analytics workspace, then you can follow the steps below to create one -

1. In the Azure portal, enter Log Analytics in the search box and select Log Analytics workspaces.

2. Select Create.

3. Select a Subscription from the dropdown.

4. Use an existing Resource Group or create a new one.

5. Provide a name for the new Log Analytics workspace.

6. Select an available Region.

7. Review and Create.

Example -


Integrate the Microsoft Entra ID logs using the Log Analytics Workspace created earlier with Azure Monitor logs

1. Sign in to the Microsoft Entra admin center as at least a Security Administrator.

2. Browse to Identity > Monitoring & health > Diagnostic settings.

3. Select + Add diagnostic setting to create a new integration.

4. Enter a Diagnostic setting name.

5. Select the log categories that you want to stream. I selected all for testing purposes.

6. Under Destination Details select the Send to Log Analytics workspace check box.

7. Select the appropriate Subscription and Log Analytics workspace from the menus and hit Save button.



Importing MFA Authentication Gaps Workbook

After the Log Analytics integration is done, next step is to import the MFA Authentication Gaps workbook. Microsoft has already made a workbook available, that can be directly downloaded from over here.

1. Sign in to the Microsoft Entra admin center using the appropriate combination of roles.

2. Browse to Identity > Monitoring & health > Workbooks.

3. Select + New.

4. Select the Advanced Editor button from the top of the page. A JSON editor opens.


5. Copy the entire contents of the JSON from GitHub repository and replace the existing text in the advanced editor.



6. Select the Save As button and provide the required information.


7. Select apply as the last step.

MFA Authentication Gaps Report

The sign-in logs will start getting monitored and will now be represented to show user sign-ins and applications that are not protected by MFA in form of a dashboard which can be drilled down as well. Through the dashboard I could see that I had an account against which the sign-in sessions were not protected by MFA.




Final thoughts..

Once organizations have performed an MFA gap analysis, the next logical step should be to enable multifactor authentication for all relevant user identities. In my opinion, the best way to achieve this is through Conditional Access. There are many methods that can be used for a second-factor authentication like - 

- Windows Hello for Business
- Microsoft Authenticator app
- Passkey (FIDO2 security key)
- OATH hardware tokens (preview)
- OATH software tokens
- SMS verification
- Voice call verification
- Temporary Access Pass
- Email OTP
- Certificate based Authentication

Once enabled, organizations can enable the Conditional access policies requiring MFA for -

-Administrators
-Specific applications
-All users
-Azure management including all admin portals.
-Network locations you don't trust

Until next time..

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){                 $KPID=$KP.KeyProtectorId                 break;             }         }        $o
Read more

Intune: Configure Printers for Non-Administrative Users

-
Image
Configuring printers for end users or giving them the ability to do it themselves is a normal requirement for organizations. Now if your users are Administrators, then the configuration can be straight forward, but in case of Non-Administrators there are additional steps required as Non-Administrators will not be able to add a driver in the driver store despite being able to install a printer. In this blog, I will cover the steps that I took to address this requirement using Intune. The setup involves 2 steps -  1. Setup registries. 2. Install the driver and configure the printer Setting up registries – The registries that need to be configured are actually part of a GPO setting – Allow non-administrators to install drivers for these device setup classes It can be found under: Computer Configuration -> Policies -> Administrative Templates -> System -> Driver Installation I used a Powershell script to set the values and wrapped it in a Win32 application. $Path1
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from starting pr
Read more