Azure AD B2B Collaboration and Guest Accounts for SharePoint Sharing

Two recent message center notifications highlight closer integration between SharePoint Online and Azure AD. MC526130 (11 March) says that new tenants created after March 31, 2023 will automatically enable the SharePoint Online integration with Azure B2B integration. Existing tenants aren’t impacted by this change. The associated update, also scheduled for roll-out in late March, is MC525663 (10 March). The news here is that SharePoint Online site sharing will use the Azure B2B Invitation manager instead of the legacy SharePoint Invitation Manager (Microsoft 365 roadmap item 117557).

Rationalization Around Azure AD

The two updates rationalize existing sharing methods with external users and focus on Azure AD as the driving force for managing invitations. The journey toward Azure AD B2B Collaboration started in 2021, so it’s been a while coming. The project makes a lot of sense for both customers and Microsoft (their gain is through reduced engineering expenses).

Ten years ago, it was reasonable for SharePoint to manage site sharing invitations. Today, when the site collection-based architecture is replaced by single-sites and most sharing occurs through Microsoft 365 groups and Teams, it’s illogical for SharePoint Online to have its own mechanism. 280 million monthly active Teams users create a lot of work for SharePoint.

Another factor is that site sharing with external users is a relatively uncommon action today. Most external users join groups or teams and gain access to the group-connected site. Although non-group connected sites do exist, they’re in the minority and some of those sites (like hub and communication sites) aren’t candidates for sharing with external people. And of course, even site owners might be blocked from sharing sites by a sensitivity label.

Time to Review Applicable Policies

Overall, I don’t think the change will disrupt many organizations. As Microsoft notes “You may want to review your Azure B2B Invitation Manager policies.” Two policies are worthy of note. The first is the Azure B2B Collaboration policy, which includes an allow or deny list (but not both) of domains.

The policy is now found under Collaboration restrictions in the External Identities section of the Azure AD admin center (Figure 1). It is commonly used to block sharing with consumer domains (deny list) or to restrict collaboration to a set of known domains belonging to partner organizations (allow list). If the organization already supports guest accounts, it’s likely that the collaboration policy already exists. Even so, changes like this are useful reminders of the need for regular review of any policy that affects how external people access tenant resources.

Azure AD cross-tenant access policies are a more powerful and flexible mechanism to control external access through both Azure B2B collaboration and Azure AD direct connect (used for Teams shared channels). Cross-tenant access policies are still relatively new and don’t need to be implemented unless required for a specific reason, so your tenant might not use them yet.

Although the Azure AD B2B Collaboration policy is likely to dominate for the immediate future, over time, I expect a slow transition to take advantage of the granular control available in cross-tenant access policies. When an organization changes over, SharePoint Online will take advantage. Leveraging advances made in Azure AD is an excellent reason for SharePoint Online to embrace Azure AD more fully.

Review Guest Accounts Too

Azure AD B2B collaboration works but that doesn’t mean that you don’t need to manage guest accounts. As more sharing happens, more guest accounts end up in your Azure AD. Some guest accounts are used once to share a document. Others are in ongoing use as guest members of groups and teams access shared documents. It’s a good idea to keep an eye on guest accounts and remove them as they become obsolete.

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.

An Unreasonable Azure AD Sign-in Frequency Creates a Barrier to Productivity

I had an unpleasant surprise this week when the security team for one of the companies where I have a guest account decided to improve tenant security. I strongly support any effort to improve tenant security, especially when the effort means better use of multi-factor authentication. It’s a topic I’ll cover during the TEC Europe 2023 tour in London, Paris, and Frankfurt in April. Registration for those events is now open.

It’s always important to take a pragmatic and practical view of security and not to implement anything that has a significant impact on user productivity. All change can impact users, but most of the time people learn to live with change and it’s not disruptive. Unfortunately, deciding to increase the user sign-in frequency for Azure AD accounts can be extraordinarily disruptive if you go too far.

Azure AD sign-in frequency is the period before a user must sign in again when attempting to access a resource, like opening a SharePoint Online document, creating a message with OWA, or accessing a Teams channel. By default, Azure AD uses a rolling 90-day window for its sign-in frequency. In other words, once you successfully sign-into a tenant, Azure AD won’t ask you to sign-in again for another 90 days.

Revoking User Account Access

Ninety days sounds like a long time, and it is. But this period needs to be viewed through the prism of how Azure AD and Microsoft 365 applications work. For example, in early 2022, Microsoft enabled Continuous Access Evaluation (CAE) for all tenants. CAE is a mechanism that allows Azure AD to notify applications of a critical change in the directory, such as an updated password. Applications that understand CAE, like SharePoint Online, revoke existing access for the account to require the user to reauthenticate.

