In the dungeons of Azure AD B2B: properties of external Azure AD account might block creation of guest account

Collaboration between organizations in an ecosystem has become more and more essential to the value organizations create. But also in these Business-2-Business (B2B) collaboration scenarios, the authorization principle of 'need-to-known' must be adhered: employees from the partner organizations should only be granted access to the information on which they actually collaborate with the inviting organization. To be able to grant selective authorizations to the externals, requires that each of them must be known with identifying identities in the information system(s) of the inviting company.

In the Azure AD B2B model, Microsoft introduced the notion of 'guest accounts' for this, based on the concept of "bring-your-own-identity". An Azure AD B2B guest account is a lightweight account, that in fact acts as placeholder in the Azure AD context of the inviting organization to external identity managed outside the responsibility of the inviting organization. As such, Azure AD B2B collaboration supports cross-company relationships by enabling partners to selectively access your corporate applications and data using their self-managed identities

Azure AD B2B supports 2 modes to invite external guests via their corporate email addresses: a federation model from the Azure AD of the inviting organization to the external Azure AD of invited partner organization. And in the case that the invited company is itself not (yet) an user of Azure AD for their identity management, via just-in-time created accounts which are then administrated in a so-called 'viral' tenancy (see: Understand the B2B user).

Guest accounts are created in the inviting Azure AD with their own (external company) email address applied as their guest account / identity name. Azure AD requirement here is that the guest identity name is not yet in-usage as proxy-address within another account in the Azure AD tenant. The typical situation in which this could occur is when an external employee already has also a Member account in the Azure AD of the inviting organization, and has the own corporate email assigned to that Member account. When next you try to create a guest account for that external email, Azure AD refuses with error message: "The user you're inviting already exists in the directory. They can simply sign in into shared apps and resources."

The most pragmatic approach to fix this guest account provision error, is to 'free' the external corporate email address of the 'to-be AAD guest': disconnect it from assignment in the Member account in the Azure AD of inviting organization.

Another apparent feasible approach is to simple select another external corporate email as guest account name: e.g. instead of '<External>.<User>@>ExternalOrg<.com', provision a guest account via '<External>.<User>1@>ExternalOrg<.com'. This is certainly a creative alternative. But you need to be aware of some pitfalls with it. 1) Redemption in Azure AD B2B is an email-verified process. Meaning that the alternative corporate email address must actually exist and resolve to an email inbox in the domain of the invited organization. 2) In case of federated Azure AD tenants, the requirement that the proxyAddresses must be unique, is verified in the combination of the Azure AD tenants of both the inviting as the invited organizations. Resulting that in case to the alternative account in the Azure AD of the invited organization, the original corporate email of person is administrated in the proxyAddresses, then the provisioning of guest account in Azure AD of the inviting organization still blocks. See How can we improve Azure Active Directory? - Show the B2B-blocking proxy address in my tenant's logs where this is shortly described.

Code snippet to have run in the Azure AD tenant of the invited organization, to identify whether and which proxyAddress value is the cause of the blocking:

Connect-AzureAD

Get-AzureADUser -Filter "mail eq '<firstName>.<lastName>1@externalcompany.com'"
   -all $true |
Select-Object displayName, @{L = "ProxyAddresses"; E = { $_.ProxyAddresses -join ";"}} |
Export-Csv -Path C:\temp\ReportOutOnAADAccount.csv -NoTypeInformation

Caveat with MS Teams Live Events: once started, your audience is fixed

Do you recognize this? You started "the party", and while in full flux you're friendly reminded that you forgot to invite your best friend... This metaphore also holds for webcasts with selected audience: as people move accross diverse departments in an organization, it is an easy miss to not authorize/invite someone new joined. And dependent on the content and information sensitivity of the information shared, even more important can be to retract the authorization of someone that moved to another department. With Stream Live Events, the owner aka organizer of the Live Events is enabled to on-the-fly make modifications to the authorized / invited audience of the event, also when the event is already live. With Teams Live Events this is not possible: once the planned event is started, the audience is locked: you can neither add new attendees (nor presenters), or remove persons that should not be allowed. It is even not possible to modify in MS Teams the audience after the event is ended.

