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_ski_outlook.com#EXT#@michev.info                        Marian Marian    True
vasil.michev_quadrotech-it.com#EXT#@michev.info                Vasil Michev     False
michev_gmail.com#EXT#@michev.onmicrosoft.com                   michev@gmail.com False
Tony.Redmond_redmondassociates.org#EXT#@michev.onmicrosoft.com Tony.Redmond     False
tempxxx_abv.bg#EXT#@michev.onmicrosoft.com                     tempxxx@abv.bg   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 onmicrosoft.com 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 tempxxx_abv.bg#EXT#@michev.onmicrosoft.com -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:

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 satya_michevdev3.onmicrosoft.com#EXT#@michev.onmicrosoft.com -UsageLocation US

Set-MsolUserLicense -UserPrincipalName satya_michevdev3.onmicrosoft.com#EXT#@michev.onmicrosoft.com -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:

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

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.

This entry was posted in Azure AD, Office 365. Bookmark the permalink.

Leave a Reply

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