Pages

Sunday, April 18, 2021

PowerShell script to remove users in an Active Directory group from all Microsoft Teams' Teams in an organization

I was recently asked by a colleague about whether it was possible to use PowerShell to remove a group of users in an Active Directory group from all Microsoft Teams’ Teams in an organization. A bit of Googling did not yield any results so I quickly wrote one that performs the following:

  1. Uses Get-ADGroupMember to export a list of users’ User Principal Name from an Active Directory group to a txt file
  2. Uses the exported list of UPNs to get the list of Teams each user belongs to
  3. Write the list of Teams the user belongs to into a txt file with their UPN as the file name
  4. Remove the user from every Team they belong to

The following is the PowerShell script.

Obtain list of users in an AD Group (you can run this on a domain controller and copy the file to where you will connect to O365)

Get-ADGroupMember -Identity "Board Members" | %{Get-ADUser $_.SamAccountName | foreach { $_.userPrincipalName }} > C:\Scripts\UPNofADGroup.txt

**The example above retrieves users from a AD Group named “Board Members”

Connect to Microsoft Teams environment

Connect-MicrosoftTeams

https://docs.microsoft.com/en-us/powershell/module/teams/connect-microsoftteams?view=teams-ps

Use the list of UPNs to export the Teams they belong to then remove them from the Teams

ForEach ($userToRemove in Get-Content C:\Scripts\UPNofADGroup.txt)

{

$exportedFile = "C:\Scripts\" + $userToRemove + ".txt"

Get-Team -User $userToRemove | FT -AutoSize > $exportedFile

$GroupIDList = Get-Team -User $userToRemove | Select *GroupID*

Foreach ($GroupID in $GroupIDList)

{

Remove-TeamUser -GroupID $GroupID.GroupID -user $userToRemove

}

}

--------------------------------------------------------------------------------------------------

Hope this helps anyone who may be looking for a script like this.

Monday, April 12, 2021

Understanding the differences between Azure AD Roles and Azure RBAC Roles with respect to the levels tenant, root, management group and subscription

I find that getting to understand the differences between Azure AD Roles and Azure RBAC Roles with respect to the following levels are often overlooked or misunderstood:

  • Tenant
  • Root
  • Management group
  • Subscription

Those who have not yet had the opportunity to be exposed to larger organizations where multiple subscriptions and the use of management groups for organizing subscriptions may not realize the way in which all these components interact with each other so this blog post serves to provide an overview of them.

Let me begin by providing the official Microsoft documentation for each of the components and note that if you decide to reach all of them then you may not need to read this blog post.

Quickstart: Set up a tenant
https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant

What are Azure management groups?
https://docs.microsoft.com/en-us/azure/governance/management-groups/overview

Microsoft Azure glossary: A dictionary of cloud terminology on the Azure platform - Subscription
https://docs.microsoft.com/en-us/azure/azure-glossary-cloud-terminology#subscription

Associate or add an Azure subscription to your Azure Active Directory tenant
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-subscriptions-associated-directory

Classic subscription administrator roles, Azure roles, and Azure AD roles (must read)
https://docs.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles

Note that there isn’t a Microsoft document that explains what the Root level is but the following diagram should explain what and where it sits among the other components:

clip_image002[14]

Notice that I’ve included an on-premise Active Directory in the diagram to denote that domains within the traditional Active Directory Domain Services (AD DS) can be synchronized into Azure AD after they have been added as a custom domain. The user accounts, computer accounts and groups (also known as security principals) that are synchronized into AAD (Azure Active Directory) can be used to assign Azure permissions from various levels of the resources (e.g. Root, manage groups, subscriptions, and resources). As accounts are primarily synchronized from AD DS to AAD and not the other way around, you cannot grant permissions to your on-premise resources with AAD accounts. I’ve also included Office 365 in the diagram to depict how Azure AD roles for SaaS application management (O365, D365, PowerBi, Intune), which I will elaborate later in this blog post.

