Same, But Wildly Different: Securing Azure AD vs. AD On-Prem

Azure Active Directory (Azure AD) is directory services in the cloud. More specifically, Azure AD is Microsoft’s platform for managing and securing identities in the cloud. There are many differences between it and on-premises Active Directory (on-prem AD). While Azure AD and on-premises AD are both vulnerable to attacks that take advantage of misconfigurations and over-privileged users, they are two completely different animals when it comes to security.

Just like on-prem AD, Azure AD is vulnerable to attackers taking advantage of users with roles or access they should not have to move laterally, escalate privilege, access sensitive data, or deploy malware. While these two systems can be abused in many of the same ways, the mechanics for doing so are quite different. Here are the most significant ways in which Azure AD security differs from that of AD on-premises, and what AD admins charged with securing both need to know.

How permissions work: game of control vs. game of roles

We’ll start by breaking down differences associated with permissions. There is one permissions system within on-prem AD. By contrast, in Azure AD, there are at least three different permissions systems involved at any given time. Not only is Azure world wildly different, but it's also much more confusing.

In on-prem AD, permissions can be applied to objects to control how those objects are manipulated. They regulate access by enforcing whether a user or group can read or write to an object, has full control of an object, or has no access to the object at all.

On-prem AD uses a permissions standard called discretionary access. That's where the acronym DACL comes from, which stands for discretionary access control list. Every securable object in on-prem AD has a DACL, which specifies which users and groups can access an object as well as what kinds of operations they can perform on that object. In other words, permissions are controlled on a per-object basis. Each object describes who has control of the object (i.e., on this object, Jon Snow has control of it; on this object, Grey Worm has control of it).

In Azure, it works the opposite way. Offering a more granular control to security, in the form of Roles, Azure AD uses a permissions model called Role-Based Access Control (RBAC). RBAC is a mechanism that restricts systems access by assigning permissions to users based on their role within an enterprise. This ensures employees have access to the information needed to get their work done while preventing them from accessing information that doesn't pertain to their job. In Azure, there is a role, and this role says that Drogon has control of this type of object and every type of object that is that type. And Viserion has control of every type of that object. And a different role says that Rhaegal has control of every one of these types of objects. On top of this role-based system, there is also a separate permissions system specific to the App Service, there is a separate permissions system specific to key vaults, and there is a different permissions system specific to security groups.

What is the result of this? Think back to the on-prem AD example, where each object describes who has control of it. That is canonical. If I look at Jon Snow’s user object and I see who has control of it, that's it. That's the end of the story. There is no other system that I need to look at.

Conversely, in Azure, every object that I look at, I need to understand:

So, you have all these distinct permissions systems that affect the permissions on every object in the tenant (tenants are similar to Forests in Active Directory – they are where trusts can be established within Azure AD). When auditing permissions against anything or from anything (i.e., what objects does Drogon have control of?), you must understand the way that all those different intermediary systems cooperate and conflict with one another. It's a wildly complicated system that is incredibly difficult to audit. Security teams must be able to audit permissions against anything or from anything in order to see what objects are controlled by which users. The harder it is to do this, the more security risks and misconfigurations they will miss, which leads to more opportunities attackers will have to exploit. 

How logon sessions work: take a token, leave a token

The second major difference worth digging into here involves logon sessions. Logon sessions work differently for principals that authenticate against Azure AD.

In on-prem AD, when a user logs onto a system, they get an operating system object called a token. That token describes what security groups a user belongs to and what local user rights assignments that user has. That token can be abused by attackers that have admin rights on the system because they can steal that token. They could then say, "your token is now my token, and I have all the same rights that are described by this token," which allows them to impersonate another user.

Also, in on-prem AD, there are shortcuts that the operating system takes to facilitate single sign-on (SSO) with other services in the environment that cannot handle token-based authentication. The operating system will store the plaintext password for the user and then use that plaintext password to authenticate to those other services. This means if I'm an admin on that system, I can abuse the architecture of the operating system to get the plaintext password, or different credential material, for that user. In both scenarios, the strength of the user password is totally irrelevant. They could have a 200-character-long password – it doesn't matter. And, the enforcement of multi-factor authentication (MFA) or smart card authentication is also irrelevant. Because once I have a token, that's it – I am now trusted, I'm authenticated, I don't need to use MFA for anything else. When hardening on-prem AD, security teams need to worry about such token and SSO abuse issues.

In Azure, there are a couple of pretty big differences. To stay logged in on the operating system when you authenticate as an Azure principal, you get a Primary Refresh Token (PRT) on the operating system to stay logged in. This PRT can be used to facilitate that same SSO concept. So, if I'm going to authenticate against a different service, I can use my PRT to validate and say, "yes, I am this user, I have proven that I am this user against this other service that knows who I am, and knows what my password is.”

There are different protections in Azure that mitigate the risk of that PRT being taken over. For example, in Azure, if I wanted to promote Drogon’s user to a global admin, I can configure Azure to force me to do an MFA confirmation before allowing me to perform that action. Even though I'm already authenticated, even though I already have a PRT, I can configure the system to initiate an interactive logon requiring me to reauthenticate or provide additional verification that enables a new PRT to be issued on successful authentication. In short, a PRT is protected by binding it to the device the user has signed in to. In Azure AD, security teams need to know they can enable PRT protection during the first sign in or during token requests and renewal. This is a different set of issues than on-prem AD and requires a different set of fixes.

Attack paths: the common denominator

As important as the differences between Azure AD and on-prem AD are what they have in common: Attack Paths. Attack Paths are the chains of user behaviors and abusable privileges that create direct and indirect connections between users and computers. They are widely used by adversaries for all types of attacks – and the challenge of AD security ultimately lies in understanding, quantifying, and mitigating or eliminating them. It's a “same, same but different” kind of situation. The technology works differently, but the attack paths that emerge in both Azure AD and on-prem AD are very similar.

As we’re already seeing with on-prem AD, a methodology termed Attack Path Management can help secure Active Directory. The true value of Attack Path Management lies in its ability to measure Attack Path exposure in more detail to quantify the problem and prioritize fixes. It allows enterprises to significantly reduce the attack surface AD presents to attackers, harden AD against abuse by helping organizations achieve and maintain effective Least Privilege and Tiered Administration, bolster Directory Services availability, and protect the ‘keys to the kingdom.’  More precisely, Attack Path Management does the following:

Attack Path Management has categorically proven itself to be successful in making on-premises AD more secure. Moreover, this methodology has the potential to keep conquering different attack paths in different Active Directory environments going forward. Azure AD might be significantly different than on-prem AD in terms of technology, but the principles for how to secure it remain the same.

Andy Robbins is Technical Architect at SpecterOps.