Reasons to store users' data in LDAP instead of RDBMS

Interoperability, as has already been mentioned, is very much in LDAP's favour with some types of server software, although much of the software that integrate with LDAP require a specific schema so it's not necessarily as simple as just installing and configuring an LDAP service and off you go - you might need to add new elements in the schema for each app you want to interact with, and each application might have different limitations with regard to authentication (for example plain text password fields, password fields as MD5 or SHA hashes, etc).

A good LDAP service requires a fair bit of configuration knowledge, more so than creating a simple schema in a relational database. SQL DB's are still a fairly interoperable option and LDAP support is not as dominant as it once was. LDAP used to be the only option years ago, but many applications (like Apache) and operating systems (like Linux's PAM) can authenticate against SQL DB's like MySQL just as easily as LDAP servers as it's all handled by drivers that abstract the interface.

Where LDAP really shines is scalability. If you specifically want a place to hold user accounts for authentication and want to scale to multiple replicated servers - and handle tends of thousands of authentication requests a second, LDAP is an great option.

It's not that modern RDBMS's don't scale it's just that LDAP is (typically) even better at this because of the way it cascades replication through different tiers; particularly assuming you have a typical authentication database setup where it's mostly read-only with relatively few write operations, so you only need one way replication with all writes coming from a single source of truth.

Really though, an LDAP server is something to consider if you have a specific need to do so, like a specific application you want to be able to interoperate with that only integrates with LDAP, or if you are building a highly scalable authentication system (e.g. for an ISP or for a super-scalable web application - where you plan on having more than a couple servers dedicated just to authentication, and where they may be spread across the country or even across the globe).

The point someone has already made about having an LDAP front end on an RDBMS is very good one. A few companies - including Oracle (who have a vested interest in RDBMSs, of course) - have products that do specifically that. If you don't want the overhead of managing an LDAP service, or if you just want to manage all your users in a DB you can create views/joins with, but think you might need an LDAP service later, than it's a good option. OpenLDAP also supports a shell back end which can take in data from any source, including an RDBMS; I've used it with MySQL and it works well, although can be a little fiddly to set up the first time if you need to support a specific LDAP schema.

In summary, LDAP is great, but it's situation specific to interoperability and extreme scalability. If you have limited resources to manage and support one, it might not be worth the hassle of supporting, but if you are planning services like UNIX hosted POP/IMAP/SMTP or other third party software integration then it's certainly worth doing (and may even be your only viable option).

Oh and lastly be wary of what LDAP server you use if you do decide to implement one! They are not all created equal and the differences between them (in terms of performance and ease of management & configuration) can be quite stark.

OpenLDAP is a pretty safe bet, scales well and is fairly easy to use. Some applications work best / come with specific configuration files for a specific LDAP server (e.g. a lot of software on Solaris assumes you are using Sun ONE directory server) which you might not otherwise want to use - either because it doesn't perform as well, or is a pig to configure, isn't well supported, etc.

Microsoft has created a TechNet article discussing their Active Directory Application Mode (ADAM) product and it has a section comparing the differences between a Directories and Databases. The following is taken directly from the site.

Directories

• Optimized for search and read operations.
• Object-oriented, hierarchical data design. Data objects in the directory represent entities such as users, computers, and shared resources. These data objects can be organized hierarchically in containers.
• Does not use schemas.
• Designed for replication and distributed management.
• Precise security, down to the object and attribute level.
• Loose data consistency between replication partners.

Databases

• Optimized for write operations.
• Relational data design. Data is organized in tables of rows and columns. Data from one table can be linked to data in another table.
• Uses standardized, extensible schemas.
• Designed for central storage and administration of data.
• Less precise security, only down to the row and column level.
• Transactional — guaranteed data consistency. Referential integrity across relational tables and concurrency control with file and record locking.