Forum Discussion

chagedorn49's avatar
chagedorn49
Copper Contributor
Mar 06, 2025

Audit users to view who are guests in other tenants

We know that there are instances where personnel from our organization have been added as Guest users in an external organization's tenant. Is there anywhere in Entra, or another admin portal, where we can identify our users who are also guest users in a different tenant? 

Our Security IG team wants to block the ability for our users to be invited / added to other tenants, but first we'd like to run an audit to figure out who this is going to affect. We'd also like to figure out if there is any way to make exceptions in the case these users have a valid business justification for being Guest users in external tenants.

2 Replies

  • Franck Horowitz's avatar
    Franck Horowitz
    Copper Contributor
    Mar 09, 2025

    For your Audit requirement this workbook is the answer https://learn.microsoft.com/en-us/entra/identity/monitoring-health/workbook-cross-tenant-access-activity

     

  • LainRobertson's avatar
    LainRobertson
    Silver Contributor
    Mar 07, 2025

    Hi chagedorn49,

     

    As far as I can recall, there's no convenient user API approach to auditing organisation-wide to which external tenants your users have been invited.

     

    My best guess alternative would be to check the sign-in logs, where you should be able to see entries when one of your users signs into the external tenant. This won't provide a complete audit, as it will only reflect recent activity, but it may be the best option you have.

     

    For the second question you have: Yes, you can establish exceptions using a layered approach - much like you see in Group Policy, or even a firewall.

     

    Navigate to the cross-tenant access settings as shown below:

     

     

    Here's where you implement your two-tiered approach.

     

    First, if you don't want any of your users being invited ad hoc to external tenants, you want to adjust your default outbound settings to reflect that:

     

    Note: Be warned that this results in "blocked" being set for both "users and groups" and "external applications". I'd recommend testing this in a non-production tenant first, if you have one that adequately mirrors the production tenant. It's the external applications context I'd be most wary of.

     

    In adjusting the defaults, you've now achieved for your first aim of blocking everyone by default, meaning you should now create your exceptions (technically, you could do this first - the ordering doesn't matter):

     

    After you've added the tenant you want to permit access to, you can edit the outbound settings and target groups (preferred approach) or users (non-preferred approach) as shown below:

     

    These settings will take precedence over the tenant-wide defaults you specified initially, which will allow your existing or new exceptions to still communicate with that external tenant.

     

    Cheers,

    Lain