In the dungeons of Azure AD B2B: prevented that external can have multiple active guest accounts on alternative email addresses

A charm of Azure AD B2B is that the responsibility for guests account management is federated to the external context of invited person. But with this charm inevitable also comes lesser direct control, as within the inviting tenant you have no insight on the federated account in the external Azure Active Directory. I wrote already on a negative effect that can result from this: properties of external Azure AD account might block creation of guest account.

Recent I experienced a peculiar variant of this issue. An external was successful invited, and able to redeem the provisioned guest account and use that to access resources in the inviting tenant. At a later moment, the same external was reinvited via New-AzureADMSInvitation cmdlet on an alternative email address as identity. This was also successful and resulted in a second guest account provisioned in the inviting tenant. But when trying to resend the redeem invitation from Azure Portal, this failed as the new guest account on deeper level is referring to the same federated external identity as the original provisioned guest account. Thus although it looked in the inviting tenant that the 2 guest accounts were isolated from each other, in the reality of the actual identity source of the invited external the 2 alternative emails are administrated as proxy addresses within the same external Azure AD account.

I consider it as correct behavior by Azure AD B2B to recognize this, and prevent that multiple guest accounts can federate to the same single external Azure AD account.

Same external invited with 2 separate guest accounts in inviting tenant

Initial guest account successful accepted and activated

Later provisioned guest account cannot be accepted

Reinvite via Azure Portal blocked as guest account is referring to same external Azure AD account

Developer inconvenience: Deploy Isolated WebPart with webApiPermissionRequests fails unless permission to create new Azure AD App Registration

In real-life enterprise context, it is advised to tag any SPFx webparts that will invoke an Azure AD protected API as isolated. This to prevent that other script running in same page, can abuse the OAuth access token assigned to the SPFx webpart and invoke any tenant-wide API permissions on behalf of current user.

However, you need to be aware of some deployment implications with Isolated WebParts. The first one is that in the Microsoft design, you can only deploy Isolated WebParts via the tenant AppCatalog. It is not possible to deploy an Isolated WebPart (only) to the site App Catalog where it will actualy be used. I suspect this is due that each Isolated SPFx WebPart creates a new Azure AD App Registration on tenant level, and for consistency the SPFx WebPart must therefore also be installed on tenant level. Negative result is that every site-specific customization is visible on all others sites where it likely is unusable. Luckily this visibility is initial limited to only the site owners in "Add an App". Only after a site owner explicit adds the Isolated WebPart to the site, then it will be visible in page editing mode in the available WebParts.

An even more significant inconvenience is that to successful deploy an Isolated WebPart, you need to have the authorization to create a new Azure AD App Registration. Without that permission, the deployment in tenant AppCatalog will fail with the generic error 'Deployment failed. Correlation Id ....'. Implication is that in effect the dependency on Ops is unnecessarily increased: a developer must reach out to a Global Admin for the deployment of SPFx solution containing Isolated WebPart. But the better option is that you request that Global Admin to assign your account the Application Developer role, then you are empowered to do this 'Ops' part yourself.

Simple pattern to ensure unique element ID inside SPFx React WebPart

When you build a SharePoint WebPart, you must take into account that the business user can add multiple instances of that webpart on a single page. So the operational execution must be robust for that. In case your webpart relies on HTML element ID, e.g. via 'getElementbyId', then you must ensure that the element ID of each instance is unique. A simple pattern I applied is to derive the ID of the inner React Component on that of the unique ID of the parent React WebPart.

Part 1: Extend the React WebPart Properties interface with a property for unique ID

Part 2: Parent React WebPart derives unique ID from its own, and pushes to the inner React Component

Part 3: Inner React Control applies the received unique ID in its rendering + operation

Office Graph and Microsoft Graph

Clear and consistent product naming remains a challenge, certain also in the Microsoft domain. An example is the reuse of phrase 'Graph' in Office Graph and Microsoft Graph aka Graph API. What do these names entail, and what if any is the relation?

Office Graph

Office Graph is the oldest name, and originates in 2014 as the foundation underlying Delve. "The brains behind Delve is the Office Graph. The Office Graph continuously collects and analyses signals that you and your colleagues send when you work in Microsoft 365. For example, when you and a colleague modify or view the same document, it’s a signal that you’re likely to be working together. Other signals are who you communicate with through e-mail, and who you’ve shared documents with, who your manager is, and who has the same manager as you."

Microsoft Graph aka Graph API

