This post is part of our series highlighting the Practical 365 authors scheduled to present at The Experts Conference 2022, December 6 & 7. Practical 365 is a proud sponsor of TEC and its mission is to provide practical and actionable Microsoft 365 insights and training for the IT manager and administrator.

Where do Guest External Identities Come From?

Azure AD external identities are created when your tenant allows users to invite guests outside of your organization (like a Gmail user or someone in another Microsoft 365 tenant) to share their documents or participate in a Microsoft 365 group or team. These actions cause Azure AD to create a guest account.

After the external user accepts the email invitation to share a document or join a group or team, a new identity in your tenant is created that looks like JoeBob_SomeDomain#EXT#@AzureTenant.onmicrosoft.com, where “Joe Bob” is the guest email address, “SomeDomain” is their SMTP domain, and “AzureTenant” is your Azure AD tenant namespace.

An issue with guest accounts is lifecycle management and cleanup. When the remote (or federated) external identity is deleted in their home directory, the local guest identity in your Azure tenant is not automatically deleted which we call an orphaned or unused guest account.

Guest accounts only show up in Azure and never synchronize to a local Active Directory, so they often go unnoticed by administrators.

It is highly recommended that every company creates a “Guest User Access Policy” as part of its overall Security Policy. Then once security and legal approve the Security Policy you can implement the security controls.

To review the Azure tenant guest access settings, refer to this Microsoft document on guest sharing settings. It will walk you through all the places where guest accounts gain access in Outlook, Teams, OneDrive, and SharePoint. It is important to review each application.

After reviewing the guest policy settings, you should review all the guest accounts in Azure AD. The articles below will help you identify and control guest accounts.

• Identity Obsolete Guest User Accounts
• Report for Azure Guest User Last Sign In
• Manage guest access with access reviews
• Create a more secure guest sharing environment
• Azure Active Directory: Automating Guest User Management

One way to manage guest access on an ongoing basis after you defined a policy and cleaned up obsolete guest accounts is to implement Azure Identity Governance (IGA). This requires an Azure AD Premium P2 license for everyone involved in conducting guest access reviews. With Azure Entitlement Management, you create Access Packages based on a user’s role that can be assigned to guest users. Each access package has an owner who will review membership during the reviews. Entitlement Management is part of the IGA methodology to create user personas based on roles that you can allow an end user to opt in or out with a manager’s approval.

Azure Business to Business (B2B) External Identities

Microsoft has been improving the Azure B2B cross-tenant access security features to make it more granular. Azure B2B cross tenant access is set up between two different Azure tenants which now includes China Office 365 21Vianet and Azure Government Clouds GCC-High and DoD clouds in Public Preview.

With cross-tenant access policies, you can control the access users have to remote domains and how users from remote domains can access resources in your tenant. This is done by defining controls for the remote (external) and local (your) Azure tenant. Controls can apply to an entire tenant or at a more granular security group or user level.

There are three ways to implement B2B cross-tenant access.

• Default settings apply to all Azure tenants that are not specifically configured in the B2B collaboration or B2B direct-connect sections
• B2B collaboration settings apply to how guest accounts from remote domains are created in your tenant. You are still responsible for managing the lifecycle management of this external identity.
• B2B direct-connect is what is called federation. This method does NOT create a guest user account in your Azure tenant but currently only supports Teams shared channels. The major benefit of this method is that there’s no need for you to manage the external identities as they are controlled in their home tenant.

An administrator can create an Allow or Block access policy for either Inbound or Outbound sharing for both B2B collaboration or B2B direct-connect policies to other remote Azure tenants. The direct-connect has an important feature that can also honor the other tenants MFA and device compliance policies so the external user doesn’t receive two MFA prompts.

An example might be your company has a sister company that you only want a small group of users from the remote Azure tenant to share documents and participate in Office 365 applications. You can create an allow group on each tenant and configure the Organizational settings to only allow that security group access to the Office 365 applications in your tenant. You would then do the same in the remote Azure tenant.

Azure Business to Consumer (B2C) external identities

Azure B2C is a Consumer Identity Access Management (CIAM) Identity Provider (IdP) that supports OAuth 2.0, OpenID Connect (OIDC), Microsoft Authentication Library (MSAL), and a rich set of development languages like .Net, PHP, Java, Ruby, and Node.js.

Azure B2C is unlike Azure B2B or guest accounts as Azure B2C is a totally separate and isolated directory inside of your Azure tenant. An Azure B2C directory (tenant) is created inside of an Azure Subscription and Azure Resource Group. A best practice is to create three Azure B2C directories: development, staging, and production. There is no cost for the development and staging of Azure B2C directories as you will probably never have more than 50,000 monthly active users (MAU) in those directories.

Azure B2C is commonly used in the retail industry to support consumer identities and has a different pricing model than Azure AD. An Azure customer can develop corporate Enterprise Applications that Azure AD users, Azure B2B users, and Azure B2C users all can access with different identities but only support a single application code base.

Azure B2C is an Identity Provider (IdP) that can federate with other Social Providers like Google, Amazon, FaceBook, and you can also create Local Users. It supports its own multi-factor authentication and Identity Protection security features natively.

When deploying any IdP it is always highly recommended to have a Web Application Firewall (WAF) like Azure Front Door, Akamai, or Cloudflare in front of your directory to protect against bots and bad actors. An IdP is just that, an identity store that houses your external identities, it does not provide native protection or external security functions like a WAF.

Conclusion

In conclusion, guest access for your company should be planned and understood by all stakeholders, documented in the company’s Security Policy, and then implemented and reviewed to maintain a clean Azure AD environment.  Ongoing checks and validation of guest accounts will make sure that your company’s Azure AD is not cluttered with obsolete accounts.