Recently, I had a customer ask how to help enable their Office 365 tenants to collaborate more easily. Currently, the problem they face is generating invitations to an ever-growing and ever-changing list of recipients across tenants. It requires a lot of hand-holding and maintenance.
Lucky for us, there’s an option that might be helpful.
Welcome to the world of Connected Organizations and Azure AD Entitlements. In this example, we’re going to work with just a few tenants, granting access to a sample Microsoft Team and SharePoint Online site in the host tenant to users in the guest tenant.
- Entitlement Configuration
Per our documentation, the idea of connected organizations is being able to more easily share content and applications across loosely coupled or partner organizations. Many of my customers have multiple tenants for a variety of business reasons, so the topic of managing guests in all of an organization’s tenants can be tricky to navigate.
Fortunately, there may be a way to help alleviate some of this. With Connected Organizations, you can configure relationships with other tenants (or on-premises environments) and assign sites, teams, or other resources as part of a package.
Before we really get rolling, though, we’re going to take a quick step back and establish some terminology and a general overview of the architecture so you know what we’re talking about before we start getting too far.
The entire concept of connected directories is really around automating and taking the manual administration out of Azure AD B2B user access scenarios. So, if you’re familiar with how Azure AD B2B works, you’re already ahead of the game.
A connected organization is just that–an organization that you have a some sort of relationship with and want to share resources. It can be a different business unit or department with their own tenant or AD forest, a partner organization, or even a vendor or customer, depending on your business scenario.
Entitlement management is the process of determining and managing who has access to what resources in your organization.
A catalog is a container of resources and access packages. It’s used to group related resources and access packages together in a logical manner.
An access package is a specific set of settings, resources, and policies that is used to administer access for a particular business purpose. For example, an access package might have a SharePoint site, a configuration specifying what users can request access, approval settings, and package lifecycle settings that govern how long users will retain access to the resources.
A policy is a set of rules used to govern the access package. They can be scoped to internal or external users.
Resources are objects in the environment that are used to identify groups, applications, or sites.
The process by which a user receives an access package (as in, it is assigned to them).
Someone who requests access to a resource.
Someone who grants access to resource request.
My Access Portal
The portal lists the resources that you have access to (or access to request). For commercial cloud customers, it’s located at
https://myaccess.microsoft.com. For US Government customers, it will be
https://myaccess.microsoft.us. If you’re using it to see entitlements outside of your organization, you’ll need to use the link supplied by the host organization, which will include a domain hint to help your browser navigate to the correct instance. By navigating to the site for your own tenant, you can see what access packages have been created, your history, and any approvals or reviews.
This is the domain that has been verified in the Office 365 tenant.
Next, we’ll look at how all of these things are supposed to work together.
The general architecture for how Connected Directories and resources looks like this:
An administrator (or other user granted permissions to be a catalog creator) creates a catalog, and then adds resources to the catalog. Once the resources have been added, roles and policies are defined and then bundled into an access package. From there, the access package is created and then shared with users.
While it just looks like a couple of boxes on the screen, the underlying workflow is a little more complex:
- For external organizations only, you’ll add a connected organization for the Azure AD directory or domain you want to collaborate with. For internal user requests, you’ll skip to step 2.
- You create an access package in your directory that includes policies. You may choose one policy for everyone, or choose different policies for internal and external users.
- Internal users will go to https://myaccess.microsoft.com and sign in with their Azure AD identity. For external users, you’ll send the My Access portal link (complete with the domain hint) to someone at the remote organization or publish it on an extranet site that remote users already have access to.
- A Requestor A in this example uses the My Access portal link to request access to the access package.
- If configured, a message is sent to an approver, who then has to choose to either approve or deny the request. If the policy is configured to allow auto-approval, it will be processed without intervention.
- If approved, the request goes into the delivering state.
- If the requestor is external, Azure AD leverages the B2B invite process and creates guest user account in your local Azure AD. If an allow list or a deny list is defined, the list setting will be applied.
- The user is assigned access to all of the resources in the access package using the policy settings for each resource. It can take some time for changes to be made in Azure AD and to other Microsoft Online Services or connected SaaS applications.
- The user receives an email indicating that their access was delivered (processed).
- To access the resources, internal users can open the resources directly or navigate to their My Access page. External users can either click the link in the email or attempt to access any of the directory resources directly to complete the invitation process.
- Depending on the policy settings, as time passes, the access package assignment for the user expires, and the external user’s access is removed.
Depending on the lifecycle of external users settings, when the external user no longer has any access package assignments, the external user is blocked from signing in and the guest user account is removed from your directory.
In order to configure these features, you’ll need to have a few ducks in order:
- You should be a Global Administrator to at least perform the initial configuration. You can later delegate various roles (such as creation of catalogs and access packages).
- You’ll also need Azure AD Premium P2 license for the members of your organization who request, use, approve, or otherwise use an access package. Depending on which licensing model your organization uses for Azure for external identities, you may also need to look at our licensing and billing guidelines to ensure you’re legit.
- Guest access for Azure AD Groups should be turned on: https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/UserSettings
- External Access for SharePoint should be configured to either Anyone or New and existing guests if you want to enable new users to be able to receive access.
- Guest access for Teams should be turned on (https://admin.teams.microsoft.com/company-wide-settings/guest-configuration):
Once you’ve got everything set, you can move on to ….
Since this is a “getting started” level tutorial, I’m going to assume you haven’t done this before. So, you’ll likely just have either nothing or a catalog called something like General. We’re going to create a brand new one so you can see the whole process.
But, before we get there, we’ll want to make sure we have the resources gathered that we want to give access to. Since a catalog is a collection of resources, it won’t be much good without any resources to add. For this example, we’re going to use the following resources:
- a SharePoint Site (ingeniously named “Cross-Org Site”)
- a Microsoft Team (with a similarly creative name, “Cross-Org Team”)
- an empty Azure AD security group with Assigned membership (you’ll never guess what I named it)
Once you’d got some resources created, it’s time to start configuring stuff!
Configuring a Connected Organization
We’ve laid enough groundwork, so now we can begin configuring everything. For this example, we’re going to use two tenants:
- Host tenant: o365ninja.onmicrosoft.com
- Connected Organization: undocumentedfeatures.onmicrosoft.com
To begin the configuration, we’re going to start in the host tenant, o365ninja.com. Remember, in the host tenant, you’ll need to be an administrator and have the Azure AD P2 licenses. Once we get to granting access and testing out the client experience, we’ll switch tenants.
First, we’ll start by adding a Connected Organization.
- Navigate to the Identity Governance blade of the Azure portal. It’s located at https://aad.portal.azure.com/#blade/Microsoft_AAD_ERM/DashboardBlade/GettingStarted.
- Select Connected organizations under Entitlement management.
- Click + Add connected organization from the menu bar area.
- Fill out a name and a description (both are required). The state, by default, is set to Configured and will allow users in this connected organization to be included in access packages targeted to “all configured organizations.” For more information on the Configured and Proposed states, see: https://docs.microsoft.com/en-us/azure/active-directory/governance/entitlement-management-organization#state-properties-of-connected-organizations. Click Next: Directory + domain > to continue.
- Select the Add directory + domain link on the top half of the page. It isn’t terribly obvious, but it does have a red asterisk next to it.
- Enter one of the verified domain names of the guest tenant. You can use the onmicrosoft.com domain or any of the other verified domains in the tenant. As the screen indicates, users from any of the verified domains in the tenant will be included, so you don’t have to specify them individually. Click Add once you’ve identified the tenant, and then click Select to choose that tenant.
- Once you’re done, you can either select Review + Create to create it immediately, or you can click Next: Sponsors > to specify sponsors for the connector. Sponsors are the points of contact for the connected directory. Sponsors have to be users already in the tenant. For internal sponsorship, select a local user from your Azure AD. For external sponsorship, select a guest user representing a user from the remote tenant.
- If you choose to add sponsors, click the Add/Remove link next to Add internal sponsors and Add external sponsors and choose the appropriate users. When finished, click Next: Review + Create >.
- Verify the configuration and then click Create.
- Pat yourself on the back now that the connected organization has been created.
With a connected organization created, now it’s time to start creating the catalog and access packages!
Creating a Catalog
As you learned earlier in this treasure trove of information, a catalog is used to store all of the objects that can be configured in various access packages.
- In the Azure AD portal, navigate to the Catalogs blade: https://aad.portal.azure.com/#blade/Microsoft_AAD_ERM/DashboardBlade/elmCatalog.
- Click the + New catalog button.
- Enter a name and description. In this case, we want to share it with users outside our tenant, so we’ll want both the Enabled and Enabled for external users toggles set to On.
- Click Create.
- Select the catalog from the list.
- Click Resources and then + Add resources.
- Search for and add the SharePoint Site and Team you want to make part of this catalog. Click Select.
- Click Add.
You’ve got a catalog!
Adding an Access Package
Now, we’ll create an access package that is used to provide … access … to those resources.
- From the Azure Active Directory management page, select Identity Governance.
- Under Entitlement management, select Access packages.
- Click + New access package.
- Add a name and a description, and then select a catalog from the drop-down. Click Next: Resource roles > to continue.
- Add the resources by clicking the + for the appropriate type.
- In this example, I’m going to add the team and SharePoint site I created earlier.
- If you find that you didn’t add all of the resources to the catalog earlier, you can select the box See all Group and Team(s) not in the ‘<name>’ catalog. You must have the correct permissions to add them in this access package and then search for the missing objects.
- For each resource type, select which role you’d like added users to receive, such as Member or Owner (for a Team or Office 365 group) or Member, Visitor, or Owner for SharePoint Sites.
- Click Next: Requests >.
- Select the For users not in your directory radio button, and then select one of the radio buttons to scope the connected organizations. For this example, I’m going to select the Specific connected organizations radio button, and after clicking the +Add directories link, I’ll add the remote tenant that I’ve already configured as a connected organization.
- For this example, I’m going to leave the Require approval toggle set to No. I’m treating the Undocumented Features tenant as a long-term collaboration partner whose users I trust, so any data stored in these shared teams or groups is safe to be accessed by members of both organizations.
- Select Yes under Enable to enable new requests and assignments.
- Click Next: Requestor Information > to continue.
- If you want the requestors to provide additional information, you can use the Requestor information tab to populate questions that the user must answer. I’m going to add a sample one, just so you can see it during the demo. This step is totally optional.
- Click Next: Lifecycle > to go to the next page.
- Here, you can manage the assignment lifecycle, requiring people to re-request or perform access reviews, based on your organization’s requirements. If you want to dive into Access Reviews, you most certainly can. Our documentation on it is here: https://docs.microsoft.com/en-us/azure/active-directory/governance/access-reviews-external-users. I’ll look to cover it in a future post. I’m going to select the Yes to enable a review, and just let the users re-confirm themselves.
- Click Next: Review + Create > to review the settings for the access package.
- Confirm the settings and then click Create.
- Once the access package has been created, you’ll be returned to the Overview properties sheet for the package.
You’ve now got an access package.
Copy the My Access portal link value to your clipboard. We’re going to use it in the next section. Woot!