Strategies for securing identities in Azure Active Directory with Sean Metcalf

[BrookeLynnWeenig]

The security community is continuously changing, growing, and learning from each other to better position the world against cyberthreats. In the latest post of our Community Voices blog series, Microsoft Senior Product Marketing Manager Brooke Lynn Weenig talks with Trimarc Founder and Chief Technology Officer Sean Metcalf, who is a Microsoft Certified Master in Active Directory, co-hosts the Enterprise Security Weekly podcast, and created the adsecurity.org website. The thoughts below reflect Sean’s views, not the views of Sean’s employer, and are not legal advice. In this blog post, Sean talks about securing identities.  

Brooke: How did you get into Active Directory security? 

Sean: When Active Directory came out, I was excited because Microsoft was my technology focus and this was an intriguing new direction. The environment where I worked had Novell NetWare everywhere, and one group was running Windows NT exclusively. I ran Windows NT within this little island and figured out how to navigate the idiosyncrasies that were NT. Once Active Directory was released, I switched to a consulting job to help customers deploy Active Directory.  

Active Directory launched with quite a bit of features we did not have with NT, like group policies and other items that help manage the environment. This was a huge improvement over the older NT domain environment. The security side of AD was a bit less clear.  

In the early 2000s, I worked as a consultant on a large global multidomain Active Directory deployment. The size of the environment and the global distribution, not to mention active migration efforts, added complexity which resulted in security concerns. To help secure this AD environment, I shifted my focus to Active Directory security. I started trying to figure out what was missing as this environment was getting deployed, configured, and rolled out all around the world, not to mention the approximately 1,000 domain controllers arrayed around the globe. My approach focused on the attacker mindset:  

How could I compromise this environment or do something that it is not meant to do? 
What did we not think about when we were designing it that we should have? 
And the question many ask themselves about their own AD environment: what am I missing…?  

Soon after this, I started the ADSecurity.org website, initially as my “web notebook” that I referred customers to; this became a central location for noting Active Directory security concerns and issues that I saw. 

 
Brooke: What are the biggest challenges of securing identity? 

Sean: Active Directory is not inherently insecure. One challenge is that it is a system much like any other, with a variety of configurable options. Since AD offers such great customization, people can do whatever they want, and AD environments can look very different. Admins can add regular user accounts into domain admins (and they have!). They can add certain groups that contain everyone in Active Directory into highly privileged AD groups and give everyone rights. Active Directory is not going to stop you from doing that any more than your car is going to stop you from driving too fast on a residential street.  

Another challenge is that there are often too many privileged accounts that have rights that are not really required. The organization does not know all the accounts with highly privileged rights. Group nesting is still an issue in Active Directory that leads to insecure configuration. This is where you have a group that is a member of one group that is a member of another group. Due to this group nesting configuration, the Administrators group at the domain level granted full AD administrative rights to every member of all these groups (and member accounts) in the chain.  

Service accounts are associated with an application but are often highly privileged in AD. The challenge is identifying the accounts that have rights because Active Directory security does not always come down to just membership of domain admins and administrators, but delegated rights through AD permissions and group policy rights assignments.  

Another challenge is with Active Directory permissions set years ago and forgotten. All these groups and accounts have rights, but nobody knows about them (or remembers!).  
 

That is what the focus for Active Directory security often is – Active Directory integrations, Azure AD Connect, and enterprise password vault features, like secret server and CyberArk – these systems that are highly privileged in Active Directory, but not often reviewed.  

 
Finally, hundreds of companies help move companies into the cloud, but not as many helps them secure it. Azure AD has the same issue of too many privileged accounts, but often with regular user accounts in these privileged Azure AD roles. Group nesting is now something you can do within Azure AD, so that adds another level to it where you can have role-assignable groups that can be placed into an Azure AD privilege role. You end up with another layer and having to figure out who is in that group. With Privileged Identity Management in Azure AD, you can have a role assignable group or have members of that group eligible (or permanently assigned) to be global, application or user administrators. Once you have that layer of abstraction, it gets more difficult to determine what a group does and who should be put into it.  

In the world of identity, the challenge comes down to knowing which account has privileged access and protecting those accounts from attack.  

 
Brooke: What vulnerabilities and response times do you see on Azure Active Directory? 

