来自非托管 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?
我正在为我的公司试用 Azure AD B2B 功能。我尝试通过门户网站和使用 https://graph.microsoft.com/beta/invitations 邀请外部用户。在这两种情况下，用户都被成功邀请并添加到我们的目录中。登录适用于社交帐户（然后使用 Microsoft 帐户）。如果它是一个非社交帐户，又名 contoso.com，之前没有 Azure AD，当我们的应用程序尝试登录用户时，我会得到一个 access_denied。如果我尝试强制同意流程，我会收到以下消息：
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 应该是无缝的：
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.
如果他们可以注册并创建他们的用户和目录，为什么他们不能给他们被邀请同意登录的应用程序（登录和读取用户配置文件委托权限是必需的应用）？
我们已经允许拥有自己托管的 Azure AD 的公司在我们的应用程序中使用他们的用户。我们让全局管理员向管理员授予我们应用程序的许可，以便他们可以登录用户并读取目录数据。这些用户未添加到我们的目录中，但它运行良好。
此外，如果我以受邀用户身份访问新门户，我可以看到域 aaa.no 已通过验证，但我无法将其设置为主要域。
我尝试过但没有用的其他方法：升级到最新的 ADAL 版本，尝试在 https://apps.dev.microsoft.com 中创建应用程序并使用它，尝试在旧的 Azure 门户中设置权限（似乎是权限未显示在清单中的新门户）并尝试使应用程序成为单一租户。没有任何效果。
编写 Azure AD 多租户应用程序的最普遍指南和示例建议使用公共终结点而不是特定于租户的终结点。
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 协作被添加为访客功能 - 简而言之，公共端点不支持来宾。
另一方面，租户特定端点仅允许该租户的用户登录。虽然它不进行租户发现，但它仍然允许其他租户的用户尝试登录，但随后会检查查看他们是否已作为客人添加到租户。如果没有，登录将失败 - 简而言之，来宾用户（通过 B2B 协作功能添加的用户），只能在租户特定端点工作。
如果您希望您的多租户应用程序支持来宾，您需要自己进行租户发现并利用租户特定端点而不是公共端点。
这意味着您的应用程序需要知道哪个 Azure AD 租户与每个 workspace/team/instance/whatever-isolation-level-in-the-all 关联，例如：
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 支持人员给了我相同的结论：公共终结点不适用于来宾用户。我最终得到的解决方法是将所有用户添加为我的租户中的来宾用户，并使用租户特定的端点。我还注意到来宾用户获得的 objectId 与他们的家庭用户不同，这意味着当外部租户用于确定组成员资格等时，我们需要存储来宾和家庭用户之间的关系。
这是我从 Azurte 支持人员那里得到的最终回复：
症状
您正在为多个客户发送 B2B 邀请，使他们能够使用您在 Azure AD 目录 nameOfTenant.onmicrosoft.com
上创建的多租户应用程序 "NameOfApplication"
驻留在非托管目录中的受邀电子邮件验证用户无法访问应用程序，并出现 "Access Denied" 错误。底层错误消息：
AADSTS65005：贵公司目前不支持应用程序 NameOfApplication。否。您的公司目前处于非托管状态，需要管理员通过 .no 的 DNS 验证来声明公司的所有权，然后才能配置应用程序 NameOfApplication。
原因
这里的问题在于用于进行用户身份验证的端点。
在 b2b 邀请和公共租户端点的情况下，暗示将使用租户发现。这也意味着用户将在其原始租户中进行身份验证，而不会使用在应用程序实际存在的租户中创建的来宾帐户。
结论：通用端点目前不支持来宾帐户。
如果使用特定于租户的端点，则将使用 b2b 过程生成的来宾帐户，但只有来自该特定租户的用户才会被验证。
这意味着来自其他租户的用户可能仍会尝试进行身份验证，但如果他们尚未作为访客添加到原始租户，则身份验证将失败。
结论：来宾用户（来自 b2b）将仅在特定于租户的端点中工作
分辨率
遗憾的是，没有其他方法可以解决此问题，除非开发您的应用程序以执行自定义的租户发现操作，并从那里能够为每个应用程序使用特定于租户的端点。
引用自己的话：
“…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)…”
我正在为我的公司试用 Azure AD B2B 功能。我尝试通过门户网站和使用 https://graph.microsoft.com/beta/invitations 邀请外部用户。在这两种情况下，用户都被成功邀请并添加到我们的目录中。登录适用于社交帐户（然后使用 Microsoft 帐户）。如果它是一个非社交帐户，又名 contoso.com，之前没有 Azure AD，当我们的应用程序尝试登录用户时，我会得到一个 access_denied。如果我尝试强制同意流程，我会收到以下消息：
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 应该是无缝的：
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.
如果他们可以注册并创建他们的用户和目录，为什么他们不能给他们被邀请同意登录的应用程序（登录和读取用户配置文件委托权限是必需的应用）？
我们已经允许拥有自己托管的 Azure AD 的公司在我们的应用程序中使用他们的用户。我们让全局管理员向管理员授予我们应用程序的许可，以便他们可以登录用户并读取目录数据。这些用户未添加到我们的目录中，但它运行良好。
此外，如果我以受邀用户身份访问新门户，我可以看到域 aaa.no 已通过验证，但我无法将其设置为主要域。
我尝试过但没有用的其他方法：升级到最新的 ADAL 版本，尝试在 https://apps.dev.microsoft.com 中创建应用程序并使用它，尝试在旧的 Azure 门户中设置权限（似乎是权限未显示在清单中的新门户）并尝试使应用程序成为单一租户。没有任何效果。
编写 Azure AD 多租户应用程序的最普遍指南和示例建议使用公共终结点而不是特定于租户的终结点。
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 协作被添加为访客功能 - 简而言之，公共端点不支持来宾。
另一方面，租户特定端点仅允许该租户的用户登录。虽然它不进行租户发现，但它仍然允许其他租户的用户尝试登录，但随后会检查查看他们是否已作为客人添加到租户。如果没有，登录将失败 - 简而言之，来宾用户（通过 B2B 协作功能添加的用户），只能在租户特定端点工作。
如果您希望您的多租户应用程序支持来宾，您需要自己进行租户发现并利用租户特定端点而不是公共端点。
这意味着您的应用程序需要知道哪个 Azure AD 租户与每个 workspace/team/instance/whatever-isolation-level-in-the-all 关联，例如：
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 支持人员给了我相同的结论：公共终结点不适用于来宾用户。我最终得到的解决方法是将所有用户添加为我的租户中的来宾用户，并使用租户特定的端点。我还注意到来宾用户获得的 objectId 与他们的家庭用户不同，这意味着当外部租户用于确定组成员资格等时，我们需要存储来宾和家庭用户之间的关系。
这是我从 Azurte 支持人员那里得到的最终回复：
症状
您正在为多个客户发送 B2B 邀请，使他们能够使用您在 Azure AD 目录 nameOfTenant.onmicrosoft.com
上创建的多租户应用程序 "NameOfApplication"驻留在非托管目录中的受邀电子邮件验证用户无法访问应用程序，并出现 "Access Denied" 错误。底层错误消息：
AADSTS65005：贵公司目前不支持应用程序 NameOfApplication。否。您的公司目前处于非托管状态，需要管理员通过 .no 的 DNS 验证来声明公司的所有权，然后才能配置应用程序 NameOfApplication。
原因
这里的问题在于用于进行用户身份验证的端点。
在 b2b 邀请和公共租户端点的情况下，暗示将使用租户发现。这也意味着用户将在其原始租户中进行身份验证，而不会使用在应用程序实际存在的租户中创建的来宾帐户。
结论：通用端点目前不支持来宾帐户。
如果使用特定于租户的端点，则将使用 b2b 过程生成的来宾帐户，但只有来自该特定租户的用户才会被验证。 这意味着来自其他租户的用户可能仍会尝试进行身份验证，但如果他们尚未作为访客添加到原始租户，则身份验证将失败。
结论：来宾用户（来自 b2b）将仅在特定于租户的端点中工作
分辨率
遗憾的是，没有其他方法可以解决此问题，除非开发您的应用程序以执行自定义的租户发现操作，并从那里能够为每个应用程序使用特定于租户的端点。
引用自己的话：
“…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)…”