Questions about Users Converted to External

Question

Lets say I follow this guide:
https://learn.microsoft.com/en-us/azure/active-directory/architecture/10-secure-local-guest
and I use the the Azure Portal 'button' on the user blade to convert a local user to an External user.

I have a few questions:

1. After I perform the conversion on the user, I noticed an additional Identity for Federated sign-in with 'ExternalAzureAD' was added.
   1. Is it correct to say that's all the button does? Add the additional Identity to the user profile?
   2. Is this new identity now permanently bound to the tenant and email used for the invite?
   3. If the mail or proxyAddress were to change, is it correct to assume they would still sign-in externally with the original invited email?
2. Without further actions, this user can sign in with the external address, or the current/pre-existing UPN. Let's also assume my user still needs access to on-premise systems, so I don't want to randomize the password as the article recommends. Then:
   1. Is this account considered Internal? External? Both? Does it depend on how they sign in?
   2. Does the user count for MAU External user licensing? Or maybe they only count when they sign-in externally?
   3. Are there security issues I should be aware of, when having a user able to sign-in two ways?
3. In another Teams article they say Teams doesn't support converting User Type: https://learn.microsoft.com/en-us/microsoftteams/guest-access#licensing-for-guest-access I am considering changing my converted users from members to guests.
   1. So, what is the Teams article trying to convey? I don't convert users in Teams, I convert them in the Azure Portal or with PowerShell. So I don't understand what is not supported?
   2. If I convert a user to an external user using this feature, will some aspects of Teams no longer work?
4. Let's say I still want the user to sign into on-premise systems, but to reduce confusion I don't want them using their local AD password to sign into Azure anymore; but I still require the Azure account to remain synced with the On-Premise AD account.
   1. Is it possible to remove the original UPN method of sign-in? So they can only collaborate in Azure with their external identity?
   2. Is it possible to free the UPN that was initially created on the first AAD Connect Sync? I imagine I could change it on-premise? Is there a way to have it appear like other external UPNs with the #EXT#? I'm mostly looking at this from an optics situation, where it's easy to identify a guest with the #EXT#, but would there be other functional impacts or benefits?

Answer 1

Hello@Jeremy , below you will find my answers added after your questions:

1. After I perform the conversion on the user, I noticed an additional Identity for Federated sign-in with 'ExternalAzureAD' was added.
   1. Is it correct to say that's all the button does? Add the additional Identity to the user profile? Not really. It also updated properties related to the invitation such as creationType (to Invitation), externalUserState (to PendingAcceptance), etc
   2. Is this new identity now permanently bound to the tenant and email used for the invite? The identity is bond to the issuer and id stored in it.
   3. If the mail or proxyAddress were to change, is it correct to assume they would still sign-in externally with the original invited email? Yes, that's correct.
2. Without further actions, this user can sign in with the external address, or the current/pre-existing UPN. Let's also assume my user still needs access to on-premise systems, so I don't want to randomize the password as the article recommends. Then:
   1. Is this account considered Internal? External? Both? Does it depend on how they sign in? External
   2. Does the user count for MAU External user licensing? Or maybe they only count when they sign-in externally? Not immediately. Once the userType is changed to guest MAU will kick in.
   3. Are there security issues I should be aware of, when having a user able to sign-in two ways? Please take a look to Plan a Microsoft Entra B2B collaboration deployment.
3. In another Teams article they say Teams doesn't support converting User Type: https://learn.microsoft.com/en-us/microsoftteams/guest-access#licensing-for-guest-access I am considering changing my converted users from members to guests.
   1. So, what is the Teams article trying to convey? I don't convert users in Teams, I convert them in the Azure Portal or with PowerShell. So I don't understand what is not supported? This is out of my field of expertice so its better to post this question as a separate thread with the teams tag so that Teams expets can answer it. However, my guess here is that changing user access could break some things for Teams.
   2. If I convert a user to an external user using this feature, will some aspects of Teams no longer work? I'm afraid yes.
4. Let's say I still want the user to sign into on-premise systems, but to reduce confusion I don't want them using their local AD password to sign into Azure anymore; but I still require the Azure account to remain synced with the On-Premise AD account.
   1. Is it possible to remove the original UPN method of sign-in? So they can only collaborate in Azure with their external identity? Removing the UPN may have limited impact since a new UPN will be synced from on-premise.
   2. Is it possible to free the UPN that was initially created on the first AAD Connect Sync? I imagine I could change it on-premise? Is there a way to have it appear like other external UPNs with the #EXT#? I'm mostly looking at this from an optics situation, where it's easy to identify a guest with the #EXT#, but would there be other functional impacts or benefits? Changing UPN is not the way to disable access to Azure. Keep in mind the Azure account is a mirror of the on-premise account. While you keep it synced and enabled you will be able to access Azure resources. The easiest is to stop syncing the user or to implement Conditional Access policies.

Let us know if you need additional assistance. If the answer was helpful, please accept it and rate it so that others facing a similar issue can easily find a solution.