Microsoft Graph is a giant proxy, it takes requests in, validates authentication token, optional does validation and transformation, and then passes / forwards to the specific inner layer in Microsoft 365 landscape; and returns the inner responses, optional after transformation to the Graph API caller. Graph API provides consistency over all the different inner services, on level of authentication, property naming and casing, exception handling, singular shared object types (eg consolidate on one definition of ErrorDetails object type). Important to understand is that Microsoft Graph itself does not provide services, it simple delegates to the actual services in the Microsoft 365 landscape.

Actual the same?

Microsoft: "The Microsoft Graph models activity in Microsoft 365 services, including Exchange Online, SharePoint Online, Yammer, Skype for Business, Azure Active Directory, and more, and in external services, such as other Microsoft services or third-party services. Microsoft Graph components are used throughout Microsoft 365. The Microsoft Graph represents a collection of content and activity, and the relationships between them that happen across the entire Office suite. It uses sophisticated machine learning techniques to connect people to the relevant content, conversations and people around them. The Microsoft Graph contains information about enterprise objects, such as people and documents, as well as the relationships and interactions among these objects. The relationships and interactions are represented as edges."

Office Graph renamed into Microsoft Graph

The Office Graph has evolved to become exposible via the Microsoft Graph. Thus they have conceptual morphed into same offering, Office Graph as backend collects and analyses signals that you and your colleagues send when you work in Microsoft 365; and the Graph Api provides central gateway access to this collected information. And also to all other services within Microsoft 365 landscape.

Used resources

• Customizing Privacy Controls for Microsoft Graph Insights with the Graph Explorer, Tony Redmond
• How does Office Delve know what's relevant to me?, Microsoft
• What is the Office Graph?, Michael Holstee
• Microsoft 365 Tenant Isolation in the Microsoft Graph and Delve, Microsoft
• Microsoft Search 101 - What’s the relationship between the Microsoft Graph and Office Graph?, Bill Baer
• Overview of Microsoft Graph, Microsoft

Graph API on top of Microsoft Graph administration of collected signals in Microsoft 365 landscape and services

The Microsoft Graph Insight APIs expose relationships generated by Office Graph services (source: Microsoft Search 101 - What’s the relationship between the Microsoft Graph and Office Graph?, Bill Baer)

Tip: how-to self-produce without external encoder into MS Stream Live Event

Webcast production for a Microsoft Stream Live Event is default tied to external encoder. Teams Live Event supports this also, but defaults to simple self-production via Teams App itself. In that case, the live event is not distributed via Stream; nor is the event recording stored within MS Stream. Instead Teams uses its internal Azure Media Services based streaming, and stores the recording somewhere for period of max 180 days after the event is over. Yammer Live Events takes a middle road, or the best of 2 worlds. It supports the same 2 production approaches as Teams - external encoder or via Teams. However, the difference is here within the Teams production handling. Even although produced as a simple Teams Live Event, under the hood this does use Microsoft Stream for the webcast distribution and processing, and after the live event is stopped for the storage of the recording for on-demand watch.

This opens multiple advantages

• It allows to use the simplicity of Teams production for a webcast, and still embed the video on an event portal (typical hosted via SharePoint Online);
• It prevent the need for and availability of external encoder (e.g. Wirecast-S, TeraDeck, OBS Studio, ...);
• Corporations that have employed Ramp Multicast+ as eCDN solution to optimize and control the webcast traffic of Stream on the corporate network, can employ this also for webcasts produced via Teams

Way to apply this approach is by:

1. Schedule your webcast as a Yammer Live Event;
2. Produce your webcast as a Teams Live Event;
3. Consume / watch the webcast as a Stream Live Event.

Step 1: Schedule as Yammer Live Event

Step 2: Produce as MS Teams Live Event

Step 3: Consume as MS Stream Live Event, e.g. embedded on SharePoint Online page

Yammer channel determines who is allowed to watch the live event

Something to be aware in case you would apply this approach, is that Yammer then controls who is allowed to watch the live webcast. Namely the members of the Yammer channel in which the Live Event is scheduled. So you must then make sure that all the accounts that are invited as webcast audience, are invited to the 'owning' Yammer channel. It is not possible to extend via Stream portal the permissions of the scheduled Yammer (= Stream) Live Event. After the event ended, then the video recording is 'released' for video management actions through Stream portal.

Inconvenient authorization management in 'classic' MS Stream

In the corporate usage of Microsoft Stream as Enterprise Video Portal (EVP), authorization to watch videos is also applied on 'need-to-known' base. In current Stream, it turns out a bit inconvenient to execute effective permission management.

