Azure Privileged Identity Management – Part 1

Blog » Azure Privileged Identity Management – Part 1

Administrating
resources and services in a company has always been a challenge and most
companies struggle with assigning the right level of access. On one hand administrative
privileges are needed to ensure productivity and implementation of new
services, while on the other hand these privileges are under attack from
adversaries.

One
solution is highly privileged administrators, which will ensure that implementing
new services runs smooth but leaves the company vulnerable to identity-theft
attacks against the administrative accounts that can give immediate access to
privileged resources.

Another
solution is to spread administrative privileges to a lot of accounts, which
again will ensure that implementing new services is possible with a little more
planning but again will leave the company vulnerable on a larger set of
identities, that can be used for elevation to higher privileges.

Decreasing
both the number of administrative accounts and privileges, increases the
overall security posture but has an impact on administration and implementation
of new services.

Finding the
right balance is challenging and with an increasing number of attacks on
identities, it is crucial that administrative access is controlled in a way
that reduces the attack surface.

Azure AD Privileged
Identity Management

From
experience we know that administrative privileges are not used most of the
time. Most administrators doesn´t even use their administrative privileges
daily, but still they are assigned to them permanently.
This means that these
identities are available at times where it is not necessary, at night, over
weekends, during holidays, sick leave, maternity leave and so on.

Our
experience also shows that a lot of administrator’s re-use passwords from their
normal user accounts on their administrative accounts.

Privileges
in Azure are assigned by adding an account to a role. Microsoft Azure AD
Privileged Identity Management is a tool that can control most of the roles in
Azure from a just in time access perspective but also it monitors the
use of most roles.

Other than the built-in roles, PIM can control roles created
for resources like VM´s or subscriptions.

Other than the
direct control over roles, PIM also covers reviews of members of roles. These
reviews can be defined to take place on certain dates or recurring and will
force reviewers to check up on members of a role.

For this article only role assignment and
activation are covered – reviews and resource role control, will be covered
later.

Role setup

Administrating
roles in PIM is accomplished by converting assigned roles from permanent to
eligible and requiring users to activate a role before it can be used, all use
of the roles is then monitored.

How the
role is activated can be configured, either overall (default for all roles) or
per role. It is possible to configure a range of settings like length of
activation, notification of role activation, ticket for internal ticketing
system, MFA and if approval should be given.

It is
recommended to setup how the role can be activated before starting to convert
roles from permanent to eligible. The available configurations are:

Activations

Maximum activation duration (hours)

Duration can be between 0,5 – 72
hours.

Notifications

Send emails notifying admins of activation

This will send a notification to members
of Global Administrators, Privileged Role Administrators, and Security
Administrators that a role has been activated.

Incident/Request ticket

Require incident/request ticket number during activation

Users will be required to enter incident
or request ticket during activation.

Multi-Factor Authentication

Require Azure Multi-Factor Authentication during activation

Users will be authenticated with MFA
during activation. This is possible to control for 19 roles but the last 17 does
not allow for MFA authentication to be disabled.

Require approval

Require approval to activate this role

This will require that activation is
approved by another administrator (approvers can be configured.)

Roles where all 5
requirements are configurable are – Application
Administrator, Application Developer, Authentication Administrator, Cloud
Device Administrator, Desktop Analytics Administrator, Device Administrators,
Directory Readers, Guest Inviter, License Administrator, Message Center Reader,
Password Administrator, Privileged Authentication, Administrator, Reports
Reader, Security Reader, Service Administrator, Teams Communications Administrator,
Teams Communications Support Engineer, Teams Communications Support Specialist
and Teams Service Administrator. For those the role setup will look like
figure 1.

Figure 1 – Role setup with all options

The last 17 roles are
considered too sensitive to allow disabling MFA. These are – Billing Administrator, Cloud Application
Administrator, Compliance Administrator, Conditional Access Administrator, CRM Service
Administrator, Customer LockBox Access Approver, Directory Writers, Exchange
Administrator, Global Administrator, Information Protection Administrator, Intune
Service Administrator, Power BI Service Administrator, Privileged Role
Administrator, Security Administrator, SharePoint Service Administrator, Skype
for Business Administrator and User Administrator. For those the role setup
will look like figure 2.

