AWS IAM Indecision
May 7, 2018Identity and Access Management (IAM) can be a confusing topic for people that are new to Amazon Web Services. There are IAM Users that could be used for authentication or solutions considered part of the AWS Directory Services such as Microsoft AD, Simple AD, or AD Connector. If none of these sound appealing, there is always the option to use Federation with a SAML 2.0 solution like OKTA, PING, or Active Directory Federation Services (ADFS). If all of these option have given you a case of decision fatigue, then hopefully this post and the associate links will help you to decide how your environment should be setup.
IAM Users
Your first option is the easiest to configure but comes with a few risks. An IAM user is a username and password that is created in the AWS IAM Console. You can give IAM Users access to login to the console or through the API, but it also means that its a separate login from the account you probably use in your corporate environment. For example, you login to your laptop every morning with a corporate Active Directory login and then go to login to the AWS console with a completely different username or password. Maybe you’ve even decided to use the same username and password that is used with your corporate AD but they aren’t sync’d so you still need to manage them separately. While IAM Users are easy to setup, they provide a few challenges for enterprises who’d like to use a single login. There are other solutions available to limit operational complexity and the number of logins managed meaning fewer attack vectors.
Directory Services
AWS also provides a service called AWS Directory Service that provides several different options for authenticating both machines and users with your environment.
Simple AD – Simple AD is an option that provides a subset of Microsoft Active Directory services and is based on Samba 4. This service deploys a pair of domain controllers, with DNS, in a VPC across a pair of subnets for availability. The solution allows you to use this new directory as a Kerberos authentication source, but be aware that this solution doesn’t allow you to create a trust relationship with your existing domain if you have one. Think of this if you plan to setup a new domain for your AWS servers to belong to, but will still be managed separate from your on-premises domain. Simple AD has two sizes where a small directory can handle around 500 users / 2000 objects and a large size can manage 5000 / 20,000 objects.
Microsoft AD – As you’d guess Microsoft AD provides a full blown Microsoft AD which is deployed in a similar fashion to Simple AD. A pair of Microsoft AD servers (2012 R2 as of now) are deployed across AZs to provide redundancy. Microsoft AD has an advantage over Simple AD where you can create a trust relationship with these new domain controllers to your existing Microsoft Active Directory environment. Be aware that your directory cannot be extended to this new Microsoft AD instance, a trust relationship can be created though. Microsoft AD also comes in two sizes where standard supports 5000 users / 30,000 objects and more than this would require the Enterprise option.
AD Connector – If you have the need to extend your existing on-premises active directory then you could consider AD Connector. AD Connector doesn’t authenticate your users directly, but rather forwards the requests on to your on-prem AD instances. This requires network connectivity between your VPC and your on-prem domain controllers for this to work, and if you lose your connectivity, logins will fail to work.
Federation
If you want to user your existing Active Directory solution for a login method for the AWS console or CLI, then federation might be your best bet. With federation, you can continue to use your existing corporate logins to login to the AWS control plane. Be aware though, that AD Federation won’t do anything for your computer objects that need a domain to join when they are spun up. This just allows for console authentication only.
Breakdown
If you’re still unsure, perhaps this table will help illustrate the differences.
| Limits the number of user Accounts? | Used for User logins and computer accounts? | Ability to create a Trust with on-premises AD? | Requires Network Connectivity to corporate data center? | |
|---|---|---|---|---|
| IAM Users | No - New Users would be created in AWS Console | No - Cannot manage computer accounts. | No | No |
| Simple AD | No - A new directory has to be maintained | Yes | No | No |
| Microsoft AD | Yes - If a trust relationship is created with on-premises AD. | Yes | Yes | No - Unless a trust relationship is created to on-premises AD |
| AD Connector | Yes | No - Computer accounts are not managed with AD Connector | N/A | Yes |
| ADFS | Yes | No - Only User authentiation | N/A | Yes - requires network access from the AWS Console to the ADFS server. (over public Internet) |
| ADFS with Deployed Domain Controllers | Yes | Yes - ADFS for console access and the DCs for users/computer accounts | Yes - AD can be extended or a trust relationship added. | Yes - If the directory on-prem has been extended to the AWS Servers or a trust is created |
Resources
The following resources may help you with some facets of the setup of the directory services, how federation can be used with or without role switching and general info.
