Cybersecurity

Microsoft Entra ID: Selective MFA Bypass for Service Accounts

Microsoft Entra ID: Selective MFA Bypass for Service Accounts

Multi-factor authentication (MFA) is a cornerstone of modern security, but it can be a major roadblock for service accounts used in automation scripts, applications, and batch processes. Imagine automating user provisioning in Active Directory via a service account—requiring MFA for that account would break the automation, creating inefficiencies and operational headaches. Microsoft Entra ID now allows you to selectively bypass MFA for these accounts, maintaining strict security for human users while keeping your automation pipelines flowing. In this tutorial, we’ll explore how to configure this feature, the prerequisites, and common pitfalls. You’ll learn how to strike the right balance between security and operability. When I implemented this for a government agency with 2,000 endpoints, we saw a massive boost in automation efficiency without compromising our overall security posture.

Prerequisites

  • A Microsoft Entra ID tenant with a P1 or higher license.
  • An account with Global Administrator or Security Administrator rights in Entra ID.
  • The Azure AD PowerShell module installed.
  • An existing service account in Entra ID that requires the MFA bypass.

Configuring the Conditional Access Policy for MFA Bypass

The primary method for bypassing MFA for service accounts is through a Conditional Access policy. This allows us to define specific conditions where MFA is not required, based on criteria such as the user, location, or application.

Creating a Security Group for Service Accounts

The first step is to create a group in Entra ID that will contain all the service accounts you want to exempt from MFA. This simplifies policy management.

  1. Navigate to the Azure Portal and go to “Groups”.
  2. Click “New group”.
  3. Select “Security” as the group type.
  4. Enter a descriptive name, such as “ServiceAccounts-MFA-Bypass”.
  5. Add the desired service accounts as members of the group.

{{IMAGE: azure active directory group creation security type}}

This group will be used in the Conditional Access policy to identify the accounts targeted for the MFA bypass. Grouping these accounts simplifies centralized management and reduces the risk of misconfigurations.

Creating the Conditional Access Policy

Now, let’s create the policy that excludes the service account group from MFA requirements.

  1. Navigate to the Azure Portal and go to “Microsoft Entra ID” > “Security” > “Conditional Access”.
  2. Click “New policy”.
  3. Assign a name to the policy, such as “MFA Bypass for Service Accounts”.
  4. In the “Assignments” section, select “Users or workload identities”.
  5. Under “Include”, select “Select users and groups” and choose the group created earlier (“ServiceAccounts-MFA-Bypass”).
  6. In the “Cloud apps or actions” section, select “All cloud apps”. This means the policy will apply across all cloud applications.
  7. In the “Conditions” section, you can specify additional conditions like location (restricting to specific networks) or device type.
  8. In the “Access controls” section, select “Grant”.
  9. Choose “Grant access” and deselect all MFA options (e.g., “Require multi-factor authentication”).
  10. Under “Grant”, select “Require one of the selected controls” and ensure no options are checked. This is crucial for successfully bypassing MFA.
  11. Set “Enable policy” to “On”.

{{IMAGE: azure conditional access policy configuration grant access}}

This configuration dictates that for accounts in the specified group, access will be granted without prompting for MFA. It’s important to carefully evaluate any additional conditions to properly balance security and operability.

Verifying the Configuration

After creating the policy, it is critical to verify that it works as intended.

  1. Log into an Azure resource (e.g., the Azure Portal) using one of the service accounts included in the group.
  2. Verify that access is granted without an MFA prompt.
  3. Check the sign-in logs in Entra ID to confirm the policy was applied correctly.

To check the sign-in logs:

  1. Go to “Microsoft Entra ID” > “Monitoring” > “Sign-in logs”.
  2. Filter by the service account used for the test.
  3. Verify that the Conditional Access policy result is “Success”.
# Example output in sign-in logs:
# Conditional Access: Success
# Policy name: Bypass MFA per Utenze di Servizio

A successful result indicates the policy is active and functioning properly. If not, double-check the policy configuration and group membership.

Using Named Locations to Restrict Access

To tighten security, you can pair the MFA bypass with Named Locations. This allows you to define trusted IP ranges from which service accounts can authenticate, mitigating the risk of unauthorized access from unknown networks.

Creating a Named Location

  1. Navigate to the Azure Portal and go to “Microsoft Entra ID” > “Security” > “Named locations”.
  2. Click “New location”.
  3. Enter a descriptive name, such as “Trusted-ServiceAccount-IPs”.
  4. Select “IP ranges” and enter the IP addresses of the servers or networks where the service accounts will be running.
  5. Click “Create”.

