Bozeman Pass engineers were heavily involved with the development of what was once known as Netscape Directory Server, aka iPlanet Directory, aka SunDS, aka Fedora DS, and officially known today as 389 Directory Server. To save some typing and confusion we’ll call it “The DS” henceforth.
Wondering: “what’s a DS good for?” Well…whenever you have a population of users for some computing service there’s a need to : store user-specific information like username, mailing address, phone number, favorite animal. We also need some way to handle user authentication : should we allow this user to log? Is their password valid? Is their password too old, too weak? Often there’s also a need to decide on authorization : should this user be allowed to perform administrative tasks?
Look inside any Web Framework like Drupal, Django or WordPress and you’ll see these user-centric features implemented as code modules that use “user” tables in a database. One way to think of The DS as essentially just all that code wrapped up around its own database of user information, deployed as a microservice, and with an API that handles user management, authentication and authorization. The DS’s “API” is the LDAP protocol which incidentally pre-dates the Web and HTTP, although there is now an HTTP-based dialect. LDAP is very widely supported — in fact there is LDAP support in Drupal, Django and WordPress which replaces the native code for user management and authentication with a thin layer over the LDAP protocol.
Directory Services have their origins in network services designed to replace the telephone company’s phone book or white page. Because everything to do with the phone company was expected to be super-reliable and to cover a wide geographic area The DS itself was designed for the same reliability and distribution with support for multiple servers replicating with each other. Even today there are few self-deployable, eventually-consistent, replicated data stores with its level of battle tested reliability. For that reason we sometimes see the DS used in non-traditional applications simply to leverage its replication features.
Typically we are hired as consultants to advise on 389DS issues such as performance, hardware sizing, replication topology and configuration and on tooling and approaches for running the DS in production. We also get involved in analyzing and fixing bugs for our clients and we have the ability to build and maintain the DS for platforms not available in binary form from Red Hat, back to the first Open Source version. To get in touch about our LDAP Consulting Services please email the team at : info@bozemanpass.com or use our Contact page.
Recent Comments