An extended view of the Privileged Access Management feature in Office 365

Every now and then, there comes a feature that promises to forever change the security landscape of the service. Privileged Access Management, or PAM, is one such feature, designed to allow customers to enforce the principle of Zero Standing Access in Office 365.

The feature is built on the same technology Microsoft has used for year in order to run operations in their datacenters. It combines Just In-Time Access (JIT), Just Enough Administration (JEA), Approval workflow and robust Auditing to enable admins to still perform their tasks, while having zero users with standing access to highly privileged roles overall.

Sounds interesting, right? Go check the full two-part review over at the Practical365 site. Here are the links:

Privileged Access Management in Office 365

Privileged Access Management – Part Two

 

Posted in Office 365 | Leave a comment

GAL segmentation and Ethical walls in Microsoft Teams

It’s not uncommon for various types of organizations to want to restrict one or more of the form of communication between their users. For example, in the EDU sector students are often limited to seeing and communicating with just their peers. Another example are financial institutions which can get into a lot of trouble for any documented case of exchanging “insider” information, and so on.

“Ethical wall” or “ethical firewall” is a term used to designate a solution, or set of settings that prevent users from communicating with each other. In the Exchange world, this is usually enforced by transport rules. Another feature commonly used in such scenarios is GAL segmentation (also known as GAL segregation), or the process of splitting users into specific “groups”, limiting their visibility into users from the rest of the organization.

Now, Microsoft has released a feature that allows Teams to use the same controls in order to enforce a basic form of ethical wall. More specifically, this is a setting that instructs the Teams client to honor any Exchange Address Book policy configured for the user, instead of using the default company-wide search. You can find the corresponding setting in the Microsoft Teams & Skype for Business Admin Center, under Org-wide Settings, Teams Settings, Search, or directly via: https://admin.teams.microsoft.com/company-wide-settings/client-settings. The setting itself is called Scope directory search in Teams using an Exchange address book policy (ABP), as shown below:

As the name suggest, the setting relies on the configuration you’ve already made in Exchange Online. In my case, I have created the following custom ABPs:

Get-AddressBookPolicy

Name            GlobalAddressList AddressLists             OfflineAddressBook RoomList
----            ----------------- ------------             ------------------ --------
All Contoso ABP \New GAL          {\All Users, \All Rooms} \New OAB           \All Rooms
Teams           \New GAL          {\CustomAttribute15}     \New OAB           \Rooms15

The Teams policy includes only users for which the value of CustomAttribute15 is set to “Teams“. Yes, I’m simple like that.

Get-AddressList CustomAttribute15

Name                      DisplayName               RecipientFilter
----                      -----------               ---------------
CustomAttribute15         CustomAttribute15         CustomAttribute15 -eq 'Teams'

So, a user that has this ABP assigned will only be able to see limited set of users in the GAL, as shown below:

If the setting works as expected, it should prevent this user from searching for any users outside of the list shown above in any of the Teams clients or contacting them via the New chat box. So let’s try this. If I log in with the same user to Teams, and head out to the Chats section to initiate a new private chat with a user not included in the ABP, I get the following:

The same experience is observed if I try to search for a user not in scope of the ABP I’m assigned to via the Search box on top. In contrast, objects that are part of the ABP are returned just fine. The same behavior is observed when trying to schedule a new meeting, so the setting does seem to have effect.

The good news ends here though. As evident from the above screenshot, Teams is happy to suggest that I contact “Vasil Michev”, even though this user is NOT part of any address list I’m allowed to look at. And since there no actual message delivery restrictions enforced, I am able to contact this user just fine. Any user that is able to see my account in any address list he has access to is of course able to initiate a chat as well, as well as use any other type of communication method with me. And, I’m able to search for and initiate private forms of communication with any user we share membership of any Team with.

So in a nutshell, while the functionality can somewhat limit who a given user can see and initiate communication with from the Teams clients, it works by simply trimming the list of entries presented at few UI elements. There are multiple exceptions and no server-side functionality is added to actually block users from reaching each other, unlike the transport rules we can use for Exchange Online. Overall, a good first step, but it leaves a lot to be desired.

Posted in Exchange Online, Microsoft Teams, Office 365 | Leave a comment

