We have an application which uses AAD B2B collaboration to invite users. These users are created as guest users in our AAD. This all works great:
- Users that have an AAD/Office 365 can use their normal credentials to sign in.
- Users that don't have an AAD/Office 365 create their account in the invite redeem process, and can use it to sign in. Microsoft stores these acounts in an external, for us hidden AAD.
Situation:
An organization uses our application. This organization doesn't have an own AAD/Office 365 yet. We invite some employees of this organization in our AAD using their email addresses. They get guest accounts in our AAD. After a while this organization gets its own AAD/Office 365, for their existing domainname. This domainname was previously used in the email addresses in the invite redeem process.
The AAD admin of the organization creates the AAD, and immediately sees existing user accounts: all the accounts that have been invited are shown in the AAD. He didn't expected this when creating a new AAD, and he doesn't know where they come from. It appears the external, for us hidden AAD, has become visible to the AAD admin. The AAD admin might decide to delete these accounts, to start with an empty AAD. As a result the employees aren't able to sign in anymore in our application.
Our application uses the Microsoft Graph API to invite the users. Is there a way to mark the users in the external hidden AAD in some way to make clear where the accounts are coming from? Like mentioning our organization/application in an existing field?
So to be clear: We don't want to set properties on the guest account. We want to set properties on the user account that an AAD admin sees when he has created the AAD. We want to make clear he must not delete this user, because it's created by/for application X.