Azure account and Azure subscriptions

Before jumping into the roles used to manage Azure, it is important to understand that an Azure account represents a billing relationship. This essentially means that an Azure account is all of the following:

  • A user identity
  • One or more Azure subscriptions
  • An associated set of Azure resources.

The administrator who creates the account is the Account Administrator for all subscriptions created in that account as well as the default Service Administrator for the subscription.

Azure subscriptions help administrators accomplish the following:

An example can be where there are multiple environments for a project and each environment’s budget should be billed separately for their own Azure consumption. Having multiple subscriptions under the same tenant would allow the access to resources and billing costs to be isolated.

clip_image002[4]

Lastly, each subscription is associated with an Azure AD directory and cannot have more than one even though an Azure AD directly can be associated to more than one subscription. The following is a diagram that depicts the relationship between the Azure AD tenant owner, the subscription and the resources.

clip_image002[6]

The Beginning of Azure – Classic Subscription Administrator Roles

When Azure was first released, access to resources was managed by only the following three administrator roles:

  • Account Administrator
  • Service Administrator
  • Co-Administrator

clip_image002[16]

Those who got into Azure later (after RBAC roles were introduced) will see references to these accounts in the Classic administrators tab:

imageimage

Or alternatively some CSP subscriptions such as the one below provides the informational message indicating:

This type of subscription does not support classic administrators.

image

The Evolution of Azure Roles with RBAC

Having only the 3 type of roles to manage the full scope of Azure resources did not scale very well so Microsoft later added Azure role-based access control (Azure RBAC) to provide a more fine-grained access management to resources. Azure RBAC provided 70 built-in roles that could be assigned at different scopes (Management Group, Subscription and Resources), and allows the creation of custom roles. There are four fundamental Azure roles. The first three apply to all resource types:

Azure role

Permissions

Notes

Owner

  • Full access to all resources
  • Delegate access to others

The Service Administrator and Co-Administrators are assigned the Owner role at the subscription scope

Applies to all resource types.

Contributor

  • Create and manage all of types of Azure resources
  • Create a new tenant in Azure Active Directory
  • Cannot grant access to others

Applies to all resource types.

Reader

  • View Azure resources

Applies to all resource types.

User Access Administrator

  • Manage user access to Azure resources
 

clip_image002[18]

The rest of the 66 roles can be found here: https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles Being familiar with these roles is useful for the AZ exams.

While most of the new environments should have move away from the Azure classic deployment model, it is important to note that only the Azure portal and the Azure Resource Manager APIs support Azure RBAC. Users, groups, and applications that are assigned Azure roles cannot use the Azure classic deployment model APIs. I would highly recommend the following document to understand the differences:

Azure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/deployment-models

Azure RBAC roles are available throughout the Azure portal via the Access control (IAM) blade for management groups:

image

… subscriptions:

image

… resource groups:

image

… other resources (a disk resource in the screenshot below):

image

In the Azure portal, role assignments using Azure RBAC appear on the Access control (IAM) blade. This blade can be found throughout the portal, such as management groups, subscriptions, resource groups, and various resources.

What is RBAC?

As a refresh, RBAC abbreviates for Role-Based Access Control, which is used to define what the security principal that is assigned the RBAC role, can perform. The nuts and bolts of how RBAC work in Azure is where a built in or custom role has a definition with a collection of permissions. The definition lists the operations that can be performed and these can include read, write, and delete. One of the ways to review the definition is to use the Get-AzRoleDefinition cmdlet with a specified role such as Contributor as shown below:

PS C:\> Get-AzRoleDefinition "Contributor" | ConvertTo-Json

{

"Name": "Contributor",

"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",

"IsCustom": false,

"Description": "Lets you manage everything except access to resources.",

"Actions": [

"*"

],

"NotActions": [

"Microsoft.Authorization/*/Delete",

"Microsoft.Authorization/*/Write",

"Microsoft.Authorization/elevateAccess/Action",

"Microsoft.Blueprint/blueprintAssignments/write",

"Microsoft.Blueprint/blueprintAssignments/delete"

],

"DataActions": [],

"NotDataActions": [],

"AssignableScopes": [

"/"

]

}

