Moving to a New Mobile Phone Means New Codes for the Microsoft Authenticator App

Moving to a new mobile device always involves a certain amount of hassle. The advent of mobile authenticator apps makes the move a little harder, especially when guest accounts on other tenants are involved.

In my case, I moved from an oldish iPhone 11 to a new iPhone 14. I was very happy with the 11 and used it since 2019. However, its battery showed signs of age and I fancied a change, which is all the reason I needed to get the 14.

Moving apps from an old iPhone to a new device is very easy. Minor hassles like making Outlook the default mail app for iOS and adding Teams to the pinned app list are easily overcome. It’s all the messing around with app passwords and authentication that causes the hassle.

Which brings me to the Microsoft Authenticator app. I am a strong proponent of multi-factor authentication and use the authenticator app to protect my Microsoft 365 and other accounts, including services like GitHub and Twitter. The app has a backup and recovery capability that I used to restore details of the accounts I use with authenticator. Unhappily (as noted in the support article), “Only your personal and non-Microsoft account credentials are stored, which includes your username and the account verification code that’s required to prove your identity.”

MFA Responses by Microsoft Authenticator App Need Device-Specific Credentials

For Microsoft school or work (Entra ID) accounts, the article explains that accounts that use push notifications (like MFA challenges) need additional verification to recover information. Push notifications require using a credential tied to a specific device. To restore accounts protected by MFA using the authenticator app on the new phone, this means that “you must scan a QR code given to you by your account provider.

The key to getting a new QR code for your Entra ID account is the Security info section of the My account page. After signing into your account, this section displays the sign-in methods used to access your account (Figure 1). This is the same kind of information that’s available when examining authentication methods for user accounts with the Microsoft Graph PowerShell SDK.

Note: If a user can’t access the My account page because they don’t have access to their old phone and therefore cannot respond to an MFA challenge, an administrator can temporarily downgrade the MFA requirement to SMS to allow the user to sign in and access the page.

Adding a QR Code for a New Device

Remember that the credential used by the Microsoft Authenticator app to respond to MFA challenges is device-specific. To generate a new QR code, click Add sign-in method and select Authenticator app from the list of options. You’ll then be told that you need to install the app, which is fine because it’s already on the device. Click Next to start the setup process and click Next again to see a new QR code for the app (Figure 2).

You can scan the code using Authenticator and once this happens, the connection between account, app, and credential works. The process includes a verification step to prove that the Authenticator app can use the credential.

After setting up Authenticator for a new device, you’ll have multiple Microsoft Authenticator entries in your sign-in methods list (one per device). It’s perfectly safe to remove the entries for devices that you no longer use.

Adding a QR Code for a Guest Account

Everything works very nicely for a full tenant account. Generating a QR code to allow Authenticator to satisfy MFA challenges for a guest account is a little more complicated. I have guest accounts in multiple Microsoft 365 organizations, mostly because I am a guest member of Teams in those organizations. Let’s assume that you see that a guest account shows up in Authenticator flagged with “Action required” (Figure 3). This means that Authenticator can’t satisfy challenges for this account because it doesn’t have the necessary credentials.

To secure the credentials for the account, the trick is to use the option to switch organizations via the icon in the top right-hand corner of the My Account page. This reveals the set of organizations that your account belongs to, starting with your account in the home tenant and then listing the organizations (aka host tenants) where you have a guest account (Figure 4).

Switching to another organization uses your account (the guest account in this case) to sign-into that organization. You can then use the Security Info page to go through the same steps to generate a new QR code and add it to the entry for the guest account in the Authenticator app. The Authenticator app should now be able to satisfy MFA challenges for the guest account when signing into the target organization.

Microsoft Authenticator App Restored to Good Health

Moving to a new iPhone isn’t something people do every day and it’s easy to forget how to renew credentials in different services. Getting new QR codes for the Authenticator app is in that category. Fortunately, the process isn’t quite as painful as I first anticipated after restoring the backup to my new phone and everything is now working as expected.

PS. If you use the Authenticator app on an Apple Watch, remember that from January 2023, the Authenticator app no longer supports WatchOS. Microsoft says that WatchOS is “incompatible with Authenticator security features.” I read that to mean that some of the changes Microsoft made recently to harden Authenticator against MFA fatigue like number matching and additional context just don’t work in the constrained real estate available for watch devices.

Use Microsoft Graph PowerShell SDK Cmdlets to Report Accounts Not Yet Set Up for SSPR

A tweet by Nathan McNulty about the Get-MgReportAuthenticationMethodUserRegistrationDetail cmdlet attracted my attention. The cmdlet generates a report about the registered authentication methods for Azure AD accounts. Nathan used the cmdlet to identify accounts that aren’t set up for self-service password reset (SSPR) by filtering the results to find only member accounts where the IsSSPRCapable property is set to False. SSPR is a premium Azure AD feature.

