AAD B2B 协作：使用附加信息在外部隐藏的 AAD 中标记用户
AAD B2B collaboration: mark users in external hidden AAD with additional info
我们有一个使用 AAD B2B 协作来邀请用户的应用程序。这些用户在我们的 AAD 中创建为来宾用户。这一切都很好：
- 拥有 AAD/Office 365 的用户可以使用他们的正常凭据登录。
- 没有 AAD/Office 365 的用户在邀请兑换过程中创建他们的帐户，并可以使用它来登录。Microsoft 将这些帐户存储在外部，对我们来说是隐藏的 AAD。
情况：
一个组织使用我们的应用程序。该组织还没有自己的 AAD/Office 365。我们使用他们的电子邮件地址在我们的 AAD 中邀请该组织的一些员工。他们在我们的 AAD 中获得来宾帐户。
一段时间后，该组织为其现有域名获得了自己的 AAD/Office 365。此域名以前用于邀请兑换过程中的电子邮件地址。
组织的 AAD 管理员创建 AAD，并立即看到现有的用户帐户：所有被邀请的帐户都显示在 AAD 中。他在创建新的 AAD 时没有预料到这一点，他也不知道它们来自哪里。
看起来外部的，对我们来说是隐藏的 AAD，已经对 AAD 管理员可见。
AAD 管理员可能决定删除这些帐户，从一个空的 AAD 开始。因此，员工无法再在我们的应用程序中登录。
我们的应用程序使用 Microsoft Graph API 来邀请用户。
有没有办法通过某种方式标记外部隐藏AAD中的用户，以明确帐户来自哪里？喜欢在现有领域提及我们的 organization/application？
明确一点：我们不想在来宾帐户上设置属性。我们想要在 AAD 管理员创建 AAD 时看到的用户帐户上设置属性。我们要明确他不能删除这个用户，因为它创建了 by/for 应用程序 X.
不，这是 Azure AD 的一项功能。
如果域所有者选择稍后创建隐藏的 Azure AD，则他们可以选择接管隐藏的 Azure AD。
他们控制了域，从而控制了用户，所以这取决于他们。
当然，如果您使用 Gmail 帐户创建 AAD 来宾用户，他们实际上不会被添加到巨大的隐藏 Google Azure AD 中。
如果 AAD 认为该帐户是社交帐户，目前他们会为该用户透明地创建个人 Microsoft 帐户（因此用户始终可以控制他们的帐户）。
因此，如果您使用工作电子邮件邀请用户，您必须期望他们的域所有者能够控制他们用户的帐户。
据我所知，没有 属性 可以设置。
我们有一个使用 AAD B2B 协作来邀请用户的应用程序。这些用户在我们的 AAD 中创建为来宾用户。这一切都很好：
- 拥有 AAD/Office 365 的用户可以使用他们的正常凭据登录。
- 没有 AAD/Office 365 的用户在邀请兑换过程中创建他们的帐户，并可以使用它来登录。Microsoft 将这些帐户存储在外部，对我们来说是隐藏的 AAD。
情况：
一个组织使用我们的应用程序。该组织还没有自己的 AAD/Office 365。我们使用他们的电子邮件地址在我们的 AAD 中邀请该组织的一些员工。他们在我们的 AAD 中获得来宾帐户。 一段时间后，该组织为其现有域名获得了自己的 AAD/Office 365。此域名以前用于邀请兑换过程中的电子邮件地址。
组织的 AAD 管理员创建 AAD，并立即看到现有的用户帐户：所有被邀请的帐户都显示在 AAD 中。他在创建新的 AAD 时没有预料到这一点，他也不知道它们来自哪里。 看起来外部的，对我们来说是隐藏的 AAD，已经对 AAD 管理员可见。 AAD 管理员可能决定删除这些帐户，从一个空的 AAD 开始。因此，员工无法再在我们的应用程序中登录。
我们的应用程序使用 Microsoft Graph API 来邀请用户。 有没有办法通过某种方式标记外部隐藏AAD中的用户，以明确帐户来自哪里？喜欢在现有领域提及我们的 organization/application？
明确一点：我们不想在来宾帐户上设置属性。我们想要在 AAD 管理员创建 AAD 时看到的用户帐户上设置属性。我们要明确他不能删除这个用户，因为它创建了 by/for 应用程序 X.
不，这是 Azure AD 的一项功能。 如果域所有者选择稍后创建隐藏的 Azure AD，则他们可以选择接管隐藏的 Azure AD。 他们控制了域，从而控制了用户，所以这取决于他们。
当然，如果您使用 Gmail 帐户创建 AAD 来宾用户，他们实际上不会被添加到巨大的隐藏 Google Azure AD 中。 如果 AAD 认为该帐户是社交帐户，目前他们会为该用户透明地创建个人 Microsoft 帐户（因此用户始终可以控制他们的帐户）。
因此，如果您使用工作电子邮件邀请用户，您必须期望他们的域所有者能够控制他们用户的帐户。
据我所知，没有 属性 可以设置。