Search This Blog

Tuesday, April 23, 2019

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:

Maximum activation duration (hours)
Duration can be between 0,5 – 72 hours.

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.


This concludes part 1 of Azure AD Privileged Identity Management. We will be back with more on how to configure ressource control and access reviews.

If you have any questions or would like so see a live demo of how PIM works, do not hesitate to contact us.

No comments:

Post a Comment