Azure AD Privileged Identity Management and new features

What is PIM?

PIM has and will be a backbone for permission Just In Time access in Microsoft based environments.

You can easily assign Permanent roles but also Eligible roles for admins and define timeout for the roles. They either have to Active the role or request a role to be assigned to them.

That’s the basic concept of PIM. They has been some limitations but as the backbone of role-based permission elevation, they has been some progress during these years from Microsoft engineers and again the is something to talk about.

If you are new to PIM, read my previous Study guide covering different features it has.

Or from Microsoft Learn

PIM for Groups (preview)

History

Before you had to assign roles to a particular user and they raised their permissions. Then you added the same role to another person and they did the same.

Well, that has changed. Now you can use Groups to assign the permissions and the group members will be able to elevate their rights when assigned to it.

If you are not using role-assigned groups, you can use this to activate the ownership or membership of a group under that is managed under PIM.

It will work with Azure AD security and Microsoft 365 groups and it was known as “Privileged Access Groups” until January 2023.

How to setup role-assigned?

Before you had to use role-assigned groups to achieve this kind of elevation.

The group does not have to be role-assignable group to be enabled in PIM for Groups. This was changed in January 2023.

But If you want to assign Azure AD roles to a group, it has to be role-assignable.

You can choose two ways to achieve this:

• Create active user assignments to the group, then designate the group as being eligible for activation by giving it a role.
• Make a role assignment to a group active and designate users who are eligible to join the group.

Now it’s possible to enable more than 500 groups per tenant in PIM, but only up to 500 groups can be role-assignable.

Azure AD role-assignable group feature is not part of Azure AD PIM. It requires Azure AD Premium P1 or P2 license.

Basically it means you will create a group that you can assign roles in but you will loose the Dynamic membership aspect and it can only be Assigned

Security group

Microsoft 365 groups

Inside Azure portal you can see the group creation like this for role-assigned groups.

And inside Microsoft 365 admin center it will look like this. You just have to make the group Private instead of Public.

Want to also point out the possibility to use Sensitivity labels inside a group, really nice feature.

Also one thing to note is that role-assignable groups can’t have other groups nested inside them.

Setup for non role-assigned groups?

And you can still create a group with roles assigned

And select Eligible or Active

How to onboard them?

Once you have the group in place, you will see it in the portal https://entra.microsoft.com/#view/Microsoft_Azure_PIMCommon/CommonMenuBlade/~/quickStart

And you can onboard new groups from Discover groups, once you choose find the group that you want to add and choose Manage groups

Verification will be asked and the group is onboarded to PIM for use

Once done, you will see it under Groups inside PIM. A group cannot be removed from management after it has been put under it. The removal of PIM settings by another resource administrator is therefore prevented.

Requesting access to a group

The user can then request to be a member or an owner of the group, depending on what you specified when assigning the permissions

When a membership or ownership is assigned, the assignment:

• Can’t be assigned for a duration of less than five minutes
• Can’t be removed within five minutes of it being assigned

Elevate rights with onboarded group

You can request role elevation with the group if it’s enabled for Role assignments or you have enabled PIM roles for individual users and they have active assignments.

For role-assigned groups admins will request their permissions just like before, no differences here.

Then to the next Preview feature that can be connected to PIM.

PIM and Conditional Access authentication context (Preview)

What is Authentication context?

Authentication context can be used to secure data and actions in applications even further. These applications can be your own custom applications, custom line of business (LOB) applications, applications like SharePoint, or applications protected by Microsoft Defender for Cloud Apps.

Organizations are limited to 25 authentication context definitions in total.

How setup?

First you to create the context definition, you can find it here https://entra.microsoft.com/#view/Microsoft_AAD_ConditionalAccess/ConditionalAccessBlade/~/AuthenticationContext

When creating a new definition, you will have the following options:

• Display name is the name that is used to identify the authentication context in Azure AD and across applications that consume authentication contexts. We recommend names that can be used across resources, like “trusted devices”, to reduce the number of authentication contexts needed. Having a reduced set limits the number of redirects and provides a better end to end-user experience.
• Description provides more information about the policies it’s used by Azure AD administrators and those applying authentication contexts to resources.
• Publish to apps checkbox when checked, advertises the authentication context to apps and makes them available to be assigned. If not checked the authentication context will be unavailable to downstream resources.
• ID is read-only and used in tokens and apps for request-specific authentication context definitions. It’s listed here for troubleshooting and development use cases.

Here you will see the current limit of 25 definition, one ID per context

To better understand how Definitions and ID’s can be used in an development environment, read Damien Bowden’s repository.

Conditional access policy

When you create the Conditional Access policy, you can assign it to specific users, groups or all users and you can also exclude object from the policy.

Then add that previously created Authentication context to the policy

In example you can require the following:

1. MFA or even authentication strenghts
2. Requiring a secured workstation (PAW) for your admin actions
3. Display Terms of Use to inform the user about any possible legal or compliance regulations.

The beauty of Conditional Access is that you can specify your own conditions and enforce them.

And maybe you want to add enforced sign-in frequency, which will be annoying but more secure.

If you want level up, you can also use Named location as they now support IPv6.

Back to PIM settings

When you back to PIM and edit the group, you can add the policy you have previously created.

The role is active for 8hrs and we set the policy to re-authenticate every hour.

Or you can add it to any built-in Azure role by editing the role

And add the policy to it that we created

Closure

Securing your Identities is important but Securing your Admin roles is even more important. Users can be scammed to give their credentials and if security isn’t thought and implemented well, there could be bad stuff happening.

When a user is compromised, the attackers will try to elevate their access by contacting those high valuable target, you admins.

If the admin accounts aren’t secured and use Just In Time access (JIT) and Privileged preferably Access Workstation (PAW) for admin tasks, all will be lost once they get compromised. We have examples from very recent history on these kind of breaches.