Reporting on Azure AD User objects via Exchange Online cmdlets and using them to grant mailbox permissions

Few months back, I blogged about an interesting observation that “plain” Azure AD Security groups can now be used to assign permissions to Exchange Online mailboxes. What was interesting in this scenario was the fact that all the familiar Exchange Online PowerShell cmdlets were oblivious to the existence of such objects, and happily reported an “object not found” error every time you tried to run them against an Azure AD Security group object’s identifier. The *-MailboxPermission and *-RecipientPermission cmdlets however do accept such groups as valid values and will allow you to configure permissions. You can find more information in the original article here.

Now, let’s examine a similar scenario for Azure AD User objects, more specifically user objects that are not recognized as valid Exchange recipients. Examples of such objects include non-licensed users, service accounts, objects synchronized from local AD and more. Generally speaking, any Azure AD user object without an email address assigned is a potential candidate, excluding Guest users. Here’s how to get a list of such objects:

Get-MsolUser | ? {$_.ProxyAddresses.Count -eq 0 -and $_.UserType -eq "member"}

or if you prefer the AzureAD PowerShell module:

Get-AzureADUser | ? {!$_.Mail -and $_.UserType -eq "Member"}

ObjectId                             DisplayName                                           UserPrincipalName                             UserType
--------                             -----------                                           -----------------                             --------
b1fbe4c6-d02c-447c-83c7-56c74df07197 Service Account for Cogmotive Reports                 CogmotiveReports@michev.onmicrosoft.com       Member
05fa5bac-b2d8-4952-800e-1e2d480e4d45 SfBUser                                               SfBUserSatya@michev.onmicrosoft.com           Member
fdd3c9ff-a101-4fec-84ba-3c42e3bef192 On-Premises Directory Synchronization Service Account Sync_DC01_052da20421fc@michev.onmicrosoft.com Member

Technically, the list generated from the above might be misleading, as in some cases the ProxyAddresses attribute isn’t correctly updated in Azure AD. In any case, we are interested in what Exchange Online knows about those objects, so how do we get this information?

Unfortunately, as with the Security groups case, the good old Get-Recipient cmdlets fails to return those users. For example, trying it against the Cogmotive service account results in this:

Get-Recipient CogmotiveReports@michev.onmicrosoft.com
The operation couldn't be performed because object 'CogmotiveReports@michev.onmicrosoft.com' couldn't be found on 'VI1PR03A001DC01.EURPR03A001.prod.outlook.com'.
+ CategoryInfo          : NotSpecified: (:) [Get-Recipient], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : [Server=VI1PR03MB3920,RequestId=eaf8df8f-f33e-4db4-ba68-7d2ca11c06e9,TimeStamp=10/30/2018 3:08:36 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] A37BED4
2,Microsoft.Exchange.Management.RecipientTasks.GetRecipient
+ PSComputerName        : outlook.office365.com

Bummer. But, the Get-User cmdlets comes to the rescue:

Get-User CogmotiveReports@michev.onmicrosoft.com

Name             RecipientType
----             -------------
CogmotiveReports User

So the object does exist in ExODS! Looking at its properties, one can spot a new value for the RecipientTypeDetails parameter, namely “User“. Thus, we can then use the following cmdlet to list all such objects:

Get-User -RecipientTypeDetails User

Name                    RecipientType
----                    -------------
Sync_DC01_052da20421fc  User
pta                     User
CogmotiveReports        User
SfBUser                 User

Interestingly, the “User” value is only accepted by the Get-User cmdlet, Get-Recipient does not recognize it. But cmdlets such as *-MailboxPermission and *-RecipientPermission do, and you can indeed use them to grant access:

Add-MailboxPermission sharednew -User SfBUserSatya@michev.onmicrosoft.com -AccessRights FullAccess

Identity             User                 AccessRights                                                                                                                                IsInherited Deny
--------             ----                 ------------                                                                                                                                ----------- ----
sharednew            EURPR03A001\SfBUs... {FullAccess}

And here’s the crazy part – you can actually access this mailbox now! Even though the user is in this shady, half-recognized state, and has no Exchange Online license applied, one can log in with it and use OWA to access the shared mailbox as shown below:

In contrast, trying to access OWA directly, without specifying the path to the shared mailbox results in:

