Did you know: passing credentials to the MFA-enabled Exchange Online PowerShell module

This is hardly news by now, as it has been available for several months already, but in case you missed it – the Exchange Online PowerShell module now support the -Credentials parameter. In other words, you can pass a PSCredential object to it, just like you would do with the “regular”, non-MFA enabled ExO PowerShell remoting. Here’s how:

$cred = Get-Credential user@tenant.onmicrosoft.com
Connect-EXOPSSession -Credential $cred

What’s even better, passing Credentials does not bypass modern authentication, i.e. does not switch to using legacy authentication like some of the other Office 365 related modules do. This has both positives and negatives, the negative being that if you do have any form of multi-factor authentication enabled for the account in question, the login will fail:

On the other hand, it means you can now easily automate connecting via the ExO PowerShell module in your scripts for accounts that do not have MFA enabled. And, the big news here, if you are using Azure MFA and you have configured any of the bypass functionalities, you will now be able to connect automatically by passing the Credentials object. No MFA prompt will be triggered, and no legacy authentication used!

Now, the bad news is that the Security and Compliance Center PowerShell does not yet support this. I know, I know, it’s weird, considering they are practically using the same cmdlets. But as different teams at Microsoft are responsible for the different portals, the SCC cmdlet (Connect-IPPSSession) has not yet been updated with the -Credentials parameter.

Well, you can easily make it available by editing the Connect-IPPSSession function inside the CreateExoPSSession.ps1 script file. I wont go into details on this, as it’s not considered a supported scenario, and anyway the file will be overwritten the next time the click-once application that represents the module is updated. But it’s certainly possible to connect to SCC PowerShell by passing a Credentials object too 🙂

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

Peeking behind the curtain of ExODS – fetching the ADRecipient object

Here’s another interesting fact – did you know that you can expose the full ADUser object for Exchange Online users? Meaning that you can peek at the actual user object stored in ExoDS – the active directory at the backend of Exchange Online.

As we don’t have any supported method to access that data, a simple workaround is used. You need to get the folder level permissions of any user to which the “target” has been granted access. For example, if my account has any explicit permissions given to another mailbox, I can do this:

(Get-MailboxFolderPermission delegate:\calendar -User vasil).User.ADRecipient

In other words, the output of the Get-MailboxFolderPermission cmdlet will return the full ADUser object. Yes, the proper Microsoft.Exchange.Data.Directory.Recipient.ADUser object. It might not look like this if you look at the output because of the formatting used. However, if you expand the User property and then do the same for the ‘AD recipient’ property, you will be presented with the full object. Here’s a sneak peek:

And by full, I mean full. 443 properties last time I checked! Basically everything you can get from Get-Mailbox/Get-User/Get-Recipient/Get-CasMailbox combined. And some added ones, for example the “c” or “co” properties found in AD, or the “DelegateListBL” and “DelegateListLink” ones (although those two don’t seem to be populated in my case). Another interesting catch is the “RecipientDisplayType” property, the value of which (“ACLableMailboxUser”) gives us a hint that Microsoft is close to enabling support for cross-premises/cross-tenant permissions.

Lots of other interesting properties to look at, some of which are pretty much unknown as they don’t exist on-premises. Some hints about “premium” features, most likely related to consumer Outlook.com accounts, Guest related properties, or things such as “HijackDetection“. Certainly some interesting stuff, however as this method is more of a bug/workaround, none of this is supported or discussed 🙂

So, in case you want to look at all these properties for some account, and more, all you need to do is grant said account any level of permissions to any folder of any mailbox. Even on your own mailbox. For example:

Add-MailboxFolderPermission vasil:\calendar -User vasil -AccessRights Owner
(Get-MailboxFolderPermission vasil:\calendar -User vasil).User.adrecipient

You can apply the same method for Groups, or in general any other object you can delegate permissions to. Sadly, not Modern Groups, as they are not considered mail-enabled security principals. But any other User Mailbox, Mail User or Mail-enabled security group should do. Have fun!

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

Playing with System mailboxes in Exchange Online

Being the curious type, I often probe different parts of the service and sometimes stumble into some interesting discovery. More often than not, it’s just some random stuff I notice while doing a quick test in order to make sure I give a proper answer to someone asking a question on the different communities. For this particular case, it all started with me trying to explain which objects types you can use to delegate permissions in Exchange Online.

