Privileged Access Management in Office 365 – Part One

One of the worst things that can potentially happen to any organization is a compromised admin account and during the last few years we have seen an enormous increase in both the amount and the complexity of attacks targeting privileged users. Recently shared data reveals that 4 out of 5 breaches involve some form of credential theft. While this data doesn’t necessarily include Office 365 breaches, another interesting fact shared at Microsoft Ignite this year mentions an average of 12.6 users with admin roles per organization across Microsoft 365 tenants, so obviously an attack surface exists there as well. And indeed, the Azure AD team shared that they see around six thousand admin accounts being compromised each month.

There are a lot of resources detailing the best practices around admin access to any given system, with new protections constantly being developed. An example of such resource for Office 365 is the whitepaper on Securing privileged access for hybrid and cloud deployments in Azure AD, published in June 2018. Even though this whitepaper was published just three months ago, some of the guidance presented there is already outdated. Without going into too much detail, the current “golden standard” is the principle of Zero Standing Access, which Microsoft has used for years in running operations for their cloud services. Now, an effort is underway to apply this principle to customer roles as well, by combining just enough administration (JEA), just in time access (JIT), approval workflows and auditing.

In reality however, getting to Zero Standing Access is not as easy as flipping a switch. Very few software systems have been designed with those principles in mind, and in many cases, it takes years before the appropriate controls are put in place. Office 365 is no exception – while arguably it’s no longer the loosely connected set of services it was back in 2011, there are still vast differences in the admin experience across different workloads, with Exchange Online leading the way with respect to Role-based Access Controls (RBAC). For most of the other services, a workload-wide admin role might still be required to perform even the basic tasks. In turn, the users holding such roles represent an attack surface.

The Privileged Access Management feature in Office 365 aims to address this issue, so without further ado, let’s take a look at it.

What is Privileged Access Management?

To put it simply, the Privileged Access Management (PAM) feature allows you to add an approval workflow on top of your RBAC controls for various Office 365 admin tasks. For example, you can restrict the execution of sensitive cmdlets such as Search-Mailbox or New-JournalRule and require approval from a designated person before anyone in the company can run them. When approval is granted, the cmdlet becomes available for just the specified admin, and only for a preset duration. Similarly, you can enable on-demand access to RBAC Roles or Role Groups. Each part of the PAM workflow is audited within the Exchange Online and Office 365 Unified audit logs. In other words, PAM enables JEA and JIT on top of the regular RBAC controls and supplements them with robust auditing to give you Zero Standing Access capabilities in Office 365.

Now, when we used “Office 365” in the previous sentence, that was an overstatement. Currently, only Exchange Online supports PAM, with the intention of bringing additional workloads as soon as possible. This hardly comes as a surprise given the fact that Exchange Online is the most mature workload in terms of admin controls, with all admin tasks in Exchange Online basically running PowerShell cmdlets on the backend. PowerShell is the toolkit on which Microsoft’s JEA/JIT implementation was initially developed, and the close collaboration between the Exchange and PowerShell teams is one of the main reasons that Exchange in the cloud became possible to begin with. With the risk of going a bit off-topic, I would recommend watching this session from TechEd 2014, where Jeffrey Snover gave a great overview of PowerShell’s JEA toolkit.

Microsoft has used similar controls for years for its Lockbox and Customer Lockbox features that govern access to customers data in the service, so the feature has a proven track record. We have also had the Azure AD Privileged Identity Management service for some years now, which enables JIT controls for the various Azure AD admin roles. The challenge is of course to make all these controls available across all workloads, with a granular approach that goes down to the individual task level. This might take some time, but Microsoft is continuously working towards enabling proper RBAC controls across different workloads. Once those are in place, PAM can step in and enforce Zero Standing Access, while still enabling admins to perform their day-to-day tasks. My personal expectations are that the Security and Compliance Center will probably be one of the first workloads to follow, as its backend borrows heavily from the Exchange Admin Center. The Office 365 Admin Center and Azure AD are another safe bet, but of course it all depends on Microsoft’s priorities.

In any case, currently the feature is limited in scope, but that should not stop you from enabling and evaluating it. One thing to be aware of however is that PAM is considered part of the Advanced Compliance suite, and therefore requires E5 licensing. To facilitate this, a new service has been introduced as part of the E5 SKU, as shown below:

Microsoft has not clarified how exactly those E5 licenses should be assigned to users, but my guess would be that every user that participates in any part of the PAM workflow should be licensed, unless clearly stated otherwise in the official documentation.

How to enable Privileged Access Management