This is of course the expected behavior, as the user does not have an Exchange Online license assigned, and is not considered a valid recipient. More surprising is the first scenario, as I didn’t expect that to work at all. Yes, we all know that Exchange Online does not enforce license requirements for some features and you have long been able to access a shared mailbox by directly logging in with the corresponding user account. But being able to access any mailbox via an account that is not even recognized as valid recipient is news to me.

At this time, I’m not at all sure that this scenario is supposed to work, and I’m almost 100% certain it’s not supported in any way. However, it does seem to work across different tenants, so it’s not just a temporary fluke. Whether it will continue working in the future, I cannot guess.

I wanted to also check how the audit logs reflect on access by such users, in particular what details for the delegate mailbox will be visible there, considering it’s half-recognized by Exchange Online. Luckily, it all seems to look just fine:

So there you have it, not only Exchange Online now seems to recognize “pure” Azure AD user objects, at least to some extent, but one can actually use such objects to access mailboxes, even though the corresponding user doesn’t have either a mailbox or license applied. Fun stuff 🙂

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

Unified labels are dead, long live “unified” labels

When you spend as much time as I do going over the various announcements Microsoft makes via blog posts or at Ignite sessions, you inevitably start developing a sense for detecting not only the loads of marketing crap, but also those hidden details both marketing and engineering folks suspiciously skip out. One such example is the story of “Unified labels” in the Office 365 Security and Compliance Center.

We first heard about Microsoft’s intention of bringing together the AIP and SCC labels back at last year’s Ignite conference. The story was great, provide a unified classification, labeling and protection experience across all workloads and clients. And then we started waiting. Almost nothing happened over the course of the year, and once we got back to Orlando, eager to see what Microsoft did with this feature, a certain fishy odor started spreading.

All the talks of “unified” experience now showcased two separate tabs in the Labels section of the Security and Compliance Center, one for “Sensitivity” and one for “Retention”. The big “unification” story seems to have shifted to “migrating AIP labels to the SCC portal” and providing some integration with SPO sites. All good stuff on its own, however nowhere near as exciting as those plans that were announced an year earlier. And annoyingly, even when directly probed about the “unified” labels, no straight answer was given by different Microsoft folks. Finally, this session spelled it all out:

So apparently somewhere along the road, Microsoft decided to change the design of the “unified labels” feature, probably because they run into various roadblocks. Nothing wrong with that, anyone using Office 365 should already be used to the high speed by which things change in the cloud. The marketing folks however seem to have decided to keep using the “unified” moniker to designate something obviously not fitting the definition. Apparently, it’s too big of an issue for them to let us know that we are NOT getting this (screenshot taken from BRK2134/Ignite 2017):

So, forget about having single “unified label” that can be used to classify an item, add visual elements to it, set retention period and action, protect it via RMS encryption, trigger DLP controls whenever it’s shared, and so on. You will still be able do all of these, and more, but simply not via the same “apply a single label” concept. Instead, we will have separate “Retention” and “Sensitivity” labels, and the focus seems to now have shifted to an “unified platform” powering those. Which can again be considered misleading, given the split between Security, and Compliance, which will both get their own portals soon.

Another thing that wasn’t clearly communicated at Ignite is the status of integration between SharePoint Online and Azure Information Protection, or the “sensitivity” labels. While there were some cool demos, those seem too far off in the future at this point, as the whole problem of “reasoning over data” remains unsolved. If you don’t know what I’m talking about, read this article for detailed explanation. Here’s a short excerpt:

…Azure Information Protection labels are different than Office 365 labels…

Be aware that when Azure Information Protection encryption is applied to files stored in Office 365, the service cannot process the contents of these files. Co-authoring, eDiscovery, search, Delve, and other collaborative features do not work. DLP policies can only work with the metadata (including Office 365 labels) but not the contents of these files (such as credit card numbers within files).

Or illustrated via a screenshot:

Among other things, this means that automatic application of Sensitivity labels to SPO content will not come anytime soon. So next time you hear Microsoft talking about “unified labels”, just ask yourself what exactly the “unified” part means…

Don’t get me wrong, I love many of the features they showcased and there’s certainly a momentum building in the right direction. However, it has taken them a long, long time and we are still far away from getting true integration between the services and a unified experience. Hopefully, they will prove me wrong and by this time next year I will have nothing but praise to post.