Figure 2 – Role setup for sensitive roles (notice MFA is greyed out.)

Role activation

So, if we
configure the global admin and enable notifications, tickets and approval like
in figure 3, the activation will look like figure 4-11:

Figure 3 – Notice that MFA cannot be configured for Global admin, it is forced

Figure 4 – The user has to login to the Azure portal and select available roles in PIM and press activate on Global Administrator

Figure 5 – Pressing activate will bring up figure 6

Figure 6 – I have chosen to activate the Global Admin privilege for 4 hours from 12:20 and given a reason and ticket number

Figure 7 – The approvers will receive an email warning them that a request for activation is awaiting approval

Figure 8 – And in the portal under requests a request is listed

Figure 9 – A reason for approval is required

Figure 10 – Request approved

Figure 11 – From the user perspective the role is now activated, notice that the role is valid until 16:35 (15 min extra) because it was activated 15 min over the requested start time

Administrative alerts

With
Privileged Identity Management the attack surface is greatly reduced because
administrative privileges are available only when required and use of
privileges are monitored.

Besides that, PIM also sends out a series of alerts. For instance, when administrative
roles are assigned outside of PIM, emails are send to PIM administrators.

Figure 12 – PIM warning message when administrative privileges are assigned outside of PIM

Configuring administrative alerts

With PIM enabled
a series of alerts are enabled too, these cover the use of roles and administrative
accounts. There are currently 7 different alerts of which 3 can be configured
and 4 are fixed.

The 4 that can´t be configured are:

Roles
don’t require multi-factor authentication for activation (not configurable)

This is a
low severity alert that is triggered if any roles are configured without MFA
requirements.

The
tenant doesn’t have Azure AD Premium P2 (not configurable)

This is a
low severity alert that is triggered if someone tries to onboard the tenant to
PIM without AAD Premium P2 licensing. (Effectively the onboarding will fail)

Potential
stale accounts in a privileged role (not configurable)

This is a
medium severity alert that is triggered if a user in an admin role hasn´t changed
the password for the account in the last 90 days.

Roles
are being assigned outside of PIM (not configurable)

This is a
high severity alert that is triggered if anyone adds a user to an
administrative role outside of PIM.

And the 3 that can be configured are:

Administrators
aren’t using their privileged roles (configurable – see figure 13)

This is a low severity alert that is triggered
if users in a role does not activate the role for a specific amount of days.

There
are too many global administrators (configurable – see figure 14)

This is a low
severity alert that is triggered if 2 configured thresholds are reached or
exceeded.

Roles
are being activated too frequently (configurable – see figure 15)

This is a low severity alert that is
triggered if role activations exceeds the configured amount in the configured
timeframe.

Figure 13 – The alert can be set to trigger from 1-100 days without role activation.

Figure 14 – Above the alert is set to trigger if there are 3 or more global admins AND they account for 10% or more of the total amounts of admins. So, for 3 global admins it would trigger if there is less than 31 admins in total

Figure 15 – The alert is triggered if admins activate a role 20 times or more within the given timeframe

PIM for all?

With alerts and access reviews (covered in a later article) PIM is a great way to ensure that administrative credentials are used in the right way and that they are assigned in the right way.

So it could be tempting to make all administrators eligible and get rid of that risk once and for all! But Microsoft hands out a warning when admins are converted to not make all eligible, this is because it should always be possible to login even if PIM is down or MFA is down or something else that could influence the activation of accounts.

For this “break glass” scenario do the following:

Create two cloud managed accounts

Assign permanent global admin to them

Remove them from any conditional access policies

Check logs frequently for use of these accounts (they should not be logging in)

Store these accounts safely for use only in case of emergency

This way access to the tenant will be possible even if the PIM service is down.