List Azure role definitions

https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions-list?tabs=roles

Note the Actions that are allowed (the * denotes all actions) and the NotActions that are not allowed (granting authorization, elevating access, and Blue Print write and delete).

What are Azure AD Roles? They should not be mistaken for Azure Roles (RBAC)

It is important to recognize that Azure AD roles and Azure roles (RBAC) are not the same. Azure roles are as described from the previous sections, while Azure AD roles are used to manage Azure AD resources in a directory such as create or edit users, assign administrative roles to others, reset user passwords, manage user licenses, and manage domains. Think of them as the traditional Active Directory but a modernized version used in the cloud with a drastically different architecture. The following table describes a few of the more important Azure AD roles.

Azure role

Permissions

Notes

Global Administrator

  • Manage access to all administrative features in Azure Active Directory, as well as services that federate to Azure Active Directory
  • Assign administrator roles to others
  • Reset the password for any user and all other administrators

The person who signs up for the Azure Active Directory tenant becomes a Global Administrator.

User Administrator

  • Create and manage all aspects of users and groups
  • Manage support tickets
  • Monitor service health
  • Change passwords for users, Helpdesk administrators, and other User Administrators
 

Billing Administrator

  • Make purchases
  • Manage subscriptions
  • Manage support tickets
  • Monitors service health
 

clip_image002[10]

The Azure AD roles can be found in Roles and administrators blade:

image

image

The complete list of Azure AD roles can be found here: https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference

Differences between Azure roles and Azure AD roles

Microsoft’s official documentation states that at a high level, Azure roles control permissions to manage Azure resources, while Azure AD roles control permissions to manage Azure Active Directory resources with the following table highlighting some of the differences:

Azure roles

Azure AD roles

Manage access to Azure resources

Manage access to Azure Active Directory resources

Supports custom roles

Supports custom roles

Scope can be specified at multiple levels (management group, subscription, resource group, resource)

Scope can be specified at the tenant level (organization-wide), administrative unit, or on an individual object (for example, a specific application)

Role information can be accessed in Azure portal, Azure CLI, Azure PowerShell, Azure Resource Manager templates, REST API

Role information can be accessed in Azure admin portal, Microsoft 365 admin center, Microsoft Graph, AzureAD PowerShell

Are there any overlaps between Azure roles and Azure AD roles?

One of the common questions I get asked about Azure roles and Azure AD is whether they overlap and the short answer is no as shown in the diagram I presented earlier:

clip_image002[20]

Azure AD role permissions can't be used in Azure custom roles and vice versa. The only situation where Azure AD spans into the resources that Azure RBAC roles manage is if a Global Admin elevates their access by activating the Global Admin can manage Azure Subscriptions and Management Groups switch in the Azure portal as shown in the following screenshot:

Access management for Azure resources

Terence Luk can manage access to all Azure subscriptions and management groups in this tenant.

image

https://docs.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin

Enabling this option will grant the user the Azure RBAC role named User Access Administrator role to all subscriptions for the tenant as shown in the screenshot below:

image

Notice that there is a Foreign Principal for ‘Tec… labeled above. The subscription in this example was provisioned by the CSP partner Tech Data and by accepting the invite, they were granted Owner permissions to the subscription. It is also important to note that the User Access Administrator role allows the user to grant other users access to Azure resources, which is only a permission an Owner has.

Azure AD and Office 365

Those who work heavily in the Office 365 space will recognize that some Azure AD administrator roles span into Microsoft Office 365. These roles include the Global Administrator role and the User Administrator role. The following is a screenshot of the Roles listed in the Microsoft 365 admin center Roles portal:

image

This list is can be expanded to show the rest of the non-administrative roles:

image

image