Get-MgReportAuthenticationMethodUserRegistrationDetail outputs filtered results, but two problems exist before the data is really usable. First, the default output for the cmdlet is user identifiers (GUIDs) instead of human-friendly display names for each account. Second, while the filter can isolate member accounts, it can’t refine the query further to drop accounts created for shared mailboxes, resource mailboxes, and other purposes. The first issue is resolved by explicitly selecting the userPrincipalName and userDisplayName properties for output; the second takes more work.

Exploring a Solution

One potential solution is illustrated below. The script uses the Get-MgUser cmdlet to find all accounts with at least one assigned license (the set of returned accounts can include those used for shared mailboxes). Information about account identifiers and display names are loaded into a hash table to make it possible to lookup an identifier very quickly. We can then loop through the set returned by Get-MgReportAuthenticationMethodUserRegistrationDetail and check each account against the hash table. If a match occurs, we know that we have a licensed account that isn’t currently enabled for self-service password result and can report that fact.

Although the Get-MgReportAuthenticationMethodUserRegistrationDetail cmdlet can output user principal name and user display name properties, looking up the user account details against a table created by Get-MgUser allows us to drop the non-user accounts and lay the foundation for retrieving other data, as explained below. Here’s the code:

Connect-MgGraph -Scope Directory.Read.All, UserAuthenticationMethod.Read.All, AuditLog.Read.All
Select-MgProfile Beta

Write-Host "Finding licensed Azure AD accounts"
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All
# Populate a hash table with the details
$UserTable = @{}
$Users.ForEach( { $UserTable.Add([String]$_.Id, $_.DisplayName) } )
Write-Host "Finding user accounts not capable of Self-Service Password Reset (SSPR)"
[array]$SSPRUsers = Get-MgReportAuthenticationMethodUserRegistrationDetail | Where-Object {$_.userType -eq 'member' -and $_.IsSSPRCapable -eq $False} | Select-Object Id, userDisplayName, userPrincipalName, DefaultMfaMethod, IsAdmin, IsMfaCapable, IsMfaRegistered, IsPasswordlessCapable, IsSSPRCapable         
Write-Host "Cross-checking against licensed users..."
[array]$NonSSPR = $Null
ForEach ($S in $SSPRUsers) {
  $DisplayName = $UserTable.Item($S.Id) 
  If ($DisplayName) {
     $NonSSPR += $DisplayName }
}
$PNonSSPR = ($NonSSPR.count/$Users.Count).toString("P")
Write-Host ("{0} out of {1} licensed accounts ({2}) are not enabled for Self-Service Password Reset" -f $NonSSPR.count, $Users.count, $PNonSSPR )
Write-Host ($NonSSPR -join ", ")

Only a list of account display names is output. When I ran the script in my tenant, the following output was generated:

Finding licensed Azure AD accounts
Finding user accounts not capable of Self-Service Password Reset (SSPR)
Cross-checking against licensed users...
23 out of 32 licensed accounts (71.88%) are not enabled for Self-Service Password Reset
Andy Ruth (Director), Ben James, Ben Owens (DCPG), Bruno Satlier, Chris Bishop, , Jackson Hoare, James Abrahams, Jeff Guillet, John C. Adams, Ken Bowers, Lotte Vetler, Marc Vigneau, Michael King, Paul Howett, Peter Bridges, Rene Artois, Sean Landy, Terry Hegarty, Tony Redmond (Office 365 for IT Pros), Vasil Michev (Technical Guru)…

Improving the Output

We can improve the output by including more information in the lookup table. A hash table is fast, but it’s limited to a key and a value, but the value can any PowerShell object. The hash table can then hold more information about each user. For example:

$UserTable = @{}
ForEach ($U in $Users) {
    $ReportLine  = [PSCustomObject] @{          
     Id                  = $U.Id
     DisplayName         = $U.DisplayName
     Department          = $U.Department
     Office              = $U.OfficeLocation  
     Country             = $U.Country
     }
    $UserTable.Add([String]$U.Id, $ReportLine) 
}

I’ve selected five properties for a user account. It’s easy to add more as necessary. With the hash table populated like this, we can grab the information from the PowerShell object in the value when a match occurs for an account and use it to build a nicer report.

ForEach ($S in $SSPRUsers) {
  $Data = $UserTable.Item($S.Id) 
  If ($Data) { # We found a match
     $ReportLine  = [PSCustomObject] @{  
       Id = $Data.Id
       DisplayName = $Data.DisplayName
       Department  = $Data.Department
       Office      = $Data.Office
       Country     = $Data.Country }
     $NonSSPRUsers.Add($ReportLine) }
}

Figure 1 shows the output of the report file.

Checking Accounts Regularly

