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.
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:
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)
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.
|
Conclusion
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