The Pros & Cons of Existing User Management Approaches

Out of necessity, DevOps and IT pros have figured out a number of different ways to handle their user management challenges. As most of them will tell you, they are less than enthused with their options, and dying to off-load these identity management processes in any way possible.  Here’s a few examples of what I mean:

Manual

Most admins just manually go on the command line and create accounts for their users. As they add new employees and IT resources, they will manually create accounts on each system, application, and network and then communicate with the user that they have a new account or access to the IT resource. The user can then login and change their password or upload their public key (if applicable). If, for some reason, the end user forgets their password or rotates their private key, those become manual requests to the IT admin. Then, some admins will take the added step of monitoring the access to servers. They will check log files occasionally to determine who has logged in to the server, as well as check for the dreaded brute force attacks, which may or may not have succeeded. Unfortunately, these things should be done regularly but it is difficult and time consuming for the admin to fully and continuously review the user login logs for signs of a compromise. There just aren’t enough hours in the day, or money in the budget to hire a dedicated staff member to review the logs. For small organizations with a limited number of servers and minimal change, manually handling user accounts is common and works, for awhile. The downside of this approach is that it doesn’t scale, isn’t systematic, and provides for little comfort on the security side.

Microsoft Active Directory

For more than a decade, the standard in the directory services space has been Microsoft’s Active Directory, which is embedded in organizations large and small. Generally utilized by companies that have been in existence for at least a few years, linking AD to cloud servers is not an easy task. AD is generally hosted on-premises or at a data center – not in the cloud. As such, cloud infrastructure and applications need to have a way to talk back to the AD server. Exposing AD to the Internet is generally a bad idea, so therein lies one problem. The second is that much of the cloud infrastructure is based on Linux. Even within an organization’s four walls, adding Linux or Mac devices to AD is difficult at best. Generally, admins will need to purchase directory extension technology to place an agent on the Linux server in order to have it talk to AD. Once that is enabled and the two can talk, then users can be controlled directly from AD with access control and permissions managed there. Of course, managing specific permissions and access on Linux servers or Macs is not nearly as well done as it is for Windows servers. For larger organizations with primarily Windows environment, extending AD to the cloud could be a viable alternative except for the security and networking issues. For Linux, dynamic cloud environments, and Macs, IT admins are best served by finding an alternative mechanism. The time and expense to have it work effectively will far outstrip the benefits.

Lightweight Directory Access Protocol (LDAP)

OpenLDAP has become the open source, lightweight alternative to AD. A database by design and historically optimized for being a directory service, OpenLDAP is often utilized by organizations for their LDAP-based systems and applications. Admins will stand up an OpenLDAP server in their cloud infrastructure and then configure it to become the user store, access control, and authorization mechanism. Not for the faint of heart, OpenLDAP is difficult to configure and requires significant expertise and effort. Access control is largely created manually here as well. As the solution is effectively a database, a new user needs to be provisioned and their permissions manually created. Subsequently, the IT resource will need to be configured to query the LDAP server for whether a user should be authenticated and what permissions they may have. Admins have generally managed OpenLDAP at the command line level, and it requires a greater level of technical expertise and time. OpenLDAP has historically been a strong option for non-Windows environments and as a result, has been utilized in the cloud. Unfortunately, OpenLDAP is an expensive solution from an ongoing maintenance and management perspective – exactly what DevOps and IT admins are looking to avoid – and, that doesn’t even include planning for scale and redundancy of your LDAP infrastructure. Like AD, LDAP also suffers from network complexities across clouds, and is similarly problematic as a result.

Configuration Automation Tools (e.g. Chef and Puppet)

The new world order of the cloud, Chef and Puppet are being used extensively to automatically configure systems, which is great. Many organizations use Chef and Puppet to set up their user accounts as well. The admins can now simply add to their scripts each of the users that they want on their systems, as well as the permission levels they can have. Chef and Puppet then provision those accounts across all of the systems managed by the configuration management tool. While a relatively simple way to provision accounts, the process is largely manual and requires static configurations across servers and users, unless the DevOps or IT admin is willing to continuously update the script or write more code. Another inherent challenge with Chef and Puppet is that the scripts are largely public inside of a company. So how do you store your users’ public keys? They are exposed publicly and changes to those become manual events for the admin. Chef and Puppet are basically an excellent extension of the manual approach. If your organization is fairly static on users and not complicated with different groups and permission levels, you can effectively use Chef and Puppet for user management. However, as soon as the infrastructure and organization become dynamic, that places a great deal of pressure on the admin to update and manage the scripts, which can become unwieldy quickly. Further, for those that are security conscious, Chef and Puppet end up representing a large vulnerability with passwords or keys embedded into the scripts.

As you can see, user management and the cloud have not mixed well. While each of these solutions is a potential path, they are clearly not ideal solutions for organizations looking for an efficient and secure infrastructure. If you would like to learn more about how to solve the cloud identity management problem, drop us a note.