{"id":1505,"date":"2014-03-04T06:00:05","date_gmt":"2014-03-04T13:00:05","guid":{"rendered":"http:\/\/www.jumpcloud.com\/?p=1505"},"modified":"2024-01-12T16:32:18","modified_gmt":"2024-01-12T21:32:18","slug":"pros-cons-existing-user-management-approaches","status":"publish","type":"post","link":"https:\/\/jumpcloud.com\/blog\/pros-cons-existing-user-management-approaches","title":{"rendered":"The Pros & Cons of Existing User Management Approaches"},"content":{"rendered":"\n
Out of necessity, <\/span>DevOps<\/span><\/a> 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\u2019s a few examples of what I mean:<\/span><\/p>\n\n\n\n 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. <\/span>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\u2019t enough hours in the day<\/a>, 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\u2019t scale, isn\u2019t systematic, and provides for little comfort on the security side.<\/span><\/p>\n\n\n\n For more than a decade, the standard in the directory services space has been Microsoft\u2019s 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 \u2013 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\u2019s 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. <\/span>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<\/a> will far outstrip the benefits.<\/span><\/p>\n\n\n\n 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\u2019t 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.<\/span><\/p>\n\n\n\nManual<\/h4>\n\n\n\n
Microsoft Active Directory<\/h4>\n\n\n\n
Lightweight Directory Access Protocol (LDAP)<\/h4>\n\n\n\n