Migration to Microsoft Graph API: Optimizing MFA management and security with PowerShell SDK

Migrating to Microsoft Graph API from outdated PowerShell modules such as Azure AD and MSOnline is a crucial task, especially in scripted environments, as Microsoft will soon deprecate these legacy modules. Moreover, this change is important to ensure future compatibility and security. For administrators, transitioning to Microsoft Graph API is essential to avoid future compatibility issues.

Starting in March 2025, Microsoft will only provide security-critical updates for the old modules and advises administrators to update their scripts to the Microsoft Graph PowerShell SDK. transition to avoid disruption in ongoing operations. This transition offers numerous benefits, including modern authentication, cross-platform compatibility, and enhanced security practices such as support for external identities and passwordless authentication.

Installing the new PowerShell modules for Microsoft Graph

The Microsoft Graph PowerShell SDK (https://learn.microsoft.com/en-us/graph/sdks/sdks-overview) provides IT administrators with a flexible interface to access Microsoft Graph API and perform various management tasks. The SDK supports the entire Microsoft Graph API ecosystem, including services like Entra ID, Microsoft 365, Teams, and many more. A key advantage of the SDK is its cross-platform compatibility, as it runs on Windows, Linux, and macOS. Additionally, using PowerShell 7 enables modern authentication methods, such as OAuth2 support.

The new PowerShell modules can be installed in PowerShell 7 using the following commands:

Install-Module Microsoft.Graph -Scope AllUsers -Force

Install-Module Microsoft.Graph.Beta -Scope AllUsers -Force

The SDK stands out because it is based on the Microsoft Authentication Library (MSAL), which offers more secure authentication mechanisms compared to older technologies like ADAL. With just a few lines of code, administrators can manage users and groups, set MFA policies, or perform complex queries—for example, retrieving all users who use specific authentication methods.

An example of a simple authentication query is:

Connect-MgGraph -Scopes “User.Read.All”

Get-MgUser -Filter “startswith(DisplayName,’A’)”

Get-MgUserAuthenticationMethod -UserId user@example.com

If the permissions are insufficient, signing in via:

Connect-MgGraph -Scopes “UserAuthenticationMethod.ReadWrite.All”

is advisable. The SDK simplifies access to many complex cloud services and makes automation and management in large Microsoft environments significantly more efficient.

PowerShell Migration to Microsoft Graph API

The migration requires reviewing and updating existing scripts, as the new Microsoft Graph PowerShell cmdlets and parameters differ significantly from the older AzureAD or MSOnline commands. For example, the command Get-AzureADUser is replaced by Get-MgUser. To ensure a smooth migration, Microsoft recommends thorough documentation of the existing scripts to identify key functionalities and transfer them to the new API. The cmdlet mapping tables and advanced query capabilities in Microsoft Graph PowerShell facilitate this process.

For managing per-user MFA, it is necessary to use the cmdlet Get-MgUserAuthenticationMethod to retrieve a user’s authentication methods. As a result, this gives administrators fine-grained control over user authentication settings. This allows methods such as Microsoft Authenticator, FIDO2, or passwordless authentications to be read and updated. To change the preferred MFA type, the Graph API offers a flexible schema, allowing the Invoke-MgGraphRequest cmdlet to set the preferred authentication type for users. This enables administrators to implement specific requirements, such as setting the default MFA method for a particular user group.

tle=”PowerShell-Migration zu Microsoft Graph API: Invoke-MgGraphRequest” src=”https://www.firstware.com/wp-content/uploads/2024/10/mfa-graph-03-1024×679.png” alt=”PowerShell-Migration zu Microsoft Graph API: Invoke-MgGraphRequest” width=”1024″ height=”679″ />

An important step in migrating to the Microsoft Graph API is to transition the old MFA configuration to the new ‘Authentication Methods Policy’ page in the Microsoft Entra Admin Center. In this centralized location, all authentication methods can be configured, while the old configurations can be disabled. This not only simplifies management but also offers additional features, such as enforcing location- and app-based authentication notifications, thereby enhancing security and user experience.

Migration and Best Practices for Managing MFA with Microsoft Graph API

A key advantage of Microsoft Graph API lies in its flexibility, especially when managing MFA methods. Using the cmdlet Get-MgUserAuthenticationMethod, a user’s authentication methods, such as Microsoft Authenticator, FIDO2, or passwordless authentications, can be retrieved and updated. A simple example of using this cmdlet is as follows:

This example outputs the different MFA methods of a user, such as Microsoft Authenticator or FIDO2 keys. The cmdlet not only returns the method type but also additional information like phone numbers for phone-based authentication and if you want to <strong>retrieve a specific method, such as the Authenticator app, for a user, this can be done as follows:

This command filters all methods and displays only the Authenticator method. This is useful if an administrator wants to ensure that all users have a specific MFA method enabled. Another example shows how to access specific properties, such as the phone number in phone-based authentication:

This example shows how to extract the phone numbers of users who have enabled phone-based MFA authentication.

Managing MFA Methods with the Microsoft Graph API

The API provides deeper capabilities to configure and manage MFA. For example, administrators can set the preferred MFA method for users by using API endpoints, which can be combined with PowerShell commands such as Invoke-MgGraphRequest. This allows for efficient configuration of standards for entire user groups. Administrators can configure a user’s preferred MFA method, such as Microsoft Authenticator, by executing an API call with Invoke-MgGraphRequest:

This script updates a user’s MFA settings and sets Microsoft Authenticator as the preferred method. The API endpoint allows direct access to a user’s authentication settings and enables changes.

If administrators want to ensure that all users in a specific group use the same MFA method, they can extend the script to change the preferred method for all group members:

This script goes through each user in the group and sets the Authenticator app as the preferred MFA method for each one. This allows administrators to efficiently and automatically enforce standards for entire user groups.

In addition to setting methods, it is often necessary to check which MFA methods users are already using. Administrators can then specifically assign the correct method to users who have not yet enabled secure methods:

This first checks if a user has enabled the Authenticator app. If not, this method is set as the preferred one. This approach can be used as part of a script to regularly validate and adjust the MFA configuration as needed.

Using the Least-Privilege Principle

A central aspect of the new API is the so-called Least-Privilege Principle. The old AzureAD and MSOnline modules often required excessive permissions. In contrast, Microsoft Graph PowerShell explicitly requests specific rights. The administrator must then request these rights. This greatly enhances security, as users and scripts only receive the minimum necessary rights. Access to a user’s MFA information can be achieved by scoping to specific permissions:

By restricting permissions, it is ensured that no unnecessary permissions are granted.

This unified approach significantly simplifies management and enhances security.

Additionally, authentication methods can also be specifically enabled or disabled. Here is an example of how to add the “Phone” authentication method for a user:

This example shows how to add a phone number as an MFA method to a user account, with “mobile” indicating the type of phone number. Another common scenario in practice is enforcing secure MFA methods for all users in a specific group. For example, you can check if all users in a group are using MFA with the Authenticator app and make changes if necessary:

The script checks all members of the specified group to determine if the Authenticator app is enabled as an MFA method. If it is not enabled, the script generates a corresponding output. For large-scale changes, standard methods can be set automatically within the script. This ensures both efficiency and consistency. For example, an administrator could configure all users to set the Authenticator app as their primary MFA method.

Conclusion

The PowerShell migration to Microsoft Graph API not only enhances security but also improves script efficiency, while providing access to modern authentication methods. The Microsoft Graph PowerShell SDK enables more flexible management and optimizes the automation of complex tasks. With a well-structured approach and best practices, administrators can efficiently execute the migration and significantly improve the security of their environment.

Learn More about FirstWare IDM Portal

The FirstWare IDM Portal from FirstAttribute is an integrated solution for Identity and Access Management (IAM). It enables the automated management of users and their permissions, whether On-Prem or in the Cloud.

This portal integrates all aspects of identity and access management and provides centralized access to identity and directory services.

Contact Us