Use Inbound and Outbound Shared User Profiles to Reveal the Ins and Outs of Membership in Teams Shared Channels

In August 2022, I discussed how to use the Get-AssociatedTeam cmdlet to report the membership of channels in teams for users within a tenant. It’s a useful cmdlet that includes the ability to report membership of shared channels in other tenants. In most cases, the reports that can be generated from the data returned by the Get-AssociatedTeam cmdlet meet the needs of administrators to know what channels users access.

Microsoft 365 often offers multiple ways to report data. In this instance, Azure AD supports shared user profile resources created for use with Azure AD B2B Direct Connect, the underlying cross-tenant access mechanism for shared channels.

• An inbound shared user profile represents an Azure AD user from an external Azure AD tenant whose profile data is shared with your tenant. The profile data is used by applications like Teams to display information about the inbound user in shared channels.
• Conversely, an outbound shared user profile represents Azure AD users from your tenant who share their profile information when they access resources in other Azure AD tenants.

Essentially, when a shared channel owner invites an external user to become a member of the channel and that user confirms their acceptance, Azure AD creates an inbound shared user profile to note this fact. Azure AD creates an outbound shared user profile when a user from your tenant becomes a member of a shared channel hosted by another tenant. For example, Figure 1 shows the membership of a Teams shared channel. The users marked with (External) have inbound shared user profiles.

Using PowerShell to Report Shared User Profiles

The Microsoft Graph PowerShell SDK contains cmdlets to fetch information about unbound and outbound user profiles. With consent for the CrossTenantUserProfileSharing.Read.All permission, you can connect to the Graph and run these commands:

Connect-MgGraph CrossTenantUserProfileSharing.Read.All
Select-MgProfile beta
Get-MgDirectoryOutboundSharedUserProfile

UserId
------
08dda855-5dc3-4fdc-8458-cbc494a5a774
5b52fba5-349e-4624-88cd-d790883fe4c4
a221d10f-e0cf-4a1d-b6a2-4e844670f118
cad05ccf-a359-4ac7-89e0-1e33bf37579e
eff4cd58-1bb8-4899-94de-795f656b4a18

The output is a list of identifiers for Azure AD user accounts, so it’s not very exciting. IApart from not listing account names, the output doesn’t tell us what outbound tenants are accessed. To get that information, we must run the Get-MgDirectoryOutboundSharedUserProfileTenant cmdlet for each account. The output of that cmdlet is a list of tenant identifiers, which we can resolve to discover the tenant name. Here’s the code:

[array]$Users =  Get-MgDirectoryOutboundSharedUserProfile | Select-Object -ExpandProperty UserId
ForEach ($User in $Users) {
   $UserData = Get-MgUser -UserId $User
   [array]$TenantNames = $Null; $TenantDisplayNames = $Null
   [array]$TenantIds = Get-MgDirectoryOutboundSharedUserProfileTenant -OutboundSharedUserProfileUserId $User | Select-Object -ExpandProperty TenantId
   If ($TenantIds) {
       ForEach ($TenantId in $TenantIds) {
         $Uri = ("https://graph.microsoft.com/beta/tenantRelationships/findTenantInformationByTenantId(tenantId='{0}')" -f $TenantId.ToString())
         $ExternalTenantData = Invoke-MgGraphRequest -Uri $Uri -Method Get  
         $TenantNames += $ExternalTenantData.DisplayName
       }
       $TenantDisplayNames = $TenantNames -join ", "    
   }
   Write-Host ("User {0} has outbound shared profiles in these tenants {1}" -f $UserData.DisplayName, $TenantDisplayNames)
}

User Sean Landy has outbound shared profiles in these tenants o365maestro
User Ken Bowers has outbound shared profiles in these tenants o365maestro
User Tony Redmond has outbound shared profiles in these tenants o365maestro, Microsoft Community & Event Tenant

Getting Inbound Shared User Profiles

The Get-MgDirectoryinboundSharedUserProfile cmdlet lists information stored about inbound shared user profiles. We can’t read Azure AD to find information about these users because they come from other tenants. This is what the cmdlet returns:

Get-MgDirectoryinboundSharedUserProfile | Format-List