The Microsoft 365 admin center also includes an option to sign users out of all current sessions (Figure 1) to force them to reauthenticate.

Of course, you might want to do more than sign a user out. In some cases, like employee departures, you might want to block future sign-ins. This is an operation that’s easily scripted with PowerShell. For example, this code:

• Retrieves the identifier for an Azure AD user account.
• Disables the account.
• Sets a new password.
• Revokes all refresh tokens.

$UserId = (Get-MgUser -UserId Lotte.Vettler@Office365itpros.com).Id
# Disable the account
Update-MgUser-UserId $UserId -AccountEnabled:$False
# Set a new password
$NewPassword = @{}
$NewPassword["Password"]= "!DoneAndDusted?"
$NewPassword["ForceChangePasswordNextSignIn"] = $True
Update-MgUser -UserId $UserId -PasswordProfile $NewPassword -AccountEnabled:$True
# Revoke refresh tokens
$Status = Invoke-MgInvalidateUserRefreshToken -UserId $UserId

It might take a little time for the full block to be effective because tokens must expire, and clients recognize the need for reauthentication, but it will happen.

How Conditional Access Can Make Guest Accounts Miserable

The reason I had a problem was that the security team updated the conditional access policies for guest users to enforce a 60-minute sign-in frequency (Figure 2). This change had a horrible effect. Guests switching to the tenant with Teams inevitably resulted in an MFA challenge. Opening a document stored in SharePoint Online or OneDrive for Business in that tenant brought an MFA challenge. My day was filled with MFA challenges, except when sending email to people in the tenant to complain about the new policy. Email isn’t affected by conditional access policies.

As Microsoft notes in their documentation, “Based on customer feedback, sign-in frequency will apply for MFA as well.” They understate the matter. Sign-in frequency does apply for MFA too.

I understand the motivation on the part of the security team. Forcing people to reauthenticate before they can access resources is a good thing. Using MFA is a good thing. Forcing MFA challenges every hour must be a brilliant change to make.

Only it isn’t. As an external person working with another company, the change made my productivity much worse, and I doubt that it added one iota to the overall security effectiveness of the tenant. The tenant did not use number matching and additional context for MFA challenges, so the constant MFA challenges were a great example of how user fatigue creeps in as I clicked and clicked again to say “yes, it’s me.” System-preferred authentication wasn’t used either, so while I used the Authenticator app, other guests might use relatively insecure SMS challenge/response.

Overall, the change made it unpleasant to work with the tenant and that’s bad. A one-hour sign-in frequency is just too rigid and strict. I don’t know of any other tenant (where I am a guest) that uses such a short frequency. Most tenants I know of use the 90-day default. Some use 7 days. The most security-conscious (before now) uses a 1-day frequency.

No Best Answer for All Tenants

In truth, I don’t know the best user sign-in frequency to use for either tenant or guest accounts. It all depends on the security posture that an organization wants to assume. But I can say that most tenants would be better off making sure that all accounts use MFA and eliminating the use of the less secure authentication methods before reducing the sign-in frequency. If you’re concerned about guest hygiene (in this case, how secure a guest account is), have a different and more restrictive conditional access policy for guest access while remembering the need to get work done through Azure B2B collaboration. And review guest accounts annually to remove unwanted and obsolete crud.

To me, bringing users along on the journey to better security is a better tactic than ramming heightened security down their throats. It’s always been that way.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Microsoft 365 Tenants Need to Link their Entra ID to Azure Subscription

Tenant administrators are all too aware of the growth of guest user accounts in tenant directories over recent years. The success of Teams and the use of guest accounts in sharing SharePoint Online and OneDrive for Business documents are the biggest factors in driving the growth in guest accounts. As we’ll discuss, some premium features of Microsoft 365 Groups require consideration of Entra ID guest user licensing.

Apart from cluttering up the directory, guest accounts don’t do any harm. You can try to identify and remove obsolete accounts using a variety of methods such as checking the Entra ID sign-in logs to discover the last sign in to the account or using the Office 365 audit log and message tracking logs to figure out if guest accounts are active.

However, one thing you should keep an eye on is the requirement to license guest accounts if you use premium Entra ID features like conditional access policies or dynamic Microsoft 365 groups. In the past, the rule was that guest accounts needed premium licenses at a 1:5 ratio to Entra ID premium licenses. In other words, each premium license covers five guest accounts. Guest accounts don’t need licenses for “normal” activity such as accessing a team or opening a shared document. Entra ID access reviews can help control the need for licenses by forcing group owners to validate continued membership of guests in their groups.

External Identities Licensing Change

