Sometimes organizations need to connect applications and devices via an LDAP server because they simply work best with LDAP. In some instances, organizations will just spin-up an OpenLDAP server and connect them together. In cases where there is an existing Microsoft Active Directory server in place, a greater challenge will be faced. Having AD act as an LDAP server can be quite tricky.
Tapping into the Relationship of AD and LDAP
In theory, Microsoft’s Active Directory started life as an LDAP-based directory server. Over time, though, Microsoft has largely moved to a proprietary version of Kerberos as its authentication mechanism. Microsoft has been able to extend Kerberos to work in the manner that is best for its solutions. However, the evolution from an LDAP foundation to a Kerberos-based authentication structure makes it more of a challenge to connect LDAP-based applications and devices back to AD.
Non-Windows Solutions are Calling, Who’s Answering?
This problem wasn’t as critical a decade ago because much of the IT resources found in any given organization were Microsoft-centric. Today, however, network infrastructures are heterogeneous. Windows is only one of the platforms present, since most organizations now also have Mac and Linux devices. Applications have undergone a couple of shifts, too. They’ve gone from being hosted on top of Windows Server to being hosted on top of Linux, and they’re now cloud-based. Many of these non-Windows solutions prefer to talk via LDAP.
Identity-as-a-Service Keeps the Conversation Going
In this situation, what options are available to IT organizations? One option is to implement a separate OpenLDAP server. While this creates a more straight forward connection with the LDAP application or device, it also means that the organization now has two directories. Sometimes the two are connected, but in most cases they are not. Having two directories increases the work and risk factors. Another option is to leverage a third-party Identity-as-a-Service (link to the yet published Identity Management Solutions post) platform that can serve as an LDAP endpoint.
In this scenario, Active Directory is synced with the cloud-hosted LDAP server. IT resources that require LDAP are pointed to the LDAP-as-a-Service server endpoint. The organization doesn’t need to spin-up or to manage their own LDAP infrastructure, thus saving time and effort. Another benefit? There exists only one core directory where users are managed.
If you would like to learn more about how your Active Directory infrastructure can also support an LDAP server, drop us a note. We’d be happy to discuss with you how JumpCloud’s Directory-as-a-Service can help support your requirements.