Sean: Many issues I hear from incident response partners are with Azure AD configurations. A lot of the defaults are too permissive. Users and guests have too many capabilities. We are starting to see them tighten up, like Azure AD “security defaults” that turn off legacy authentication by default.  

Attackers sometimes phish a user and the user sees what looks like a legit application requesting permissions, but it is an application that the attacker created. The attacker then has full access. The attacker could pull data through the application continuously and the user does not even know about it. This is not just a Microsoft thing. This happens due to OAuth and other cloud providers such as Google are susceptible.  

In other attacks, the attacker keeps calling the admin until they consent to the multifactor authentication prompt. This is why Microsoft has pushed for number-matching, because number-matching requires that you think about, “What is the number on the screen and the thing that I am authenticating to” and you have to enter that number into the app to complete that multifactor authentication response. This validates that the person requesting the access is the person confirming the access versus just accepting a push response of “Accept” or “Deny”. 

In Azure AD, regular users may get full rights to add a credential to an application to a level way above what their rights actually are based on their role membership. There are applications in many tenants around the world that have effective global admin rights and if there is a regular user who created that application and got it approved through the normal process, they are an owner. A compromise of that regular user account could completely compromise the tenant. 

Attackers are going after permissions and anything to get a foothold. During the SolarWinds incident, many saw compromise of the on-prem environment and accounts and then the attacker leveraged these credentials to pivot into the cloud. That is a challenge for a lot of organizations because the cloud is seen as an extension of the on-prem environment, where we often see synchronized accounts in Active Directory that are members of highly privileged roles in Azure AD, like Global Administrator. 

If neither Conditional Access nor security defaults are enabled, that is a problem. Conditional Access is effectively an identity firewall for the Microsoft cloud environment where you can control who can connect to what, how, and where. All those answers can be done within Conditional Access and Microsoft continues to expand this capability. An Azure AD risk is not enforcing multifactor authentication on all privileged accounts, not just global admin, because there are other roles that are highly privileged. There is even an Azure AD permission where the application delegated this right can give itself its own permissions to have full admin rights to the Azure AD tenant.  

 
Brooke: What challenges are you seeing in the world of permissions and roles?  

Sean: One of the biggest challenges many organizations are experiencing today relates to what I call the “Identity Nexus”. The Identity Nexus is where identities across systems connect and often provides attackers opportunity.  

We have all these identity systems— on-prem Active Directory, Azure AD, Okta, and other cloud providers, like Google Cloud Platform or Amazon Web Services). Each has its own Identity Access Management system, roles, and permissions. Some things are similar across cloud providers, but there is different nomenclature across cloud providers and a variety of capabilities as far as security, management, and operations. These differences, paired with the required interconnectivity between cloud and on-prem (the nexus), can result in interesting scenarios where a cloud admin can make changes that affect on-prem administration, including updating on-prem privileged access! 

Often, Active Directory is still the core of identity. Most companies have on-prem Active Directory accounts that are synchronized with Azure AD, which means there are Azure AD accounts linked to the AD accounts. Unprivileged accounts in Active Directory can have highly privileged rights through Azure AD roles and depending on the configuration, there may be unintended consequences related to our identity systems and infrastructure systems of which attackers can take advantage.  

Another interesting connection point between on-prem and cloud is when there is a domain controller virtualized in Azure that is part of the on-prem Active Directory. This configuration could result in the compromise of the on-prem Active Directory due to a breach in the cloud environment.  

There are unintended consequences with how most organizations are connecting things across the Identity Nexus, especially with hybrid cloud components like Azure AD Connect. There is interplay among hybrid cloud components and Azure AD Connect is often at the center of this. Common hybrid components include Azure AD, Seamless Single Sign-On, and Pass-Through Authentication. With Pass-Through Authentication, credentials pass through that system that enables an attacker to potentially spoof and impersonate someone on the network if the server is not protected appropriately. This underscores the importance of protecting both the hybrid systems and privileged credentials. 

Strong authentication, like Multifactor Authentication, secured systems like Privileged Access Workstations for highly privileged accounts, and limiting rights that service accounts and third-party systems have are the most important ways to protect identity. 

​​To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and Twitter (@MSFTSecurity) for the latest news and updates on cybersecurity.