DisplayName          : Alex Wilber
HomeTenantId         : 22e90715-3da6-4a78-9ec6-b3282389492b
UserId               : a6453657-2058-4c15-a38a-b0a94f0ed737
UserPrincipalName    : AlexW@o365maestro.onmicrosoft.com
AdditionalProperties : {}

Once again, we can resolve the tenant identifier to make the information more understandable:

[array]$Guests = Get-MgDirectoryinboundSharedUserProfile
ForEach ($Guest in $Guests) {
    $Uri = ("https://graph.microsoft.com/beta/tenantRelationships/findTenantInformationByTenantId(tenantId='{0}')" -f $Guest.HomeTenantId.ToString())
    $ExternalTenantData = Invoke-MgGraphRequest -Uri $Uri -Method Get  
    Write-Host ("User {0} comes from tenant {1}" -f $Guest.DisplayName,  $ExternalTenantData.DisplayName)
}

User Christina Smith comes from tenant CM Portal Solutions
User Nicolas Blood comes from tenant NBConsult
User Alex Wilber comes from tenant o365maestro
User Tom Jones comes from tenant o365maestro
User Vlad Bitton comes from tenant vNext Solutions

The interesting thing here is that I didn’t recognize some of the user names and tenants that Azure AD stored inbound shared user profiles for. However, given that the names were all MVPs and my tenant supported many beta versions of Teams shared channels in the past, it’s entirely possible that the profiles originated in a test. Azure AD doesn’t register a date to tell you when it created a profile, so there’s no clue from that source.

Tracking External Access to Teams Shared Channels

My previous article describes how to create a report about the users accessing shared channels in your tenant. The added piece of information covered here is finding the set of Azure AD accounts from your tenant who use Azure AD B2B Connect to access resources in other tenants. That’s a valuable nugget if you want to track who’s interacting with Teams shared channels externally.

New Token Protection Conditional Access Policy Session Control

Now that the removal of basic authentication from Exchange Online has made password spray attacks far less likely to compromise user credentials for an Azure AD account, those who want to sneak into a tenant need another avenue to explore. Microsoft’s Detection and Response Team (DART) reports an increase in adversary-in-the-middle phishing attacks where attempts are made to capture user credentials and the tokens used by applications to access protected resources like user mailboxes or SharePoint Online sites.

If you need further evidence of the techniques used to compromise and exploit tokens, this article by Edwin David is a good read. It’s a reminder that although all Azure AD accounts should be protected by multi-factor authentication, MFA is not a silver bullet and attackers will continue to develop methods to work around barriers erected by tenants.

Token Binding to Devices

Which brings me to a new session control for Azure AD conditional access policies designed to protect sign-in tokens (refresh tokens) using token protection. The control, which has just appeared in preview, creates a “cryptographically secure tie” between the token and the device Azure AD issues the token to (aka token binding). Without the client secret (the device), the token is useless to an attacker. The device needs to run Windows 10 or above and be Azure AD joined, hybrid Azure AD joined, or registered in Azure AD. When this is the case, a user’s identity is bound to the device.

Microsoft notes that “Token theft is thought to be a relatively rare event, but the damage from it can be significant.” One interpretation of this statement is that Microsoft knows the bad guys are working on using more token thefts, so they’re investing to get ahead of the curve.

Clients

It’s a preview, so some limitations are inevitable. For instance, conditional access policies with token protection can only process connections from tenant accounts and can’t handle inbound connections from guest accounts. Token protection supports Microsoft 365 apps for enterprise subscription versions of desktop clients accessing Exchange Online and SharePoint Online. Perpetual versions of the Office apps aren’t supported. The apps include the OneDrive sync client (22.217 or later) and the Teams desktop client (1.6.00.1331 or later). These are relatively old versions already, so meeting the software requirements should not be a big issue.

PowerShell clients accessing Exchange Online, SharePoint Online, or these endpoints via the Microsoft Graph APIs are unsupported by conditional access policies with token protection, meaning that users are blocked from accessing Exchange and SharePoint. The same is true for some other apps like Visual Studio and the Power BI desktop app. It also applies to connections generated using OWA and Outlook mobile.