First issue is that it is made complex to nearly impossible to efficient configure permission management on a collection of videos. The root cause of this is in how Microsoft Stream handles the authorization and organization of the video store: "In Microsoft Stream, you can use channels and groups to organize and grant permission to your videos" [Source: https://docs.microsoft.com/en-us/stream/groups-channels-overview]. This is actually not a valid statement. Indeed Stream (aka Azure AD) groups "are both a way to organize videos and to control access to videos", but channels merely "are an organization method for videos, but not a permission method". Limiting for efficient permission management is that Stream portal does not include a capability to logical associate video(s) within either a Group or Channel, this is only supported initial on the moment of adding / uploading video(s) into Microsoft Stream. Once already stored in Microsoft Stream, the only possible way to associate video(s) with additional groups or channels it to do this per video, via the manual Add to group/channel action in the video-edit menu. When this must be done for larger collection of videos, this is a cumbersome and time-consuming effort.

Second issue is that Stream suffers from a delay before the indirect authorization assignment via Stream groups is actual applied (becomes active). In situation that authorization to watch a certain video is managed by one or more Stream groups, authorizing another person for access by adding her/his Office 365 account to an authorized group (e.g. via Azure Portal), does not immediate grant the person allowed access to the video. In reality it can take up to even an hour before the group based authorization within Stream context is updated to incorporate the new added account. Until then, the person remains confronted with Stream access denial on the video.

Even worse, similar effect occurs when revoking the access by removing from Stream group. This is neither immediate effectuated. Luckily the elapse time period is in this situation shorter, max 1 to 2 minutes; not a full hour. Still, immediate access revocation on unjustified granted video is not possible.

Perhaps within new Stream, in which the video storage moves to SharePoint Online, the authorization management improves. Not 100% confident yet, as Modern SharePoint also uses Azure AD groups for permission management. However, experiences within regular SharePoint Online usage are that any change in the Azure AD group(s) are almost immediate applied for access control, both on access assignment as revocation.

Tip: Teams NDI® only becomes active for capture when 2nd person joins the meeting

The new NDI® capability in Teams is interesting for webcast production, as it allows that you simultaneously combine the video signals of multiple persons in the stream. An use case is for a digital (panel)conversation between 2 or more presenters, which are physical at different places. This scenario is native already possible via Teams Meeting; however then you miss the flexibility in organizing the screen layout of the webcast production. E.g. display another background, display a PowerPoint presentation, switch between picture-in-picture vs full profile; display a ticker message and so on.

As I acknowledge the usability of Teams NDI capability for productive company webcasts, I played around a bit with it: in Teams (MSDN development tenant) configured NDI capability on tenant level (Use NDI® technology in Microsoft Teams) + for own Teams account (Broadcasting audio and video from Teams with NDI® technology); webcam setup (via IVCam) on home system; OBS Studio with NDI plug-in.

While playing, I notice that the NDI signal only becomes active on the network once a second person joins in the Teams meeting. Implication of this is that as producer you cannot prepare a production setup with only you present yet in the Teams meeting. In reality this should not be an issue: the reason to use NDI for capturing is because you want to capture the video of other person or persons. Not that of yourself, that you can just as simple direct capture in OBS Studio (or other encoder) as 'video camera' input.

Screenshots of exploring Teams NDI capability

Join as webcast producer / organiser the Teams Meeting, with NDI enabled for yourself

Teams does not yet activate NDI broadcasting, while not actually a meeting of multiple persons

Second person joins the Teams Meeting

Teams now activated NDI broadcasting, and can be captured in OBS Studio

Once 2nd attendee in the meeting, Teams displays the NDI broadcasting notification

How-to prevent download of video files stored in SharePoint Online site

Context

• Event portal with both company internal as external audience
• Teaser videos to prepare the audience for the event
• Due the company information in the videos, not allowed that visitors download the videos for uncontrolled distribution.

An answer on the first aspect can be a SharePoint Online communication site, via Azure AD B2B external shared with known guest accounts. For the second aspect it would be preferred to use Microsoft Stream as secure Enterprise Video Platform. However, as Stream is still lacking the capability of external access; this would result that the external audience cannot watch the videos. Pragmatic alternative is then to fallback on using SharePoint Online itself as administration plus platform for the teaser videos. Remaining question is then whether possible, and if so how, to prevent that the external audience can easily download the video files.

Prevent download on SharePoint level

First component in answerring is to prevent on SharePoint Level that site visitors can download content from the site. The standard 'Read' permission level grants the authorization to "Can view pages and list items and download documents". There required to create a restricted permission level that only allows to "View content", and assign that permission level to the 'Visitors' permission group.

Prevent download on browser level

However, this does not prevent that visitors can download on browser level the SharePoint stored .mp4 videos, whether embedded in a SharePoint page, or the .mp4 video direct visited + played in the browser. All modern browsers native understand / recognize .mp4 as a video file, and then default to allow play, download and 'save as video' on browser level of that video file.

Does this mean it is not possible to prevent download of video files? The honest answer is: you can't stop downloading of html5 videos. But you can make the action more complicate to do. Multiple options for that.

Option 1: Download as blob in video player

This suggestion is made in Prevent HTML5 video from being downloaded (right-click saved)?

Result wrt default browser behavior:
As for the video player it is not .mp4, the default menu options for 'save as video' and 'download' are not triggered. However, on network level the video file is still initial downloaded as .mp4; and a knowledgeable person has no problem to simple direct navigate on browser level to the SharePoint address of the .mp4 videofile.

Option 2: Play as 'renamed video extension' file, so that default browser behaviour is prevented

Steps:

1. Rename the file extension to something else than .mp4; example rename 'SampleVideo.mp4' into 'SampleVideo.videofile'
2. Upload the renamed file into SharePoint Assets library
3. Also upload an image to use as preview
4. Embed a videojs based videoplayer on SharePoint page, that is configured to understand how-to play '.videofile' as '.mp4'. Also customize the videoplayer to not render the standard contextmenu

Result wrt default browser behavior:
As the file-extension is not a video format; neither SharePoint, nor browser recognize this as video file. And the default browser behavior to play the video-file address as video, is not fired; and thus the option from menus to ‘download’ + ‘save video as’ is not presented.

However, when navigating in browser to the SharePoint address of the renamed videofile, it will then download as file (despite that SharePoint permission does not allow). It is downloaded with the renamed file extension, but a knowledgeable person can guess that it is actual a .mp4 file, fix the downloaded file, and then it is native playable again.

Option 3: Convert from single .mp4 into HLS; with division accross multiple files

Steps:

1. Convert .mp4 video file into .HLS video (manifest file + video fragments). An approach for this is via 'FFmpeg'.
2. Upload the manifest + video fragments into SharePoint Assets library
3. Also upload an image to use as preview
4. Embed a HLS videoplayer on SharePoint page.

Result wrt default browser behavior:
Browser default do not handle HLS video files; this is handled via a HLS video player (JavaScript). To download the video, one must navigate in browser first to manifest file, and then all individual video fragments. Doable, but manual labor for the person downloading.

Beware: Request SharePoint Root Certificate as administrator

On trying the Microsoft advised workaround 1 in situation in which in the SharePoint 2016 central admin server every hour a 'Critical Error' is logged on 'A certificate validation operation took milliseconds and has exceeded the execution time threshold', I initial failed as Get-SPCertificateAuthority returned Null for RootCertificate. The trick / requirement here is to invoke the cmdlet from PowerShell runas administrator:

MS Teams capabilities and external access

MS Teams as collaboration hub exhibits in its total set of capabilities differences wrt external access; some minor, some significant. Overview of my current understanding:

Teams capability	External access options
Chat and Calls	Teams Federation Teams Guest Access
Meeting	Anyone can be invited on own email Lobby function for controlled entrance in the meeting
Live Event; audience	Teams Federation Teams Guest Access Full anonymous
Live Event; presenter	Teams Guest Access
Teams instance	Teams Guest Access

How-to enable for mobile device the seamless consumption of embedded Microsoft Stream on SharePoint page

SharePoint Online Modern Sites/Pages are by-design prepared for mobile / on-the-go consumption. An use case is to embed a Stream video on a page - either on-demand or live event -, and the audience then has the freedom to consume on regular workplace, or via their own mobile device.

However, be aware that in the latter case for seamless Stream behavior it is required that the mobile browser is set to 'Allow All Cookies / Block No Cookies'. Without this, typical the mobile browser fails from within the authenticated SharePoint Online context, next implicit logon the user to the embedded Stream service. The SharePoint Online Product Group confirmed this: To enable in Edge on mobile device seamless MS Stream behavior when embedded on SharePoint Online [modern] page, then infra prerequisite is that mobile Edge is configured to ‘Not block cookies’. The subject is current missing from the requirements stated on Microsoft official Knowledge Base. The Engineering Team will add this to the documentation for further clarity in the future.

Tip: for customizing on Modern Site shared with B2B guests, use SPFx and not PowerApps

In Modern SharePoint, the citizen-developer way for page customization is through PowerApps (instead of the dreaded InfoPath approach). This works out fine..., unless your site is shared with external Azure AD B2B guests. A condition for PowerApps usage is namely that the logged-on user is licensed for a PowerApps Plan. For regular member accounts this license is typical provisioned on onboarding time. For guest accounts you cannot trust that each of them has a PowerApps license already themselves, and then access to use the PowerApps customization requires that a license is assigned in the inviting tenant. But probably you do not want to assign licenses in the inviting tenant to Azure AD B2B guests. After all, one of the charms of the Azure AD B2B model is that for each paid Azure AD license the organization is entitled to invite up to 5 guest accounts without additional costs.

The result for guests that do not have a PowerApps license themselves, is a broken user experience. Instead of a working custom control / form in the SharePoint page, the guest site visitors are confronted with a notification about need for PowerApps Plan license:

A minimal approach to at least avoid the broken UI experience would be to hide the PowerApps control for guest accounts. But also this is not possible: audience targeting on arbitrary webparts is not supported in Modern Pages, see Overview of audience targeting in modern SharePoint sites.

In a SPFx control you can utilize an alternative for audience check, by check on permission group, or check on account type (member or guest). A code example of this approach: Show and hide SPFx Webpart Content based on user permission.

However, when using SPFx for page customization then you’re not subject to additional licensing on top of SharePoint license. So it would not even be needed to hide the control in case logged-on user is a guest account....

Conclusion: if you plan to share a Modern SharePoint site with external guests, then better not use PowerApps for customizing a page that is accessible for guest accounts. Better approach is via SPFx, and accepts this requires coding skills iso no/low-code.

Be aware: Azure AD Hybrid-Join requires Chromium Edge sign-in

Microsoft is loudly promoting and actively pushing upgrade from classic Edge browser to the new Chromium Edge. One thing to be aware of for organizations that utilize Azure AD Hybrid Join for conditional access to enterprise applications, is that Chromium Edge requires user sign-in with Azure AD account. Without the Azure AD sign-in, Chromium Edge does not enroll in hybrid join, and the remote user is denied access to the company enterprise resources (such as Office 365 services, but also any other enterprise application that have Single Sign-On with Azure AD).

See: Hybrid Join - Chromium Edge Browser and Microsoft Edge identity support and configuration

How-To include an external as presenter in Yammer Live Event

After I earlier this week did the pleasant discovery that and how-to an external can be involved as presenter in a Teams Live Event, I decided to test whether same is possible within Yammer Live Event production. That could work, as Yammer Live Event production can be via Teams. The short report out: Yes, also this proofs possible!

The enabling preconditions (external known as Azure AD B2B guest in organizing Teams, and switched in Teams App to the organizing tenant) and steps are comparable with involving an external in Teams Live Event presentation, although few significant differences:

1. In the organizing tenant, schedule in producer / organizer role within Yammer a new Live Event. Crucial also here is to select that the production will be done 'via Teams', not 'via External app or device'. In this step in Yammer UI, do not try to invite the external as presenter as that fails: Yammer does not allow the external to be resolved (unless you have enabled external access of the Yammer channel itself)
2. In Yammer of the organizing tenant, navigate to the scheduled Live Event and click on "Produce (Open in Teams)". After the Yammer Live Event is opened in Teams App, click 'Join now'.
3. Crucial step: in the internal Teams meeting of the Live Event, click on the button 'Show participants'. And in the Teams meeting context, invite the external person via his/her external guest identity;
4. Under the preconditions that the external person is active in Teams, and switched there to the organizing tenant, (s)he receives a request notification to join in the internal Teams meeting of the Yammer Live Event
5. The invited external accepts the invite to join this active Teams Meeting, and can then share content + video in the meeting context of the Yammer Live Event;
6. The Yammer Live Event producer waits in the Teams Live Event production room until the external person has joined, and shares content in the internal meeting of the Live Event. When visible, the producer is in control to select content and/or video of this external presenter in the queue;
7. The producer pushes from the queue to live, and starts the Live Event;
8. The audience of the Yammer Live Event see the content and/or video of the external presenter;
9. And audience on-the-go can watch the external presenter in the Yammer Mobile App;

   

How-To include an external as presenter in Teams Live Event

When it comes to organizing a webcast, Microsoft 365 offers multiple options: Teams Meeting, Stream Live Event, Teams Live Event, Yammer Live Event. Each with their own differentiating characteristics, and you can select which best fits the specifics of your planned event. A significant differentiator of Teams Live Event is that you can extend beyond internal audience only. Either full public open, or still restricted audience by inviting externals as authorized via Azure AD B2B in your tenant. In the B2B guest model, the external access into the Live Event can then be secured by multi-factor authentication (MFA), to protect the company information shared for external access only in trusted context.

A pleasant discovery I did this week is that the authorized external involvement also extends to the Presenter role: you can include in the set of event presenters also identified people from outside your own organization.

The enabling conditions:

1. The Live Event must be produced via Teams itself, not produced by External app or device. Reason is that the latter delegates to MS Stream for processing and delivery, and that Microsoft 365 service up today sadly still does not support external access;
2. The external person must be known in your tenant, either as Azure AD B2B guest or via Teams Federation;
3. The Live Event organizer / producer must invite the external person via his/her external guest identity in the Presenter role;
4. The external person must be authorized as member to a Teams instance in your tenant
5. And as first crucial: to be allowed in the Live Event as presenter, the external person must at the presentation time switch in Teams to your tenant. Without this step, the external person sees in own Teams calendar the Live Event as meeting; but when trying to join that from own tenant will be blocked with notification
   "This event is in <external-tenant>. To join, you'll need to be in that org,too."
   If the organizing tenant has enabled MFA as conditional access rule, the external person will be challenged for that before secure and governed allowed access in the organizing tenant.
   
6. And second crucial: to actively join the live event the external person cannot go from Teams calendar once switched to the organizing tenant as it is not administrated there for the external person. Workaround is to join the 'external live event' via the invitation mail that the external person received in the own mail inbox when the Live Event organizer identified the external as an event presenter. Click on 'Join Live Event' seamless opens the Teams App of the external person in the internal producer/presenter meeting of the Teams Live Event within the organizing tenant. As result of the tenant-switch (previous step), the external person is now namely already authenticated and known in the organizing tenant.

After following the above steps, the external person is from perspective of the Teams Live Event organization just another presenter, who is authorized and enabled to share video and content in the event. And can communicate with the producer + other presenters in the chat of the internal Teams meeting to align on the event production.

From the perspective of the organizing producer, (s)he remains in control to determine which content of the presenters included in the Teams Live Event production to actual put live for the audience. The final control remains thus within the organization hosting the live event to its invited audience - internals, potential authorized guests, or full public-open.

MS Teams Channels - Yet Another Inconsistency on SharePoint Permission handling

Microsoft introduced Office 365 Groups as overarching concept to bring consistency in Office 365 permission management. Each single Office 365 Group manages authorization to a multitude of diverse Office 365 services (MS Teams, SharePoint Online, Planner, Exchange Online), in theory simplifying on the model in which each tool individual applies its own permission management.

In practice, Microsoft itself struggles with the consistent application of this new permission management model. In previous post I visualized the differences in permission management of Communications Site versus Modern Teams Site. Yet another difference is visible on the level of SharePoint site collection that is associated with a MS Teams channel. In the associated site of the main channel, Microsoft utilizes the concept of Office 365 Groups as overarching permission management. However, in the associated site of any private channel, the notion of Office 365 Group is missing.

Comparision Permission Handling + Management within associated site of Main vs Private Teams channel

Observations:

1. In the associated site of the Teams main channel, site authorization is delegated done via Office 365 Group.
   1. The SharePoint Members permission Group has as single member the Office 365 Group ‘Members’
   2. The SharePoint Members permission Group has as permission level 'Edit'
   3. The SharePoint Owners and Visitors permission Groups are both EMPTY
   4. Instead, the ‘Owners’ responsibility is assigned by having the full O365 Group 'Owners' as SCA
2. In the associated site of a private channel, site authorization is still on named accounts level
   1. The SharePoint Members permission Group has as members the named accounts of everyone authorized in membership in the private channel, both the owners and members of the channel
   2. The SharePoint Members permission Group has as permission level 'Contribute'
   3. The SharePoint Owners permission Group has as members the named accounts of the persons that are owners of the Teams private channel
   4. And these same named persons that are owner of the Teams private channel, are assigned SCA

I think this deviation is driven both by the current situation that Office 365 Groups itself does not support hierachy and subsets, plus the restricted usage scope of a private channel. A private channel is meant to restrict access to certain content in the Teams instance, but it is not meant itself as a container hub consisting of multiple tools. As example, you cannot associate a Planner Plan with a private channel. There is thus in the context of private channels less need for the overarching permission management concept via Office 365 Groups.

A concern with this effectively broken permission management in private channel compared to Teams instance itself, is what happens when on the Teams instance level a membership is revoked. Turns out that on Teams level itself the effect of this cascades to any of its potential private channels: whenever an account is removed as member in Teams instance, the same account is also automatic revoked as authorized member in any of the private Teams channels.

SharePoint Governance complicated, due deviation in permission handling within modern site templates

With the introduction of Modern Sites, Microsoft added an additional layer in the permission handling for SharePoint Online sites: via Office 365 Group (soon to be renamed/branded as 'Microsoft 365 Groups'). Below that new level, one can still authorize within the SharePoint site itself via SharePoint Permission Groups. And to make the story even more confusing: not all 'Modern' sites are equal wrt this new Permission model. In a Modern Communication Site there is no notion / connection to an Office 365 Group.

Comparision Permission Handling + Management within Modern Communication Site vs Modern Team Site

Observations:

1. In a Modern Teams Site, site authorization is delegated done via Office 365 Group.
   1. The SharePoint Member permission Group has as single member the Office 365 Group ‘Members’
   2. The SharePoint Owners and Visitors permission Groups are both EMPTY
   3. Instead, the ‘Owners’ responsibility is assigned by having the full O365 Group Owners as SCA
2. In a Modern Communications Site, site authorization is still on named accounts level
   1. The SharePoint Group has as members the named accounts of persons in the role
   2. And only the person that on site provision/create time was identified as ‘Site Owner’ (in SharePoint Admin portal), is assigned SCA

This deviation is intentional / by design from Microsoft, with justification: "Most often, a communication site has a small number of people with permission to author content and many people who only have permission to read content. Team sites use Office 365 Groups for permissions. Communication sites use SharePoint groups." (source: Teams Site vs. Communication Site: Which one should I choose?).

However, in concrete business usage more and more business users prefer the Communications Site for internal collaboration usage above that of Team Site. Most significant motivation being the page layout options, that make better usage of the available screen estate. And this practical usage results in a governance flaw, as the permission handling on a "team collaboration site" created via Communications Site deviates from that within a Teams site; and the typical business user has no understanding for this.

I'm not alone in my misunderstanding, a good post on this topic is How broken are Office 365 SharePoint permissions?.

Tip: How-To determine whether guest email already in-usage in your Azure AD tenant

Invitation of a new Azure AD B2B guest is blocked in case the identifying guest email is already present in the inviting Azure AD. A typical situation in which this occurs is that the intended guest is already present as regular Member account, and has to that the external email associated. To avoid the error on invoking Invite Api and instead send an informed response to the requestor, the B2B invitation automation can check first on any occurence of the external email.

The codeline for that is:

Get-AzureADUser -Filter "proxyAddresses/any(c:c eq 'smtp:external.user@externalComp.com')" | Select UserType, UserState

Needed Api Permission for Service Principal to invoke Get-AzureADUser

This week I extended our custom B2B invitation handling build as Azure Automation Runbook to check upfront whether guest account is not present yet. The way to check is by quering for potential presence of requested Guest account via the UPN:

if ($guestAccRequests.length -gt 0) {
    # Get the Service Principal connection details for the Connection name
    $servicePrincipalConnection = Get-AutomationConnection -Name $servicePrincipalConnName   

    # Logging in to Azure AD with Service Principal
    Connect-AzureAD -TenantId $servicePrincipalConnection.TenantId -ApplicationId $servicePrincipalConnection.ApplicationId -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint

    ...

            # 1. Check whether already present as guest account
            $guestUpn = ConvertExternalEmailToUpn -guestEmail $guestEmail
            $existingAccount =  Get-AzureADUser -Filter "userPrincipalName eq '$guestUpn'" | Select UserType, UserState
            if ($existingAccount) {
                ... 
            if ($continueToInvite) {
                try {
                    $inviteResult = New-AzureADMSInvitation -InvitedUserEmailAddress $guestEmail -InvitedUserDisplayName $guestDisplayNameWithOrg -InvitedUserMessageInfo $messageInfo -SendInvitationMessage $False -InviteRedirectUrl "http://www.wvstrien.com" -ErrorAction Stop
                    $inviteurl = $inviteResult.InviteRedeemUrl

The PowerShell coding part was quickly up-and-running. More time-consuming was identifying the proper Api Permission to grant to the Service Connection that connects into Azure AD. We already assigned the 'User.Invite.All' Api Permission from the Microsoft Graph Api, and one would expect that also permission for Get-AzureADUser is within the Graph Api permissions. However, granting the likely permissions 'User.Read.All', 'Directory.Read.All', 'Domain.Read.All'; none of these authorizes the Service Connection.

The information provided by Microsoft in identifying the needed Api Permission is not very good, or at least not easy to find. The StackOverflow post Graph API - Insufficient privileges to complete the operation put me on the right track. Turns out that for this cmdlet you still need to assign permission from the deprecated Azure Active Directory Api.

Replicate B2B governance of SharePoint to Teams

In nowadays enterprises, being able to seamless collaborate with one’s ecosystem is gaining more and more importance. The Office 365 platform supports Business-2-Business collaboration in multiple of its services. However, there are significant differences in the governance supported.

In SharePoint, their is finegrained governance possible, which convinced our critical information security risk management to allow its usage. On tenant level you configure to allow sharing, however without per se enable it on each individual site collection. Plus you can white- and blacklist allowed + never allowed domains, again without this automatic propagated to the individual site collection level. On site collection level you can by default turn off sharing and only explicit enable for targetted site collections, including then white- and blacklisting of domain(s) under condition that these are configured [(dis)allowed] on tenant level. Protection effect is that invited guest is only actually authorized to access a B2B shared site collection if the external domain of guest is allowed for particular site collection. Finally, the customization / extensibility options of SharePoint allow to make visitors of the site via an across site banner aware that the information in this particular site collection is also accessible by persons outside the company.

The out-of-the-box B2B governance of Microsoft Teams is much more limited. Ok, the visual indication of guest(s) presence in the Teams membership is standard. But the guest allowed-mode is on tenant level only: if turned on, all Teams instances by default are allowed / opened for guest access. Including all the Teams instances for which not explicit requested, or even should not be allowed given the internal purpose + audience of that Teams instance. Another miss is that of the check on domain per Teams instance. The resulting risk is that a business user can per accident invite a guest of company Y while intended to invite guest with almost same name from company X.

The lack of the B2B governance with MS Teams results that it is insufficient business secure for our information / security risk management. To get approval, we need to bring the same level of controls to Teams guest access as there is with SharePoint. We do this by extending / customizing on the invite experience in MS Teams. Business users are allowed to invite guests, however not from Teams direct itself due its lack of domain check. Instead we provide via SharePoint a B2B process request page where business user can:

1. Request whitelisting of allowed partner on tenant level; usable for all SharePoint sites and Teams instances
2. Request sharing of individual SharePoint site or Teams instance (including the associated site underneath) for one or more domains; that must be whitelisted on tenant level
3. Request provision of one or more guests, of companies that are allowed on tenant level; usable across entire tenant
4. Specific for Microsoft Teams: invite guest account to a Teams instance

In the automated handling of 4 (via Azure Automation) we verify that the domain of requested guest account is within the “whitelisting” of the identified Teams. If so, the guest is automated added; if not then the request is rejected and business error is prevented.

Peculiarity with Hub sites - SPFx Header displayed state of associated site is initial preserved

Following information architecture situation:

1. A communication site registered as hub site
2. Another site (can be communications or modern teams site) associated with the hub site
3. The associated site has some site info tagging; which is visualized to site visitors through a SPFx Header extension
4. The hub site either does not have site info, or the values that it has are different from that in the associated site

Effect of this situation is that when one navigates within the hub association from associated site to hub and vice versa, it can in its (cached / preserved) header display false / incorrect information...

Site associated with Hub; in this site via SPFx Header extension, some ‘site identification’ is visualized in the site’s header

From this hub-associated site, navigate to the hub site. The header info remains visible, even though the info does not hold for the hub site

Refresh / explicit (first)visit the hub site; then the ‘false-positive’ site info is gone

From first visit of hub, navigate to the associated site. The header info remains invisible, even though this site holds identifying site information

Cause: in an hub, only on 'first-visit' the SPFx Header(s) are executed Inspecting the network traffic, it is evident that the displayed header info is not refreshed on navigating 'within hub context': the SPFx Header is not re-executed. Apparent only on explicit 'first-visit' to an Hub assocation - hub or associated site; then SPFxHeader components are executed. And on any navigation 'within' the hub; the (visual) state of the SPFxHeader is preserved; on same notice as the 'hub navigation.

For performance perspective, makes sense. But in situation where via SPFx Header extension essential site information is displayed, -- which is not per se similar throughout the entire hub association; the result in browser is functional / governance-wise incorrect.

UPDATE - problem resolved thanks to community

On friendly suggestion of Vesa Vujonen, I submitted our finding as SharePoint dev issue: Hub site on navigation preserves SPFx header display state of associated site. And the combined power of the community delivered; Andrew Connell suggested that it's related to the navigatedEvent & the page routers partial page loading, and referred to post of Elio Struijf in which similar behavior is described and solution provided: Handling navigation in a SharePoint Framework application customizer.