Can users from an unmanaged Azure AD directory, sign into an Azure AD multi-tenant application which resides in a different directory?

Question

I\'m trying out Azure AD B2B capabilities for my company. I have tried to invite external users through the portal and by using https://graph.microsoft.com/beta/invitations.

Answer 1

As you can see from below, Azure support gave me the same conclusion: The common endpoint does not work for guest users. The workaround I ended up with is to add all users as guest users in my tenant and use the tenant specific endpoint. I also noticed that guest users get a different objectId than their home user, which means we needed to store the relation between guest and home user when external tenants where used to determine group membership etc.

Here is the final response I got from Azurte support:

Symptom

You are sending B2B invites for several customers to enable them to use your multi-tenant application "NameOfApplication" that has been created on the Azure AD directory nameOfTenant.onmicrosoft.com

Invited email verified users that reside on unmanaged directories are unable to access the application with an "Access Denied" error. The underlying error message :

AADSTS65005: The application NameOfApplication is currently not supported for your company .no. Your company is currently in an unmanaged state and needs an Administrator to claim ownership of the company by DNS validation of .no before the application NameOfApplication can be provisioned.

Cause

The issue here lies with the endpoints being used to proceed with user authentication.

In the case of b2b invites and the common tenant endpoint it is implied that tenant discovery will be used. This also means that the users will be authenticated in their original tenants and not use the guest account that was created in the tenant where the application actually exists.

Conclusion: the common endpoint does not, at this point in time, support guest accounts.

If tenant specific endpoints are used, then the guest accounts generated by the b2b process will be used but only users from that specific tenant will be authenticated. This means that users from other tenants might still try to authenticate but if they haven’t been added as guests to the original tenant, the authentication will fail.

Conclusion: guest users (from b2b) will only work in the tenant specific endpoint

Resolution

There is unfortunately no other method to resolve this matter unless by developing your application to perform a customized tenant discovery operation and from there being able to use the tenant specific endpoint for each.

Quoting from you own words:

“…I use the tenant specific endpoint and convert all users to guests in that tenant. Users in managed external tenants that we get directory read access to can then be added as guests when they become members of groups (in their tenant) that we monitor. That way we still allow these companies to control access to our systems from within their system. All other users will be added as guests manually (social accounts, unmanaged external tenants, and from managed external tenants that we do not have read directory access to)…”

Answer 2

The most prevalent guidance and examples for writing Azure AD multi-tenant apps recommend using the common endpoint instead of tenant specific endpoint.

Common endpoint: https://login.microsoftonline.com/common/oauth2/authorize
Tenant specific endpoint: https://login.microsoftonline.com/company.com/oauth2/authorize

The common endpoint allows users from any tenant to log in. It achieves this by doing tenant discovery, meaning that, based on the user's email, it'll automatically redirect the user to their tenant endpoint. However, this also means that user@company.com will always be signed-in as an employee of company.com and never as a guest of some other company they've been added as a guest to via the B2B collaboration feature - In short, the common endpoint doesn't support guests.

The tenant specific endpoint on the other hand, only allows users from that tenant to log in. While it doesn't do tenant discovery, it still allows users from other tenants to attempt to sign in, but will then check to see if they've been added as guests to the tenant. If they haven't, the sign in will fail - In short, guests users (users added via the B2B collaboration feature), only work in the tenant specific endpoint.

If you want your multi-tenant application to support guests, you'll need to do tenant discovery yourself and leverage the tenant specific endpoints rather than the common endpoint.

This means that your application will need to know which Azure AD tenant is associated to each workspace/team/instance/whatever-isolation-level-in-the-all, for example:

contoso.myapp.com or www.myapp.com/contoso will sign in users via login.microsoftonline.com/contoso.com

and

fabrikam.myapp.com or www.myapp.com/fabrikamwill sign in users via login.microsoftonline.com/fabrikam.com