Yammer networks configured in Microsoft 365 mode now support Azure B2B collaboration guest users. Which is nice, if it worked. But it doesn’t for me. Guest access worked for me during the testing phase but now that the feature has reached general availability, it won’t – using the same accounts. It’s odd. Yammer’s implementation of Azure B2B Collaboration has some other quirks too, all of which mean that it’s not very usable.
A new preview feature allows the resources available to an Azure AD guest account to be reassigned to another email address. It’s a nice feature, but Teams has some problems with it at present. On the upside, everything works great with SharePoint Online and Planner, and we’re sure that Microsoft will fix the problem with Teams soon.
Teams supports federated guest access for Gmail accounts using the identity provider framework of Azure B2B Collaboration. Office 365 tenants must first decide if they want Gmail accounts as guests in all or some teams before going down the federation route. Why Teams and not other Office 365 apps? It’s all to do with the endpoint used by the client to connect. If it can handle federation, all good. If not, it’s standard Azure B2B Collaboration.
Office 365 Informatiom Barriers allow tenants to erect communication firewalls between different groups. Teams supports Information Barriers, but currently has a problem adding new guest accounts to team memberships. An easy workaround exists, but debugging what’s going on is difficult because of the lack of clues.
When you impose a block on certain domains, you’d like to think that applications like Teams will respect that block. As it turns out, if you have some lingering guests in your Azure Active Directory, the B2B collaboration policy might not be as effective as you’d hope.
Microsoft has launched the preview of Google B2B Federation, which allows Google accounts to be used to access Azure AD apps. Quite how this will work out for apps that use guest user accounts is unknown at this point.