In effect, the users selected to test a token protection condition access policy (Figure 1) should be those who don’t need to use any of the unsupported clients and are happy to limit their access to Outlook desktop and Teams.

Users who don’t meet the policy requirements (like attempting to sign in with OWA, the browser version of Teams, or the SharePoint Online or OneDrive for Business browser clients) will fail to connect (Figure 2).

In fact, any Office browser app that connects to Exchange or SharePoint resources will be inaccessible. For instance, Viva Engage (Yammer) will start up before immediately exiting when the client attempts to access SharePoint Online.

A Pointer to the Future

Given the relative lack of support by Microsoft 365 apps for token protection, this preview feature is unlikely to get the same range of testing as other recent extensions to conditional access policies (like authentication strength). That being said, if token theft becomes as biga  problem as some security commentators think it might, it will be good to have methods like token protection ready to repel the threat.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Use the Revoke-MgUserSignInSession cmdlet to Revoke Access for Azure AD Accounts

Microsoft’s documentation for how to revoke access to an Azure AD account describes the use of the Revoke-AzureADUserAllRefreshToken cmdlet from the Azure AD PowerShell module. That’s unfortunate because of the upcoming deprecation of that module. If we consult Microsoft’s cmdlet map to find the appropriate replacement cmdlet from the Microsoft Graph PowerShell SDK, it turns out to be Invoke-MgInvalidateUserRefreshToken, which “Invalidates all of the user’s refresh tokens issued to applications (as well as session cookies in a user’s browser), by resetting the refreshTokensValidFromDateTime user property to the current date-time.”

The guidance could not be clearer. Any script using the Revoke-AzureADUserAllRefreshToken should replace it with the Invoke-MgInvalidateUserRefreshToken cmdlet. Except when you discover that the SDK also includes the Revoke-MgUserSignInSession cmdlet. This cmdlet is in beta and its documentation is less than perfect (or totally inadequate), but the salient fact is that it performs the same task. These two commands have the same effect:

$RevokeStatus = Revoke-MgUserSignInSession -UserId $UserId
$InvalidateStatus = Invoke-MgInvalidateUserRefreshToken -UserId $UserId

Up to now, the Office 365 for IT Pros eBook (chapter 5) documented how to use the Invoke-MgInvalidateUserRefreshToken cmdlet to block an Azure AD user account. Finding the alternative cmdlet used in a Microsoft example provoked a query to ask why two cmdlets did the same thing.

Microsoft’s response is that they built Invoke-MgInvalidateUserRefreshToken for a specific purpose. The cmdlet still works and has the significant benefit of being part of the production (V1.0) module. However, Microsoft’s recommendation is to use Revoke-MgUserSignInSession in the future, even if it is in the beta module.

Use the Beta SDK Module

Using cmdlets from the beta module might seem problematic but it’s not. For instance, if you want to do any license management with the Microsoft Graph PowerShell SDK, you must use the beta module because the production version of cmdlets like Get-MgUser don’t return any license information. It’s one of those important to know things when converting scripts to use the SDK.

Revoking Access for an Azure AD Account is the Start

Of course, revoking access for an Azure AD account might just be the first step in the process of securing the account. Revoking access will force the user to reauthenticate, but if you want to stop further access to the account, you must:

• Disable the account.
• Change the password.
• (Optionally) disable any devices registered to the account.

Disabling the account and changing the password are both critical events that force Azure AD to signal applications that support continuous access evaluation (CAE) to terminate sessions. Many of the important Microsoft 365 apps like Outlook and SharePoint Online support CAE (see current list).

This PowerShell code does the necessary, if the account signing into the Microsoft Graph PowerShell SDK holds at least the User Administrator role:

Connect-MgGraph -Scopes Directory.AccessAsUser.All
Select-MgProfile Beta
$Account = Read-Host "Enter the User Principal Name of the account to block"
$User = (Get-MgUser -UserId $Account -ErrorAction SilentlyContinue)
If (!($User)) { Write-Host ("Can't find an Azure AD account for {0}" -f $Account); break }
Write-Host ("Revoking access and changing password for account {0}" -f $User.DisplayName)  
# Disable the account
Update-MgUser -UserId $User.Id -AccountEnabled:$False
# Create a password profile with details of a new password
$NewPassword = @{}
$NewPassword["Password"]= "!NewYorkCity2022?"
$NewPassword["ForceChangePasswordNextSignIn"] = $True
Update-MgUser -UserId $User.Id -PasswordProfile $NewPassword
# Revoke signed in sessions and refresh tokens
$RevokeStatus = Revoke-MgUserSignInSession -UserId $User.Id
# Disable registered devices
[array]$UserDevices = Get-MgUserRegisteredDevice -UserId $User.Id
If ($UserDevices) {
ForEach ($Device in $UserDevices) {
    Update-MgDevice -DeviceId $Device.Id -AccountEnabled $False}
}

Figure 1 shows that after running the script, the user account is disabled and the SignInSessionsValidFromDateTime property (referred to as refreshTokensValidFromDateTime above) is set to the time when the Revoke-MgUserSignInSession cmdlet ran.

Consequences of Disabling an Azure AD Account

In a scenario like a departing employee, losing access to some teams might not be important. If it is, or in situations where it’s necessary to preserve the account in full working order, an alternative to disabling an account is to change its password and revoke access. The account remains active but is inaccessible unless those attempting to sign-in know the new password.

Example of Knowledge Gap

In July 2022, I wrote about the opening of a knowledge gap as tenants transitioned from the depreciated Azure AD and Microsoft Online Services (MSOL) modules. Having two cmdlets that revoke user access to pick from is one too many. It doesn’t help people migrate scripts to use the Microsoft Graph PowerShell SDK. But at least the recommendation is clear: use Revoke-MgUserSignInSession.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Creating a Report From Azure AD Manager and Direct Reports Data with PowerShell

It’s always good to be able to build on the knowledge contributed by someone else. This brings me to a post by Vasil Michev, the esteemed technical editor for the Office 365 for IT Pros eBook. The post covers how to Create an All Managers group in Microsoft 365 and covers how to do this in different ways for different types of group. It brought back some memories of Microsoft’s initiative in April 2017 to auto-generate a Microsoft 365 group for every manager with its membership populated with the manager’s direct report.

Retrieving Azure AD Manager and Direct Reports

In any case, Vasil discussed how the Get-Recipient (but not Get­ExoRecipient) and Get-User cmdlets have a filter to find accounts that have direct reports using the backlink from users to their managers. By definition, these accounts are managers, so you can use the commands as the basis to control the membership of distribution lists, dynamic distribution lists, or Microsoft 365 groups.

Get-Recipient -Filter {DirectReports -ne $Null}
Get-User -Filter {DirectReports -ne $Null}

The only problem is that the output of the two cmdlets is imperfect. The cmdlets find accounts with direct reports, but their results include some accounts that don’t have any direct reports. In my tenant, I found that the cmdlets found three accounts with no direct reports. I believe that these accounts had direct reports at some point in the past, but they don’t now. For instance, when I queried the accounts to see the set of direct reports reported by Get-User, I see a blank:

Get-User -Identity Ben.Owens | Select-Object Name, Manager, DirectReports

Name      Manager      DirectReports
----      -------      -------------
Ben Owens tony.redmond {}

The same is true when viewing details of the account through Exchange address lists, the organization chart in Teams, or the Outlook Org Explorer (Figure 1).

According to message center notification MC492902 (updated 7 February 2023), the Outlook Org Explorer is only available to users with the “Microsoft Viva Suite” or “Microsoft Viva Suite with Glint” licenses, which is why you might not be seeing it. Originally, Microsoft said that the Org Explorer would be available to accounts with Microsoft 365 E3/E5 or Microsoft 365 Business licenses, but they decided to align this feature with the Viva initiative. The Org Explorer is not available for OWA.

My conclusion is that synchronization between Azure AD and Exchange Online leaves some vestige behind in the DirectReports property following the removal of the last direct report for a manager. It’s enough to stop the filter working accurately.

Reporting Azure AD Managers and Direct Reports

Which brings me back to considering how to report the links between managers and employees using the information stored in Azure AD. I covered this ground in an article two years ago, but I didn’t realize the flaw in Get-User at the time, so the script I wrote (available from GitHub) can produce incorrect results. A different approach is needed.