Notice how there is a Billing admin in the Microsoft 365 roles. This is the same role as the Billing Administrator in Azure AD and assigning this role in either Azure AD or Microsoft 365 will have the other reflect the same change:

image 

This is also the same for the Global Administrator role in Azure AD and in Office 365:

image

image

CSP Permissions for Subscriptions

Having worked for CSP over the past few years, one of the most common questions I get asked by the client we as the CSP is trying to establish a relationship with is what type of permissions are granted when they accept us (the vendor) as the their CSP and the answer is that we are granted Global Administrator and Helpdesk admin roles as shown in the Microsoft 365 admin console screenshot below:

image

Which can be removed if required:

image

As well as a Owner as shown in the Azure portal below:

image

Here are some useful reference documents about this topic:

Azure subscriptions and resource management
https://docs.microsoft.com/en-us/partner-center/customers-revoke-admin-privileges#azure-subscriptions-and-resource-management

Delegated admin privileges in Azure AD
https://docs.microsoft.com/en-us/partner-center/customers-revoke-admin-privileges#delegated-admin-privileges-in-azure-ad

Invite a customer to establish a reseller relationship with you
https://docs.microsoft.com/en-us/partner-center/request-a-relationship-with-a-customer#invite-a-customer-to-establish-a-reseller-relationship-with-you

Transitioning to CSP for Seat-based services
https://docs.microsoft.com/en-us/partner-center/transition-seat-based-services

Multi-partner functions in CSP
https://docs.microsoft.com/en-us/partner-center/multipartner

I hope this blog post has been informative for anyone who may be looking for information about the differences between Azure AD roles and Azure RBAC roles.

Logging onto a Citrix ADC / NetScaler hosted on Azure with nsroot fails with the error: "nsnet_connect: No such file or directory"

Problem

You’ve noticed that Citrix ADC / NetScaler hosted on Azure is no longer reachable and attempting to use the Serial console feature in Azure administration portal fails with the following error after entering the password for the nsroot account:

Nsnet_connect: No such file or directory

image

Solution

One of the possible reasons why the above error is displayed is if the /var directory is full but not being able to log into the appliance means that there is no way of cleaning up the drive. The workaround for this scenario is to try and use the nsrecover account to log in. The default password for this account is usually nsroot:

image

Once successfully logged in, proceed to use df -h to confirm the issue as shown in the screenshot above then use the following KB to clean up the /var directory:

How to free space on /var directory for logging issues with a Citrix ADC appliance
https://docs.citrix.com/en-us/citrix-adc/current-release/system/troubleshooting-citrix-adc/how-to-free-space-on-var-directory.html

Monday, April 5, 2021

Configuring Azure Privileged Identity Management (PIM)

One of the features I’ve liked a lot when I was able to work with clients who had Azure AD Premium 2 or Enterprise Mobility + Security (EMS) E5 licenses is the Privileged Identity Management (PIM). This feature has a lot of offer when it comes to one of the most neglected operations that every organization should have:

managing privileged access. In this post, I will describe attempt to describe the benefits of it as well as demonstrate some of its features.

What is Azure Privileged Identity Management (PIM)?

Let me begin by saying that Microsoft provides an excellent write up and video about PIM, which can be found here:

What is Azure AD Privileged Identity Management?
https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure

When I am asked this question, I usually provide the following:

The short and condensed explanation of Azure’s Privileged Identity Management (PIM) is that provides you with the tools to manage, control, monitor, and audit access to resources in the organization. An example of this could be a consultant is engaged in a project with your organization and I need administrative rights in Azure because I need to add or manage another domain so this I am granted the global admin role but the role then never gets removed. The use of a consultant can easily be interchanged with any administrator on the team who was granted the global admin role and never gets removed, which is very similar to, say, the Enterprise Admins or Domain Admins group in an on-premise Active Directory. Another example could be that we do not want administrators to have persistent administrative permissions whenever they log into Azure so we would like them to have the ability to elevate their permissions. Lastly, another example could be that there is suspicion the account used to sign up for the Azure tenant had its password reset at some point and is being used so an audit of the history is required.

