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:

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:

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.

Posted in Azure AD, Office 365 | Leave a comment

Generating a report of users’ group membership (MemberOf inventory)

There are a gazillion PowerShell scripts out there that can generate a report of group membership, so one might wonder why I decided to create yet another one. Mostly, because I like things done in a certain way, which in the case of generating a membership report means “by utilizing server-side filtering and the MemberOf attribute”. In addition, most of the scripts generate the report by expanding the membership of each group, while often times people are interested doing the “opposite”. While this can be done easy enough in Excel or similar, this correlation happens to be exactly what the value of the MemberOf attribute returns, so querying it seemed like the natural approach.

This method, as described in a previous blog post, is simple, quick and efficient. It does not require you to iterate over the list of all groups in the organizations just to check whether a particular user is a member of the group. Instead, it takes a single execution of the Get-Recipient cmdlet, and lets the server do the work for you. Combining this with the Invoke-Command implicit remoting method, which allows you to further minimize the data received, and thus the time it takes to complete the script, you end up with a faster and more reliable method to generate the report.

So what exactly does the script do? In a nutshell, it gets the list of recipients you want to generate the report for, then for each recipient uses server-side filtering to quickly get the list of groups, which then gets outputted to the console and saved to a CSV. Since we a re using the Exchange cmdlets, only groups recognized by Exchange will be included in the report: Distribution groups, Mail-Enabled Security groups  and Office 365 (modern) groups.

The bulk of the script is contained within the Get-DGMembershipInventory function, with another function introduced to check connectivity to Exchange. The script will detect and reuse any existing sessions to Exchange Remote PowerShell. Basic functionality to facilitate a new connection is also included, but it does not cover all possible scenarios. If you are using an MFA-protected account or any of the non-MT Office 365 instances, make sure you connect manually before running the script. If you need help connecting PowerShell to Exchange Online, follow the steps in this article:

The script can be dot-sourced to expose said cmdlets and takes parameters via splatting. Speaking of parameters, by default the script will generate the inventory only for User mailboxes. If you want to include other recipient types, use the corresponding switch parameters, namely:

  • -IncludeUserMailboxes
  • -IncludeSharedMailboxes
  • -IncludeMailUsers
  • -IncludeMailContacts
  • -IncludeGuestUsers
  • -IncludeAll

Running the script without parameters is the same as using the –IncludeUserMailboxes switch. Here’s an example of including User mailboxes and Guest users:

.\DG_MemberOf_inventory.ps1 -IncludeGuestUsers -IncludeUserMailboxes

To identify the recipient, the PrimarySMTPAddress attribute is used. If the recipient does not have this attribute populated (which might be the case for Guest users), the ExternalEmailAddress is used instead, failing that the ExternalDirectoryObjectID identifier is used. For the groups list, the PrimarySMTPAddress attribute is used. If you want to use a different attribute instead, don’t forget to add them to the relevant script blocks inside the Invoke-Command instances, as no other attributes are returned from the implicit remoting session.

If you have a large number of recipients in your organization, it’s a good idea to add some artificial delay between each iteration in order to combat throttling. This can be done by uncommenting line 100, or by adding proper logic to the script, as described in this article.

The script will save the report to a CSV file in the working directory and will also store it in a global variable ($varDGMemberOf) for reuse. Here’s an example of what the report might look like:

You can download the script from the TechNet Gallery here:

Do let me know if you run into any issues with the script or have comments on it.

Posted in Exchange Online, Office 365, PowerShell | Leave a comment

Using filters against objects containing special characters with Invoke-Command

Continuing the series “blog this so you don’t forget about it later”, here’s another interesting example on how PowerShell handles special characters. In a previous blog post, we discussed how to use server-side filters against objects containing a special character in the DistinguishedName attribute, more specifically an apostrophe (‘). The example used there will work just fine when you are running the cmdlets directly in console, however if you try the Implicit remoting method, it will fail. It took me a while, but now I finally have a working solution for this scenario as well.

Let’s describe the issue in more detail first. The task is simple enough, use server-side filtering to return a list of groups a specific user is a member of. Which in turn means, get the DN attribute of the user, put it in the –Filter statement and use the Members clause. Like this:

Get-Recipient -Filter {Members -eq 'CN=user,,OU=Microsoft Exchange Hosted Organizations,DC=EURPR03A001,DC=prod,DC=outlook,DC=com'}

All very straightforward, with the exception of the special care you need to pay to characters such as apostrophes (which is totally legit character to have in a DN). However, using a server-side filtering is even more efficient if you combine it with the Invoke-Command method of executing the query directly against the remote shell, as it allows you to minimize the amount of data returned. This might not sound like a big deal, but in a large organization you can have thousands upon thousands of users, each member of dozens of groups. As the Get-Recipient cmdlet will return the full ReducedRecipient object with over 100 properties, this can easily result in huge overhead. So, combining server-side filtering and Invoke-Command can make your scripts run a lot faster, and way more reliable.