This is exactly the kind of check against user accounts that tenants might want to run regularly. A scheduled runbook executed by Azure Automation is a good way to process these kinds of operations and the code discussed here would move over easily to a runbook. In the interim, here’s the link to the full script in GitHub for you to improve and enhance it as you like.

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.

Manage the Mailboxes of ex-Employees

Updated 19 September 2023

As reported in September, a listing of inactive mailboxes is now available in the modern Exchange Online admin center. This prompted some discussion about the management of inactive mailboxes, with some pointing to Microsoft’s recommendation to create an inactive mailbox retention policy to specifically manage inactive mailboxes. While retention policies are not a new feature as alleged by Microsoft, the page contains some good points to consider.

Shared mailboxes are also a valid method of retaining the mailboxes of ex-employees. I don’t discuss that alternative here.

Inactive Mailbox Retention Primer

Briefly, an inactive mailbox is a mailbox belonging to a deleted account. If you run the Get-ExoMailbox cmdlet to return the set of inactive mailboxes, you might see some with a value for the ExternalDirectoryObjectId property, the pointer which connects an Exchange Online mailbox to an Entra ID (Azure AD) account.

Get-ExoMailbox -InactiveMailboxOnly | Format-Table DisplayName, ExternalDirectoryObjectid

DisplayName                                  ExternalDirectoryObjectId
-----------                                  -------------------------
Dongli Pan 
Dylan Webb
Ed Banti
Frank Clonan
Imran Khan                                   b8eef43d-6854-4d77-9e03-745cf2e11e11

The mailboxes with ExternalDirectoryObjectId values belong to user accounts deleted within the last 30 days. During this period, administrators can recover the accounts and reconnect the mailboxes. Once the 30 days lapse, Entra ID permanently removes the account and Exchange Online nullifies the connection between the two objects.

Multiple holds (litigation, in-place eDIscovery, or retention policy) can be present for an inactive mailbox. These holds must be placed while the mailbox is active. Even after their user accounts disappear, inactive mailboxes remain in place until the last hold lapses. At that point, the Managed Folder Assistant cleans up and removes the mailbox.

Administrators can still recover data from inactive mailboxes or restore an inactive mailbox to connect it to a brand-new account, but the link between the original account and mailbox is gone. In a nutshell, inactive mailboxes are a great way for organizations with Office 365/Microsoft 365 E3 and E5 licenses to keep information for ex-employees until the need for their mailboxes disappear. You don’t have to pay anything for inactive mailboxes, no matter how much storage their primary and archives (including auto-expanding archives) occupy.

The Advantage of a Retention Policy for Inactive Mailboxes

A retention policy for inactive mailboxes is often used to gradually clear out information from inactive mailboxes on the basis that old information loses its value to the organization over time. To achieve this goal, the retention policy will:

• Apply only to inactive mailboxes. You can identify the mailboxes individually or by using a distribution list. Up to 1,000 individual inactive mailboxes can be added to a single (static scope) retention policy. If you want to add more, you can create multiple policies. Retention policies using adaptive scopes don’t have the same limitations, and you can identify inactive mailboxes by searching for their mailbox state. Because this process happens automatically and on an ongoing basis, you don’t have to worry about adding new inactive mailboxes to the retention policy.
• Remove content after a set period. Usually, this period ranges from six months to two years. In certain regulatory or legal conditions, an organization might retain mailbox contents for longer periods (I’ve heard of situations where inactive mailboxes are kept for ten years).

If you use a distribution list to add mailboxes to a retention policy with a static scope, remember that this is a one-time operation. Microsoft 365 reads the mailboxes from the list membership and adds them as separate Exchange locations to the retention policy. Any further additions or removals from the distribution list are not synchronized with the locations in the retention policy. Also, Microsoft 365 adds the managers of the distribution list to the policy. All of the above means that using a distribution list to populate a retention policy is strictly a method to add multiple locations to a policy rather than a means of maintaining the set of Exchange locations used by the policy.

The Managed Folder Assistant (MFA) processes inactive mailboxes along with active mailboxes. For instance, if the retention policy mandates the removal of information older than a year old, MFA will scan the mailbox to find any items older than a year and remove these items each time it processes the mailbox. Note that MFA might have to apply several retention policies to an inactive mailbox. If this is the case, the longest retention period applies.

Microsoft says that the advantages of having a specific policy are:

• You can configure the retention policy to retain mailbox content only as long as necessary to meet your organization’s requirement for former employees.
• It’s a good way to identify inactive mailboxes because the retention policy will only be applied to inactive mailboxes.

The first point is correct. The second is technically correct but depends on administrators applying the policy to mailboxes before deleting their user accounts. You can’t apply a retention policy to a mailbox once it becomes inactive. Any attempt through the administrative GUIs or PowerShell fails because the inactive mailbox is not recognized as a valid target.

