Revealing Full Details of Authentication Methods and Why This Might Be a Privacy Issue

Soon after releasing V1.2 of the Tenant Passwords and MFA Report (to add details about per-user MFA states), I was asked if it was possible to add more information for authentication methods, like the phone number used for SMS responses. My response was that I had covered the topic of reporting the details of authentication methods in a previous article and it was simply a matter of using the code from that article, updating it slightly to deal with the device-based passkeys recently introduced for Entra ID.

Not everyone likes cracking open a PowerShell script to insert code that they didn’t write. I don’t like messing with other peoples’ code either and will usually write my own version when necessary. In any case, I found some time and upgraded the script to include the expanded details, available in V1.3 of the script in GitHub.

Reporting Authentication Methods

Figure 1 shows the information about authentication methods registered for a user account in V1.2 of the report. The information given use the names from the MethodsRegistered property returned by the Get-MgBetaReportAuthenticationMethodUserRegistrationDetail cmdlet from the Microsoft Graph PowerShell SDK.

The problem is that the names aren’t very user-friendly. If you’re used to working with authentication methods, you probably recognize the values and understand what they mean. If not, this information might be useless.

More detail about the methods is available by running the Get-MgUserAuthenticationMethod cmdlet. Even so, some manipulation is necessary to generate human-friendly output. I’d done most of the work before, so it was easy to generate more information for each method. For instance, in Figure 2 you can see the mobile phone number used for SMS challenges and the version of the Authenticator app used for push notifications.

Because the script captures details in a PowerShell list, it’s also possible to query the list to find information like who uses a YubiKey FIDO2 key with a command like:

$Report | Where-Object {$_.'Authentication Methods' -like "*Yubikey*"}

The Privacy Issue

All was going well when I realized that the information generated about authentication methods might include some PII data, like the mobile phone number used for SMS responses. In most instances, I don’t think this will be a problem because details like mobile phone numbers are often included in the properties of Entra ID user accounts. The email addresses used to recover passwords via the Self-Service Password Reset (SSPR) feature are often personal accounts, so they might be more of an issue.

However, the regulations covering access to PII differs from country to country and it’s a good idea to cover all bases. The script now has a PrivacyFlag parameter. It’s a switch parameter, so the value is false by default. If set to true by including the parameter when running the script or by setting the flag explicitly, the script generates the names of the authentication methods without any details.

$PrivacyFlag = $true

On to The Next Version

I am sure that many other good ideas about how to add value to a report like this exist within the community. If you do, suggest the change through the Office 365 for IT Pros GitHub repository (for this script or any of our other scripts). Many people create a fork of our repository and work on updates that way. Whatever’s easier for you…

Learn more about how Microsoft 365 applications and Entra ID work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

New Graph API Reveals MFA Preferred Authentication Method for User Accounts

In his copious spare time when he’s not reviewing chapters of the Office 365 for IT Pros eBook in his technical editor role, Vasil Michev writes for his blog. A recent post covers the Graph API to configure multi-factor authentication methods for Azure AD user accounts. This API is helpful because it fills in a gap in Graph coverage.

We’ve been able to report authentication methods set on accounts for quite a while, but setting methods has been problematic, especially with the upcoming deprecation of the Microsoft Services Online module (MSOL). Until now, the MSOL cmdlets to deal with “strong authentication methods” are what people have had to use in automation scenarios. Go to Vasil’s blog to learn about how to fetch and set the preferred MFA authentication method for Azure AD accounts (the signInPreferences object for accounts), or read up on the documentation.

Vasil makes the point that the new APIs have not yet appeared in the form of cmdlets in the Microsoft Graph PowerShell SDK. This is because a process needs to run (called AutoRest) to generate the SDK cmdlets from Graph APIs. Microsoft runs the process regularly, but some delay is always expected.

Invoke Graph Requests

The workaround is to use the Invoke-MgGraphRequest cmdlet. Here’s an example of using the cmdlet to fetch details of all Azure AD user accounts that have at least one assigned license (to filter out accounts used for room mailboxes, etc.) The filter used with the Get-MgUser cmdlet is a good example of using a lambda operator with what Microsoft calls a complex Azure AD query (the check assigned licenses). Because it’s a complex query, we need to use the ConsistencyLevel parameter and pass eventual as its value. If you haven’t seen this kind of filter used to find accounts before, store it away because it’ll be one that you use time and time again in your scripts.

After fetching the set of users, it’s a matter of running the query to return the authentication sign in preferences for each account and storing the details in a PowerShell list object. Here’s the code:

Connect-MgGraph -Scopes UserAuthenticationMethod.ReadWrite.All
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All

$Report = [System.Collections.Generic.List[Object]]::new() 
ForEach ($User in $Users) {
 $Uri = ("https://graph.microsoft.com/beta/users/{0}/authentication/signInPreferences" -f $User.Id)
 $AuthData = Invoke-MgGraphRequest -Uri $Uri -Method Get

 $ReportLine = [PSCustomObject]@{
    User   = $User.displayName
    UPN    = $User.userPrincipalName
    'System preferred MFA enabled' = $AuthData.isSystemPreferredAuthenticationMethodEnabled
    'System preferred MFA method'  = $AuthData.systemPreferredAuthenticationMethod
    'Secondary auth method'        = $AuthData.userPreferredMethodForSecondaryAuthentication }
  $Report.Add($ReportLine)

}

