Search code examples
active-directoryldapdirectoryservicesapacheds

Besides user/auth info, what else should be stored in Directory Services?

This excellent answer explains the advantages of LDAP/Directories over RDBMSes under the right circumstances, but only mentions user account and auth-centric information as being the types of data to store in a directory.

The answer basically attributes the following advantages to a directory:

  • Tuned for ultra-fast reads, typical in an auth system
  • Scalability
  • Replication capabilities out of the box that are not easily achieved with most RDBMSes
  • Interoperability

I'm wondering what other use cases might warrant storing data in a directory. If read performance is the main benefit, then I would think any OLAP storage might be a decent candidate, such as a data warehouse or report generating system.

But I've had such limited experience with LDAP and directories, it's tough for me to see the "forest through the trees"; I've only seen user data stored in a directory, such as:

DC=example, DC=org, OU=Customer Service, CN=John Smith

I'm not entirely sure how this would translate to storing/querying non-user data.

Can someone clue me in as to what use cases, besides user/auth systems, would be prime candidates for storage in a directory, and provide an example or two of what an entry would look like in the directory, just so I can wrap my brain around how to store/organize non-user data?

Solution

  • Mine contains:

    • users
    • roles
    • password policies
    • entries for email accounts used by the system
    • entries for server hosts
    • entries for VM guests, arranged under their respective hosts
    • entries for server software modules, e.g. Apache HTTPD, Tomcat, MySQL, OpenLDAP itself, SSH, etc, and their replication slaves where applicable, showing their public URLs, arranged under their respective hosts or guests.
    • The previous item also includes our mail server, which is operated externally by the ISP, with URLs for its SMTP and POP3 ports and for the Webmail interface, the sort of thing it is too easy to forget.
    • entries for networks and subnets
    • entries for countries we operate in and the divisions that are in those countries

    In other words, beside user/auth information, a whole lot of stuff that is:

    • naturally hierarchical
    • non-transactional
    • mostly indicative
    • probably wouldn't be stored in a database at all, and
    • that can benefit from being organized and visible in one place, subject to backup and replication, etc.

    I also have an entry for the Site itself, containing its title &c for display on web pages.

    I also have a subtree for Products, showing their inter-relationships and bills of materials: our system doesn't really have a catalog per se but it does need to be explorable hierarchically via a Web page. These products are really documentSeries, each owning one or more documents, again with URLs. This actually serves to organize the site, without planting links everywhere.

    I also use it as an inventory of certain lab equipment that again wouldn't appear in a database.

    And I haven't had to write a single table schema.