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 . Users are successfully invited and added to our directory in both scenarios. Login works for social accounts (that then use a Microsoft account). If it's a non-social account aka contoso.com, that does not have an Azure AD from before, I get an access_denied when our application tries to log in the user. If I try to force a consent flow, I get the following message:

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

We have a lot of small companies as customers and it seems unreasonable that they all have to make the Azure AD directory managed before their users can use our applications. It's supposed to be seamless according to Microsoft :

Seamless: The partner companies who need access to your corporate apps do not need to have Azure AD. Azure AD B2B collaboration provides a simple user sign-up experience to provide these partners with immediate access to your apps.

If they can sign up and create both their user and the directory, why can't they give the application they have been invited to consent for sign-in (Sign in and read user profile delegate permissions is required by the application)?

We already allow companies with their own managed Azure AD to use their users in our applications. We get a Global Administrator to give admin consent to our applications so they can sign in users and read directory data. These users are not added to our directory and it works perfectly.

Also, If I go to the new portal as the invited user, I can see that the domain aaa.no is verified, but I cannot set it as primary.

Other things I have tried that did not work: Upgraded to newest ADAL version, tried to create application in https://apps.dev.microsoft.com and use that, tried to set permissions in old azure portal (seems to be a bug in the new portal where permissions does not show up in the manifest) and tried to make the application single tenant. Nothing works.

Answer 1

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

Answer 2

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)…”