Security boundaries are often thought of as firewalls, IPS/IDS systems, or routers. Also, logical setups such as DMZs or other network constructs are often referred to as boundaries.
But in the modern world, where many companies support dynamic work models that allow you to bring your own device (BYOD) or are heavily using online services for their work, the real boundary is the identity.
Today’s tutorial is an excerpt taken from the book, Implementing Azure Solutions written by Florian Klaffenbach, Jan-Henrik Damaschke, and Oliver Michalski. In this book, you will learn how to secure a newly deployed Azure Active Directory and also learn how Azure Active Directory Synchronization could be implemented.
In this post, you will learn how to secure identities on Microsoft Azure.
Identities are often the target of hackers as they resell them or use them to steal information. To make the attacks as hard as possible, it’s important to have a well-conceived and centralized identity management. The Azure Active Directory provides that and a lot more to support your security strategy and simplify complex matters such as monitoring of privileged accounts or authentication attacks.
Azure Active Directory
Azure Active Directory (AAD) is a very important service that many other services are based on. It’s not a directory service like many may think of when they hear the name Active Directory. The AAD is a complex structure without built-in Organizational Units (OUs) or Group Policy Objects (GPOs), but with a very high extensibility, open web standards for authorization and authentication, and a modern, (hybrid) cloud-focused approach to identity management.
Azure Active Directory editions
The following table describes the differences between the four Azure Active Directory editions:
| Services | Common | Basic | Premium P1 | Premium P2 |
| Directory Objects | X | X | X | X |
| User/Group Management (add/update/delete)/ User-based provisioning, Device registration | X | X | X | X |
| Single Sign-On (SSO) | X | X | X | X |
| Self-Service Password Change for cloud users | X | X | X | X |
| Connect (Sync engine that extends on-premises directories to Azure Active Directory) | X | X | X | X |
| Security/Usage Reports | X | X | X | X |
| Group-based access management/ provisioning | X | X | X | |
| Self-Service Password Reset for cloud users | X | X | X | |
| Company Branding (Logon Pages/Access Panel customization) | X | X | X | |
| Application Proxy | X | X | X | |
| SLA 99.9% | X | X | X | |
| Self-Service Group and app Management/Self-Service application additions/Dynamic Groups | X | X | ||
| Self-Service Password Reset/Change/Unlock with on-premises write-back | X | X | ||
| Multi-factor authentication (Cloud and On-premises (MFA Server)) | X | X | ||
| MIM CAL + MIM Server | X | X | ||
| Cloud App Discovery | X | X | ||
| Connect Health | X | X | ||
| Automatic password rollover for group accounts | X | X | ||
| Identity Protection | X | |||
| Privileged Identity Management | X |
Overview of Azure Active Directory editions
Privileged Identity Management
With the help of Azure AD Privileged Identity Management (PIM), the user can access various capabilities. These include the ability to view which users are Azure AD administrators and the possibility to enable administrative services on demand such as Office 365 or Intune. Furthermore, the user is able to receive reports about changes in administrator assignments or administrator access history.
The AAD PIM allows the user to monitor the access in the organization. Additionally, it is possible to manage and control the access. Resources in Azure AD and services such as Office 365 or Microsoft Intune can be accessed.
Lastly, the user can get alerts, if accesses to privileged roles are granted. Let’s take a look at the PIM dashboard. To use Azure PIM, it needs to be activated first:
- Azure AD PIM should be found in the search easily:
Azure AD PIM in the marketplace
- After clicking on Azure AD PIM in the marketplace, PIM will probably ask you to re-verify MFA for security reasons. To do this, the MFA token needs to be typed in, after clicking on Verify my identity:
Re-verify identity for Azure AD PIM setup
- After a successful verification you will get an output as illustrated here:
Successful re-verification
Now the initial setup will start. The setup guides the user through the task of choosing all accounts in the tenant that have privileged rights. It is also possible to select them if they are eligible for requesting privileged role rights.
- If the wizard is completed without choosing any roles or user as eligible, it will by default assign the security administrator and privileged role administrator roles to the first user that does the PIM setup. Only with these roles it is possible to manage other privileged accounts and make them eligible or grant them rights:
Setup wizard for Azure AD PIM
- In the following screenshot the tasks related to Privileged Identity Management are illustrated:
Azure AD PIM main tasks
- As my subscription looks very boring after enabling Azure AD PIM I chose to show a demo picture from Microsoft that shows how Azure AD PIM could look in a real-world subscription:
Azure AD PIM dashboard
(https://docs.microsoft.com/en-us/azure/active-directory/media/active-directory-privileged-identity-management-configure/pim_dash.png)
- It’s now possible to manage all chosen eligible privileged accounts and roles through Azure AD PIM. Besides removing and adding eligible users to Azure AD PIM, there is also a management of privileged roles, where the role activation setting is available. This setting is used to make privileged roles more transparent, trackable, and to implement the just-in-time (JIT) administration model. This is the activation setting blade for the Security Administrator:
Role activation settings for the role Security Administrator
It’s also possible to use the rich monitoring and auditing capabilities of Azure AD PIM and never to lose track of the use of privileged accounts and to track misuse easily.
Azure AD PIM is a very useful security feature and it is even more useful in combination with Azure AD Identity Protection.
Identity protection
Azure AD identity is a service that provides a central dashboard that informs administrators about potential threats to the organizations identities. It is based on behavioral analysis and it provides an overview of risks levels and vulnerabilities.
The Azure AD anomaly detection capabilities are used by Azure AD Identity Protection to report suspicious activities. These enable one to identify anomalies of the organization’s identity in real time, making it more powerful than the regular reporting capabilities. This system will calculate a user’s risk level for each account, giving you the ability to configure risk-based policies in order to automatically protect the identities of your organization. Employing these risk-based policies among other conditional access controls provided by AAD and EMS enables an organization to provide remediation actions or block access to certain accounts.
The key capabilities of Azure Identity Protection can be grouped into two phases.
Detection of vulnerabilities and potential risky accounts
This phase is basically about automatically classifying suspicious sign-in or user activity. It uses user-defined sign-in risk and user risk policies. These policies are described later.
Another feature of this part is the automatic security recommendations (vulnerabilities) based on Azure provided rules.
Investigation of potential suspicious events
This part is all about investigating the alerts and events that are triggered by the risk policies. So basically, a security related person needs to review all users that got flagged based on policies and take a look at the particular risk events that triggered this alert and so contributed to the higher risk level. It’s also important to define a workflow that is used to take the corresponding actions.
It also needs someone who regularly investigates the vulnerability warnings and recommendations and estimates the real risk level for the organization.
It’s important to take a closer look at the risk policies that can be configured in Azure AD Identity Protection.
We will skip the Multi-factor authentication registration configurations here. For more details on MFA, read the next paragraph. Just because it can’t be said often enough, I highly recommend enforcing MFA for all accounts!
The two policies we can configure are user risk policy and sign-in risk policy. The options look quite similar, but the real differentiation happens in the background:
Sign-in risk policy
In the following diagram, user risk policy view is illustrated:
User risk policy
The main differentiation between Sign-in and User risk policies is where the risk events are captured. The Sign-in policy defines what happens when a certain account appears to have a high number of suspicious sign-in events. This includes sign-in from an anonymous IP address, logins from different countries in a time frame where it would not be possible to travel to the other location, and a lot more.
On the other hand, User risk policies trigger a certain amount of events that happen after the user was already logged in. Leaked credential or abnormal behavior are example risk events.
Microsoft provides a guide to simulating some risks to verify that the corresponding policies trigger and events got recorded. This guide is provided at this address: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-identityprotection-playbook.
The interesting thing after choosing users is the Conditions setting. This setting defines the threshold of risk events that is required to trigger the policy. The different option for the threshold are Low and above, Medium and above, and High. When High is chosen, it needs much more risk events to trigger the policy, but it also has the lowest impact on users. When Low and above is chosen, the policy will trigger much more often, but the likelihood of false positives is much higher, too.
Finding the right balance between security and usability is one more time the real challenge.
The last option provides a preview of how many users will be affected by the new policy. This helps to review and identify possible misconfigurations of earlier steps.
Multi-factor authentication
Authentications that require more than a single type of verification method are defined as two-step verifications. This second layer of sign-in routine can critically improve the security of user transactions and sign-ins. This method can be described as employing two or more of the typical authentication factors, defined as either one, something you know (password), two, something you have (a trusted device such as a phone or a security token) or three, something you are (biometrics).
Microsoft uses Azure MFA for this objective. The user’s sign-in routine is kept simple, but Azure MFA improves safe access to data and applications. Several verification methods such as phone call, text message, or mobile app verification can help you to strengthen the authentication process.
There are two pricing models for Azure MFA. One is based on users, the other is based on usage. Take your time and consider both models. Just go to the pricing calculator and calculate both to compare them.
Now we will see how easy it is to activate MFA in Azure:
- First sign in to the old Azure portal (https://manage.windowsazure.com). After choosing the right Azure Active Directory, click on USERS:
Azure Active Directory in the old Azure portal
- At the USERS page click on MANAGE MULTI-FACTOR AUTH at the very bottom:
Multi-factor authentication settings
- Now a redirection to the MFA portal should take place. In this portal, the MFA management takes place. I will use my demo user Frederik to show the process of activating MFA:
MFA portal
- Just choose the user that needs to be enabled for MFA and press Enable:
Choosing users for MFA and enabling them is enabled for MFA
- After confirming the change, it takes a few seconds and the user is enabled for MFA.
Do you really want to enable MFA?
- Search for the Multi-Factor Authentication in the search box and then click on it:
Confirmation for enabling MFA
- To change the billing model for MFA, a new MFA provider needs to be created to replace the existing one. For this, the Multi-Factor Authentication resource should be created from the marketplace:
MFA provider in the marketplace
- Click on Create button to proceed:
Redirection at creation
- The little arrow in the box indicates a redirection to the old portal. In the old portal, the MFA provider page directly opens up. There is an exclamation mark next to the usage model. This and the text at the bottom warns that it’s not possible to change the usage model afterwards:
New MFA provider
There are many more features related to Azure Active Directory and Identity Security that we are not able to discuss in this book. I encourage you to take a look at Azure AD Connect Health, Azure AD Cloud App Discovery, and Azure Information Protection (as part of EMS). It’s important to know what services are offered and what advantages they could offer your company.
This is an example dialogue that will be shown after typing the password when MFA is enabled and the Authenticator-App was chosen as the main method:
MFA with authenticator-app
Conditional access
Another important security feature that is based on Azure Active Directory is conditional access. Although it’s much more important when working with Office 365 it is also used to authenticate against Azure AD applications.
A conditional access rule grants or denies access to a certain resource based on location, group membership, device state, and the application the user tries to access.
After creating access rules that apply to all users who use the corresponding application, it’s also possible to apply a rule to a security group or the other way around and exclude a group from applying. There are scenarios with MFA, where this could make sense.
Currently, Conditional access is completely managed in the old Azure portal (https://manage.windowsazure.com). There is a conditional access feature in the new Azure portal, but it is still in preview and not supported for production.
The administrator is also able to combine conditional access policies with Azure AD Multi-factor authentication (MFA).
This will combine the MFA policies with those of other services such as Identity Protection or the basic MFA policy. This means that even if a user is per group excepted from authenticating with MFA to an application, all the other rules still apply. So if there is an MFA policy configured in Identity Protection that enforces MFA, the user still needs to log in using MFA.
In the old portal the conditional access feature is configured on an application basis, in the new portal the conditional access rules are configured and managed in the Azure Active Directory resource:
Per application management old Azure Portal
Following screenshot shows view of new Azure AD:
Central management in Azure Active Directory in the new portal
To summarize, in this tutorial, we learned how to secure Azure identities from hackers. If you’ve enjoyed reading this post, do check out our book, Implementing Azure Solutions to manage, access, and secure your confidential data and to implement storage solutions.
Read Next
Azure Functions 2.0 launches with better workload support for serverless
Microsoft’s Immutable storage for Azure Storage Blobs, now generally available
Automate tasks using Azure PowerShell and Azure CLI [Tutorial]