The following are the key features taken straight from the Microsoft documentation:

  • Provide just-in-time privileged access to Azure AD and Azure resources
  • Assign time-bound access to resources using start and end dates
  • Require approval to activate privileged roles
  • Enforce multi-factor authentication to activate any role
  • Use justification to understand why users activate
  • Get notifications when privileged roles are activated
  • Conduct access reviews to ensure users still need roles
  • Download audit history for internal or external audit

Leveraging the features above can allow any organization to better manage privileged access to Azure AD, Azure, and other Microsoft Online Services such as Microsoft 365 or Microsoft Intune.

Active vs Eligible Roles for Privileged Identity Management

With Azure Privileged Identity Management, there are two types of assignments that can be made to roles and they are:

  • Eligible assignments require the member of the role to perform an action to use the role. Actions might include performing a multi-factor authentication (MFA) check, providing a business justification, or requesting approval from designated approvers.
  • Active assignments don't require the member to perform any action to use the role. Members assigned as active have the privileges assigned to the role at all times.

It is generally advised to use eligible as much as you can so you can avoid having an account that always has permissions. If an account needs to have the an active assignment for scenarios such as hiring a consultant for a full day of review, specify an active assignment with an assignment start and end date/time.

Licensing Requirements

The official Microsoft provided licensing requirements for using PIM can be found here:

License requirements to use Privileged Identity Management

https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/subscription-requirements

To summarize, if you are strictly purchasing Azure AD Premium P2 licenses for PIM then you will only need as many employees that will be performing the following tasks:

  • Users assigned as eligible to Azure AD or Azure roles managed using PIM
  • Users who are assigned as eligible members or owners of privileged access groups
  • Users able to approve or reject activation requests in PIM
  • Users assigned to an access review
  • Users who perform access reviews

Azure AD Premium P2 licenses are not required for the following tasks:

  • No licenses are required for users who set up PIM, configure policies, receive alerts, and set up access reviews.

Examples of usage scenarios can be found here: https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/subscription-requirements#example-license-scenarios

The following is what happens with the license examples:

If an Azure AD Premium P2, EMS E5, or trial license expires, Privileged Identity Management features will no longer be available in the directory:

  • Permanent role assignments to Azure AD roles will be unaffected.
  • The Privileged Identity Management service in the Azure portal, as well as the Graph API cmdlets and PowerShell interfaces of Privileged Identity Management, will no longer be available for users to activate privileged roles, manage privileged access, or perform access reviews of privileged roles.
  • Eligible role assignments of Azure AD roles will be removed, as users will no longer be able to activate privileged roles.
  • Any ongoing access reviews of Azure AD roles will end, and Privileged Identity Management configuration settings will be removed.
  • Privileged Identity Management will no longer send emails on role assignment changes.

Note that Azure AD Premium P2 also provides the Identity protection feature for accounts (https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection), which would enable the following:

  • Vulnerabilities and risky accounts detection
  • Risk events investigation
  • Risk-based Conditional Access policies

If these features are designed for the organization then everyone will need to be licensed.

With an overview of PIM provided, I will proceed to demo each of the key features provided in the Microsoft documentation:

  • Provide just-in-time privileged access to Azure AD and Azure resources
  • Assign time-bound access to resources using start and end dates
  • Require approval to activate privileged roles
  • Enforce multi-factor authentication to activate any role
  • Use justification to understand why users activate
  • Get notifications when privileged roles are activated
  • Conduct access reviews to ensure users still need roles
  • Download audit history for internal or external audit

Deploy PIM

I find that many administrators typically skip through the Deploy PIM section of the Microsoft documentation (https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-deployment-plan) as the section does not actually contain any configuration instructions but I’d like to stress how important it is to read through all the items that Microsoft outlines to successfully plan for a PIM deployment. I would highly recommend going through the documentation before jumping into the next configuration section.

