Active Directory (AD) is among the oldest pieces of software still used in the production environment and can be found in most organizations today. This is despite the fact that its historical security gaps have never been amended. For example, because of its inability to apply any security measures beyond checking for a password and username match, AD (as well the resources it manages) is dangerously exposed to the use of compromised credentials. Furthermore, this exposure is not confined to the on-prem environment. The common practice of syncing passwords between AD and the cloud identity provider means any AD breach is a potential risk to the SaaS environment as well.
In this article, we’ll explore AD’s inherent security weaknesses and examine their scope and potential impact. We’ll then learn how Silverfort’s Unified Identity Protection platform can address these weaknesses at their root and provide organizations using AD with the resiliency they need to thwart identity threats and mitigate the risks of compromised user accounts.
What Cloud? Why AD Will Be Continue to Be Part of the Hybrid Environment
While cloud computing has triggered a tectonic shift in IT, it hasn’t completely replaced the on-prem environment but instead lives with it side by side. The pragmatic route that most organizations have chosen is to maintain a hybrid environment, where user access to SaaS and web resources is managed by a dedicated identity provider while AD still manages the on-prem resources.
From the operations side, this strategy is reasonable since there are multiple resources that can be migrated to the cloud or exchanged with SaaS apps. However, it’s important to be aware that this approach means AD’s long-ignored security weaknesses are still at large.
To learn more about how Silverfort addresses weaknesses in your identity security posture, check out our resource, Silverfort MFA: Protect the Unprotectable.
AD’s Achilles Heel: Unable to Detect and Prevent Malicious Access Attempts Using Compromised Credentials
When a user initiates an access request, AD knows how to do one thing only: check if username and password match. If they don’t, AD blocks access; if they do, access is granted. But what can AD do if username and password match but are being used by an adversary that has obtained them? Unfortunately, the answer is absolutely nothing.
As strange as it sounds, from AD’s perspective there’s no difference between a legitimate user providing the correct username and password and a malicious adversary doing the same thing. Both are granted the same access.
So Why Can’t Traditional MFA Solve This Problem?
At this point, you may wonder why MFA can’t simply be added to the AD authentication process, as is done with SaaS apps. The answer, unfortunately, is that it’s not so simple. AD and its authentication protocols (NTLM and Kerberos) were built and designed more than two decades ago — long before MFA even existed. As a result, unlike modern authentication protocols that SaaS apps use, they can’t support MFA at all. Nor are there any plans from Microsoft to open up these protocols and rewrite them so that they’d have this capability.
This means we’re back to square one, where an attacker using compromised credentials in an AD environment can literally connect to any workstation, server, or app they please, with no security measures barring their way.
An AD Breach AD Paves The Adversary’s Way to Your Cloud Resources
What many security stakeholders often forget is that on-prem and cloud environments are entwined. In fact, many attackers seeking to access SaaS apps choose to access them via a compromise of the on-prem environment, instead of attacking them directly through a browser. The common pattern of this kind of attack is to gain control of an employee’s endpoint using social engineering and, once there, strive to compromise usernames and passwords to use them for malicious access to SaaS apps. Alternatively, if a federation server is in place, adversaries can simply compromise it as they would with any other on-prem resource and gain SaaS access from there.
One way or another, it’s important to realize that when we’re talking about AD’s security gaps, this doesn’t mean that only the AD-managed environment is at risk rather but the entire hybrid environment with all its users and resources.
Silverfort Unified Identity Protection: Overcome AD’s Gaps with Real-Time Protection
Silverfort has pioneered the first platform purpose-built to protect against identity threats – in real time – making use of compromised credentials to access targeted resources. Silverfort provides continuous monitoring, risk analysis, and active policy enforcement on every incoming authentication and access request made by any user to any resource, both on-prem and in the cloud.
In this way, Silverfort can solve AD’s security gaps at their root through an integration with AD’s native authentication flow, thus taking the role of deciding for AD whether a user can fully be trusted when accessing a resource or not.
Silverfort’s AD Protection: A Layer of Threat Protection Natively Integrated into AD’s Authentication Flow
Here’s how it works:
- A user wants to access a resource and initiates an access request to AD.
- AD, instead of deciding by itself whether to grant or deny access based on the password match, forwards this access request to Silverfort.
- Silverfort receives the access request and analyzes it using a multi-layered AI engine while also evaluating the request against pre-configured access policies.
- If the analysis reveals a suspected compromise, Silverfort connects to an MFA service to challenge the user to verify their identity.
- The MFA service sends the user the message and passes their response back to Silverfort.
- Based on the MFA response, Silverfort instructs AD whether to block or allow access.
- AD blocks or allows access per Silverfort’s instruction.
Agentless and Proxyless Technology, Agnostic to All Protocols and Access Methods
As you can see, this unique ability to receive every access attempt in real time from AD enables Silverfort to add the missing risk analysis and MFA capabilities into the AD authentication flow. Additionally, because Silverfort sits behind AD and gets 100% of its authentication requests, this eliminates the need to install MFA agents on individual resources or place a proxy in front of them. It also means that it makes no difference what protocol is used or whether it supports MFA. As long as an authentication to AD is carried out, AD will forward this to Silverfort and protection will be in place.
Want to learn more about Silverfort’s AD protection? Schedule a call with one of our experts.