For those of you that don’t know it yet, the Get-SecurityPrincipal cmdlet is one of the hidden gems in Exchange – rarely used, but very useful in answering that specific question. It’s fairly straightforward to use and has some convenient parameters, but the most interesting portion of is the output. Here’s an example:

Get-SecurityPrincipal | select Name,Type,RecipientTypeDetails

Name                                                          Type  RecipientTypeDetails
----                                                          ----  --------------------
DiscoverySearchMailbox{D919BA05-46A6-415f-80AD-7E09334BB852}  User  DiscoveryMailbox
vasil                                                         User  UserMailbox
Public Mailbox #1                                             User  PublicFolderMailbox
WC                                                            User  UserMailbox

OK, I’m cheating a bit here and trimmed some of the output to hold the suspense. But as you can see from the above, using the Get-SecurityPrincipal cmdlet will give you a nice list of all the objects you can use for delegation, so maybe give it a try?

Anyway, if you look at the full output of the cmdlet, you will notice some interesting entries. First of all, the WellknownSecurityPrincipal objects will be returned in the default, unfiltered output, and yes, they can be used to assign permissions as I’ve described here. For this particular article however, they are not important, so lets just ignore them. And lets do the same for all “boring” objects as well – filter them out. Here’s the full list of “User” object recipient types returned by the cmdlet:

Get-SecurityPrincipal -Types User | Group RecipientTypeDetails | select Name | sort


Striping the familiar ones, we are left with AuxAuditLogMailbox, ArbitrationMailbox, and AuditLogMailbox. So what’s so interesting about those you ask? The simple fact that they are considered “system” mailboxes, and we are not allowed to look at them in the service. For example, if you try to use the good old Get-Recipient cmdlet against any of those, you will get a nice error message like this one:

Get-Recipient -RecipientTypeDetails AuxAuditLogMailbox,ArbitrationMailbox,AuditLogMailbox
Cannot bind parameter 'RecipientTypeDetails' to the target. Exception setting "RecipientTypeDetails": "The following specified values aren't supported by this cmdlet: 'AuxAuditLogMailbox', 'ArbitrationMailbox', 'AuditLogMailbox'.

Well, seems out the devs simply forgot to apply the same rules against the Get-SecurityPrincipal cmdlet, so we can (ab)use it to get a list of those interesting objects:

Get-SecurityPrincipal -Filter {RecipientTypeDetails -eq "AuxAuditLogMailbox,ArbitrationMailbox,AuditLogMailbox"} | select Name,Type,RecipientTypeDetails

Name                                                         Type RecipientTypeDetails
----                                                         ---- --------------------
SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}          User ArbitrationMailbox
SPO_Arbitration_f5c4804b-2cad-4f9a-9882-c6c68fc5859a         User ArbitrationMailbox
FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042          User ArbitrationMailbox
SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}          User ArbitrationMailbox
Migration.8f3e7716-2011-43e4-96b1-aba62d229136               User ArbitrationMailbox
SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}          User ArbitrationMailbox
SystemMailbox{2CE34405-31BE-455D-89D7-A7C7DA7A0DAA}          User ArbitrationMailbox
AggregateGroupMailbox.A.201708152125                         User ArbitrationMailbox
Loki_Hashtags_394866fc-eedb-4f01-8536-3ff84b16be2a           User ArbitrationMailbox
Weve-7afd44ee-758f-483c-993d-4f779f219ebe                    User ArbitrationMailbox
OrgExtensionProperties0_ED5B1323-0DC1-43D3-96C7-0049903548CF User ArbitrationMailbox
AuxAuditMailbox157c8858-e89c-4a2d-8d3d-3fdf9ff066fc          User AuxAuditLogMailbox
AuxAuditMailbox68a1604b-663c-47ae-983d-8d1aa2740074          User AuxAuditLogMailbox
SystemMailbox{8cc370d3-822a-4ab8-a926-bb94bd0641a9}          User AuditLogMailbox

The list above is again trimmed, but you can still see a rich variety of objects. Based on their recipient type or Name, you can make some assumptions on their purpose, and for some of those you can find some information available online, although Microsoft has not published a full list afaik.

Here’s the best part – although those objects are “hidden” from the *-Mailbox cmdlets, some other cmdlets will still happily accept output. So, if you were bored enough, you could do something like this:

Get-MailboxPermission "SystemMailbox{8cc370d3-822a-4ab8-a926-bb94bd0641a9}" -User vasil