As the positioning of MS Teams Live Events compared with MS Stream Live Events is that the first is aimed for webcast distribution with a typical known team (of people), the lack of dynamic authorization may in reality not be a concrete issue. But good to be aware of, also to make a judged selection between webcast via MS Teams Live Events or via MS Stream Live Events.

Just be aware: recorded data of MS Team Live Events "QuickStart" is stored outside own tenant

Microsoft Teams Live Events supports 2 flavours: Teams (formerly code-named "QuickStart"), and External App using Microsoft Stream. The charm of the Teams option is illustrated by its code-naming: it's very easy to start up and use. In the most basic and raw form, the only thing needed is a laptop with onboard camera, and Microsoft Teams desktop application installed. And then anyone granted the Teams Live Events scheduling authorisation (TeamsMeetingBroadcastPolicy -AllowBroadcastScheduling parameter = True; Who can create and schedule live events?), can self-schedule and self-produce a Live Event. However, a caveat to at least be aware of is on the location where collected data is stored: the video recording, and the data of the Moderated Q&A. When using Microsoft Stream for event webcasting, the recording is stored in your own tenant and under your direct control. The MS Teams situation is to date different:

1. The video recordings are stored as Azure Blob in the Microsoft system instance of Azure Media Service, a generic tenant shared accross multiple customers. The AMS instance is within the same data center as your tenant (not much information on this shared, but see: Manage a live event recording and reports in Teams: "Recordings from live events produced in Teams are currently not saved in Microsoft Stream", and Teams Live Events storage location);
2. Captured Questions & Answers are stored in a combination of Azure Tables and CosmosDb, also in a generic tenant. The QnA data is automatic deleted 180 days after end of the Live Event, unless earlier explicit deleted by yourself.

It can very well be that this outside-tenant administration of your's company data is totally irrelevant for your organization. If so, you don't need to concern yourself nor your information security. However, in case you are in a business for which legal compliance and/or data privacy holds, I do advise that you consult your information security and compliance office on whether the outside-tenant administration does not impose a continuity risk. Better be safe than afterwards sorry...

Beware with Unique Permissions on PublishingPages, AddAndCustomizePages and Embed Code in a page

Interesting puzzle solved: page authors complained that some of them face an issue when they try to insert a Microsoft Stream video via embed code in the page body:

The message clearly points to missing of 'AddAndCustomizePages' permission for the logged-on page author. However, on checking the permissions, all the authors / editors do have that permission via an assigned 'Content Management' permission level. After some trial-and-error, I discovered the SharePoint internal cause. The below error message on trying to insert a ScriptEditor webpart in the page content, led me to the Eureka insight:

This site says... Aha: In the site the permission inheritance is broken, to achieve that page authors can only create and modify page (= news) items, but are restricted from modifying anything else in the site. The 'Content Management' permission level is for that purpose not assigned to them on site level, but on the Pages library. On required permission for their author task this assignment is sufficient. But a flaw in SharePoint is that it checks in the 'Insert Embed-code' handling whether the 'AddAndCustomizePages' permission is granted to the logged-on author on site level.

With this insight / understanding on SharePoint level, the fix clear: make sure that all the page authors are also granted a permission level on site level that includes the 'AddAndCustomizePages' permission. And with that fix, all page authors are enabled / authorized to user-friendly apply 'Embed Code' in page edit mode:

Misleading Conditional Access response on trying access with expired Azure AD B2B guest invitation

In the situation that an invited Azure AD B2B guest is homed in an external instance of Azure AD, there is no need to await redemption by the invited guest before the guest account can be utilized in the inviting Office 365 tenant to grant access in a SharePoint site. Instead, on first visit of the invited + authorized external / guest account, the redemption will take place implicit. This improved B2B invitation experience is available since May 2018 (Exciting improvements to the B2B collaboration experience).

However, this scenario breaks in the situation that the invited guest lets the invite expire:

That the implicit redemption in such situation fails is on itself logical and the correct behavior. However, the error notification that the guest receives is misleading. It does not point to the cause that the guest invitation is not accepted yet (and thus guest account still in 'Invited User' state), but falls through to the conditional access for regular Member accounts:

