Share This Article
In our third post on how to federate your Microsoft Active Directory or OpenLDAP directory server to AWS we talk about how user access management on AWS servers functions today (read Part 1: Federating AD or LDAP User Access to AWS Servers and Part 2: The What and the Why of Managing Users on AWS Servers).
At its very core, user management is about making sure the right people have access to the right servers, as well as the ability to control what they do once they’re on those servers. This process can be broken down into two functions: authentication and authorization. In order to manage users on AWS servers, these functions must be addressed.
For authentication, there are a couple of different mechanisms that make this work – broadly, you can use either password or key-based authentication. While we will explain both, it should be noted that, by default, AWS forces you to use the more secure SSH key-based authentication. This is a significant step forward from a security perspective and a clear statement from AWS that they take security of your infrastructure seriously.
With password-based authentication, end users are prompted for a password when they attempt to login. The text is hashed (a value generated from the password from which the original password cannot be easily obtained) and compared against a hashed version of the original password the user provided at some point in the past for verification. The actual password itself is never stored on the server, only its hash, so if the server is compromised, each user’s password remains unknown.
Password-based authentication has flaws, of course. Poor password choice, or irresponsible password protection can lead to compromised security. One way the mechanism can be fortified is through the use of multi-factor authentication – authenticating the user based on something they have, such as a rolling key generator like Google Authenticator, on their phone, rather than just on something they know (the password).
Another, more secure mechanism for authentication is key-based authentication. This is the approach that AWS uses. This method uses a protocol for logging in to most servers (and all UNIX-based servers) that includes the ability to do public-key authentication. A user’s public key is already made available on the server itself, and a cryptographic handshake upon connection confirms the requester has the corresponding private key.
Key-based authentication is quite secure but also has some complications. For instance, requiring a copy of a user’s public key and installing it on all the appropriate servers is logistically possible for a few instances, but the difficulty increases geometrically as the combinations increase. This explains why many administrators give all users access to all servers, despite the increased security risk. Another important, but often neglected, factor is that when an organization needs to deprovision users it’s extremely hard to remove users, and track their removal quickly and effectively. One further complicating factor is that best practices submits that end users should have a unique private/public key pair per device. That further adds to the complexity of managing key-based access on servers.
User management, authorization, and authentication are fundamental to a business’s productivity and security. Though there are several approaches to solving the ongoing process of user access and control, they fall short in some key ways (no pun intended).
Cloud Identity Provider Allows You to Manage Users on AWS Servers
One of the forerunning solutions is integrating a Directory-as-a-Service® user management solution. This approach rectifies password risks, user access, management, and removal, and allows businesses to leverage current solutions into the cloud. Learn more about this cloud based directory services approach.
Stay tuned for future posts that continue to detail problems associated with manually managing users on AWS and why federating access from an on-premise AD or LDAP is preferred.