Identity             User                 AccessRights
--------             ----                 ------------
SystemMailbox{8cc... vasil@michev.info    {FullAccess}

And even this:

Yes, those are automapped to my mailbox and added to Outlook. No, there’s not much you can do with it. But it opens the possibility to play around with it in MFCMAPI and such, if you are interested.

Some other cmdlets will also work just fine with those “hidden” mailboxes, so for example you can get the mailbox- or folder-level stats, toy with permissions, etc. None of this is supported though, in any way or form, so if you manage to mess things up, you are on your own. Have fun 🙂

Posted in Exchange Online, Office 365 | Leave a comment

Recover or Delete Office 365 Groups via the Exchange Admin Center

Last week, Microsoft started rolling a small update through the service, allowing us to restore (and delete) Office 365 Groups via the Exchange Admin Center. In case you have missed it, here’s the Message center post (MC125402):

and the corresponding Roadmap item:

The new functionality integrates seamlessly with the EAC and is very easy to use. Simply open the EAC and navigate to Recipients, then Groups, select the Office 365 Group in question and perform the necessary action. The below screenshot illustrates the important elements:

Behind the scenes, the EAC seems to be calling the Remove-UnifiedGroup cmdlet when pressing the delete button and the UndoSoftDeletedUnifiedGroup cmdlet when trying to restore the Group, as shown below:

Probably due to the expected delay in synchronizing the Office 365 Group status between Azure AD and ExODS, in my case I am being presented with an error message every time I perform a delete/restore operation in the EAC:

Remember that Office 365 Groups are “special” in this regard, with “notifications” being responsible to keep the object properties in sync across the different workloads.

Apart from the error message though, the action is performed successfully. If you check the Group status via the Office 365 admin center or the Azure AD PowerShell cmdlets, it will be correctly reflected. EAC will eventually “catch up” on it as well, so try few refreshes.

Additional details on the new feature and the Group recovery process in general can be found here: https://support.office.com/en-us/article/Restore-a-deleted-Office-365-Group-b7c66b59-657a-4e1a-8aa0-8163b1f4eb54?ui=en-US&rs=en-US&ad=US

Posted in Exchange Online, Office 365 | Leave a comment

Early look at the new Message Trace UI in Office 365

Ignite 2017 is long over, yet I’m still finding some interesting bits of information or feature announcements that I have somehow missed. One of the best examples is the session Carolyn Liu and Khushru Irani did on “Office 365 mail flow insights“.

In this session, among lots of other useful things, a short demo of the new Message trace UI was shown. The Message trace functionality is now homed in the Security and Compliance Center it seems, and thus it uses the same design elements. As the feature is still in development, no link is exposed on the left navigation menu, however some tenants seem to already have access to it via the following link: https://protection.office.com/#/messagetrace

For those of you that do not have access, here’s how the “landing page” for the new Message trace UI looks like:

Now, what you see on that page is basically some predefined “reports” as well as any custom ones you have “saved” and a list of the 10 most recently run Message trace reports (“auto-saved”). In addition, if you have requested a detailed message trace report, any queued/completed downloads will show up in the first section.

To run a new Message trace, press the New button and simply enter the criteria. Not much has changed here and we pretty much have the exact same options as exposed by the Get-MessageTrace cmdlet. It’s all packaged with a new look and feel, and in general it’s a lot more intuitive. If you want to get the list of all the messages, simply press the Search button without entering any criteria.

Once you get the list of results, you can click on any message to get the “detailed” message trace, i.e. the info that you would get by running the Get-MessageTraceDetails cmdlet against the message in question. It’s all available in the UI now and prettified with the new “joyous NDR” look and feel, which makes it that much easier to understand what’s going on. Additional insights as to forwarding, spam processing or mailbox rules that affected the message are all shown here.

Some other UI improvements are immediately visible. Color coding based on the message status is used, making it easier to spot any failed or delayed messages. The Export button allows you to export a list of all or selected messages to a CSV file. To help you select just the right messages, a new client-side filtering functionality is exposed, via the Filter results button. The Find related button makes it very easy to run a trace based on specific messageID – select the message in question and press the button to return all other messages with the same ID. Another improvement is the option to select the timezone in which to display the results, you can configure that by using the “custom” Time range control.

For additional details make sure to watch the hands on demo here:

Posted in Exchange Online, Office 365 | Leave a comment