In Blog, Cloud Infrastructure, Directory-as-a-Service (DaaS), LDAP

difference LDAP and DaaS

We are often asked how the JumpCloud® Directory-as-a-Service® platform compares to the open source directory service, OpenLDAP™. This is a bit like comparing apples and oranges, or at least variants of apples. You can like and leverage both, but there are reasons to leverage one over the other in different areas. A core piece of information to understanding this comparison is that Directory-as-a-Service leverages the LDAP protocol as part of its solution.

The Difference Between LDAP and Directory-as-a-Service

Core differences center around these areas:

  1. Authenticating devices. Leveraging the LDAP protocol to bind devices is straightforward when thinking about Linux® machines. As soon as you start to include Mac® and Windows® devices the complexity increases significantly. In fact, connecting a Mac to LDAP can be upwards of 30 steps. That workload becomes unmanageable when you have a fleet of devices. User management is remarkably simplified on Windows, Mac, and Linux when leveraging the agent architecture on the Directory-as-a-Service platform. A use-case that we do see occasionally is leveraging an OpenLDAP server as an Infrastructure-as-a-Service provider such as AWS® to manage user access to Linux servers. Even in this case, there are downsides for LDAP including the management and security of the system.
  1. Authenticating applications. Many legacy, on-premises applications leverage LDAP as a protocol to connect to a directory service. Examples of these applications include Jira, MySQL and many others. Both Directory-as-a-Service and LDAP solutions are able to connect to applications and manage user access. Each can manage group access and permissions. Perhaps the only significant difference on this segment is that because Directory-as-a-Service is provided with support resources, IT admins have help and assistance when dealing with the tedious process of connecting their application to LDAP.
  1. Device management. One of the most significant differences between LDAP and Directory-as-a-Service is device management. Where LDAP was designed only as an authentication and authorization protocol, Directory-as-a-Service was built to also manage Windows, Mac, and Linux devices. Device management is a core aspect of directory services in modern organizations, and includes the ability to set security policies, update systems and configure them properly. LDAP has no ability to help in this area. (Microsoft®’s Active Directory® led the movement to include device management within directory services.)
  1. Custom schema. If you need to edit and manage your LDAP database schema, your best bet is managing it yourself, including OpenLDAP. Commercial Directory-as-a-Service platforms, while sufficient, will not be nearly as flexible as doing it yourself with OpenLDAP. Very few organizations need the ability to customize the LDAP schema, but if it’s necessary, OpenLDAP is often the best choice.
  1. Managed versus unmanaged. Depending upon how busy your organization is, and you are, you may want to consider outsourcing your LDAP needs. Directory-as-a-Service delivers this, and more, acting as a third party to manage the LDAP server and software. This pushes the requirements around availability, reliability, and security to a third party and off of the internal IT team’s plate.
  1. Technical expertise. LDAP is a notoriously difficult protocol to master. Connecting various IT resources to it is tedious at best, and as a result, requires significant time and expertise. Directory-as-a-Service is an opportunity to tap into the LDAP expertise of a third-party.

Comparing LDAP and Directory-as-a-Service isn’t as simple as a direct comparison. Directory-as-a-Service is a modern directory service platform, while OpenLDAP is an open source instantiation of the LDAP protocol. Both solutions can have value in your network. If you have questions about which one is right for you, drop us a note and we’d be happy to discuss it with you.

Recent Posts