At its very core, user management is all about making sure the right people have access to the right IT resources as well as the ability to control what they do once they’re on those IT resources. 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 log into 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, 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
- Users may 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 auth. That is, 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. However, 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 deprovisioning of users. How do you track and quickly and effectively remove users that are no longer supposed to have access to these machines?
Check Out Our Authentication Practices
This was a very high-level primer for those wanting to learn about the basics of user management, especially authentication. For additional information, the JumpCloud® Knowledge Base has additional information as does this blog. If you are up for it, you can see these authentication practices live with JumpCloud’s Directory-as-a-Service® platform. Your first 10 users are free forever.