System Preferred Authentication Policy

An important factor to take into account is the existence of the Entra ID system-preferred authentication policy, which is now generally available. When this policy is active (as it soon will be for all tenants), Azure AD uses the strongest authentication method available to an account. A note in the documentation for updating authentication methods says that “this value is ignored except for a few scenarios where a user is authenticating via NPS extension or ADFS adapter.” That’s something to consider when updating user accounts.

Progress, Not Perfect

I don’t think anyone would say that things are perfect in terms of the transition from the old MSOL and Azure AD PowerShell modules to the Graph (APIs or SDK cmdlets). Migrations are never perfect, and we’ll be coping with the effects of this changeover for many months to come. That being said, it’s nice to see progress, albeit in small steps.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Moving from Old Modules to the Microsoft Graph SDK for PowerShell

Update: This article describes a script to generate a report showing the MFA status for accounts and highlights administrative accounts that aren’t MFA-enabled.

Microsoft 365 tenants often create reports to understand the health of their Azure AD accounts. In June 2021, Microsoft announced that they are moving away from the Microsoft Online Services (MSOL) and Azure AD PowerShell modules and would deprecate the Azure AD Graph API at the end of June 2022. Customer feedback convinced Microsoft to push the deprecation date out to the end of 2022, and then to March 2024. However, the writing is on the wall for the Azure AD Graph API and it’s time to move to Graph-based interfaces.

Their future focus for PowerShell access to Entra ID data is the Microsoft Graph SDK for PowerShell. The only definite drop-dead date affecting the older modules is June 30, 2022, when Microsoft moves to a new license management platform. At this point, any cmdlet which retrieves license information for user accounts will cease working. Any scripts used for tenant license management that haven’t been updated now require urgent attention.

I have an MFA status script written in 2018. The script uses the MSOL cmdlets to check and report the “strong authentication methods” for each user account. The state of multi-factor authentication has moved on since 2018 to accommodate new methods like FIDO2 keys and passwordless authentication. These methods aren’t handled by the MSOL cmdlets. It’s therefore time to take a different approach.

Given Microsoft’s direction to use the Microsoft Graph SDK for PowerShell for Azure AD access, it seems like this is the right path to follow. I’ve done a reasonable amount with the SDK and have written several articles to report my progress. For example, here’s how to generate a licensing report for a tenant.

Not a Perfect SDK

The SDK is not perfect. Essentially, its cmdlets are wrappers around Graph API queries. If you’re used to dealing with Graph APIs, the SDK cmdlets will be second nature. If not, it will take time to become familiar.

Getting acquainted isn’t helped by the poor state of the documentation for the SDK cmdlets. Microsoft uses automatic text generation tools to create the documentation from source code. The result is often as useful as a snowball in a desert, especially in terms of practical examples and explanations about inputs. Again, if you know the Graph APIs, you probably won’t be surprised at what you find in the documentation, but the current state of the documentation is no credit to Microsoft and a barrier to adoption.

Steps in the Creation of the Report

The aim is to create a report showing the authentication methods used by Azure AD accounts and highlight accounts which might attention (hopefully, by enabling multi-factor authentication). According to a recent Microsoft report, only 22% of Microsoft 365 accounts use multi-factor authentication. Although this marks an improvement over the past, it’s still far too low a percentage. Perhaps people don’t know about recent improvements Microsoft has made in MFA processing to make it easier for people to use.

The script I wrote to create the report does the following:

• Connects to the Graph endpoint with the following permissions: UserAuthenticationMethod.Read.All, Directory.Read.All, User.Read.All, Auditlog.Read.All. If the service principal for the SDK doesn’t have administrat9or consent of any permission, it must be granted at this point.
• Set the Graph profile to beta to make sure that we have access to all the user account data.
• Call the Get-MgUser cmdlet to fetch the set of Azure AD member accounts. The set returned excludes guest accounts but includes the accounts used for shared and resource mailboxes. To focus solely on licensed member accounts, you could apply a filter to look for accounts with at least one assigned license.
• Loop through each account to check its authentication methods. To ensure that only active accounts are checked, the script calls the Get-MgAuditLogSignIn cmdlet to look for a sign-in record. This check can only go back 30 days.
• For each active account, call the Get-MgUserAuthenticationMethod cmdlet to return the authentication methods used by the account. An account can use all the valid authentication methods from passwordless to the Microsoft authenticator app. The first time an account uses a method, Azure AD adds it to the list used by the account.
• For each method, retrieve some information.
• Report the results of checking each method.
• After processing all user accounts, create a list of users for which an authentication method is available and check each account to see if one of the strong (MFA) methods is noted.
• Create a final report and output it to a CSV file.

Figure 1 shows an example of the kind of output generated.

You can download the script from GitHub. As always, the code is intended to illustrate a principal rather than being a fully-baked solution.

Automating the Check

A script like this is a good candidate for execution by an Azure Automation runbook. It can be run on a schedule and the results emailed to administrators for action. Getting a weekly or monthly reminder to improve the security posture of the organization by increasing the percentage of well-protected accounts can only be a good thing, can’t it?

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.