How to Manage Linux Identities Without LDAP
A common configuration for on-premises Linux servers includes using an LDAP directory to manage identities and for user authentication. This approach has been a de-facto standard and best practice for more than a decade. But LDAP directories have posed challenges to administrators and security professionals. There is a better way to manage Linux identities, without relying on LDAP.
In the beginning, there was Linux. The operating system was based on UNIX and gained wide adoption as an alternative to Windows servers. Linux maintains identities in local files (i.e., /etc/passwd, /etc/shadow), and it is easy to manage identities in a single Linux server.
But organizations don’t have a single Linux server. As you add multiple Linux servers, managing identities in the multiple servers becomes more challenging. This is due to the fact that Linux servers do not share identities from server to server. Each server is a stand-alone island of identities, and each needs to be managed separately.
So for example, if a new administrator needs an identity on multiple servers, a “user add” operation would need to be performed for every server in the farm. This results in the same identity, for the same user, being provisioned multiple times, once for each server. Likewise, user update or delete operations also require multiple operations, performed locally on each server. As the number of servers grows, this becomes a bigger challenge.
First generation approaches for simplifying the identity management problem used in-house developed tools, such as scripts, to perform basic identity operations. For example, a master server could store all the identities in files, and a script would copy the files to every server on a scheduled or on-demand basis. While approaches such as this were more productive than doing the operations manually on each server, there are many problems as well. These include differences in identity requirements between servers, security issues with allowing access for the scripts to the servers, version control, and synchronization if a server was offline when the operation was attempted.
Early commercial user provisioning systems relied on similar types of processes. Often agent-based, they would create user accounts locally on each server, and perform the various identity operations and password synchronization. These systems typically relied on a ”push” model, so were also prone to synchronization problems when servers were offline, and were expensive and high maintenance. Additionally, storing credentials in local files presents a security concern with “credential sprawl”, where the credentials for identities are stored on every server in the enterprise. Other early approaches to solve the Identity problem include NIS and NIS+, which were largely discontinued due to security issues and complexity.
Enter LDAP
LDAP directories solve many of the problems described above. Rather than storing user identities locally on the server, instead the server is configured to refer to the directory, which stores the identities. No user identities or credentials are stored on the servers, so there is nothing to keep in sync. LDAP directories provide a single repository, so user CRUD operations can be performed one time in the directory, and be effective for every server in the farm. Problem solved, right?
Not so much.
Problems with LDAP
LDAP directories come with their own set of challenges. For one thing, the servers that run the directory have to be deployed and maintained. And since no one can access the Linux environment without the directory, High Availability and Disaster Recovery (HA/DR) are required. The result is that there may be multiple servers that have to be built, maintained and updated to ensure access to the Linux environment. Sometimes additional controls are added, such as synchronizing passwords with corporate directories such as Active Directory. Some of these additional controls result in the administration of the directory becoming unwieldy and difficult to maintain over time. As the original designers of the directory and its servers leave the organization, institutional knowledge of the administration of the directory may be lost, and in the worst case scenario, the directory becomes a “black box” that is poorly understood and hard to maintain. Additionally, the directory may become a performance bottleneck for authenticating users in large Linux farms.
Introducing Okta’s Advanced Server Access (ASA)
ASA provides a modern approach to managing Linux identities securely without requiring an on-premises LDAP server. Using ASA, you can benefit from automatic identity CRUD for your Linux servers without the problems of LDAP directories or of local files administration.
ASA relies on Okta’s Identity Cloud as a master source for the Linux identities. Identities are stored in Okta’s Universal Directory (UD), and provisioned automatically to the appropriate servers based on the authorization policies of your organization. This means that Identity Management is performed automatically as Access Management policies are added or changed. Identities in Okta can be automatically pulled from a master source, such as Active Directory, an HR system, another application, a CSV master, or other source. Your existing LDAP directory may be the source for your Linux attributes during the migration to ASA.
No on-prem infrastructure required
Because ASA does not require any on-premises infrastructure, you can retire the LDAP directory as well as its servers and any HA/DR infrastructure that is dedicated to it when you have adopted ASA.
Automatic lifecycle management
ASA provisions Linux identities in the local /etc files, without any of the problems traditionally associated with that approach. Because Lifecycle management is performed automatically, there is no manual intervention required to perform CRUD operations, even in large fleets of Linux servers. ASA’s agent-based “Pull” approach ensures that identities are synchronized automatically even in cases where a server was offline or unavailable for a period of time.
Enhanced security
ASA mints short-lived ephemeral certificates to authenticate users when they login to servers. ASA does not rely on static credentials such as passwords or SSH Keys, so there is no security concern regarding “credential sprawl” in your Linux environment, as no authentication credentials are maintained on the ASA-managed servers.
Easy adoption
ASA provides a simple migration path from the existing LDAP directory. Additionally, ASA provides DevOps friendly features that allow systems to automatically come under the management of ASA as they are provisioned.
The bottom line
Okta’s Advanced Server Access delivers a modern approach to identity management in Linux. ASA delivers a low TCO due to no requirement for on-premise directory infrastructure, and provides automated and reliable LCM operations, using Okta’s Universal Directory as its identity source. Because user authentication is performed locally on each server using /etc files, the performance bottleneck of the LDAP server is eliminated. ASA eliminates the security vulnerability of storing credentials on Linux servers, and enhances the security of the user identities by delivering a resilient client certificate-based authentication architecture. And finally, ASA delivers a secure, high-quality SSO user experience.
To learn more about Okta Advanced Server Access, check out the Advanced Server Access Product Page.
