Azure Privileged Identity Management (PIM)

Azure Privileged Identity Management deals in managing access governance framework around highly privileged office365 and Azure account. Azure PIM is based on a Just In Time access framework where highly privileged accounts like Global Admins, other admins, and Azure Admin are eligible to elevate their access based on eligibility criteria set by PIM administrator for a specific timeframe. It also provides the ability to audit the actions of administrators, be it an internal or external account.

Key Features of PIM are:-

It provides an ability to grant just-in-time access to Azure AD or Azure ARM-based roles.

It assigns time-bound access with start and end date

It can force an approval workflow if configured

It forces MFA for all privileged user accounts

It forces users to provide justification while activating a role

It will notify other Global Administrators when escalation in privileges activated

It can conduct access review to ensure users that still need roles should have eligibility

It allows downloading history for an internal and external audit

Licenses Requirement –

It requires Azure AD P2 license to activate Azure AD Privileged Identity Management.

Considerations –

Microsoft also recommends having at least 2 x Global Admin cloud-only accounts that should keep out of the PIM umbrella to ensure that there will be a jailbreak option if any issue with PIM can lock everybody out.

Roll-out plan –

Microsoft has highlighted a detailed plan to roll out PIM for Azure AD and ARM administrator roles that will start with auditing and then roll it out with very sensitive accounts like Global Administrators. After that, the same process can be followed for the rest of the privileged accounts.

https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-deployment-plan

Exceptions to PIM –

There can be exceptions where you might end up leaving permanent assignments for accounts used by applications where you have no control to request elevated access from time to time.

Introduction to Azure Multifactor Authentication

 Azure AD MFA

Azure AD Multi-Factor Authentication (MFA) provides an extra layer security to our identities be it cloud base, synced or guest by requiring two or more method of validating authenticity of user.

Azure MFA work on a core element of: -

-        Something you know – could be a password or the answer to a security question.

-        Something you possess – could be a mobile app that receives a notification or a token-generating device.

-        Something you are - which is typically a biometric device, such as a fingerprint or face scan used on many mobile devices.

 

Licensing Requirement: -

-        Included in Azure AD premium licenses

-        Provided as a part of free or standard office 365 subscription for cloud only identities

-        Provided as a standard offering to cover global admin accounts irrespective of licenses

 

Why to use it?

User name and passwords are legacy authentication methods that are not strong enough to with stand with sophisticated attacks by modern hackers and even making password more and more complex make it hard to remember, hence, users will start writing it to desk or storing to some alternate source.

So, to make identities more secure and overcome these challenges multifactor authentication is playing a key role and azure multifactor authentication made it simpler and easier to implement and use.

What are different methods of authentication supported by Azure MFA?

Following Authentication methods are supported by Azure MFA

-        Password

-        Microsoft Authenticator App

-        OATH Hardware token

-        Text Message

-        Voice Call

-        App Password

What are the different ways to configure MFA?

Azure MFA can be configured from Azure Active Directory admin portal on per user basis or by using a conditional access policy where MFA can be enabled or disabled based group membership or by using other supported arguments.

Another method to enable MFA is by enabling security defaults to ensure that Microsoft recommended security policies should be enforced. However, this is only suitable for small deployment where conditional access policies are not required.

Importance of Azure Integrated Application Auditing

SaaS base application solutions are is at Centre stage in the era of cloud-based digitalization. It provide immense capabilities in the space applications and productivity tools, however, it’ll also pose an extreme challenge in terms of increasing our attack surface, increases chances of data breach or identity theft. Hence, a regular auditing of these integrated application in term of usages and access right is must and can save a day for us in case an intruder try to take an advantage unnecessary permission or unused service principles.

Moreover, these tasks are tedious without a specialized tool like MCAS but can still be done with the help of PowerShell scripts and some manual efforts.

 

You can use below mentioned Powershell Cmdlets against your Azure AD tenant in order to pull out required information.

 

1.      1.  You can pull application dispalyName, objectID and appID by using command below:

 

Get-AzureADApplication | Select DisplayName,ObjectID,AppID

 

2.       2. You can list appOwner by using application’s objectID in the command below:

 

Get-AzureADApplicationOwner -ObjectId '<Mention Object ID here>’

 

3.       3. You can find API permission via command below:

 

$appl = Get-AzureADApplication -ObjectId ‘<Mention Object ID here>'

$appl.requiredResourceAccess| ConvertTo-Json -Depth 3

 

Note :-

The ResourceAppId represent the application ID of the SP of the API e.g. Microsoft Graph and ResourceAccess list the permission assigned to it where Scope is delegated permission and role is the application permission

Azure AD user consent setting ( Feature that you should Consider seriously)

Azure application consent is a way users can authorize applications to access their information and data to perform a specific job. The default setting of this application consent allows users to permit the application to access data requested by the application while asking for consent. So technically, it'll create a service principal in Azure AD to provide OAuth token to the application that will, in turn, allow the application to access data based on permission approved by users.

However, the downside is that malicious applications can request greater permission than required and potentially steal critical information or confidential data. It even poses a greater risk to organizations that don't have data loss prevention policies to track usage of their confidential or critical data.

Hence, it is recommended to keep this setting as restricted as possible, possibly set it to admin consent, however, you can still set it to allow users to consent verified providers in case your organization doesn't want to impact user experience as recommended by Microsoft.

Change Enterprise Application -->User setting

 -- Change setting highlighted in red as follow to change it to admin consent (Most Restrictive)

1. User can consent to apps accessing company data on their behalf No
2. User can consent to apps accessing company data for the groups they own No
3. User can request admin consent to apps they are unable to consent to Yes
4. Add users, groups, or roles that will be responsible to review as highlighted in Reviewer type

  

Change enterprise application -->onsent and Permissions --> User consent settings

-- Change setting highlighted in red as follow to change it to admin consent

1. User consent for applications to Do not allow user consent
2. Group Owner consent for apps accessing data to Don not allow group owner consent