Microsoft also makes the point that if you use a specific retention policy for inactive mailboxes, you can update the retention settings in one place to apply the new values to all inactive mailboxes. I think this is fair.

Finding Inactive Mailboxes with a Specific Retention Policy

I have doubts about Microsoft’s assertion that having a specific retention policy for inactive mailboxes is a good way to identify inactive mailboxes. Running Get-ExoMailbox -InactiveMailboxOnly is the best way to find the set of inactive mailboxes. To find the set of mailboxes to which a retention policy applies, you would have to examine the InPlaceHolds property of each mailbox to see if it is stamped with the identifier of the retention policy. Something like this would work:

# Find the identifier for the retention policy
$Policy = Get-RetentionCompliancePolicy -Identity "Retention Policy for Inactive mailboxes" | Select-Object -ExpandProperty ExchangeObjectId
# Build search string
$CheckGuid = "mbx" + $Policy.Guid.SubString(0,8) + "*"
[array]$Mbx = Get-ExoMailbox -InactiveMailboxOnly -Properties InPlaceHolds
If (!($Mbx)) {Write-Host "No inactive mailboxes found - exiting"; break} 
Write-Host ("Processing {0} inactive mailboxes..." -f $Mbx.Count)
ForEach ($M in $Mbx)  {
    $Holds = Get-ExoMailbox -Identity $M.UserPrincipalName -Properties InPlaceHolds -InactiveMailboxOnly | Select-Object -ExpandProperty InPlaceHolds
    If ($Holds -like $CheckGuid) { 
        Write-Host ("The in-place hold for Inactive mailboxes applies to mailbox {0} ({1})" -f $M.DisplayName, $M.UserPrincipalName )
    }
} #End ForEach

Note that you’ll need to run the Connect-IPPSSession cmdlet first to connect to the compliance endpoint before running Get-RetentionCompliancePolicy to fetch the identifier for the retention policy. Running this PowerShell will report the exact set of inactive mailboxes assigned the retention policy, so there’s some value in that. Then again, if you use the one retention policy and assign it to mailboxes before deleting their Azure AD accounts, the Get-ExoMailbox cmdlet will return the same set.

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

Using Azure AD Accounts to Accumulate Microsoft Rewards with Bing Searches

Message center notification MC249775 published on April 9 says that tenants can soon allow their users to earn Microsoft Rewards points with their Microsoft Services (MSA) accounts. This is Microsoft 365 roadmap item 70634 and the toggle to turn the feature on or off is now available under Org-wide settings in the Microsoft 365 admin center (Figure 1). Rewards will accumulate from May 10, 2021, but not for government users.

Update April 16: Microsoft said: “At this time we will not be moving forward with rolling out the feature as outlined. We are evaluating changes based on feedback and will announce our new plan via Message center when we are ready proceed.”

Edge Profiles Make it Easy to Sign in

The option says that users connect their Azure AD and Microsoft Rewards account. It’s more accurate to say that before a user can accrue Microsoft Rewards, they must:

• Sign up for Microsoft Rewards using a personal Microsoft account.
• Sign into the browser with their Azure AD (work) account.
• Sign into the browser with their Microsoft account. This account is the one linked to Microsoft Rewards. Microsoft 365 then links the user’s Azure AD and personal accounts.
• Configure the browser to use Bing as the search engine (or go to Bing.com to perform searches). Microsoft doesn’t give people rewards when they use Google, Duckduckgo, or another search engine. The aim here is to create more demand for Bing.

I use Edge as my default browser and have work and personal profiles. The work profile uses my Azure AD account; the personal profile uses my MSA account.

Microsoft Rewards is currently available in a limited set of countries (the page says that Microsoft will gradually introduce the program “across the globe”). If your tenant is located outside one of the supported countries, you might not have seen MC249775.

Even More Bing

Optionally, if an organization wishes to make more use of Bing, they can configure Microsoft Search in Bing to include information from Office 365 sources (Teams, Yammer, SharePoint Online and OneDrive for Business, but not Exchange Online). Figure 2 shows an example of a Bing search in Edge configured to include work results. In this instance, we can see that the search has found some Teams and Yammer conversations. The Microsoft Rewards counter in the top right-hand corner tells me how diligent my collection of rewards has been (not very).

Obvious Attempt to Drive Bing Usage

I guess it’s unsurprising that Microsoft should use every means at their disposal to drive Bing usage. You could say that Microsoft shouldn’t try to take advantage of the captive Office 365 audience. The opposing view is that it’s up to a tenant to decide whether to enable the feature and the toggle is easily accessible in the Microsoft 365 admin center.

A more pragmatic perspective is that in many cases, users make their own minds up about their preferred search engine. Unless the organization insists that they use Bing, they might make another decision. And if they’re happy to use Bing, at least now they can collect some rewards (cynics will say that the rewards are necessary to tolerate the search results produced by Bing, but that’s a discussion for another day).