In September 2020, Microsoft announced a change in licensing for external identities (Azure B2B and B2C collaboration). Instead of requiring customers to buy premium licenses to cover guest accounts, the new monthly active users (MAU) billing model allows up to 50,000 free MAU for premium activities monthly. Licenses are still needed for tenant accounts that use premium features.

The definition on Microsoft’s billing model for Entra ID external identities page explains that MAU is “the count of unique users with authentication activity within a calendar month.” In other words, the MAU threshold covers all authentication activity by 50,000 external identities (like guest accounts) in a month. Any individual identity within that set can authenticate as many times as they like. If a tenant exceeds the 50,000 MAU threshold, Microsoft bills for authentications by subsequent external identities. Pricing varies according to market and whether an authenticated external identity uses Entra ID P1 or P2 features (see MAU pricing). As an example, in the U.S., an engra ID P1 MAU costs $0.00325.

To date, Microsoft hasn’t done much to enforce the changeover to MAU pricing, and it’s very possible that Microsoft’s change in licensing strategy passed tenant administrators by without registering. It certainly made no impact on me. However, the signs are that some new features might require tenants to use MAU billing, which requires customers to link their Entra ID tenant to an Azure subscription. If you’ve already done this, you don’t need to do anything else as Microsoft bills you based on the MAU model. If you haven’t, you’ll need to link your tenant to an existing or new subscription.

Switching Entra ID Guest User Licensing to MAU Billing

On the surface, the process to switch to MAU billing seems straightforward:

• Create a new Azure subscription or identify an existing subscription to use for MAU billing.
• Go to the External Directories blade in the Entra admin center and select the Linked subscriptions option. Figure 1 shows the result of successfully linking Entra ID to a Azure subscription.
• Select your directory (most tenants have just one).
• Click Link subscription to select the Azure subscription and resource group (within the subscription) to use for MAU billing. Click Apply to link the directory to the subscription.

Registering the Entra ID Resource Provider

In my case, linking proceeded smoothly until Azure rejected my chosen subscription with the error:

The subscription is not registered to use namespace ‘Microsoft.AzureActiveDirectory’. See https://aka.ms/rps-not-found for how to register subscriptions.

The referenced page contains a lot of information about fixing various problems but nothing I could see relating to Entra ID. Some research (aka web searches) revealed that Microsoft.AzureActiveDirectory is the name of the resource provider for Entra ID. As you might imagine, not every resource provider is registered for every Azure subscription, so the solution is to register Entra ID for the subscription.

You can do this in two ways. First, go to the Subscriptions section of the Azure portal and select the subscription you want to use. Now select resource providers and look for Microsoft.AzureActiveDirectory in the set of providers. Select and register the provider. Figure 2 shows that the provider is registered, which is what you want to see.

Those wanting to live on the edge can register the provider using the Azure Cloud Shell. Start a session by clicking the Cloud Shell icon in the menu bar (it’s the icon which looks vaguely like PowerShell). This opens a small pane in the Azure portal into which you can type commands (you have a choice of Bash-like or PowerShell-like environments).

Accessing Cloud Shell from the Azure portal logs into your account automatically. All you need to do is run two commands to select the subscription you want to update and then register the Microsoft.AzureActiveDirectory provider with the subscription:

Az account set –-subscription "Visual Studio Enterprise Subscription"
Az provider register –-namespace Microsoft.AzureActiveDirectory

If you access the Cloud Shell directly (https://shell.azure.com/), you’ll need to sign in first with:

Az login

In either case, after registering the provider, you can link the subscription to Entra ID and use the MAU billing model.

It seems strange that Microsoft hasn’t optimized the Entra admin center to make sure that a selected subscription has access to Entra ID and if not, offer the administrator to register Entra ID with the subscription. There should be no need to force administrators to solve the problem when software can do it automatically.

Extra SMS Charges

Although Microsoft allows for 50,000 free MAU monthly, the MAU pricing page says:

A flat fee of $0.03 is billed for each SMS/Phone-based multi-factor authentication attempt.

Note the wording. The charge applies whether the attempt to send an SMS code is successful or not and covers the telephony charge involved in sending the SMS. The charge does not apply when external identities use the Microsoft Authenticator app for MFA verification, which is another good reason to encourage guest accounts to use the app.

Entra ID Guest User Licensing Works for Microsoft and Tenants

I’m sure Microsoft likes the new MAU pricing model for external identities because it gives them more control and visibility over the volume of guest account activity with premium Entra ID features. The old 1:5 licensing model was unenforceable and probably ignored in many tenants. On the upside, because MAU pricing is linked to Azure subscriptions, tenants gain more insight into the activity level for guest accounts too. I’ll be keeping an eye on costs as time goes by.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what’s happening.