Given that Azure AD is the source of the information, it makes sense to use Graph APIs to retrieve data. I chose to use the Microsoft Graph PowerShell SDK to avoid the necessity to create a registered app.

The new script (also available from GitHub) does the following:

• Finds user accounts with at least one assigned license. This step filters out accounts created for purposes like room and shared mailboxes.
• Use the Get-MgUserManager cmdlet to check each account to see if it has a manager. If not, note this fact.
• Use the Get-MgUserDirectReport cmdlet to see if the account has direct reports. If it does, record the details of the manager’s reports.
• Create an HTML report detailing each manager and their reports.
• At the end of the report, add a section detailing accounts without managers.
• Output the HTML file and a CSV file containing details of managers and reports.

Figure 2 shows some example output. Because the code is PowerShell, it’s easy to tweak it to include other information about each employee.

Go to the Source to Find Azure AD Managers and Direct Reports

It’s never nice to discover that a technique you thought worked well is no longer fit for purpose and it’s necessary to rework a script. The Get-User and Get-Recipient cmdlets return accurate information about managers and direct reports, but only if managers always have at least one report. I guess that’s possible, but it’s better to make sure by using Graph APIs to retrieve data about managers and their direct reports. At least then you’ll know that your reports show the same reporting relationships that surface elsewhere in Microsoft 365.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Old Limit with SignInActivity was 999 – New Limit for Azure AD Accounts is 120

Because it retrieves details of Azure AD accounts, the List Users API is one of the most heavily used of the Microsoft Graph APIs. It also underpins the Get-MgUser cmdlet from the Microsoft Graph PowerShell SDK. Microsoft generates the cmdlet from the API using a process called AutoRest, which means that changes made to the API show up soon afterward in the cmdlet.

I’ve documented some of the issues that developers must deal with when coding with the cmdlets from the Microsoft Graph PowerShell SDK. The cmdlets have been stable recently, which is a relief because tenants are migrating scripts from the Azure AD and MSOL modules. However, last week an issue erupted in a GitHub discussion that caused a lot of disruption.

In a nutshell, if you use List Users to fetch Azure AD accounts and include the SignInActivity property, the API limits the page size for results to 120 items. Calls made without specifying SignInActivity can set the page size to be anything up to 999 items.

An Unannounced Change

To help manage demand on the service, all Graph API requests limit the number of items that they return. To retrieve all matching items for a request, developers must fetch pages of results until nothing remains. When a developer knows that large numbers of items must be fetched, they often increase the page size to reduce the number of requests.

Microsoft didn’t say anything about the new restriction on requests that fetch Azure AD account data with sign-in activity. Developers only discovered the problem when programs and scripts failed. I first learned of the issue when some of the users of the Office 365 for IT Pros GitHub repository reported that a Graph request which included a $top query parameter to increase the page size to 999 items failed. For example:

$uri = "https://graph.microsoft.com/beta/users?`$select=displayName,userPrincipalName,mail,id,CreatedDateTime,signInActivity,UserType&`$top=999"
[array]$Data = Invoke-RestMethod -Method GET -Uri $Uri -ContentType "application/json" -Headers $Headers
Invoke-RestMethod : The remote server returned an error: (400) Bad Request.
At line:1 char:16
+ ... ray]$Data = Invoke-RestMethod -Method GET -Uri $Uri -ContentType "app ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest)
   [Invoke-RestMethod], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.I

As shown in Figure 2, testing with the Get-MgUser cmdlet revealed some more information in the error (“Cannot query data for more than 120 users at a time”). This was the first time I learned about a query limit:

According to a response reported in the GitHub discussion, Microsoft support reported

“The PG have confirmed that this endpoint will be transitioning from beta to General Availability (GA).

As part of this transition, changes to its behavior has been made, this includes not requesting more than 120 results per call. They recommend requesting less than 120 results per call, which can be done by setting the top parameter to, say 100.”

It’s likely that Microsoft made the change because retrieving sign-in activity data for Azure AD accounts is an expensive operation. Reducing the page size to 120 possibly makes it easier to process a request than if it asked for 999 items.

Beta Version of List Users Moving to Production

