For enterprise IT, "hybrid" is the word of the year. You're either operating a hybrid infrastructure model already or you're teetering on the edge.
It's getting easier now that AWS, Microsoft, Google, et al are improving their services in support of such a model. At the Amazon AWS re: invent show in November, every other sentence contained the word "hybrid." This was in stark contrast to last year where Amazon still firmly believed a total migration was the only logical choice.
Some of our customers are very aggressive with plans to dissolve all their data centers and migrate everything to IaaS. The vast majority, however, are more cautious—using IaaS for new projects only. This presents them with a problem: how to extend a successful on-premise privileged access security model to protect IaaS workloads.
In other blogs, we've discussed best practices on how to do this. We also have the best practices white paper that springboards off one published by Amazon. In this blog, however, I want to explore how you can leverage your on-premise Active Directory (AD) infrastructure to authenticate users to AWS EC2 Linux instances. I'm going to describe the most common approaches and finish with Delinea's best practice recommendation involving our latest Identity Broker capability announced at the re: invent show.
Active Directory Security and Hardening
What's the problem?
You've been doing dev and test in the cloud using EC2 Linux instances. With few users, you've created local /etc/password IDs on each instance, as required. However, as you move to production, this won't scale. There are orders of magnitude, more users to manage and unsurprisingly, security is now top of mind. Since all your EC2 users already have credentials in Active Directory on-premise, it's logical to want to enable EC2 instance login with these Active Directory credentials. The challenge is, how you do it simply, securely, and cost-effectively.
You have three common options when accessing Linux EC2 instances:
- SSH, logging in with a Shared EC2 Key Pair (automagically created for you by the AWS root/billing account).
- Replicate Active Directory in the cloud, deploying an additional Active Directory infrastructure.
- Set up a site-to-site VPN to extend your on-premise Active Directory to the cloud.
Delinea best practice calls for eliminating Shared EC2 Key Pairs altogether (you were not seriously thinking of using shared credentials, were you?) and using your existing Active Directory/Kerberos infrastructure, which we will cover below.
Each of the Active Directory deployment options has its pros and cons. Cost, security, and productivity are all impacted through duplication of identities, additional complexity, operational overhead, increased attack surface, and the need for additional licenses.
Let's step through these Active Directory options starting with the least preferable to the most.
Direct Connection
The simplest option is a direct connection from your AWS VPC to your data center. However, you're essentially exposing Active Directory-Corp to the cloud.
With this setup, your host-based Server Suite agent can authenticate users against Active Directory-Corp over a site-to-site VPN. Users can then log in via SSH with domain credentials (ID/password) or a Kerberos ticket. Once they're logged in, users have a Kerberos ticket that supports Kerberos-based single sign-on.
There are firewall implications on both sides. You need to permit any IT user access to the VPC side for remote SSH or RDP sessions. On the corporate side, you need to allow any EC2 instance access to Active Directory-Corp (i.e., all Active Directory ports open). Many customers don’t like this increased attack surface since any new EC2 instance in the VPC can now communicate openly with Active Directory-Corp.
Hang on. What about Amazon's Active Directory Connect? Sure, that's viable but it is limited. It constrains log in to AWS portals only (e.g., Management Console, WorkSpaces, WorkMail,) not your custom apps. Although Amazon says it supports "Federated SSO," it's really just role mapping and not a true (SAML-based) federation. It also exposes your Active Directory credentials to a portal and Connector running in AWS connecting back to your on-premise Active Directory via LDAP. Not ideal.
Resource forest with one-way trust
Here, we set up a new Active Directory forest (Active Directory-AWS) with a one-way trust relationship to Active Directory-Corp. The forest is essentially a resource forest with the user records still being held in Active Directory-Corp. This model is more popular given its higher level of security. EC2 instances are joined to the Active Directory-AWS forest instead of Active Directory-Corp. Computer accounts are managed within Active Directory-AWS not Active Directory-Corp, since Active Directory-Corp does not trust Active Directory-AWS there is less risk to corporate credentials from a potential server breach in AWS.
In practice, a legitimate IT user would authenticate to Active Directory-Corp (obtaining a Kerberos TGT) and SSH to an EC2 instance, authenticating with a Kerberos Service Ticket that his computer automatically obtained from Active Directory-AWS. The Server Suite agent on the instance is able to validate the user’s Kerberos credentials and log the user in (assuming the user has appropriate Delinea roles managed within Active Directory-AWS).
This model also has a more acceptable set of firewall rules; you can be more explicit allowing only Active Directory-AWS to Active Directory-Corp communication and limiting ports for all other EC2 instances to only ports 88 and 464 for Kerberos authentication.
Resource forest with one-way trust to local RODC
This model is a slight variant of the previous scenario. The goal here is to streamline VPN traffic (selectively replicating accounts to a Read-Only Domain Controller (RODC) only for users who need to log in to the instances). The one-way trust is then established from the Active Directory-AWS to the RODC for Active Directory-Corp and we eliminate the direct Active Directory-AWS connection to Active Directory-Corp. Here, you only need open ports for the RODC->Active Directory-Corp communication path. This minimizes risk, while still enabling selected users to authenticate to the EC2 instances. Additionally, Microsoft designed the RODC model to prevent any Kerberos tickets generated by the RODC from enabling access to any on-premise resources joined to Active Directory-Corp.
Independent Active Directory with Delinea privilege service
In this model, we're able to remove the VPN completely by leveraging the Delinea Privilege Service. I won't go into the benefits of the Privilege Service here; there's a lot of other content on that. Suffice to say, this model enables VPN-less access to the EC2 instances and MFA for additional identity assurance with the option to vault passwords. The Delinea Connector in AWS acts as a bastion host and establishes a persistent outbound mutually-authenticated connection to the Delinea Identity Platform in the cloud, avoiding the need to configure any additional inbound ports to the VPC or into the enterprise.
This model also supports a common scenario of giving administrators “dash-a” accounts for privileged activity (also promoted by Microsoft in their “Red Forest” design.) So, IT can log in to the Privilege Service portal using their individual (fully-accountable) Active Directory credentials via the on-premise Delinea Connector and then use the Privilege Service to open a secure remote VPN-less session to the EC2 instance using the vaulted password of the user’s dash-a account. The dash-a account password is not revealed and is rotated automatically after use. Since the dash-a account is tied to a unique user, there’s host-level control over privilege and full accountability.
Full Identity Broker model
This is the nirvana state where we eliminate both the VPN and Active Directory infrastructure completely within the VPC. It represents the most efficient and risk-averse configuration. A user, logged into the Privilege Service portal (using individual credentials), can remotely log in to an EC2 Linux instance using either their individual account or a vaulted dash-a privileged account. You now have the freedom to authenticate EC2 Linux users against any user repository (e.g., Active Directory, LDAP, and cloud directories including Google G-Suite Directory). Identity Broker authenticates transparently, so the EC2 instances don’t have to be directly connected to sources of identity. No instances require public IP addresses since all SSH/RFP connections are proxied through the Delinea Connector, which also records all privileged session activity.
You have lots of options to consider. Hopefully, this has provided a little clarity on the common issues and considerations.
