Some new interesting experiences with Guest users in Office 365

Guest users have been around for a while now in Azure AD/Office 365, and are the cornerstone of collaboration for workloads such as Microosft Teams or SharePoint Online. The access mechanism for Guest users is somewhat similar to “regular” users one, with an actual Azure AD user object being provisioned, albeit with a strange-looking UPN. Here are some examples on that from my tenant:

UserPrincipalName                                              DisplayName      isLicensed
-----------------                                              -----------      ----------                        Marian Marian    True                Vasil Michev     False          False Tony.Redmond     False              False

In the examples above, there are users from other Office 365 tenants, users with MicrosoftIDs, users with GoogleIDs, but their accounts all look the same: username, followed by underscore and the domain part, followed by the “#EXT#” string, the @ sign and then the tenant’s domain. The users themselves login using their regular username and password against the “home” Identity provider (be it another Office 365 tenant or Google, etc), instead of this “constructed” UPN. There is one caveat however, Guest users cannot login directly to your tenant and thus have to access files or applications shared with them via a link or invitation. Until now that is.

Thing have now changes it seems, probably in relation to the recent announcement for support for Google federation. I have no idea whether this is now the intended behavior or is some sort of a bug, but such users can now access the Office 365 portal and apps directly. To make this work however, you need to reset the password for the associated user account, as no password is ever displayed (or used) as part of the Guest invitation/redeem workflow. Resetting/generating a new password can be done with the familiar admin tools, for example via this PowerShell cmdlet:

 Set-MsolUserPassword -UserPrincipalName -NewPassword XXX -ForceChangePassword $false

Once the password is known, you can simply navigate to the Office 365 login page, enter this long UPN and the password, and login to the portal. Another important new feature (or bug) is the fact that such users can now have admin roles assigned. Technically, assigning a role was possible previously as well, however none of the admin portals actually respected this and the corresponding users were not able to access the portals or perform any admin actions via PowerShell. This is no longer the case, as shown below:

Guest users can be admins?

Similarly, you can now provision such users for services such as Exchange Online. Yes, you got it right, you can have a mailbox provisioned for Guest users now. To do this, you will need to assign the corresponding Exchange Online license, and this in turn has a requirement on the user object. You will need to “convert” the object to a regular user first, so technically I lied, and this will not be a considered a true guest user anymore. Still, it’s an interesting fact that you can trigger the provisioning process:

Get-AzureADUser -SearchString satya | Set-AzureADUser -UserType Member

Set-MsolUser -UserPrincipalName -UsageLocation US

Set-MsolUserLicense -UserPrincipalName -AddLicenses michev:ENTERPRISEPACK

After assigning the license, give it some time for the provisioning process to trigger. You will then notice that the recipient type will change from GuestMailUser to UserMailbox and the corresponding object will move from the Contacts tab in the EAC to the Mailboxes one. At that point, the user can access OWA directly:

Mailbox for a Guest user?

He can send and receive messages just fine, and perform any other operation just like a regular user. Few notes on the mailbox object though: by default it will be hidden from the GAL, so you might want to unhide it. As already mentioned above, you will also need to reset the password for the user if you want them to be able to login directly. If you don’t want that, you can still access the mailbox as a delegate, simply by adding the necessary permissions:

Add-MailboxPermission satya -User vasil -AccessRights FullAccess -AutoMapping $false

Mailbox for a Guest user!

At the time of writing, provisioning such a mailbox requires that the corresponding user is converted to “Member”. While assigning a license to Guest user object is certainly possible, it seems that the “provision mailbox” workflow will only trigger for Members, not Guest users. There are probably good reasons behind this behavior, and in general you should not attempt any of the examples discussed in this article, until Microsoft releases official documentation on any new Guest-enabled experiences. Don’t say I didn’t warn you 🙂

Regardless of whether the scenarios detailed above are supported or unintended, the work that Microsoft is doing in the area of Guest access and more generally cross-organizational collaboration is eagerly awaited by many, and long, long overdue. We should hear more about it in a week or so at Ignite, so I will make sure to follow up with additional details.

9 thoughts on “Some new interesting experiences with Guest users in Office 365

  1. Russ says:

    This still works for the most part. Mailbox gets created once they are converted to a Member and given the correct license. I also changed the UPN and Mail Nickname to something more legible without the #ext# stuff but that shouldn’t matter. I don’t think the PS for the password reset works (use Set-AzureADUserPassword instead) but the rest works. Unfortunately, the guest user has to log in with the password you just set; they can’t auth with their home directory credentials. That would be sweet.

  2. Ron says:

    I’ve done the steps you said: Converted the guest user into a member and added an Exchange online license. But mailbox isn’t created while the RecipientTypeDetails was converted from GuestMailUser to MailUser.
    Any idea how to force mailbox creation?
    We would like a Guest account to be able to get reviewer permission on a certain mailbox in our organization.

    1. Vasil Michev says:

      It’s a three year old article, things change 🙂 And this was never a supported solution to begin with, if you need to delegate mailbox permissions best create a regular user account from scratch.

      1. Ron says:

        So there is no way you can create a mailbox for a guest account?

        1. Vasil Michev says:

          No supported way, no. I havent played with it recently, but if the steps above don’t work for you, I suppose there’s no unsupported way anymore, either.

      2. Ron says:

        No, it doesn’t work anymore.
        Even after a night it’s not picked up for mailbox creation.
        Recipienttype rests at MailUser, not changed to UserMailbox


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.