To enable PAM, you can use either the Office 365 Admin Center or Exchange Online PowerShell. If you prefer the UI approach, navigate to the Office 365 Admin Center as a Global admin (technically GA is not a hard requirement, but more on that later), expand the Settings menu on the left, select Security & Privacy, then under the Privileged Access section, click the Edit button. To toggle the feature ON or OFF, use the Require approvals for privileged tasks control. One additional configuration must be performed before you start exploring the feature: assigning the Default approver group. Members of this group will be able to approve or deny privileged access requests in your organization. The group in question must be a mail-enabled security group, with flat membership. Other group types are currently not supported.

If you prefer, you can also enable and configure PAM via PowerShell. To do so, you need to connect to Exchange Online via Remote PowerShell, either via the legacy method or by using the ADAL-enabled module. Once connected, you can use the Enable-ElevatedAccessControl cmdlet to enable the feature. By default, this cmdlet is only available for users that have been assigned the Role Management role, which in turn is only available for members of the Organization Management Role group.

As mentioned above, the UI in the Office 365 Admin center has more strict permission requirements and you will not be able to fully manage the feature unless you have the Global Admin role. It’s important to understand however that even users without Office 365 admin privileges assigned can manage the PAM feature via PowerShell, as long as they have been assigned access to the role/cmdlet. Microsoft is already working on better controls for managing the feature and aligning the experience across all endpoints.

In addition to the settings exposed in the UI, PowerShell gives you the option to configure exceptions to the PAM controls by designating “system accounts” that can still execute all tasks within the constraints of the roles assigned to them, but without being subject to approval policies. This functionality is useful for automation/workflow scenarios, but it is strongly recommended that you limit the number of such exceptions and take this opportunity to re-evaluate the need of using highly-privileged, permanent admin accounts for such tasks. One important note here is that the “system account” must be a valid Exchange recipient, meaning that you cannot use any Azure AD user object that doesn’t have an email address assigned, such as unlicensed cloud-provisioned users. This is an unfortunate limitation, inherited because of the dependency on the Exchange cmdlets, but the team is already looking into it and should remove it in the future.

Examples of controlling PAM via PowerShell

The example below shows how you can enable PAM by running the Enable-ElevatedAccessControl cmdlet and specifying the default approver group (via the –AdminGroup parameter) and optionally, a list of “system accounts” to be excluded (via the –SystemAccounts parameter). As already mentioned above, the approver group must be a mail-enabled security group and must already be created. Although the cmdlet currently accepts regular Distribution Groups or even Office 365 Groups as valid values for the –AdminGroup parameter, using these is not a supported scenario.

Enable-ElevatedAccessControl -AdminGroup PAMAdminGroup@tenant.onmicrosoft.com -SystemAccounts @(‘systemaccount@tenant.onmicrosoft.com', ‘anotheraccount@tenant.onmicrosoft.com')

To check the status of the feature, you can use the Get-OrganizationConfig cmdlet, which will also return information about the approver group, number of PAM policies configured (more on that in the next section), and any “system accounts”:

Get-OrganizationConfig | fl ElevatedAccessControl

As seen from the above screenshot, the status of the feature in my tenant is Enabled and a default approver group has been assigned. However, no approval policies have been configured yet. One additional piece of information exposed here is the system mailbox from which all the PAM-related email notifications will be sent. Unfortunately, there doesn’t seem to be any possibility to modify this in order to brand the notifications, and they will be sent using “Microsoft Exchange” as the display name – but more on that later too.

If you want to change any of the PAM settings, use the Enable-ElevatedAccessControl cmdlet with the corresponding attributes. Be warned though that running the Enable-ElevatedAccessControl cmdlet will overwrite all settings, so make sure you review the current configuration first. Should you want to disable the feature, you can use the Disable-ElevatedAccessControl cmdlet. As with the Enable-ElevatedAccessControl cmdlet, this can be run by any user with the Role management role assigned, at least for the time being, so make sure you control access for this role.

You can also view the status or make changes to the PAM settings via the Office 365 Admin Center. The UI there can be funky at times, as it seems to always default to displaying the feature as turned Off and the status gets updated only after a query to the backend is made, which takes several seconds to complete. Another thing to bear in mind is that the Default approver group dropdown doesn’t reflect on the currently configured approver group but will always highlight the first eligible group entry instead. In addition, the dropdown will happily list regular Distribution groups, even though the documentation tells us that only mail-enabled security groups are currently supported.

This concludes the first part of our extended look into the Privileged Access Management feature in Office 365. In the next part, we will see how PAM can be used to restrict various tasks and enable users to get time-bound, scoped access to Roles and Role Groups.