Posts Tagged 'User Management'

We invite each of our featured SoftLayer Tech Marketplace Partners to contribute a guest post to the SoftLayer Blog, and this week, we're happy to welcome David Campbell from JumpCloud. JumpCloud is an automated SaaS-based offering that automates the manual, tedious system administration tasks for DevOps and IT pros. It works with your provisioning to complete your operations set by automating server maintenance, management, monitoring, and security.

User Management in a DevOps World

Maybe you're a developer who's recently been given responsibility for managing production infrastructure at your company. Or maybe you're a career SysAdmin whose boss read the DevOps Cookbook and decided that it's time for you to learn to embrace DevOps and start treating your configuration as code and automating everything. DevOps promises to change the way organizations develop, operate and maintain applications and IT infrastructure, both on-premise and in the cloud. However you came upon it, you're now firmly entrenched in the world of DevOps.

No matter what your background, you're probably not alone in terms of needing access to the servers in your environment. Which brings us to the topic of this post. It's bad practice to use a shared "root" account to manage your systems and especially to run your application. So you want to create and manage separate user accounts. This is easy enough to do manually when you have only one or two admins and just a couple of servers. But in today's elastic, auto-scaling environments, you may have two servers at 9am and 1200 servers at 3pm.

So what to do?

In short, what you want is a method by which you can have each admin within your organization have their own user account on all of the systems within your organization to which they should have access. You want to require the admins to use ssh keys to authenticate to the servers, as requiring key based auth will make it impossible for brute force attackers to guess passwords in order to compromise your systems. You likely will want to grant "sudo" access to certain admins, and have them prove their identity to the system before executing privileged commands by entering their password. You may want to require multi factor authentication for admin shell access to especially critical systems, like production database servers.

Access needs to be granted when new admins join your team, and when new servers are brought up in the environment. That's where it gets complicated. Maybe you don't want the junior admin having full access to the customer database system? Access also needs to be removed when somebody inevitably leaves the company, sometimes unexpectedly.

There are a lot of DevOps friendly ways to automate the process of provisioning and deprovisioning user accounts. Techniques can be as simple as using rsync to copy "shadow files" from one system in the environment to all systems in the environment, though this can be tricky to manage in auto-scaling environments.

More advanced approaches involve using configuration management tools like Puppet or Chef to manage local user accounts on managed systems. These tools have native capability for user management, but do not provide any centralized audit trail about who is doing what on your servers. They also make it difficult for the user to select their own initial credentials, or change them down the road should they be forgotten or compromised. Using configuration management tools to manage user accounts also requires "code changes" to add or remove users, and changes can take 30 minutes or more to propagate through your whole environment.

If you want to automate and streamline your server user management process or you're interested in enhancing the security of your infrastructure, visit JumpCloud. We can help make quick work of tedious user management and security issues so that you can get back to growing your business.

This guest blog series highlights companies in SoftLayer's Technology Partners Marketplace. These Partners have built their businesses on the SoftLayer Platform, and we're excited for them to tell their stories. New Partners will be added to the Marketplace each month, so stay tuned for many more come.

Now that you're an expert when it comes to bash, logs, SSH, and passwords, you're probably foaming at the mouth to learn some new skills. While I can't equip you with the "nunchuck skills" or "bowhunting skills" Napoleon Dynamite reveres, I can help you learn some more important — though admittedly less exotic — user management skills in UNIX.

Root User

The root user — also known as the "super user" — has absolute control over everything on the server. Nothing is held back, nothing is restricted, and anything can be done. Only the server administrator should have this kind of access to the server, and you can see why. The root user is effectively the server's master, and the server accordingly will acquiesce to its commands.

Broad root access should be avoided for the sake of security. If a program or service needs extensive abilities that are generally reserved for the root user, it's best to grant those abilities on a narrow, as-needed basis.

Creating New Users

Because the Sysadmin Boot Camp series is geared toward server administration from a command-line point of view, that's where we'll be playing today. Tasks like user creation can be performed fairly easily in a control panel environment, but it's always a good idea to know the down-and-dirty methods as a backup.

The useradd command is used for adding users from shell. Let's start with an example and dissect the pieces:

-c "admin" – This command adds a comment to the user we're creating. The comment in this case is "admin," which may be used to differentiate the user a little more clearly for better user organization.-d /home/username – This block sets the user's home directory. The most common approach is to replace username with the username designated at the end of the command.-g users\ – Here, we're setting the primary group for the user we're creating, which will be users.-G admin,helpdesk – This block specifies other user groups the new user may be a part of.-s\ /bin/bash userid – This command is in two parts. It says that the new user will use /bin/bash for its shell and that userid will be the new user's username.

Changing Passwords

Root is the only user that can change other users' passwords. The command to do this is:

passwd userid

If you are a user and want to change your own password, you would simply issue the passwd command by itself. When you execute the command, you will be prompted for a new entry. This command can also be executed by the root user to change the root password.

Deleting Users

The command for removing users is userdel, and if we were to execute the command, it might look like this:

userdel -r username

The –r designation is your choice. If you choose to include it, the command will remove the home directory of the specified user.

Where User Information is Stored

The /etc/passwd file contains all user information. If you want to look through the file one page at a time — the way you'd use /p in Windows — you can use the more command:

more /etc/passwd

Keep in mind that most of your important configuration files are going to be located in the /etc folder, commonly spoken with an "et-see" pronunciation for short. Each line in the passwd file has information on a single user. Arguments are segmented with colons, as seen in the example below:

Now that you've gotten a crash course on user management, we'll start going deeper into group management, more detailed permissions management and the way shadow file relates to the passwd usage discussed above.