Calculating inferred or effective MFA for non-Microsoft applications
This week Detexian’s CTO Adrian Kitto is delving into a topic that not many will think of; Working out the effective MFA status for non-Microsoft SaaS applications in your organization.
In case you missed it last time, please check out:
Part 1: Who / What / Why does the mid-market all have Microsoft M365 E3 licenses
Part 2: How does Microsoft M365 E3 work with the non-Microsoft ecosystem applications?
Part 3: Discovering user consented apps with Microsoft M365 E3
Part 4: Identifying and removing inactive users with Microsoft M365 E3
Introduction
In today's digital landscape, securing user accounts has become a top priority for organizations. Multi-Factor Authentication (MFA) plays a crucial role in protecting sensitive data and preventing unauthorized access.
While Microsoft applications offer a robust MFA framework through Azure Active Directory (Azure AD), determining the inferred or effective MFA for non-Microsoft applications can be a complex task.
In this blog post, we will explore the factors that influence the effective MFA for non-Microsoft applications and how it relates to Azure AD.
Centralizing Identity via Federation
Centralizing identity management is key to streamlining access control and security measures. Identity federation allows organizations to establish a trust relationship between their identity provider (such as Azure AD) and various service providers, including non-Microsoft applications. By integrating these applications with Azure AD, organizations can achieve a centralized identity management approach, enabling users to authenticate using their Azure AD credentials across multiple applications.
By federating identities, organizations gain the ability to enforce consistent security policies, including MFA, across all integrated applications. This not only simplifies user access but also ensures that MFA settings are applied consistently, reducing the administrative overhead of managing MFA configurations separately for each application.
Let's look at the ways applications handle identity and specifically multi-factor authentication:
SaaS Apps with SSO via SAML against Azure AD
Many Software-as-a-Service (SaaS) applications support Single Sign-On (SSO) integration using Security Assertion Markup Language (SAML) against Azure AD. In such cases, the effective MFA for these applications will align with the MFA settings configured in Azure AD. This means that if Azure AD requires MFA for a user, they will be prompted for MFA when accessing any SaaS app integrated with Azure AD via SSO.The advantage of this approach is that organizations can enforce a consistent MFA policy across multiple SaaS applications, eliminating the need for separate MFA configurations for each application. Additionally, Azure AD offers various MFA methods, such as SMS verification, mobile app notifications, or hardware tokens, allowing users to choose the method that suits them best.
Apps Without Identity Federation
For SaaS applications that do not have identity federation capabilities, the native MFA settings of the application come into play. In these cases, the effective MFA relies solely on the MFA options provided by the application itself. Organizations must configure and manage MFA settings directly within each application, potentially leading to a more fragmented and less centralized MFA experience.It is crucial to understand that if an organization enables MFA in Azure AD but does not integrate the SaaS application via SSO and SAML, the MFA policy from Azure AD will not automatically apply to the application. Therefore, users accessing the application directly will not be prompted for MFA, unless the application itself has MFA functionality.
"Sign Up with Microsoft" and the OpenID Scope
When users sign up for a non-Microsoft application using their Microsoft account, they often see an option to "Sign up with Microsoft." This integration is possible through the OpenID Connect protocol, which allows applications to authenticate users using their Microsoft identities. When users choose this option, the application requests specific scopes, including the "openid" scope.The "openid" scope in the user consent process allows the application to receive an ID token, which contains information about the user and their authentication context. Notably, requesting this ID token requires MFA if enforced on the users account. As a result, regardless of the native MFA setting in the SaaS application, the effective MFA for users who signed up with Microsoft will be determined by their Azure AD MFA status.
OpenID Connect is an identity layer built on top of OAuth 2.0 that facilitates the authentication and authorization process for web and mobile applications. It allows applications to authenticate users using their existing accounts from providers like Microsoft, Google, or Facebook. In the context of Azure AD, OpenID Connect integration enables users to sign up for non-Microsoft applications using their Microsoft accounts.
When users choose to "Sign up with Microsoft" for a non-Microsoft application, the application initiates the user consent process, which includes requesting specific scopes. One of these scopes is the "Sign you in and read your profile". This is known as the OpenID scope and by requesting the application seeks authorization to receive an ID token from Azure AD.
Checking OpenID Connect Usage in Azure AD
To verify whether a user has used OpenID Connect to sign up for a non-Microsoft application, administrators can navigate to the Azure AD portal. Within the portal, under the "Users" section, administrators can search for the specific user and view their application details. In the user's applications, you can view the user consents and see the “Sign in a read user profile.”
As you can see, evaluating a users effective MFA in a non-Microsoft SaaS application like Calendly requires checking multiple settings including SSO settings, the apps native MFA and user consents for the OpenID role.
In order to save you a little time I’ve knocked together a PowerShell script that will connect to your Azure AD tenant and list out all users who have an application without OpenID and what that application is called. This should give you a head start on working out the applications where you need to focus on the native MFA settings to assess your effective MFA.
# Install required Azure AD module if not already installed
if (-not (Get-Module -ListAvailable -Name AzureAD)) {
Install-Module -Name AzureAD -Force
}
# Connect to Azure AD
Connect-AzureAD
# Get all users from Azure AD
$users = Get-AzureADUser -All $true
# Search for users with app roles without the "openid" scope
$usersWithoutOpenID = @()
foreach ($user in $users) {
$userRoles = Get-AzureADUserAppRoleAssignment -ObjectId $user.ObjectId
$rolesWithoutOpenID = $userRoles | Where-Object { $_.ResourceId -ne "openid" }
if ($rolesWithoutOpenID) {
$usersWithoutOpenID += [PSCustomObject]@{
User = $user.DisplayName
UserPrincipalName = $user.UserPrincipalName
Apps = $rolesWithoutOpenID | ForEach-Object { $_.ResourceDisplayName }
}
}
}
# Display the users and the names of the apps without the "openid" scope in assigned app roles
if ($usersWithoutOpenID) {
Write-Host "Users with app roles without the 'openid' scope:"
$usersWithoutOpenID | ForEach-Object {
$user = $_
Write-Host "User: $($user.User) - UserPrincipalName: $($user.UserPrincipalName)"
Write-Host "Apps without 'openid' role:"
$user.Apps | ForEach-Object {
Write-Host "- $($_)"
}
Write-Host
}
} else {
Write-Host "No users found with app roles without the 'openid' scope."
}
# Disconnect from Azure AD
Disconnect-AzureAD
Conclusion
Determining the inferred or effective MFA for non-Microsoft applications involves considering various factors, including identity federation, native MFA settings, and OpenID Connect integration with Azure AD. By centralizing identity management through federation and leveraging OpenID Connect, organizations can establish a unified and consistent MFA experience for users across a range of applications. This not only enhances security but also simplifies administration and reduces the risk of unauthorized access to sensitive data.
Understanding these concepts empowers organizations to make informed decisions regarding MFA configurations and reinforces their commitment to protecting user accounts and valuable information across diverse application ecosystems.
Security thought for the week
ChoicePoint faced the first-ever civil penalty for a data breach in the United States. In this incident, fraudsters posing as legitimate businesses gained access to ChoicePoint's database by creating fake businesses. They used this access to obtain personal information, including social security numbers, addresses, and credit reports, which could be used for identity theft and fraud.
As a result, ChoicePoint faced the first-ever civil penalty for a data breach in the United States. In 2006, the company reached a settlement agreement with the FTC, requiring ChoicePoint to pay a $10 million fine. Additionally, the settlement mandated that ChoicePoint implement comprehensive information security measures and undergo third-party audits to ensure compliance with those measures.
Till then, stay secure.
Adrian
