I know, I’ve read the arguments over why a “directory” is different
from a “database” (at least of the relational kind), and why LDAP is
not SQL. I understand that the kinds of records that LDAP deals with
can belong to different object classes in a way that is quite at odds
with the relational mindset.
But there is one little area where LDAP seems to have trouble. I’m
looking at moving the authorized-user database for a customer
installation from the traditional *nix /etc/passwd file (and friends)
into an LDAP directory. I find there is already a set of relevant
classes and attributes (from Sun?) in their “NIS schema”.
I see this has suitable definitions for all the necessary fields in
the passwd, shadow and group files etc. Except ... how does it
represent the fact that a user can be a member of multiple groups?
Turns out they hadn’t quite figured that out to begin with. In a
relational database, the obvious answer is to define the groups in a
separate table, and then have a user-group association table which can
have any number of entries, each associating one user with one group.
But of course LDAP cannot, will not, work that way. Instead, I find a
couple of proposed specs, like <
https://github.com/jtyr/rfc2307bis>
and <
https://datatracker.ietf.org/doc/html/draft-findlay-ldap-groupofentries-00>, which seem to have expired before they could be officially approved.
OK, so LDAP wants to allow unnormalized fields, which is generally
frowned on in a relational database. So why didn’t they use that
facility? Make the gidNumber field in the posixAccount record
multi-valued? That would have solved the problem in a simple way.
Instead, you have to do lookups on a separate table (sorry, “domain”)
to get the group memberships for a user.
In SQL, you could do a join to retrieve the user info and their groups
all in the same query. Not possible in LDAP, for some reason.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)