BLOG POST

Rethinking Active Directory for the Cloud

 

July 17, 2014 | DevOps | Kevin O'Brien

 

Active Directory for the Cloud – The Conjur Solution

Earlier this week, security firm Aorato “identified a new threatening flaw within Active Directory that enables attackers to change a victim’s password, despite current security and identity theft protection measures”.

In essence, this flaw has more to do with how Active Directory is designed than it does with a bug. An attacker who obtains the NTLM hash from a client can then force authentication with it, bypassing the more-secure Kerberos system in favor of the (known to be weak) NTLM authn protocol. It’s a classic pass-the-hash attack, but one that is (a) enabled by default in AD, (b) not logged by the system, and (c) can be used even when Kerberos is selected for authentication, since Kerberos relies upon NTLM for encryption.

Stepping back, what does this mean?

07_17_14

One perspective is that this flaw is indicative of how Active Directory is poorly aligned with the rapidly expanding set of devices, services, and platforms that comprise the modern infrastructure stack that many companies are moving to. The combination of poor technical choices and weak logging mean that as the threat surface expands, AD struggles to provide robust authn and authz. In other words: Active Directory is a legacy tool, and while essential for many organizations today, it should be carefully considered and replaced when IT and DevOps teams are moving some or all of their infrastructure to the cloud.

In doing so, there is an opportunity to break down and rebuild both the authn and authz model. Unlike Active Directory, this new model should comprise three elements:

  • Extensibility — unlike the network model that existed when AD was designed, the modern network is highly dynamic, with rapid system, service, and server provisioning and deprovisioning; by federating authn and centralizing authz, environmental change can be easily sustained without creating single failure points (as happened with AD in this case)
  • Auditability — relying on external logging exclusively can result in auth blind spots; wherever a user or service accesses a component under management from the authz system, permissions rules should broker that access and also log the incident in an immutable datastore.
  • Security — modern development practices and avoidance of legacy support requirements (such as the Kerberos/NTLM problem that arose in AD as a legacy of a Windows NT key system) helps to reduce the likelihood of built-in vulnerabilities

As organizations drive innovation and change in their own IT and development teams, they typically shift their architecture focus to the cloud. This creates an opportunity to set aside legacy technologies like Active Directory, which do not map to this new infrastructure stack, and in doing so create a more robust, secure, and cloud-native authz system.

 

 

Share This