In this blog post I will go through the process of enabling a user sign-in and user risk policy within Azure Identity Protection located within the Azure Portal.
Risk detections in Azure AD Identity Protection include any identified suspicious actions related to user accounts in the directory.
User risk policy With the user risk policy turned on, Azure Active Directory detects the probability that a user account has been compromised. As an administrator, you can configure a user risk conditional access policy to automatically respond to a specific user risk level. For example, you can block access to your resources or require a password change to get a user account back into a clean state.
Identity Protection categorises risk into three tiers: low, medium, and high. While Microsoft does not provide specific details about how risk is calculated, Microsoft say that each level brings higher confidence that the user or sign-in is compromised. For example, something like one instance of unfamiliar sign-in properties for a user might not be as threatening as leaked credentials for another user.
User sign-in policy Turning on the sign-in risk policy ensures that suspicious sign-ins are challenged for multi-factor authentication (MFA). Note that if MFA is not enabled for the user, access will be blocked.
Note: to make use of these features every user that benefits or is affected from a feature exclusive to the Azure AD P2 offerings needs a Azure AD P2 licence or a licence including Azure AD P2, for example 365 E5 – Source: Microsoft
Login to your Azure Portal (portal.azure.com
Search and click Azure AD Identity Protection
3. Below is a screenshot displaying both user risk policy and sign-in risk policies We’ll start with user risk policy
4. Click user risk policy and below are the parameters available
5. Click all users and below I can apply this policy to all users or target individuals or groups.
I can also exclude users or groups as shown in the screenshot below
Note: exclusions over ride inclusions, so if a user is in two groups, one excluded and the other included, the excluded will policy will take priority.
For the purpose of this demo, I will be leaving the default of all users
6. Next, move onto user risk which assesses the likelihood that the user account is compromised.
7. The below risks (High, Medium and above, low and above) are based on a Microsoft Algorithm. While Microsoft does not provide specific details about how risk is calculated, they say that each level brings higher confidence that the user or sign-in is compromised. For example, something like one instance of unfamiliar sign-in properties for a user might not be as threatening as leaked credentials for another user. For common questions, visit the following Microsoft article – Common Questions
I’ll be setting the user risk as High so I’m going to be looking for something that has been flagged as a high risk which means there is an account which has highly likely been compromised. Click Done
8. Next, I move onto Access located under Controls
9. Here is where we configure the action if the condition is met. For the purpose of this demo, I will click Allow access but will force the user to change the password. You could also block the user when a high risk is identified. Click done
10. Select On and click save
11. That’s the user risk policy set
Let’s move onto Sign-in Risk Policy
Click Sign-in risk policy
2. I’ll be leaving the default setting to apply the policy to all users
3. Next I click on Sign-in risk which is based on the likelihood that the sign-in is coming from someone else other than the user.
4. I set this to high and click done
5. Click access located under Controls
6. I click allow but the user will be forced to perform multi-factor authentication, click done
Note: If multi-factor is not configured for the user, the user will be blocked
7. Finally, I turn on the policy and click save
That’s both policies configured
To view risk alerts, click the options located under Report in the menu located towards the left.
Further down the menu, we have notify on users at risk detected alerts and weekly digest. Users in the Global administrator, Security administrator, or Security reader roles are automatically added to this list if that user has a valid email or alternate email configured. Microsoft attempt to send emails to the first 20 members of each role. If a user is enrolled in PIM to elevate to one of these roles on demand then they will only receive emails if they are elevated at the time the email is sent.
By default admins are alerted based on high risk alerts as shown below
In this blog post I will go through the process of preventing users in your organisation from allowing third party apps to access their Office 365 information, and require future consent operations to be performed by an administrator.
This is a recommended Microsoft action and you may come across an alert within the secure score section of your Azure Portal. The message is as follows:
Tighten the security of your services by regulating the access of third-party integrated apps. Only allow access to necessary apps that support robust security controls. Third-party applications are not created by Microsoft, so there is a possibility they could be used for malicious purposes like exfiltrating data from your tenancy. Attackers can maintain persistent access to your services through these integrated apps, without relying on compromised accounts. Policy in place: false.
Login to your Azure Portal (portal.azure.com)
Locate and click Azure Active Directory
Click Enterprise applications
4. Click User Settings
5. Switch Users can consent to apps accessing company data on their behalf to No
Users can consent to apps accessing company data on their behalf If this option is set to yes, then users may consent to allow applications which are not published by Microsoft to access your organisation’s data, if the user also has access to the data. This also means that the users will see these apps on their Access Panels. If this option is set to no, then admins must consent to these applications before users may use them.
6. After selecting No, the following message appears with instructions on managing LinkedIn account connections if required.
There is also a further warning that users can still consent to apps accessing the groups they own. I’ll cover this in step 7 below.
7. Further down you may also wish to disable Users can consent to apps accessing company data for the groups they own or limit to a certain group as show in the second screenshot below
Users can consent to apps accessing company data for the groups they own If this option is set to yes, then all users who are owners of a group may consent to allow third-party multi-tenant applications to access the data of the groups they own.If this option is set to no, then no user can consent to those application to access the data of the groups they own.If this option is set to limited, then only the members of the group selected can consent to those applications to access the data of the groups they own.
8. After disabling user access, you may wish to setup Admin consent. If this option is set to yes, then users request admin consent to any app that requires access to data they do not have the permission to grant. If this option is set to no, then users must contact their admin to request to consent in order to use the apps they need.
Users can request admin consent to apps they are unable to consent to: If this option is set to yes, then users request admin consent to any app that requires access to data they do not have the permission to grant. If this option is set to no, then users must contact their admin to request to consent in order to use the apps they need.
Select users to review admin consent: The selected users can review and act on new admin consent requests. Only users with the Global, Application, or Cloud application administrator role can grant admin consent, so only those users will be available for selection. Removing a user from the list of reviewers will not remove their role, so they will retain their admin privileges until their role is explicitly changed.
9. When ready, don’t forget to click the save button
Privileged Identity Management (PIM) is a service in Azure Active Directory (Azure AD) that enables you to manage, control, and monitor access to important resources in your organisation.
Privileged Identity Management provides time based and approval based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources that you care about. Here are some of the key features of Privileged Identity Management:
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
Azure AD Premium P2 or Enterprise Mobility + Security (EMS) E5
Ensure that your directory has at least as many Azure AD Premium P2 licenses as you have 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.
It can become confusing when working out the number of Azure AD P2 licences required so Microsoft have provided examples at the following link: Azure PIM Example Licence Scenarios
In this blog post I will go through the process of configuring Azure AD Roles in Privileged Identity Management (PIM). I will grant a user named Joe Bloggs eligible assignment for one of my Azure admin roles.
As mentioned above, to use PIM you must have an Azure AD P2 or Enterprise Mobility + Security (EMS) E5 licence. I currently have access to an E3 license which grants me access to an Azure AD P1 licence which is obviously not sufficient.
If you already have access to Azure AD P2, skip to the next section by scrolling down to section Configuring Azure Privileged Identity Management (PIM)
Firstly, I will sign up to a free 90 day Enterprise Mobility + Security (EMS) E5 trial account. As you can see from the screenshot below my licence assignment is currently Azure AD Premium P1.
and if I attempt to access PIM, I receive the message below
Microsoft offer trials for a number of their products including Azure AD P2 which will allow you to test Azure PIM. I’ll start with activating a free trial which can be ready within minutes as you’ll find out shortly.
2. Access Azure AD, click Licenses, click All products and click the + Try / Buy button as highlighted below
3. Enterprise Mobility + Security E5 includes Azure AD P2 and Microsoft offer a 90 day trial so I selected this option. I’ll be going through further demo’s at a later date which require Enterprise Mobility + Security E5 so this licence will be useful.
4. Click Free Trial under the licence you wish to activate. In my case I clicked Free trial under Enterprise Mobility + Security E5
5. Click Activate
6. Wait for the product to activate which should take seconds
7. After activation my licence status still shows as Azure AD P1
8. Log out of the portal and back in and the correct version is now displayed
That’s the free trial sorted
Configuring Azure AD Roles – Azure Privileged Identity Management (PIM)
Log into the Azure Portal (portal.azure.com)
Search PIM and select Azure AD Privileged Identity Management
3. Click Azure AD roles
4. Click Assignments
5. I don’t have any assignments at the moment, click +Add Assignments
6. Select a role and member
For the purpose of this demo, I have selected the role Global Administrator and selected an existing user named Joe Bloggs from my directory. Click Next
7. For the purpose of this demo, I will select Eligible and leave the default at permanently eligible.
Eligible A role assignment that requires a user to perform one or more actions to use the role. If a user has been made eligible for a role, that means they can activate the role when they need to perform privileged tasks. There’s no difference in the access given to someone with a permanent versus an eligible role assignment. An eligible administrator can activate the role when they need it, and then their permissions expire at a set time, until the next time the role is activated. The only difference is that some people don’t need that access all the time. So in my case, Joe Bloggs will be eligible which means he will request access each time he requires access to the Global Administrator role (Default limit for 8 hours and his permissions will be removed until he activates again). Permanently eligible which means he will be allowed to continue to activate the role when he needs to perform privileged tasks. A permanently eligible end date can be configured, for example, users can activate access for 8 hours at a time for up to 1 year instead of being able to activate the role continuously without an end date. I’ll cover more on this as we move on.
Active: This is a role assignment that doesn’t require a user to perform any action to use the role. Users assigned as active have the privileges assigned to the role at all times but can be setup so access is removed at a certain date.
Continuing with Active Assignment, this options provides a user with permanent access or up to a date set by the administrator. See screenshot below. In this case, the user will have access to the role assigned permanently or by a set expiry date. A further text box appears as shown below requesting a justification on why the admin is granting the user with an active assignment.
8. For the purpose of this demo, I have selected eligible. Click Assign when ready
9. Now that Joe Bloggs has been granted an eligible assignment, I will log in as Joe Bloggs and demonstrate what Joe Bloggs will see.
10. When logging in as Joe Bloggs, I am prompted to enable MFA.
11. MFA configured, I can now move on to logging in as Joe Bloggs. Now that I am logged in, Joe Bloggs is still a basic user without global admin permissions, which is normal. He can’t create accounts within Azure AD or perform any other administrative tasks which require elevated permissions. Access is disabled.
12. Joe Bloggs will need to activate his eligible assignment within PIM. Whilst still logged in as Joe Bloggs, I search for PIM and click Azure AD Privileged Identity Management
13. Click My roles
14. The eligible assignment is displayed with an Activate link as shown below. Click Activate
If the user skipped MFA at the initial logon stage, as shown in the screenshot below, the user will be prompted to authorise via MFA which is enforced by a default enabled setting within PIM. I’ll explain where this option is found shortly. If you wish to disable the below 14 day reminder, you can have a read of the following link later – Disable Skip MFA prompt
15. After clicking activate, Joe Bloggs receives the below prompt
Duration: maximum of 8 hours access. After the 8 hours, Joe Bloggs access will be revoked and he will have to activate his assignment again. Joe Bloggs was allowed permanent eligibility which allows him to activate his eligible assignment when required.
Custom activation: If Joe Bloggs requires admin access in the future, he could select the option Custom activation start time and select a date and time he would like his 8 hours access to begin. In the example below, I have configured the time for a time in the past.
16. When ready, click activate
17. Activation has been scheduled
If I check access from my account, i’ll find that Joes Bloggs has been granted access without any further action required from me
From here you could also cancel Joe Bloggs access by clicking the Cancel link
That’s the default settings but what if you wish to increase the default 8 hour access limit? Or you would like for the request to go to a team of approvers for review before Joe Bloggs is granted access? or you require 8 hours access for the Global Administrator role but 10 hours access for the Exchange Administrator role. Let’s move onto where these settings are configured.
Configuring Azure AD Privileged Identity Management Azure AD role settings
Click Azure AD Privileged Identity Management
2. Click Azure AD roles
3. Click Settings
4. Here you can apply different configuration settings based on roles. For the purpose of this demo, I will be configuring the Global Administrator role.
5. After clicking the Global Administrator Role, you’ll find the below settings. Review and click Edit
6. The first windows displays a number of settings including the default 8 hour access. You can extend this to 24 hours if required
Azure MFA is enabled by default, which enforces MFA while activating the assignment.
Require justification: requests a reason why the user requires access
Require ticket information: you may have a process where the user requiring access needs to input a ticket or change number
Require approval to activate: this feature is an important one. Setting approvers adds an additional check before a users assignment is activated. The request goes into a pending approval list after the user activates the assignment which allows a approver to review access and deny or approve access accordingly.
Note: each approver will need to be assigned an Azure AD P2 licence
To allow me to demo the approval process, I have enabled require approval to activate and added a single user as an approver.
Before I move on and demo the approval process, clicking the assignments button moves us onto the next screen below. You may wish to leave the defaults or set an expiry. For example, you could configure the below policy so that users will be eligible to elevate their account into the role assigned for one year instead of being eligible forever. The same applies for the active role.
Finally, the next screen is where you can configure email notifications
7. When ready, click the update button. Note the below fields which can be useful.
We can now move on and test the approval process.
Azure AD PIM Approval demo
I granted Joe Bloggs an eligible assignment earlier. The new settings I configured above will apply to Joe on his next eligible assignment activation.
I log in as Joe Bloggs
Click Azure PIM
Click My Roles
Click Activate
6. Type in justification details and click activate
7. After clicking activate, Joe Bloggs is not granted access immediately. His request is pending approval as shown below
8. The admin allocated as a approver earlier must review the request and decide whether to approve or deny access. Back over to my account where I will review Joe Bloggs access. I will also receive an email to notify me that there is a request pending.
Access PIM > Azure AD Roles > Approve requests
9. Here is the pending request where I can review each case.
Note: Clicking approve or deny opens the window below allowing you review the details fully without having to expand the tabs above. A justification needs to be provided.
10. And Joes Bloggs access is approved. He will be granted access for 8 hours and does not need to take any further action to activate the role.
A complete audit of all actions carried out in PIM Azure AD Roles can also be located at: PIM > Azure AD Roles > Audit
Using Azure Active Directory (Azure AD) Privileged Identity Management (PIM), you can also improve the protection of your Azure resources and as you can see below Privileged access groups which was in preview at the time of writing this post.
Azure PIM also offers Access Reviews. Access to privileged Azure resource roles for employees changes over time. To reduce the risk associated with stale role assignments, you should regularly review access. You can use Azure Active Directory (Azure AD) Privileged Identity Management (PIM) to create access reviews for privileged Azure resource roles. You can also configure recurring access reviews that occur automatically. I will cover these topics in a further post.
Note: Azure AD P2 licences are required within your directory for users assigned to an access review and users who perform access reviews.
Feedback welcome, please comment below. It would also be great to hear about your experience using Azure PIM.
In this blog post I will go through the process of configuring an alert within the Microsoft 365 Compliance portal which will trigger an email whenever permissions are assigned to a mailbox.
From the 365 Admin Center locate and click Compliance or visit the Compliance Admin Center directly via Security & Compliance (compliance.microsoft.com)
2. Click Policies
3. Expand Alert and click Office 365 alert
4. Click New Alert Policy
5. Complete details as required (Demo info below). Click Next
6. There are a number of activities to choose from. For the purpose of this demo, I have selected Granted Mailbox Permission
7. You could also add a condition based on IP address and username. For example, if you want to be alerted when a particular group of users assign permissions, you can do so here. Ignore the conditions box if you would like an alert to be triggered when any user in the organisation performs the action.
8. Click next and select your notification groups or emails. Click Next, review settings and click finish
Dynamic group memberships reduce the administrative overhead of adding and removing users from a group as the process is automated and driven by attribute changes. For example, a user with a department attribute of Sales within AD could be automatically added to a dynamic group named Sales, and removed automatically if the user moved roles. For example, the user department attribute in AD was amended from Sales to Marketing. In this case, the user would be automatically removed from the Sales group and moved to the Marketing group if a dynamic group existed for Marketing.
In this blog post I will go through the process of creating a dynamic group within Azure AD and add a dynamic query/condition so staff from Sales UK are automatically added to a dynamic group.
Access Azure AD
Click Groups located in the left pane
3. Click + New group
4. Complete the fields for your group (Example below)
Group Type: Security Group Name: CloudBuild_Sales Group Description: Dynamic group for staff working in Sales UK Membership Type: Dynamic User Owner: I have assigned myself as an owner
The next step involved adding a dynamic query
5. Click Add dynamic query
6. Input details for your query, see example below
Property: department (This is the field located within the users Azure AD account properties) Operator: Equals Value: Sales UK (I want all users with a department of Sales UK to be added into my new dynamic group)
7. Click save
8. Click create
The result, all users with Sales UK included within the department field will automatically be added to your dynamic group. When the department field is changed, such as, the user moves departments, the process will automatically remove the user from the dynamic group.
Notes:
1. You can not manually add or remove a member of a dynamic group
2. You can create a dynamic group for devices or for users, but you can’t create a rule that contains both users and devices
3. This feature requires an Azure AD Premium P1 licence for each unique user that is a member of one or more dynamic groups. You don’t have to assign licences to users for them to be members of dynamic groups, but you must have the minimum number of licenses in the Azure AD organisation to cover all such users. For example, if you had a total of 300 unique users in all dynamic groups in your organisation, you would need at least 300 licences for Azure AD Premium P1 to meet the licence requirement. No licence is required for devices that are members of a dynamic device group.
Subscribe
Subscribe to new tech posts.
We will never send you spam email or forward your details to third parties.
This will close in 0 seconds
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