No more “Consent to PIM”

Those who have worked with PIM in the past or written the older AZ-500 exam may remember how administrators need to “consent to PIM” prior to using the feature. The process of consenting to PIM has been removed so there is no need to perform this step anymore and the console now has the following banner inserted into the Quick start page:

You are using the updated Privileged Identity Management experience for Azure AD roles.

image

The changes that Microsoft made as per the documentation https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-getting-started#prerequisites is as such:

When a user who is active in a privileged role in an Azure AD organization with a Premium P2 license goes to Roles and administrators in Azure AD and selects a role (or even just visits Privileged Identity Management):

  • We automatically enable PIM for the organization
  • Their experience is now that they can either assign a "regular" role assignment or an eligible role assignment

When PIM is enabled it doesn't have any other effect on your organization that you need to worry about. It gives you additional assignment options such as active vs eligible with start and end time. PIM also enables you to define scope for role assignments using Administrative Units and custom roles. If you are a Global Administrator or Privileged Role Administrator, you might start getting a few additional emails like the PIM weekly digest. You might also see MS-PIM service principal in the audit log related to role assignment. This is an expected change that should have no effect on your workflow.

Start Using PIM with Wizard

If you’re new to PIM and need to quickly start using the features with minimal configuration, using the security wizard (https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-security-wizard) would be a great start. The Discovery and insights (Preview) feature in the Privileged Identity Management blade provides the easy to use wizard to begin leveraging PIM features:

image

Configuring a PIM Administrator with an Active Assignment

If you already have a deployment plan created then our first step would be to assign the planned account to Privileged Role Administrator role for PIM administration. Navigate to Azure AD roles under Manage:

image

Then Roles and type in Privileged Role Administrator to list the PIM role, then select it:

image

Once in the properties of the role, proceed to use the Add assignments button to add a user into the role. I will add my own account for the purpose of this example.