The correct fix in this situation is to either resend the invitation in Azure Portal, or re-invite via New-AzureADMSInvitation cmdlet. The invited person is then re-enabled to accept the invite. Either redeem explicit via the URL in the invitation email, or redeem implicit on first access to a site in the inviting SharePoint Online tenant that is shared with the guest account.

Confusing SharePoint UI to add guest to Modern Group-connected Site

Once in Azure AD a guest account is created for an external, site owners can use that guest account in same way as for regular accounts to grant access in a SharePoint Site: 'Share' the site, and lookup the guest account. However, within Modern / Office 365 Group-connected site, this similarity is broken. The cause is that in the SharePoint UI of a Group-connected site, the Membership in the top-level UI is actually referring to the Office 365 Group; not that of the connected SharePoint Site. Yet external / guest accounts cannot be added via SharePoint to an Office 365 Group, this needs to be done via Outlook on Web as membership management interface (Manage guest access in Office 365 Groups).

Not possible to add guests to Office 365 Groups via SharePoint top-level UI

The proper way to add guest accounts to the B2B shared site, remains to authorize them on level of SharePoint site. Preferable utilizing SharePoint Groups, instead of direct individual assigned authorization. The path in the UI to this is via 'Settings' menu, 'Site permissions', 'Invite people'. And in this step, select 'Share site only':

How-to authorize guests to access Modern Site via SharePoint UI

The above experience is a smoothened version for the old-fashioned SharePoint membership management: making one aware on the existance and concrete membership management of the SharePoint Groups in the site. This 'old-way' is also still available, via 'Advanced permissions settings'. Or for those knowledgable SharePoint insiders...; direct via the known URL (<site-URL>/_layouts/15/user.aspx).

(old-way) How-to authorize guests to access Modern Site via SharePoint UI

Beware: with B2B sharing enabled on SharePoint tenant level, all new provisioned Modern sites are by default open for non-constrained sharing

The governance of B2B sharing of SharePoint Online is setup on 2 levels: at first, on tenant level the SharingCapability must be configured in an enabled state (SharingCapabilities enumeration), otherwise all sharing in the full collection of sites in the tenant will be disallowed / blocked. Also on tenant level, SharePoint admin can configure allowed (whitelisted) and disallowed (blacklisted) domains of invited organizations. On the 2nd level, the SharingCapability of individual site collection must also be configured to same enabled state, to enable sharing of that particular site. Plus also on this level, SharePoint admin can specify both allowed and disallowed domains.

With this 2-step configuration, the inviting organization is enabled with explicit (IT) control on which of the site collections, their business owner(s) can invite (authorize for access) guests of targeted invited partner organizations.

Something to be aware of in this SharePoint Online B2B governance is that on site collection level of Modern / Group-enabled sites, the default setting of the SharingCapability property follows the tenant-configured value. This means that in the situation where sharing is enabled on tenant level, all new provisioned Modern sites by default are also direct configured to allow sharing.

In the 2-step B2B governance process this is not compliant; individual site collections may only be configured for sharing on explicit business request and approval, and potential for identified domain(s) only.

To get back into compliant state, each new provisioned site collection must be configured via an after-step to reset the SharingCapability into ‘Disabled’. This after-step can be executed via Site Designs, or in case a site provisioning solution is used (e.g. PnP provisioning) as post-processing provision step. Another approach is via a scheduled automation job (e.g. Azure Automation, or remote PowerShell).

Note: remarkable is the difference with classic sites: these are by default always provisioned with disabled 'SharingCapability', independent of the setting on tenant level.

Inconsistency within MS Teams External Sharing activation

A special case is with the SharePoint sites that are created underneath MS Teams instances (for the ‘Files’ capability). Also on the tenant level of MS Teams, the external / guest capability is configured. However, there is an inconsistency in the context of the MS Teams B2B configuration when external sharing is enabled on SharePoint tenant level, but not on MS Teams tenant level: the underlying SharePoint sites follow the SharePoint tenant setting, not that of their ‘owning’ MS Teams. The effect is that external guests may be authorized for access to the SharePoint site underneath a MS Teams instance, despite that on MS Teams tenant level external sharing is explicit disabled.

To correct this inconsistency, any of the above sketched set of ‘compliance’ approaches can be applied on the SharePoint sites that are created 'underneath' MS Teams instances.