Posted in Office 365 | 1 Comment

The new Microsoft 365 Admin Center is in Preview – a quick look

Over the weekend, the preview for the new version of the Office 365/Microsoft 365 Admin Center landed in my tenant, so naturally I took it for a quick spin. In case you want to do the same, look for the “Try the preview” toggle in the top left corner of the portal:

The first thing you might notice is that it looks unpolished, and way too bright, but those are of course subjective, so instead lets focus on the page elements. The navigation menu on the left is trimmed and only shows few entries by default, with the option to “Show more” expanding the rest of the menu. This might be seen as a welcome change by people who got lost into the complex navigation menu previously, which featured a dozen or so links to other Admin portals, among other things.

Sadly, clicking the “show more” doesn’t persist across sessions, so if you want to get the expanded menus by default, it’s best to click the new “Edit” button instead and toggle any and all entries you want shown. The selection you make here does persist, and in case you have selected all the available entries, the “Show more” link will disappear. Another set of customizations you can make is to add/remove Cards to the homepage, similar to the experience we have in the “old” portal. The number of cards is fairly limited at this point though, and the “drag & drop” UI used for this functionality is a questionable choice.

Another thing to note is that custom themes do not have effect on the navigation menu. All this should hopefully be addressed in the coming weeks, as the preview gains traction and the feedback comes pouring in. Overall, the customization options should be sufficient once fully developed, and allow you to change your portal from the slim version shown above to the “full” view, akin to the old portal, with ease:

And in case you miss the long menu of “admin portals” we had previously, you now have a dedicated page just for it. You can access it by clicking the “All admin centers” button on the bottom of the navigation menu or directly via https://admin.microsoft.com/AdminPortal/Home#/alladmincenters.

Apart from the homepage, the only part of the portal that has received a significant overhaul at this point is the Users page, and more specifically just the Active users section. The list interface is preserved, with the first column serving as checkbox for each item, but there are numerous improvements throughout. We have customizable columns now, which you can manage via the Choose columns button on the right. We can sort by clicking the column header, or rearrange the columns by dragging them. A Search field is also exposed. A Filter experience replaces the old “views”, which are all migrated. Lastly, a toggle between “normal” and “compact” list has been added.

In terms of actions, you have the option to Add a user or Add multiple users exposed on top. Few additional actions are available under the “” menu, such as resetting a password, deleting a user or accessing the MFA or Directory synchronization settings.

Selecting a user enabled few additional actions such as Reset password, Assign to groups, Manage roles, and more. The Reset password action is also exposed via the small key icon that appears on the right of the user’s display name when you hover over it. Additional actions are exposed when you click the three vertical dots or you can simply click the user to bring the right pane with all its details. As you can see from the below screenshot, the user’s pane is organized into six sections, surfacing all the actions you are accustomed to from the “old” portal. Management of the individual services assigned to a user is now split between the Licenses and the Apps tab, with the latter listing each individual service name and status. Convenient Filter by and Arrange controls have been introduced here:

Most of the available actions currently “call” the familiar pane-based UI, so you can expect a lot of clicks and flying panes, but I hope we will see some more streamlined experience in the future. Some links such as “Edit Exchange properties” don’t seem to function at present, but that will surely be addressed.

In terms of bulk actions, the old-portal experience is used. By that I mean that once you select a group of users and click one of the available actions, the familiar pane-based “wizards” from the old portal will appear. In what seems like a minor issue, cancelling out of those wizards seems to always bring the new-style pane for the last user in your selection, which can be misleading. Administrative units are also supported in the new version, however there seems to be a minor bug currently that requires you to manually refresh the user list when switching between AUs.

While there are indeed some minor issues with the new User management experience, the overall impression is a positive one. Unfortunately, it is currently only available for the Active users page, and all the others use the old portal controls. The only other page with new experience I’ve noticed was the Billing > Products & Services one, which now features a Grid view by default, with an option to switch to Table view, Filter and Search for subscriptions.

One other thing I’ve noticed is that the Report experience seems to be broken, so if you need access to that section, make sure to switch back to the old experience.

Posted in Office 365 | Leave a comment