**Note that as of the time of writing this post, the Microsoft documentation dated on 08/06/2020 specifies that we should click on the Add Member button (https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-how-to-give-access-to-pim#delegate-access-to-manage-pim) but this button is no longer available on 4/3/2021.

image

image

I will configure this assignment to be active and permanently assigned but note that it is generally advised that most active assignments should be configured with a start and end time/date if possible.

image

The account specified should now be displayed under the Active assignments tab:

image

Navigating back to the Privileged Role Management page and selecting My roles:

image

Then under Azure AD roles and Active Assignments should display the roles I am currently a part of (Global Administrator and Privileged Role Administrator):

image

Note that the act of granting my account the Privileged Role Administrator role will send the following notification to my email address about the assignment.

image

Privileged Identity Management Alerts

You can instantly view a list of issues as identified by PIM by clicking on the Alerts under the Manage settings:

image

Note the 3 alerts that are raised for this environment:

  • Roles don’t require multi-factor authentication for activation
  • Potential stale accounts in a privileged role
  • There are too many global administrators

The first two are fairly obvious while the second one lists accounts that have not changed their password in the past 90 days and clicking into the line item will bring up the details:

image

Clicking on the Settings button will bring us into configuration set for identifying these risks:

image

You can click on each of the alerts to see what configuration changes you can make as well as whether to disable them:

image

Assigning a User with Eligible Role (J.I.T)

With the initial configuration and walk through of the alerts out of the way, let’s proceed to assigning a user with the eligible role for the Global Admin role. Begin by navigating to Azure AD roles under Manage:

image

Then Roles and type in Global Admins to list the PIM role, then select it:

image

Click on Add assignments:

image

I’ll be using a account named John Smith as the example:

image

In the Setting tab, we will configure the Assignment type as Eligible with Permanently eligible disabled and a Assignment starts and Assignment ends date/time specified to be one day:

image

Note that the Assignment starts and Assignment ends date/time cannot exceed more than a year or the message Time duration specified exceeds maximum allowed. will be displayed:

image

The role assignment should now be displayed under the Eligible assignments tab:

image

Note that upon completion of assignment John Smith the eligible role, notification emails such as the one below would have been sent to the admins.

image

Testing a User with Eligible Role

With the eligible role assigned to John Smith, we can log into the Azure portal and confirm that he does not have the ability to create new users or reset passwords as he is eligible but not a Global Admin yet:

image

We can then navigate to the Privileged Identity Management section, click on Azure AD roles under Activate, then see that we can eligible for the Global Administrator role with the option of activating it:

**Note that there is an end time for this eligible assignment as how it was configured in the previous section.

image

We’ll notice that attempting to activate the role indicates we are prompted with:

Additional verification required. Click to continue

The reason why this prompt is displayed is because this account does not have MFA set up and the default settings for activation is to have MFA setup, which I will show a bit later.

image

Proceed to set up MFA:

image

imageimage

Once MFA is successfully set up, the following activation options will be displayed. Note how there are various parameters we can configure such as the activation start time, the duration, and a reason, which is required for activation:

image

For the purpose of this example, I will set the duration to only 2 hours mimicking the scenario that I only need 2 hours of elevated permissions. My reason for the activation will be to: Test Global Admin activation.

image

The activation proceeds through 3 stages and will complete fairly quickly (you don’t need to walk away from the computer):

image

Upon completion of activation, the Eligible assignments tab will refresh and display the following message:

You have just activated a role. Click here to view your active roles

image

Clicking the Click here to view your active roles will change the table to Active assignments which will display the activated state. Note the End time listed is 2 hours from when I activated it:

image

The test John Smith user will now be able to create accounts:

image

Upon activating the Global Admin assignment, notification emails such as the one below would have been sent to the admins:

image

When the duration has expired an email will be sent:

image

Activation Role Settings Configuration

It is possible to customize the activation role settings as demonstrated in the previous activation by navigating to Azure AD roles under Manage:

image

Roles and type in Global Admins to list the PIM role, then select it:

image

Click on Role settings to list the parameters that we can edit:

image

The configuration settings are partitioned into tabs, which I have combined into one screenshot.

The Activation tab allows us to:

  1. Change the activation maximum duration in hours, which defaults to 8 and is customizable during the activation process
  2. Requires the account to have MFA setup – why John Smith had to set up MFA
  3. Require a justification – why we had to enter a reason
  4. Require ticket information on activation – this will provide two fields – 1. ticket number, 2. ticketing system link
  5. Require approval to activate – One of the features I enjoy most as this will require another administrator to interactively approve the activation from the Azure portal

The Assignment tab allows us to:

  1. Allow permanent eligible assignment – this can be changed to limit the amount of time an eligible assignment can be
  2. Allow permanent active assignments after – this enables or disables permanent active assignment and if it is disabled, the active assignment can be force to expire after a period of time (1 year, 6 months, 3m months, 1 month, 15 days)
  3. Require Azure MFA on active assignment – this will force MFA for active assignments
  4. Require justification on active assignment – forces a reason to be entered

The Notification tab allows us to specify various notification settings for when activation or assignments take place.

image

These configuration settings are set independently for each role.

PIM Auditing

To perform an audit of on the activities of privileged accounts, navigate to Azure AD roles under Manage:

image

Select Resource Audit under Activity and you will see the actions of PIM administrators as well as users who have activated their eligibility for configured roles:

image

Clicking on a line item will bring the details of the action:

image

Navigating to the My audit section will display all the PIM activities the account logged in has made:

image

Creating an Access Review

You can create an access review to list the specific PIM activities of a role such Global Admin by navigating to Azure AD roles under Manage:

image

Then Access reviews and select New:

image

Then configure the review as required:

image

The frequency can be set to the following:

image

Note the Upon completion settings and Advanced settings that are available:

image

A review will be created in the Access reviews:

image

Clicking into the report will provide information about the PIM activity for Global Admins:

image

image

image

image

image

Hope this gives anyone looking for information about PIM an overview and demonstration of what it has to offer.