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.
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 [email protected] 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