{{IMAGE: azure named location ip ranges configuration}}

Modifying the Conditional Access Policy

Now, modify the previously created policy to include the Named Location.

  1. Go to “Microsoft Entra ID” > “Security” > “Conditional Access” and select the “MFA Bypass for Service Accounts” policy.
  2. In the “Conditions” section, select “Locations”.
  3. Set “Configure” to “Yes”.
  4. Under “Include”, select the Named Location you created (“Trusted-ServiceAccount-IPs”). You can also exclude specific locations if necessary.
  5. Save the policy.

With this configuration, MFA will only be bypassed if the authentication originates from the IP ranges specified in the Named Location, adding a critical layer of defense.

Automating with PowerShell

Configuring Conditional Access policies can be automated using PowerShell. This is especially useful in complex environments with numerous service accounts.

Installing the Azure AD PowerShell Module

If you haven’t already, install the Azure AD PowerShell module.

Install-Module -Name AzureAD -Force

Connecting to Azure AD

Connect your PowerShell session to Azure AD.

Connect-AzureAD

You will be prompted to authenticate with an account that has Global Administrator privileges.

Creating the Policy with PowerShell

Use the following commands to create the Conditional Access policy.

# Definisci le variabili
$PolicyName = "Bypass MFA per Utenze di Servizio (PowerShell)"
$GroupObjectId = "<ObjectID del gruppo UtenzeServizio-MFA-Bypass>"
$LocationId = "<ObjectID della Named Location IP-UtenzeServizio-Affidabili>"

# Crea l'oggetto della policy
$ConditionalAccessPolicy = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessPolicy
$ConditionalAccessPolicy.DisplayName = $PolicyName
$ConditionalAccessPolicy.State = "Enabled"

# Definisci le condizioni
$Conditions = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessConditionSet
$Conditions.Users = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessUserCondition
$Conditions.Users.IncludeGroups = $GroupObjectId
$Conditions.Applications = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessApplicationCondition
$Conditions.Applications.IncludeApplications = "All"
$Conditions.Locations = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessLocationCondition
$Conditions.Locations.IncludeLocations = $LocationId

# Definisci i controlli di accesso
$GrantControls = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControls
$GrantControls.GrantAccess = New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControlsGrantAccess
$GrantControls.GrantAccess.ODataType = "#Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControlsGrantAccess"
$ConditionalAccessPolicy.GrantControls = $GrantControls

# Assegna le condizioni e i controlli di accesso alla policy
$ConditionalAccessPolicy.Conditions = $Conditions

# Crea la policy
New-AzureADMSConditionalAccessPolicy -Policy $ConditionalAccessPolicy

Make sure to replace <ObjectID del gruppo UtenzeServizio-MFA-Bypass> and <ObjectID della Named Location IP-UtenzeServizio-Affidabili> with the correct values. You can find the Object IDs in the Azure Portal.

{{IMAGE: powershell console output example}}

This script automates policy creation, reducing the risk of manual errors and accelerating the configuration process.

Common Issues and Troubleshooting

  • MFA still required after applying the policy: Verify that the service account is actually a member of the correct group. Also, check that the policy is enabled and that there are no other Conditional Access policies overriding the configuration. Policy precedence matters: the most specific policy usually takes priority.
  • Error during policy creation with PowerShell: Ensure you have correctly installed the Azure AD PowerShell module and are connected with an account with sufficient privileges. Double-check the command syntax and ensure the Object IDs are correct.
  • Access blocked from locations not defined in the Named Location: Verify that the IP addresses used by the service accounts are included in the Named Location and that the policy is properly configured to include the Named Location.

Conclusion

In this tutorial, you learned how to selectively bypass MFA for service accounts in Microsoft Entra ID using Conditional Access policies and Named Locations. We covered creating a service account group, configuring a policy to exclude them from MFA, and automating the process with PowerShell. Remember, any security configuration change must be carefully evaluated and tested to ensure it doesn’t degrade your overall security posture. Balancing security and operability is key to an efficient and protected IT infrastructure. Have questions or tips? Drop a comment below!

Share this article:

Written by

Rosario Giordano

Rosario Giordano is a system administrator and IT consultant specializing in cybersecurity and cloud, with over 20 years of experience managing enterprise Linux infrastructures. His areas of expertise include SSH hardening, Kubernetes platforms, PostgreSQL databases, VMware/ Proxmox virtualization, and compliance with NIS2 and ISO 27001 security frameworks