When the product group (PG) says that the endpoint is transitioning from beta to GA, it means that instead of needing to use https://graph.microsoft.com/beta/users to access sign-in activity, the data will be available through https://graph.microsoft.com/V1.0/users. If you use the Microsoft Graph PowerShell SDK, you won’t have to run the Select-MgProfile cmdlet to choose the beta endpoint. Moving the beta version of the API to the production endpoint is a good thing because there are many other account properties now only available through the beta endpoint (like license assignments).

If you use the Microsoft Graph PowerShell SDK, the Get-MgUser cmdlet is unaffected by the change if you specify the All parameter. This is because the cmdlet handles pagination internally and fetches all pages automatically without the need to specify a page size. For instance, this works:

$AccountProperties = @( ‘Id’, ‘DisplayName’, ‘SignInActivity’)
[array]$Users = Get-MgUser -All -Property $AccountProperties | Select-Object $AccountProperties

Moving to Production

Although it’s good that Microsoft is (slowly) moving the beta versions of the List Users API towards production, it’s a pity that they introduced a change that broke so many scripts and programs without any warning. At worse, this so exhibits a certain contempt for the developer community. At best, it’s a bad sign when communication with the developer community is not a priority. That’s just sad.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Last Gasp for Azure AD PowerShell Deprecation as June Deadline Approaches

Microsoft’s original announcement about the deprecation of the Azure AD and Microsoft Online Services (MSOL) PowerShell modules goes back to 26 August, 2021. At that time, Microsoft wanted to have the retirement done by June 30, 2022. Customer pushback duly ensued and Microsoft decided to push the dates out another year to allow customers more time to upgrade their scripts.

This was the only sensible course of action. The Graph APIs for dealing with many Azure AD account interactions, especially license assignments, were sadly undocumented. The suggestion of using cmdlets from the Microsoft Graph PowerShell SDK ran into difficulties because the production version (V1.0) of cmdlets like Get-MgUser didn’t return license information. Allied to that, the documentation for the SDK cmdlets remains poor and inscrutable at times.

Time Helped Improve the Situation

Time is a great healer and allows for improvements to be made. The Graph Explorer works better and the Graph X-Ray tool reveals details about how Microsoft uses Graph calls in places like the Azure AD admin center (or rather, the Microsoft Entra admin center).

In addition, Microsoft developed documentation to help people migrate scripts, including a cmdlet map to translate old cmdlets to new. The important thing to realize here is that automatic translation from one set of cmdlets to the other is difficult. People code in PowerShell in different ways and it’s not always clear how to translate code to a new cmdlet. Some community-based projects do exist (here’s a new one that is spinning up), but any attempt to covert to SDK cmdlets must take the SDK foibles into consideration, like its fundamental disregard for the PowerShell pipeline.

But mostly time allowed people to share their knowledge about how to use SDK cmdlets to automate administrative tasks like user and group management. For instance, here’s a writeup I did about license management for Azure AD accounts using the SDK, and here’s another covering how to create a license report for Azure AD accounts.

What Will Happen Between Now and June 30, 2023

But time eventually runs out and we are now at the point where Microsoft is progressing the retirement of the Azure AD and MSOL modules. Here’s my understanding of the situation based on some discussions with Microsoft:

• The licensing cmdlets from the Azure AD and MSOL modules do not work for tenants created after November 1, 2022. These tenants must use Graph APIs or SDK cmdlets to manage license assignments for Azure AD accounts.
• For all tenants, March 31, 2023, marked the official retirement date for the licensing cmdlets in the Azure AD and MSOL modules.
• Retirement doesn’t mean “stop working on March 31.” Instead, Microsoft now throttles cmdlets that assign licenses to Azure AD accounts so that they’re not as responsive as before. This is in line with the warning posted on July 29, 2022, that “Customers may notice performance delays as we approach the retirement deadline,” The affected cmdlets are:
  • Set-MsolUserLicenseSet-AzureADUserLicense
  • New-MsolUser (where the creation of an account includes a license assignment)

