来自不受管理的Azure AD目录的用户可以登录到位于其他目录中的Azure AD多租户应用程序吗? [英] Can users from an unmanaged Azure AD directory, sign into an Azure AD multi-tenant application which resides in a different directory?

查看:230
本文介绍了来自不受管理的Azure AD目录的用户可以登录到位于其他目录中的Azure AD多租户应用程序吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在为公司试用Azure AD B2B功能.我试图通过门户并使用 https://graph.microsoft.com/beta邀请外部用户/邀请.在这两种情况下,都成功地邀请了用户并将其添加到我们的目录中.登录适用于社交帐户(然后使用Microsoft帐户).如果它是一个非社交帐户(又名contoso.com),并且以前没有Azure AD,则当我们的应用程序尝试登录用户时,我得到一个access_denied.如果我尝试强制达成同意流程,则会收到以下消息:

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:您的应用当前不支持应用程序zzz 公司aaa.no.您的公司目前处于不受管理的状态,并且 需要管理员通过DNS声明对公司的所有权 可以在配置应用程序zzz之前对aaa.no进行验证.

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.

我们有许多小型公司作为客户,似乎它们在用户使用我们的应用程序之前都必须对Azure AD目录进行管理是不合理的.根据 Microsoft :

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:

无缝:需要访问您的公司应用程序的合作伙伴公司 不需要具有Azure AD. Azure AD B2B协作提供了 简单的用户注册体验,可为这些合作伙伴提供 立即访问您的应用.

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)?

我们已经允许拥有自己的托管Azure AD的公司在我们的应用程序中使用其用户.我们获得了全球管理员的同意,以便管理员同意我们的应用程序,以便他们可以登录用户并读取目录数据.这些用户没有添加到我们的目录中,并且可以正常运行.

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.

此外,如果我以受邀用户的身份转到新门户,则可以看到域aaa.no已验证,但是无法将其设置为主域.

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.

我尝试过的其他方法无效:升级到最新的ADAL版本,尝试在 https:中创建应用程序: //apps.dev.microsoft.com 并使用它,尝试在旧的Azure门户中设置权限(似乎是新门户中的错误,其中权限未显示在清单中),并尝试使应用程序单租户.什么都行不通.

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.

推荐答案

有关编写Azure AD多租户应用程序的最流行的指南和示例建议使用公共终结点而不是特定于租户的终结点.

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

公共端点允许任何租户的用户登录.它通过进行租户发现来实现此目的,这意味着,它将根据用户的电子邮件自动将用户重定向到其租户端点.但是,这也意味着user@company.com将始终以company.com的员工身份登录,而永远不会作为其他公司的访客通过B2B协作功能被添加为访客. ,公共端点不支持访客.

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.

另一方面,特定于租户的端点仅允许该租户中的用户登录.虽然它不执行租户发现,但仍允许其他租户中的用户尝试登录,但随后将进行检查以查看(如果已将它们添加为租户的来宾).否则,登录将失败-简而言之,来宾用户(通过B2B协作功能添加的用户)只能在特定于租户的端点中工作.

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.

如果您希望多租户应用程序支持来宾,则需要自己进行租户发现并利用租户特定的端点而不是公共端点.

这意味着您的应用程序将需要知道哪个Azure AD租户与每个工作区/团队/实例/所有隔离级别相关联,例如:

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

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

这篇关于来自不受管理的Azure AD目录的用户可以登录到位于其他目录中的Azure AD多租户应用程序吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