In the second blog of this series, we discussed how Access Reviews in Azure Active Directory (Azure AD) provides a guided review of a group of Microsoft 365 users to help determine if their continued access to tenant resources is required. The third and final tool designed to control and audit access to company resources is Privileged Identity Management (PIM). PIM works synergistically with the other tools to help keep a watchful eye on the collaboration space without impeding productivity.
In Part 3, we’ll discuss PIM in detail. This tool is designed to provide just-in-time escalation of permissions to ensure higher permission levels are only available when needed and can be applied with governance in mind.
Privileged Identity Management
Setting up Privileged Identity Management
PIM is designed to support a “least privileged” model by making granular roles available to users requiring elevated functionality. In addition, users with continuous excessive access are vulnerable in the event their account is compromised, so when not-needed users’ accounts have no extraneous permissions. When needed, a user simply requests elevation into a specific role that has been made available to them. Depending on configuration, the assignment is either automatic or requires approval and/or justification.
The first step in configuring PIM is selecting which roles should be available under which circumstances. This configuration is found under Identity Governance, in the Manage section, by selecting Roles. The Roles screen presents a large list of Roles along with a Description of the Role’s intended usage. The screen will also display how many users are currently Active in a Role and how many users are eligible to be activated in the role.
For example, suppose you want to allow an Administrative Assistant to occasionally reset passwords without involving a tenant Global Administrator. To set this up, click on the Helpdesk Administrator Role in the list, or use the search to filter the list. Selecting this Role will list all current assignments for that Role, including Eligible, Active, and Expired. Pressing the “Add assignments” button will begin the process.
The first screen will show you the Role you have selected, with a link to select member(s) to assign to the role. Pressing the hyperlink under the Select member(s) will bring you to a search for all users within your tenant.
Select the user and press the Select button to add them to the list of members eligible for the Role. Selecting Next navigates to the Settings section, where you determine the Assignment type and durations. Leaving the type Eligible will require the user to request elevation when needed, which is the intention in this case. If you want the assignment to be limited in duration, such as covering an employee who is on leave or vacation, you can set dates for the start and end of the assignment by un-checking Permanently eligible and select dates. Selecting Assign will move that assignment into the Eligible list.
Additional settings can be applied to the Role by selecting the Settings button at the top of the Assignments screen for the Role.
From this screen, there are many configuration options to allow for more granular control of how the escalation process is executed, including approval and notification options.
The first section covers the Activation process itself. Here you can set a maximum duration for the escalation, require Azure MFA, justification, ticket information, or even approval. If requiring approval, you can select who provides the approval from this screen as well.
The next section covers Assignment, where you can decide if permanent Eligible assignments are allowed, permanent Active assignments, and whether justification and/or MFA is required for Active assignments.
The final section provides rich configuration for Notifications to be sent regarding this process. Notifications can be enabled for when members are assigned eligible to the role, when they are assigned as Active to the role, and when eligible members activate the role. This last alert would trigger when escalation has occurred. Each section of notification includes three options: Role activation, Notification to requestor, and request for approval. All of these options are enabled by default, with default recipients being Admin, Requestor/assignee, and Approver. Additional recipients can be added for most notifications.
Requesting Elevation
Once a role is configured to be available, a user can request escalation by going to Azure AD, navigating to the Identity Governance screen, and selecting “Activate Just In Time”. There, they will see all Roles for which they are eligible, and have the opportunity to request being assigned to that role. Pressing Activate will start the process to be added to the role.
Depending on configuration there may be approval and / or justification needed for the assignment to be completed. They can also set a Duration, up to the configured maximum, for how long the assignment should be in effect.
Once completed, they will be in the Active roles section until the duration has been met, or they manually Deactivate the assignment.
Summary
Privileged Identity Management in Azure AD Identity Governance provides just-in-time elevation to targeted roles, helping to protect users’ accounts during normal usage, but providing an easy, governed method of escalating privileges when needed. As with the other facets of Identity Governance, PIM provides a healthy balance of productivity and security within the Microsoft 365 platform.
Need a refresher?
In our first blog of this series, we discussed how entitlement management in Azure Active Directory (Azure AD) Identity Governance creates Access Packages to control the scope and duration of access to groups, applications, and SharePoint sites. The two additional primary tools designed to control and audit access to company resources include Access Reviews and Privileged Identity Management. These three functions work synergistically to help keep a watchful eye on the collaboration space without impeding productivity.
In Part 2, we’ll discuss Access Reviews in detail. These are about auditing access to ensure previously-granted permissions are still appropriate and necessary.
Access Reviews
Setting up an Access Review
An Access Review is a scheduled, guided review of a group of Microsoft 365 users to help determine if their continued access to tenant resources is required. The review can be performed by multiple users and can be set to report on dispositions and, in some cases, automatically take action based on the dispositions set.
The first step of creating an Access Review is naming and describing its purpose. You will also set a start date and frequency if the intention is to perform the review periodically. Frequencies include weekly, monthly, quarterly, semi-annually, and annually. Occurrences can run indefinitely or can end by a specified date or after a number of occurrences. The review will also have an end date, after which the review will close and the “upon completion settings” will be applied.
Next, you determine who will be reviewed and who will be performing the review. The users to review can be Members of a Group or users Assigned to an Application on the tenant. Additionally, you can scope the review to include Guest users only or include all users. For Reviewers, you can select the Group’s owners, specific tenant users, or allow for self-review by the users. You can also associate the review with a Program (similar in concept to a Catalog for Access Packages) or choose the Default Program.
Next, we’ll set the “Upon completion settings,” which determine the action to take when the end date of the review is reached. The first choice is whether or not you’d like to auto-apply the results. With this setting enabled, any user whose disposition is to Deny access will automatically have their access removed upon the completion of the review. The second option is to determine what actions to take if reviewers don’t respond. These options include “No change,” “Remove access,” “Approve access,” or “Take recommendations.” The last option is based on Azure AD’s auto-set recommendations, which are primarily based on the last time the reviewed user utilized the system.
The final settings, under Advanced, include options to Show recommendations, Require a reason on approval, Mail notifications, and send Reminders to reviewers. All are currently enabled by default.
At this point, we are ready to start the review process. After pressing the Start button, the new Access Review will be added to the Access Reviews section within the Identity Governance module. The listing will include the name, the resource being reviewed, the status, and when it was created.
Clicking on the review will show an overview of the settings as well as a chart showing the status of the resources being reviewed. There are also pages to view the Results and the Reviewers. You can even send automated reminders for individual reviewers with the press of a button.
Performing a User Access Review
If the Mail Notifications option was set to Enabled, reviewers should receive an email with a link to begin their review. The email will have a hyperlinked button to take the user directly to the review page.
The Review page will show all relevant information, including who requested the review, when it is due by, the names of any other reviewers, and the progress made so far. It will also list each Resource being reviewed with their name, email address, Access Info (statement about whether they have recently logged in), and a recommended Action.
This list of users can be filtered based on Status (Reviewed, Not Yet Reviewed, All), Recommendation (Approve, Deny, All), or Action (Approved, Denied, Don’t Know, All). The reviewer can click on a single source to review or multi-select resources using the checkboxes, then press the “Review n user(s)” button. Reviewing resources opens a dialog with options for the disposition and comments. Actions can be Approve, Deny, or Don’t Know. The recommended action will be highlighted already. Don’t Know is useful if there are other reviewers who may have more insight or knowledge of the resource being reviewed.
Although all Resources may have been reviewed, the Access Review will stay open until its end date has been reached to allow for changes or other reviewers to provide input. If desired, a review can be manually stopped so action can be taken. This can be done by the user who originally set up the review using the Access Review overview screen. At that time, the actions will be automatically applied if the “Upon completion” setting’s “auto apply results to resource” is enabled, or the Apply Results button can be pressed if not.
The results of the review can be reviewed in the Results section of the Access Review.
Summary
Access Reviews in Azure AD Identity Governance provide a simple, consistent, and governed method of reviewing and controlling access to company tenant resources. By combining Access Reviews with Access Packages, administrators can tightly control who has access to which resources and ensure they retain the appropriate access only as long as required, all while maintaining agility and simplicity for users.
Next up: Privileged Identity Management. Configure just-in-time role escalation to implement a least-privileged security model for day-to-day operations while providing a rapid but governed path to escalated roles as required. Stay tuned!
How Azure Active Directory (Azure AD) Identity Governance can assist your organization in responding quickly to new collaboration needs while maintaining security and governance.
The sudden onset of the COVID-19 pandemic sent much of the world into a frenzy. With businesses concerned for the safety and wellbeing of their employees and customers, and many governments strongly advising social distancing, the need to ramp-up the remote workforce went from a distant goal to a top priority almost overnight. One of the many groups greatly impacted by this new priority is the group of people responsible for collaboration platforms such as Microsoft 365. The need to quickly enable remote workers has made it seem necessary for many groups to ignore or postpone best practices and security considerations in favor of business continuity. Azure AD’s Identity Governance is one set of tools designed to help strike the balance between security and productivity, enabling quick turnaround on required resources while providing checks and balances to mitigate risk.
What is Azure AD Identity Governance?
Simply put, Azure AD Identity Governance is about “ensuring the right people have the right access at the right time.” More specifically, it is a set of 3 primary tools designed to control and audit access to company resources.
Entitlement Management is about creating Access Packages to control the scope and duration of access to groups, applications, and SharePoint sites.
Access Reviews are about auditing access to ensure previously granted permissions are still appropriate and necessary.
Privileged Identity Management covers the just-in-time elevation of tightly scoped roles to allow users to perform privileged operations when needed while maintaining lower permission levels during their day-to-day job functions.
These three functions work synergistically to help keep a watchful eye on the collaboration space without impeding productivity. Part 1 of this series will cover Entitlement Management in detail.
Entitlement Management
Setting up an Access Package
The key component of Entitlement Management is the creation of “Access Packages”. An Access Package is a collection of resources that users can be granted or request access to. Unlike simply adding users directly to Groups, these packages can control the duration, approval process, and periodic reviews of those assignments.
The first step of creating an Access Package is naming and describing its purpose. You can also create “Catalogs” to group multiple packages and delegate the administration of them to the appropriate users.
Next, you determine the Resource Roles that will be part of this package. It can be a combination of Groups/Teams, Applications, and SharePoint sites. In this case, we will grant access to the “COVID-19 Response Team” team in the Member role.
We’ll then move onto the Request process. Since this team may be made up of external collaborators who are unknown at this time, we’ll select “For users not in your directory”, and we’ll allow “All users (All connected organizations + any new external users)” to request access.
Since we are allowing as of yet unknown external users, we must require approval (other settings allow you to disable approval). We will set a specific user to provide approval, ensure a decision is made within 2 days, and force both the requestor and the approver to provide a justification for the access. We’ll enable this access request when we are ready to start requesting access.
Next, we will set the lifecycle of the access being provided. In this case, we will allow for 30 days of access, with the ability to request an extension (which also requires approval). If this was a longer duration or did not expire, we could also tie access to an Access Review, which we’ll cover later.
The last page will show a summary of all the choices to allow you to make any desired changes before creating the package.
Once the package is created, the browser will display a list of all Access Packages the current user has access to. From here, you can use the ellipsis to copy the link used to request access. This link can be emailed, put on a public site, or shared in any other traditional way.
Requesting Access
To request access via an Access Package, a user can use the link generated during the creation process. Once they sign in to the 365 tenant, they will be presented details of the access being requested. The user would then select the package and push the “request access” button.
From there, because we require justification, the user will be presented an area to provide the reason they are requesting access.
They will receive confirmation that their request was submitted.
Approving Access
After requesting access, the Approver will receive an Email with actions to Approve or Deny the request, and a summary of the information about the request.
Pressing the Approve or deny request button takes you to an Approvals page where you can approve or deny and provide the required justification.
Now that the request has been approved, the user should have access to the Team as a Member. When the expiration date is reached in 30 days, that access will be revoked unless an extension is requested.
Summary
Entitlement Management using Access Packages is a great way to govern access to resources such as Teams, SharePoint sites, and Applications, especially when external users are involved or the context of the access is limited to a specific timeframe. Users can request access as needed, owners can be empowered to grant access on demand, and removal of access can be automated to prevent lingering exposure of company information.
Next up: Access Reviews
Configure periodic, guided reviews of access to resources with suggestions based on login activity and automated resolution based on dispositions.
Secure Score metrics are an important guideline used to ensure security and performance across your Office 365 tenant. Secure Score analyzes your Office 365 organization’s security based on your regular activities and security settings and assigns a score. Think of it as a credit score for security.
A few tasks in the Secure Score toolbox are repeated tasks of reviewing certain logs within Office 365 and Azure. These tasks are typically repeated on a weekly or monthly basis. In this article, we will discuss how to automate a couple of these review tasks. By the end of this article, you should have a good understanding of how Azure Automation is used and how you can continue to use it to help streamline your Secure Score efforts.
Creating an Automation Application
Our first step in the process is to create an Azure Automation application.
Navigate to your Azure portal (https://portal.azure.com), click on “Create a resource”, search for “Automation” and click on “Create”.
Please note that provisioning a Microsoft Bot, Azure Active Directory Application, App Service, and other Azure resources will result in associated costs. In order to fully understand the associated costs that may incur from following this guide, please refer to the Azure Pricing Calculator which can be found here.
In the configuration menu, give the Automation Account a Name, select the appropriate Subscription based on your tenant, select “Create New” or “Use Existing” Resource group, and then select the appropriate Location. The last option to “Create Azure Run As account” is not necessary in this guide but is something you may want to utilize in the future, so we can leave this set to “Yes”. This account can be used to automate Azure specific functions. These are functions that you can run within the Azure CLI (not functions such as Exchange/MSOL commands). When finished, click on “Create” to create all the required resources.
When all resources have finished provisioning, click on the “Go To Resource” button in the notifications area to go to our new Automation resource or search for it in your resources list.
Once there, navigate to “Runbooks” in the “Process Automation” section.
By default, these resources are provisioned with example runbooks. The runbooks here are using the various methods of creating an automated function such as Python, PowerShell, and the Graphical Interface provided by Microsoft. We can ignore all of these examples, but feel free to look at them later on as they provide a good insight into everything we can do with Azure Automation.
Creating Our Runbook
While still in the Runbook section, click on the “Add Runbook” button.
In the new menu that appears, click on “Quick Create”. You will need to fill in two values here: the Name of the runbook and the platform or Runbook Type in which we will build it. Type in the name of the runbook that you would like, and select PowerShell as the Runbook type.
Before we jump into the code of the runbook, we need to set up the credentials that we will use for automation. The account that we use will need to be an Exchange Administrator, have the Discovery Management role in Exchange, and not have MFA configured on the account (unfortunately, there is no way to handle this automation on an account with MFA just yet, but this may change in the future). We recommend provisioning an Azure Service Account that you can use for this functionality. This will ensure that you don’t have an overly provisioned account that is currently being used for other things in your tenant.
In the Automation Resource section, scroll down to the Shared Resources section and click on “Credentials”.
Once there, click on “Add a Credential” and fill in all of the required fields. The name of this can be whatever you’d like it to be. This will be used to reference this set of credentials within the code. The username and password should be one with the roles defined above and should follow standard login standards for Office 365 such as joesmith@contoso.com.
Coding our Azure Automation Runbook
Navigate back to the runbook you created earlier.
Once there, click on the “Edit” button to edit the code within.
Our first step is to grab the set of credentials we stored in our application earlier. To do so, use the dropdown on the left-hand side for “Assets”, click on “Credentials”, and you should see the credential object you created.
Use the … menu to “Add to Canvas”. This should then give you the PowerShell needed to pull the Credential object. We will also store this as a variable as shown below.
In this article, we will be covering how to automate two Review processes in the Secure Score toolbox. These are mailbox auditing and mailbox forwarding rules. Mailbox auditing needs to be automated as it will only affect users currently in your system. Any users added after this command is run will not have Mailbox Auditing enabled and therefore you will receive no points on Secure Score. The review of Mailbox Forwarding rules is something done weekly, and with this process automated you should always receive the Secure Score points for this task. We will first need to connect our runbook to the necessary areas of Office 365. These will be the ExchangeOnline and MsolService connect prompts. I will be posting the remainder of the code required for this runbook below and will break down what each piece is doing afterwards.
#Connect to Azure Automation
$Credentials = Get-AutomationPSCredential -Name ‘AutomationCredentialsSecureScore’
#Connect-MsolService -Credential $Credentials
The first function exists to connect to Exchange Online Management via PowerShell. As we are looking to take care of the Mailbox Auditing as well as Mailbox Forwarding, we give it the commands you see in the $Commands array. We specify the commands for performance reasons as there is no reason to load every single Exchange Admin command here. The next few lines utilize this function as well as the standard Connect-MsolService command to connect to both services using the credentials object we grabbed earlier. Once connected, we first take care of mailbox auditing.
The code between lines 22 and 29 are set up to take care of Mailbox Auditing. These lines will loop through all users in the tenant that do not currently have Mailbox Auditing configured and setup auditing on them with a time frame of 365 days.
Next, we take care of compiling all forwarding rules that are reviewed within Secure Score. Lines 31 to 47 take care of this task and store all User Inbox Rules, User Delegates and SMTP Forwarding rules inside variables we use next. Lines 49 to 87 serve the primary purpose of reporting. These lines are set up to utilize the Send-MailMessage function to send out an email to whomever you specify (group or single user) for them to review everything this script has done. The content of the email will be all users (if any) that now have Mailbox Auditing configured that did not have it before. In addition, it will send three attachments which are the output of all User Inbox Rules, User Delegates and SMTP Forwarding we stored earlier. Once the code has been implemented, publish the current revision and we are ready to set up our schedule for this runbook.
Scheduling our Runbook
Navigate to the overview of the current runbook we have been working on. Scroll down to the “Resources” section and click on “Schedules”. From here, click on “Add a schedule” to implement a schedule for this runbook.
Once here, click on “Link a schedule to your runbook”, then on “Create a new schedule” and finally fill in all required fields. We will want this runbook to run weekly, so set up a time in the future that you’d like to start the schedule on, select “Recurring” and have it repeat once each week on the day of your choosing. For the foreseeable future, we won’t want this expire so leave the “Set expiration” option to “No”.
Once this has been completed, the setup of your Azure Automation resource and its runbook will run once a week, take care of a couple of your Secure Score review tasks automatically, and email your administration the report for review.