• From now on, Microsoft will increase the throttling rate to make the licensing cmdlets less attractive. Shortly, Microsoft will initiate short outages to gauge the effect of stopping the cmdlets completely. Doing this allows Microsoft to understand if any major pain is caused to customers.
• Before or on June 30, 2023, the licensing cmdlets “will no longer receive a successful response.” In other words, no throttling, no short delays, just nothing. The exact date when the shut-off happens depends on the information Microsoft gains about customer usage. What’s for sure is that the licensing cmdlets in the Azure AD and MSOL modules will stop working soon.
• After June 30, 2023, the Azure AD and MSOL modules are unsupported. Cmdlets may still run, but no guarantees exist that they will be successful. Given that the modules have been around for many years, you could anticipate that the cmdlets that don’t interact with the Microsoft 365 licensing platform will be OK. You might be right, but you don’t know how long that state will last because the modules are officially retired.

The Bottom Line About Azure AD PowerShell Deprecation

The Azure AD and MSOL modules are now on borrowed time. If you haven’t already started to upgrade scripts to use the Graph APIs or the Microsoft Graph PowerShell SDK, scripts that use these modules could encounter an unpleasant failure very soon. It’s time to get busy to make sure that all scripts can run after June 30, 2023.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Example of Ongoing Changes in Microsoft 365

I guess we all knew it was coming (after all, Microsoft published message center notification MC477013 in December 2022), but the news that the Microsoft Entra admin center (Figure 1) will replace the Azure AD admin center from April 1, 2023 is yet another example of the ongoing and constant changes in Microsoft 365. Those changes range from a massive introduction of fundamental new functionality, like Microsoft 365 Copilot, to a small update to how something appears.

In this instance, Microsoft portraits the replacement of the Azure AD admin center as a unification of its identity management platform (Azure AD) with its identity and access solutions. Another way of looking at the move is that it allows Microsoft to bring those identity and access solutions to the attention of some organizations who wouldn’t otherwise consider them. Every time you open the Entra admin center, identity governance and other solutions will be there to discover. To be fair to Microsoft, if you access Azure AD from the Microsoft 365 admin center, the link goes direct to the Azure AD section of the Entra admin center.

Microsoft says that the old Azure AD admin center will continue to function until May 2023. Azure customers who don’t use Microsoft 365 can manage Azure AD through the Azure portal.

Many Rebranding Campaigns

Microsoft is well known for its love of rebranding campaigns. Microsoft 365 has steadily embraced a huge ecosystem, including the subscription version of the Office apps, and we’ll probably have to rename the next version of the Office 365 for IT Pros eBook to use Microsoft 365 instead. Microsoft Purview is another example, albeit one that at least collected together a bunch of different compliance solutions under a common banner. Defender did the same for security solutions, and so on.

Sometimes, Microsoft makes changes for what appears to be no good reason. Take the announcement in MC532194 (March 23) that Teams now uses an “EA” indicator instead of “P” when users run the preview version of the software. I’m still wondering why “Early Access” is any better than “Preview.” The change appears to deliver zero added value except that it aligns with the nomenclature Microsoft uses in places like the Office Insider program. From my perspective, the change meant that we needed to update Chapter 15 in the Office 365 for IT Pros eBook and our article about Teams preview.

Naming Changes Affect the Wider Technical Community

Microsoft makes naming changes for its own reasons. I doubt that they take the wider community into consideration when they decide on these updates but the effect of a naming change or rebrand ripple through documentation and training. For instance, video training companies that have a program telling people how to use the Azure AD admin center must now update their collateral and perhaps even reshoot some or all of their video. That’s a big cost for the production company.

The same is true for books that cover Azure AD or any of the other topics affected by naming or branding changes. Switching references from the Azure AD admin center to the Entra admin center isn’t quite as simple as doing a search and replace. Microsoft often takes the opportunity to rename options in administrative consoles when they change things. Data lifecycle management is now the place in the Purview compliance portal that was once known as the location for the management of retention labels and policies. The justification is that the section of the portal now spans additional options such as adaptive scopes, policy lookup, and legacy Exchange mailbox retention policies and tags (both of which are still very useful).

Changes in Microsoft 365 Will Keep on Happening

I don’t expect Microsoft to poll the technical community before they change the name of anything inside Microsoft 365. It won’t happen and would be unreasonable. Microsoft will continue to make changes how and when they like, even if the outcome displeases some. Their decision to stop accepting inbound email from old and vulnerable on-premises Exchange servers to protect Exchange Online is a good example of a change that inflamed many opinions. However, we don’t get to vote.