For the purposes of the task at hand, all I needed was an unique identifier for each group the user is a member of, such as the PrimarySMTPAddress – everything else can be dropped. So, how does on adapt this to work against Invoke-Command? After banging my head for a while trying all sorts of variations, it turned out that the solution is very simple. So simple indeed that I can just adapt the example from the previous post with minor changes. Here’s how:

$dn = (Get-Mailbox user).DistinguishedName
$dnnew = "'" + "$($dn.Replace("'","''"))" + "'"
$cmd = 'Invoke-Command -Session $session -ScriptBlock { Get-Recipient -Filter "Members -eq $using:dnnew" | Select-Object PrimarySmtpAddress } -HideComputerName'
$list = Invoke-Expression $cmd

The culprit – use two apostrophes instead of four. Sheesh!

The example also takes advantage of the Using scope modifier, which we’ve talked about previously. In case you need more information about it, read here.


Posted in Exchange Online, Office 365, PowerShell | Leave a comment

Pass-through authentication now supports legacy protocols and applications

Azure Active Directory Pass-through authentication, or simply PTA, is a great feature, designed to close the gap between the “same sign-on” and “seamless single sign-on” experience. In other words, it gives you the benefits of the same end-user experience as AD FS, and it ensures that passwords are validated against your on-premises AD, without the overhead of a typical AD FS deployment. When the feature was first released in Public Preview at the end of 2016, one major limitation existed, namely only applications that supported Modern authentication could leverage PTA.

Now, in July 2018, the feature has been updated to support legacy authentication protocols and applications. Here are the relevant bits from the Azure AD Changelog:

Pass-through Authentication now supports legacy protocols and apps. The following limitations are now fully supported:

  • User sign-ins to legacy Office client applications, Office 2010 and Office 2013, without requiring modern authentication.
  • Access to calendar sharing and free/busy information in Exchange hybrid environments on Office 2010 only.
  • User sign-ins to Skype for Business client applications without requiring modern authentication.
  • User sign-ins to PowerShell version 1.0.
  • The Apple Device Enrollment Program (Apple DEP), using the iOS Setup Assistant.

While the notes above don’t explicitly mention protocols such as POP3, IMAP or Exchange ActiveSync, the AAD PTA Current limitations article has been updated to state the following:

The following scenarios are supported:

  • User sign-ins to web browser-based applications.
  • User sign-ins to Outlook clients using legacy protocols such as Exchange ActiveSync, EAS, SMTP, POP and IMAP.
  • User sign-ins to legacy Office client applications and Office applications that support modern authentication: Office 2010, 2013 and 2016 versions.
  • User sign-ins to legacy protocol applications such as PowerShell version 1.0 and others.
  • Azure AD joins for Windows 10 devices.
  • App passwords for Multi-Factor Authentication.

As support for legacy authentication scenarios was probably the biggest blocker for most organizations in regards to embracing PTA, we should see an increase of the PTA adoption and a big decrease in AD FS usage in the Azure AD login statistics Microsoft will share next month at Ignite. The last time such statistics were shared, the number of AD FS logins was almost at the 50% mark, my bet for this year’s stats is 30% or so 🙂

Posted in Azure AD, Office 365 | Leave a comment

Connected accounts are being deprecated in Office 365

The Connected accounts feature basically works as an email client, which connects to and fetches messages from Gmail, Yahoo or any other IMAP/POP account. While Connected accounts have certainly never been the most popular feature, they were useful for scenarios where you wanted to keep messages from all your email accounts across different providers in the same mailbox.

Now, Microsoft is deprecating support for the feature and will soon remove it from the service. No announcements or any other type of communication has been published on this yet, but those should be coming in the next few days/weeks. In the meantime, the official documentation has been updated with the following warning:

Important: Microsoft will be removing the ability to add new accounts to Outlook on the web using the Connected accounts feature in September 2018.​

  • You won’t be able to connect new accounts after September 15, 2018.
  • Accounts that were connected before September 15th will continue to sync as usual until October 30, 2018.
  • On October 30th, all connected accounts will stop syncing email.
  • On November 15th, the Connected accounts option (Settings > Mail > Accounts) will be removed from Outlook on the web .
  • Email that has already synced will continue to appear in your inbox unless you remove it manually.​

In addition, the following alternatives have been suggested for people who want to keep receiving all their messages in the same account.

Notes: To continue seeing email from other accounts:

As evident from the above text, the timeframe of this deprecation is rather short, so I decided to do my part and spread some awareness as well. Note that this deprecation only affects Office 365, for the time being Connected accounts in are safe.

Posted in Exchange Online, Office 365 | 4 Comments