The content below is taken from the original ( Exchange Online Introduces Office 365 Privileged Access Management), to continue reading please visit the site. Remember to respect the Author & Copyright.

Controlling Elevated Access to Office 365

Traditionally, on-premises administrators are all-powerful and can access anything they want on the servers they manage. In the multi-tenant Office 365 cloud, Microsoft’s datacenter administrators are both few in number and constrained in terms of what they can do, and tenants must grant Microsoft access to their data if needed to resolve support incidents. Tenants with Office 365 E5 plans can use the Customer Lockbox feature to control support access to tenant data.

Privileged Access Management (PAM) for Office 365 is now generally available. PAM is based on the principle of Zero Standing Access, meaning that administrators do not have ongoing access to anything that needs elevated privileges. To perform certain tasks, administrators need to seek permission. When permission is granted, it is for a limited period and with just-enough access (JEA) to do the work. Figure 1 shows how the concept works.

This article examines the current implementation of PAM within Office 365. I don’t intend to repeat the steps outlined in the documentation for privileged access management or in a very good Practical365.com article here. Instead, I report my experiences of working with the new feature.

Only Exchange Online

Exchange is a large part of Office 365, but it’s only one workload. The first thing to understand about PAM is that it only covers Exchange Online. It’s unsurprising that the PAM developers focused on Exchange. Its implementation of role-based access control is broader, deeper, and more comprehensive than any other Office 365 workload. Other parts of Office 365, like SharePoint Online, ignore RBAC, while some like Teams are taking baby steps in implementing RBAC for service administration roles.

Privileged Access Configuration

PAM is available to any tenant with Office 365 E5 licenses. The first step is to create a mail-enabled security group (or reuse an existing group) who will serve as the default set of PAM approvers. Members of this group receive requests for elevated access generated by administrators. Like mailbox and distribution group moderation, any member of the PAM approver group can authorize a request.

To enable PAM for a tenant, go to the Settings section of the Office 365 Admin Center, open Security & Privacy, and go to the Privileged Access section. This section is split into two (Figure 2). Click the Edit button to control the tenant configuration, and the Manage access policies and requests link to define policies and manage the resulting requests for authorization.

To manage PAM, a user needs to be assigned at least the Role Management role, part of the Organization Management role group (in effect, an Exchange administrator). In addition, their account must be enabled for multi-factor authentication. If not, the Manage access policies and requests link shown in Figure 2 won’t be displayed.

By default, PAM is off and must be enabled by moving the slider for “require approval for privilege tasks” to On. You also select a PAM approver group at this point.

Configuration Settings

The settings are written into the Exchange Online configuration. We can see them by running the Get-OrganizationConfig cmdlet:

Get-OrganizationConfig | Selectn -Expand-Property ElevatedAccessControl

Enabled:True; Mode:Default; AdminGroup:[email protected]; ApprovalPolicyCount:5; SystemAccounts:; NotificationMailbox:SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}@office365itpros.onmicrosoft.com

Excepted Accounts

One interesting setting that the Office 365 Admin Center does not expose is the ability to define a set of accounts who are not subject to privileged access requests, such as accounts used to run PowerShell jobs in the background. To add some excepted accounts, run the Enable-ElevatedAccessControl cmdlet to rewrite the configuration (the only way to change a value). In this case, we specify a list of highly-privileged accounts (which should be limited in number) as system accounts. These accounts must, for now, be fully licensed and have Exchange Online mailboxes.

Enable-ElevatedAccessControl -AdminGroup '[email protected]' -SystemAccounts @('[email protected]', '[email protected]')

If you check the organization configuration for elevated access after running the command, you’ll see that the SystemAccounts section is now populated.

Access Policies

PAM policies allow tenants to set controls over individual tasks, roles, and role groups. If you are familiar with RBAC in Exchange Online, these terms are second nature to you. Briefly, a RBAC role defines one or more cmdlets and their parameters that someone holding the role can run, while a role group is composed of a set of roles. By supporting three types of policy, PAM allows tenants control at a very granular level for certain cmdlets while also having the ability to control higher-level roles.

As shown in Figure 3, the individual cmdlets chosen by PAM include adding a transport or journal rule, restoring a mailbox, adding an inbox rule, and changing permissions on mailboxes or public folders. Hackers or other malicious players might use to gain access to user mailboxes or messages. For instance, a hacker who penetrates a tenant might set up inbox rules to forward copies of messages to a mailbox on another system so that they can work out who does what within a company, information which is very helpful to them in constructing phishing or business email compromise attacks.

If you chose to create policies based on RBAC roles or role groups, the policies cover all the cmdlets defined in the chosen role or role group. You cannot add cmdlets, roles, or role groups to the set supported by PAM.