Content producers like Office 365 for IT Pros simply need to be proactive and respond to Microsoft changes the best way we can. In that respect, being able to publish a complete new book every month is a major advantage, even if it takes a lot of hard work. Now back to the task of looking for all those references to the Azure AD admin center – a change that we’ll probably make in the May 2023 update.

Introducing Authenticator Lite

Without too much fuss, Microsoft introduced the preview of a new “surface” (way) for users to complete multi-factor authentication (MFA) challenges. The new method is a companion app for the Microsoft Authenticator app and is covered by Microsoft 365 roadmap item 122289 and is slated for roll-out in May 2023.

Azure AD already covers a variety of methods to satisfy MFA challenges. The methods are categorized from weak to strong in terms of their ability to resist attacks and conditional access policies can insist that a connection uses a certain strength of MFA response before it is accepted. “Authenticator lite” is rated as strong as the Authenticator app because it’s basically code taken from Authenticator and built into other Microsoft apps. In addition, Authenticator lite only supports push notifications with number matching and one-time codes, which are less likely to provoke MFA fatigue than the traditional “click here to approve” response.

Outlook Mobile Leads the Way

Outlook mobile (iOS 4.2309.0, Android 4.2308.0, or higher versions) is the first Microsoft 365 app to pick up the Authenticator Lite code. Some might ask why Microsoft choose Outlook as the test case. I think it’s because Outlook is likely the most heavily used mobile client. The last time Microsoft gave a number for Outlook mobile (April 2019), they reported that Outlook for iOS and Android had more than 100 million users. At that time, Office 365 reached 180 million monthly active users. Now Office 365 is up around 400 million monthly active users. Assuming Outlook mobile has kept pace, it has around 220 million monthly active users.

Building MFA responses into the most popular mobile client is a great way of making MFA easier for organizations to deploy. Microsoft wants customers to deploy MFA. They also want customers to use strong MFA responses and move away from methods like SMS text-based responses. The recent introduction of the Azure AD system-preferred authentication policy to force Azure AD to select the strongest available authentication method for a user when it issues a challenge is a pointer to the future. Who needs to resort to an SMS response when you can respond to a number challenge within Outlook? It makes absolute sense.

Update the Azure AD Authentication Methods Policy

If you’re interested in trying Authenticator Lite with Outlook mobile, the steps to make everything happen are covered in a Microsoft article. In summary:

First, use a Graph API PATCH request to update the Azure AD Authentication Methods Policy to update the companionAppAllowedState setting from disabled (the default) to enabled. The easiest way to do this is with the Graph Explorer (make sure to sign in with an administrator account because you’ll need to consent to the Policy.ReadWrite.AuthenticationMethod permission to update the policy. The relevant lines for the policy in my tenant look like those shown in Figure 1. The state is enabled and the policy is targeted at a group of users with an identifier of “all_users.” This is a special identifier that instructs Azure AD to apply the policy setting to all tenant users. If you want to limit the policy to a specific set of users, create a security group with those users as members and update the authentication methods policy with the group identifier.

The updated policy might take a little time to become effective and people can respond to MFA challenges from Outlook. Only accounts enabled to use the Authenticator app (with the mode set to Push or Any) to respond to MFA challenges can use Authenticator Lite within Outlook, and responses are limited to number matching or one-time codes. It’s important to realize that if the Microsoft Authenticator app is present on a device, Outlook won’t attempt to use Authenticator Lite and instead refers all authentication challenges to the full Authenticator app.

It’s also important to realize that the code incorporated into Outlook supports fewer options than the full Authenticator app. For instance, it doesn’t support Self-Service Password Reset (SSPR). The Authenticator app is a more appropriate option for users who need functionality like handling MFA responses for other cloud services like Twitter and GitHub.

MFA Responses for the Masses

I like any action that reduces the friction of MFA deployment and operation for both organizations and users. Authenticator Lite falls into this category. Although I won’t use the new capability because I need the power of the full Authenticator app, I think that Authenticator Lite will meet the needs of most Microsoft 365 users when it comes to responding to MFA challenges.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.