At its very core, user management is all 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 can be broken down into the authentication (who can access) and authorization (what they can do) components. We’ll discuss authentication in this post.
For authentication, there are a couple of different mechanisms that make this work – broadly, you can use either password- or key-based authentication.
With password-based authentication, the end user is prompted for a password when they attempt to login to your server. The text they enter is then 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 they provided at some point in the past. The actual password itself is never stored on the server, only its hash, so if the server is compromised in some way, each user’s password should still be secure.
Password-based authentication does have its flaws, of course:
Users can choose a poor password (short, or commonly used) – so it can be easily guessed or cracked
They can write it on a post-it note – where it can easily fall into the wrong hands
Or, share the same password across different servers – if it gets compromised at one location, it can be used to access other locations
One way the mechanism can be fortified is through the use of multi-factor authentication – authenticating the user also 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 auth. The protocol for logging into most servers (and all UNIX-based servers) includes the ability to do public-key authentication. This works by having the user’s public key already available on the server itself, and doing a cryptographic handshake upon connection to confirm that the requester has the corresponding private key.
This mechanism is quite secure but also has some complications. Perhaps foremost is the necessity of copying the user’s public key and installing them on all the appropriate servers. For a few users and a few machines, this isn’t terrible, but the difficulty increases geometrically as the combinations increase – this explains why many administrators give all users access to all servers. Another important, but often neglected factor is the de-provisioning of users – how do you track and quickly and effectively remove users that are no longer supposed to have access to these machines.
This was a very high-level primer for those wanting to learn about the basics of user management and especially authentication. For additional information, the JumpCloud Knowledge base has additional information as does this blog. Also, feel free to drop us a line with any questions!