In a hybrid identity environment, Active Directory professionals need a good understanding of Azure Active Directory (AAD) roles, applications, and multifactor authentication (MFA) to effectively secure the environment. These are the three core security configurations that an AAD administrator needs to tame. Once you have roles, applications and MFA sorted, you can dig deeper into your security stance knowing that the core is in good shape.
Each piece of this triad represents a critical point of focus for security. But while these subjects are frequently discussed independently, it’s vital to think of each of them as interconnected—three parts of a whole that, when taken together, can improve and safeguard security.
Know your role
Azure AD is managed by roles, of which there are two types: built-in roles and custom roles. Built-in roles come with their own permissions. All totaled, there are around 60 of these in Azure AD. These roles are broken up into three categories:
- Service-specific roles (e.g., CRM Service Administrator)
- Azure AD-specific roles (such as Application Administrator or Groups Administrator)
- Cross-service roles (such as Service Support Administrator)
Azure AD also supports the creation of custom roles that can be set with whatever permissions the administrator wants. These custom roles can then be assigned to a user by creating a role assignment that grants the user the permissions in a role definition according to its defined scope. Getting your permission model all tied up in roles can lead to security confusion, and administrators should proceed with caution.
Knowing the privileges associated with all these roles and what roles are tied to particular users is critical for security. We advocate for companies to regularly assess their on-premises AD environment for orphaned accounts, accounts with excessive privileges, and other red flags. This same diligence must be applied to the cloud environments as well. Once threat actors have breached an environment, one of their key tactics is to elevate their privileges. Monitoring role creations and modifications can alert the organization to a possible attack. Most of these changes, when investigated, will likely turn out to be legitimate. However, any unauthorized alteration of roles or privileges will be caught as well.
MFA provides a strong defense
In a certain light, MFA can be seen as an early warning system. Suppose an attacker steals a user’s credentials and attempts to log into their account. In that case, the second factor effectively stops threat actors in their tracks and alerts the organization to the attack. MFA prevents an estimated 99% of account compromises. Unfortunately, MFA is often not fully implemented. It is not uncommon for privileged accounts to be protected via MFA while others are not.
In other situations, all privileged accounts might have MFA except for one, which is given a Temporary Access Pass. This type of fragmented approach to MFA opens potential security holes for attackers to exploit by making it easier for threat actors armed with stolen or compromised credentials to slip by undetected.
Microsoft partially enables MFA automatically through Security Defaults. These defaults are:
- Requiring all users to register for Azure AD Multi-Factor Authentication
- Requiring administrators to perform MFA
- Blocking legacy authentication protocols
- Requiring users to perform MFA when necessary
- Protecting privileged activities like access to the Azure portal
Security Defaults can be turned on in the Azure portal. If your tenant was created on or after Oct. 22, 2019, Security Defaults might already be enabled. The goal of the defaults is to help organizations that are just beginning to understand their security needs. It’s important to remember, however, that the default security settings will only force the following nine Azure AD administrator roles to perform additional authentication every time they log in:
- Global administrator
- SharePoint administrator
- Exchange administrator
- Conditional Access administrator
- Security administrator
- Helpdesk administrator
- Billing administrator
- User administrator
- Authentication administrator
Other users will only be prompted to authenticate with an additional method under certain circumstances, such as using a new device or performing certain tasks. The Security Defaults also block legacy authentication methods, which account for many of the compromised login attempts organizations face. Since older protocols might bypass MFA, shutting them down as an attack vector is a vital part of security Azure AD.
Any indication that MFA has been circumvented—such as users being unregistered—should trigger an investigation.
Application security in Azure
A new concept for Active Directory administrators is the importance of registering Applications within Azure AD, which is a new level of access for users both within and outside of the AAD perimeter. Applications are common to extend your Azure Active Directory to other services, especially SaaS services. Security Defaults will also require users to authenticate via MFA when they log in via these new applications. However, MFA is not a cure-all for security. While MFA can limit the effectiveness of stolen credentials, controlling the risk posed by third-party applications is not just about password protection. Consider this scenario: an attacker targeting an organization’s Azure AD tenant decides that instead of tricking a victim into giving up their password, they will instead attempt to trick them into installing malicious applications. If they are successful, the user will grant the threat actor the keys to the kingdom—giving them access and control over the user’s account. If the user is moving quickly, they might not fully consider the rights the application is being provided. Application Registrations need to be reviewed and Self-Service Application assignment should be considered only if you feel fully comfortable with your end users recommending applications for use. In most cases there should be a formal process for application requests.
Many organizations might not think about this attack vector, and it is more difficult to detect because there is no malicious code executing on the user’s endpoint. It simply relies on social engineering and abuses trust. With the ever-growing number of cloud applications in use in today’s enterprises, closing the door on these types of attacks requires reviewing the list of applications by clicking the “Enterprise Applications” option under the “Manage” section in the Azure portal. Administrators can also monitor the consent events in Azure AD to see if unauthorized applications have been granted rights they should not have.
The big picture
When thinking about security in the cloud, IT leaders should take a step back and view it holistically. One layer of protection should reinforce every other layer. Effective role assignment limits the damage attackers can do if they trick a user into enabling a malicious application; having the ability to enforce multifactor authentication can prevent a third party from using the application to circumvent access controls. If the fabric of your organization’s approach to security is woven together carefully, you can substantially reduce the amount of risk your enterprise will face.