Each policy can have its own approval group. A policy can also be defined with an approval type of Manual, meaning that any request to use the commands within scope of the policy must receive explicit approval, or Auto, meaning that a request will be logged and automatically approved. Figure 4 shows a set of policies defined for a tenant.

Creating an Elevated Access Request

With PAM policies in place, users can request elevated access through the Office 365 Admin Center through the Access Requests section (Figure 4). A request specifies the type of access needed, the duration, and the reason why (Figure 5).

Although Exchange logs all PAM requests, it does not capture the information in the Office 365 audit log. This seems very strange as any request for elevated access is exactly the kind of event that should be recorded in the audit log.

Approving PAM Requests

When a PAM request is generated, Exchange Online creates an email notification generated from the mailbox pointed to in the organization configuration and sends it to the approval group (Figure 6). The person asking for approval is copied.

I found that the delay in receiving email notification about requests ranged from 3 minutes to over 40 minutes, so some education of administrators is needed to make them aware of how long it might take for the approvers to know about their request and then grant them access.

Approvers can also scan for incoming requests (or check the status of ongoing requests) in the Office 365 Admin Center. As you’d expect, self- approval is not allowed. Another administrator with the necessary rights must approve a request you make.

Upon approval, the requester receives notification of approval by email and can then go ahead and run the elevated command. An internal timer starts when the requester first runs the authorized command. They can continue to run the command as often as they need to during the authorized duration.

PAM by PowerShell

Cmdlets to control PAM are in the Exchange Online module. You must use MFA to connect to Exchange to run the cmdlets. You can run the cmdlets in a session created with basic authentication, but cmdlets fail unless they can authenticate with OAuth.

To start, here’s how to create a new request with the New-ElevatedAccessRequest cmdlet:

[uint32]$hours = 2
New-ElevatedAccessRequest -Task 'Exchange\Search-Mailbox' -Reason 'Need to search Kim Akers mailbox' -DurationHours $hours

Note the peculiarity that the cmdlet does not accept a simple number for the DurationHours parameter, which is why the duration is first defined in an unsigned 32-bit integer variable.
To see what requests are outstanding, run the Get-ElevatedAccessRequest command:

Get-ElevatedAccessRequest  |? {$_.ApprovalStatus -eq "Pending"}  | Format-Table DateCreatedUTC, RequestorUPN, RequestedAccess, Reason

DateCreatedUtc      RequestorUPN                     RequestedAccess Reason                           
--------------      ------------                     --------------- ------                           
5 Nov 2018 21:41:52 [email protected] Search-Mailbox  Need to search Kim Akers mailbox
5 Nov 2018 18:20:03 [email protected] Search-Mailbox  Need to look through a mailbox

The Approve-ElevatedAccessRequest cmdlet takes the identity of a request (as reported by Get-ElevatedAccessRequest) as its mandatory request identifier. For example:

Approve-ElevatedAccessRequest -RequestId 5e5adbdc-bfeb-4b01-a976-5ac9bf51aff0 -Comment "Approved due to search being necessary"

PowerShell signals an error promptly if you try to approve one of your own requests by running the Approve-ElevatedAccessRequest cmdlet, but the Office 365 Admin Center stays silent on the matter and doesn’t do anything.

Shortcomings and Problems for PAM

PAM for Office 365 is a promising idea that I strongly support. However, the current implementation is half-baked and incomplete. Here’s why I make that statement:

There’s a worrying lack of attention to detail in places like the prompt in the PAM configuration “require approval for privilege tasks” which should be privileged tasks. It’s a small but annoying grammatical snafu. Another instance is the way that the DurationHours parameter for New-ElevatedAccessRequest doesn’t accept simple numbers like every other PowerShell cmdlet in the Exchange Online module. Or the way that the Office 365 Admin Center proposes the first group found in the tenant as the default approval group when you go to update the PAM configuration, making it easy for an administrator to overwrite the default approval group with an utterly inappropriate choice. Seeing code like this released for general availability makes me wonder about the efficiency and effectiveness of Microsoft’s testing regime.

The lack of auditing is also worrying. Any use of privileged access or control over privileged access should be recorded in the Office 365 audit log. In some mitigation, audit records for the actual events (like running a mailbox search) are captured when they are executed.

The biggest issue is the tight integration with Exchange Online. Leveraging the way Exchange uses RBAC makes it easier for the developers to implement PAM, but only for Exchange Online. Other mechanisms will be needed to deal with SharePoint Online, OneDrive for Business, Teams, Planner, Yammer, and so on. Basing PAM on a workload-dependent mechanism is puzzling when so much of Office 365 now concentrates on workload-agnostic functionality.

Some organizations will find PAM useful today. Others will be disappointed because of the flaws mentioned above. We can only hope that Microsoft will address the obvious deficiencies in short order while working as quickly as possible to make “Privileged Access management in Office 365” (as announced) a reality.

The post Exchange Online Introduces Office 365 Privileged Access Management appeared first on Petri.