Next section to my SC-300 study guide will cover the following:
- plan for access reviews
- create access reviews for groups and apps
- monitor access review findings
- manage licenses for access reviews
- automate access review management tasks
- configure recurring access reviews
Table of Contents
Where do you create reviews?
Depending on what you want to review, you will create your access review in Azure AD access reviews, Azure AD enterprise apps (in preview), or Azure AD PIM.
|Access rights of users||Reviewers can be||Review created in||Reviewer experience|
|Security group members|
Office group members
|Azure AD access reviews|
Azure AD groups
|Assigned to a connected app||Specified reviewers|
|Azure AD access reviews|
Azure AD enterprise apps (in preview)
|Azure AD role||Specified reviewers|
|Azure AD PIM||Azure portal|
|Azure resource role||Specified reviewers|
|Azure AD PIM||Azure portal|
Guest users and Access reviews
You can find the external users that don’t have any group assignments or other resources with this script.
Then you can create an Access review only for all guest users or to a specific M365 Group.
Creating Access reviews
Note! B2B direct connect (Cross-tenant Access settings) users and teams in shared channels are included in access reviews. B2B direct connect users and teams are not supported in reviews of ‘All Microsoft 365 groups with guest users’.
Scheduled minimum duration is 1 day.
Select reviewers and frequency of the review.
Really useful settings to help reviewer decision is the last sign-in. System recommends reviewers to deny users who have not signed-in within 30 days. Recommendation accounts for both interactive and non-interactive sign-ins.
And the advanced settings.
Additional content means that an email will be sent to reviewers. Best practices are to include context on why users are being asked to do this review and where they should go if they have questions.
Email notification will use Azure AD to send emails to reviewers when an access review starts, and to the review owner when a review completes.
If reminders is enabled, Azure AD will send emails for in-progress access reviews to all reviewers during the midpoint of the review period.
Multi-stage access review (preview)
Why to use?
This feature helps you and your company to create complicated workflows to meet recertification and audit needs that require numerous reviewers to attest to access for users in a certain order. It also aids in the creation of more efficient reviews for your resource owners and auditors by minimizing the amount of decisions that each reviewer is responsible for.
How to configure?
And to reviews page. From here You can add a Multi-stage review up to 3 stages.
You can make the decisions easier with allowing the later approvers to see what other stages answered.
You will also decide who goes to the next stage.
And what happens if reviewers don’t answer.
So at the end You will have these settings.
Enabling Access reviews for Entitlement management
With approvals and reasons
Open Your package, containing the Guest users.
And go to enable Access reviews, remember that we didn’t enable it in the last post.
Yep, we didn’t, then choose Edit
Go to Lifecycle and enable Access reviews
And we can see really familiar settings here.
Action to apply on denied guest users.
The default option removes denied user’s membership from the resource and is the behavior for non-guest users. The second option will block guest users that are denied access from signing-in after the review ends. If the guest users that are blocked are not re-granted access within 30 days, they will be removed from the tenant
How does it look for the end-user?
End-user goes to myaccess.microsoft.com or myapplication.microsoft.com and open Access packages. Then requests access.
They have to fill the required question from access package.
In here you can see the helping decision for last logins.
And approval needs a justification like we specified earlier
Without approval and reasons
When you create Access package without requiring reason or approval, it will be easier for end-users
And the admin will get approval request to Myaccess portal.
Separation of duties (Preview)
Yes, still in preview but wanted to show want it means to you.
Why to use?
Azure AD entitlement management allows you to configure multiple policies with different settings for each user community that needs access through the access package. For example, an employee may only need manager approval to access a particular app, while guests from other organizations may need approval from both sponsors and resource team leaders. A policy for users that are already in the directory allows you to specify a specific set of users who can request access. However, there may be times when you need to prevent users from being overly accessible. To meet this requirement, we need to further limit the users who can request access based on the access that the requester already has.
Scenarios for separation of duties checks
For example, you have an access package, Marketing Campaign, that people across your organization and other organizations can request access to, to work with your organization’s marketing department while that campaign is going on. Since employees in the marketing department should already have access to that marketing campaign material, you don’t want employees in the marketing department to request access to that access package. Or, you may already have a dynamic group, Marketing department employees, with all of the marketing employees in it. You could indicate that the access package is incompatible with the membership of that dynamic group. Then, if a marketing department employee is looking for an access package to request, they couldn’t request access to the Marketing campaign access package.
Similarly, you may have an application with two roles – Western Sales and Eastern Sales – and want to ensure that a user can only have one sales territory at a time. If you have two access packages, one access package Western Territory giving the Western Sales role and the other access package Eastern Territory giving the Eastern Sales role, then you can configure
- the Western Territory access package has the Eastern Territory package as incompatible, and
- the Eastern Territory access package has the Western Territory package as incompatible.
How to use?
Add for Access packages
Or to groups, example a dynamic group with all guest users.
Configure incompatible access packages programmatically
You can also configure the groups and other access packages that are incompatible with access package using Microsoft Graph. A user in an appropriate role with an application that has the delegated EntitlementManagement.ReadWrite.All permission, or an application with that application permission, can call the API to add, remove, and list the incompatible groups and access packages of and access package.
Admin review email
Initial approval email
Reminder of Access review
Once specified time for Access has passed you will get an email notification with users that will be revoked is you do nothing.
My applications portal
User can access the assigned catalogs from myapplications.microsoft.com
And they can request access.
And give justification.
Or extend if their access has ended.
And remove their own access
If they click on the package they will see resources that they have access to.
Who can access reports?
Global Administrator and Global Reader can see all access reviews. All other users are only allowed to see reports on access reviews that they’ve generated.
Generating the report
What is included in a review history report?
The reports provide details on a per-user basis showing the following:
|AccessReviewId||Review object id|
|AccessReviewSeriesId||Object id of the review series, if the review is an instance of a recurring review. If a one-time review, the value will be am empty GUID.|
|ReviewType||Review types include group, application, Azure AD role, Azure role, and access package|
|ResourceDisplayName||Display Name of the resource being reviewed|
|ResourceId||Id of the resource being reviewed|
|ReviewName||Name of the review|
|CreatedDateTime||Creation datetime of the review|
|ReviewStartDate||Start date of the review|
|ReviewEndDate||End date of the review|
|ReviewStatus||Status of the review. For all review statuses, see the access review status table here|
|OwnerId||Reviewer owner ID|
|OwnerName||Reviewer owner name|
|OwnerUPN||Reviewer owner User Principal Name|
|PrincipalId||Id of the principal being reviewed|
|PrincipalName||Name of the principal being reviewed|
|PrincipalUPN||Principal Name of the user being reviewed|
|PrincipalType||Type of the principal. Options include user, group, and service principal|
|ReviewDate||Date of the review|
|ReviewResult||Review results include Deny, Approve, and Not reviewed|
|Justification||Justification for review result provided by reviewer|
|ReviewerUPN||Reviewer User Principal Name|
|ReviewerEmailAddress||Reviewer email address|
|AppliedByName||Name of the user who applied the review result|
|AppliedByUPN||User Principal Name of the user who applied the review result|
|AppliedByEmailAddress||Email address of the user who applied the review result|
|AppliedDate||Date when the review result were applied|
|AccessRecommendation||System recommendations include Approve, Deny, and No Info|
|SubmissionResult||Review result submission status include applied, and not applied.|
A valid Azure AD Premium P2, Enterprise Mobility + Security E5 paid, or trial license is required to use Azure AD access reviews.
Here’s some examples on how many licenses you need.
|Scenario||Calculation||Number of licenses|
|An administrator creates an access review of Group A with 75 users and 1 group owner, and assigns the group owner as the reviewer.||1 license for the group owner as reviewer||1|
|An administrator creates an access review of Group B with 500 users and 3 group owners, and assigns the 3 group owners as reviewers.||3 licenses for each group owner as reviewers||3|
|An administrator creates an access review of Group B with 500 users. Makes it a self-review.||500 licenses for each user as self-reviewers||500|
|An administrator creates an access review of Group C with 50 member users and 25 guest users. Makes it a self-review.||50 licenses for each user as self-reviewers.*||50|
|An administrator creates an access review of Group D with 6 member users and 108 guest users. Makes it a self-review.||6 licenses for each user as self-reviewers. Guest users are billed on a monthly active user (MAU) basis. No additional licenses are required. *||6|
Monitoring could be performed with Azure Monitor, just send those logs to Log analytics instance.
Things to remember
Where do you create reviews?
How to made Access reviews only for Guest users and why?
Decision helpers for reviews.
Users and Admin user Myaccess.microsoft.com to request and approve access.
You can request more info in the review if needed.
Licensing and amount of licenses needed.
Reporting and monitoring