Checking Where Tenant Users Go as Guests

Managing External Guest Activity Controlled by the Host Tenant

After the original fuss about the Teams feature where users can invite external people to join chats through email had subsided, a brief flame reignited when The Hacker News posted an article explaining the risks involved when someone invites a user from your tenant to join them for a chat. If the invitation is accepted, a guest account for the invited user is created in the host tenant and the chat proceeds.

The problem highlighted by the article is that the host tenant determines what kind of protection it wishes to apply to Teams messaging. The host tenant can turn Microsoft Defender for Office 365 protection off, and disable the protections against weaponized file types and malicious URLs recently introduced for Teams. With all protection disabled, there’s nothing to stop a malicious file or URL being shared in chat that could potentially infect your tenant.

It’s correct that Entra B2B Collaboration works this way. When someone becomes a guest in another tenant, they agree to collaboration managed by the host tenant rather than their home tenant. For instance, any compliance records captured to note actions taken by the guest account are owned by the host tenant. The user’s home tenant has no idea whatsoever about what someone does outside the security boundary of that tenant.

Discovering Where Tenant Users Go as Guests

This then begs the question whether a home tenant can discover what host tenants their users are active in. A home tenant can restrict access to certain host tenants through policy, but that doesn’t mean that guest accounts for users in the home tenant don’t exist and are not active in “blocked” host tenants. If those accounts were created prior to the block being imposed, they will continue to function afterwards.

Microsoft’s solution for figuring out where users are active guests is a workbook to report cross-tenant activity, which uses sign-in data ingested into Azure Log Analytics to generate an activity analysis. This is great if the tenant ingests Entra ID sign-in logs into Log Analytics because you can go back further than the 30-day retention period for online sign-in logs used by Entra ID. Unfortunately, not every tenant uses Log Analytics, but we can use PowerShell to do the job. Let’s look at what needs to be done.

Using PowerShell to Analyze External Guest Activity

PowerShell can access the same sign-in audit data using cmdlets from the Microsoft Graph PowerShell SDK. In this case, we use the Get-MgBetaAuditLogSignIn cmdlet to fetch sign-in logs because the beta version delivers more information than the production (V1.0) version does. Two key properties are the HomeTenantId and the ResourceTenantId. The first is the identifier for the home tenant; the second is the identifier for the host tenant. For normal activity by a user within their home tenant, the two values are the same. When the identifiers differ, we know we’re dealing with cross-tenant activity.

The logic flow is straightforward:

• Find audit log records for successful sign-in records for the period to analyze. A very large number of sign-in records might be available for large tenants, so it will take time to retrieve the audit data for a complete month. Unfortunately, the Graph API doesn’t support a server-side filter to find records where the home tenant identifier is different to the host tenant identifier, so a client-side filter is necessary to extract the records for cross-tenant activity.
• Cross-tenant activity can be outbound (our users accessing host tenants as guests) or inbound (users from other tenants accessing our tenant as guests). The script creates separate arrays for both types of activity.
• For each tenant identifier, the script calls the Find-MgTenantRelationshipTenantInformationByTenantId cmdlet to resolve the identifier to a tenant name and domain. For example, the identifier 72f988bf-86f1-41af-91ab-2d7cd011db47 resolves to “Microsoft.”
• The script extracts details of the number of unique sign-ins for the tenant, the user principal names of the accounts that are signing in as guests, and apps hosted by the tenant that are being signed into.
• The script reports some basic information and generates an output file. If the ImportExcel module is available, the output is an Excel worksheet. Otherwise, it is a CSV file.

Figure 1 shows the external tenant access report for my tenant. I’m the only one who has accessed other tenants as a guest, but a reasonable number of people from other tenants have guest accounts in my tenant, notably to help with the Office 365 for IT Pros eBook.

The script is available from the Office 365 for IT Pros GitHub repository.

Only Sign-ins

It’s important to recognize that the data reported here are sign-in records captured by Entra ID when someone goes through the sigh-in process. There’s no detail about what someone actually does after they successfully authenticate and connect to a host tenant. That data resides in the host tenant and is inaccessible unless an administrator of that tenant makes it available to you. But at least we can determine who’s an active guest in other tenants, which is the purpose of this exercise.

---

Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.