🚀 go-pugleaf

I am writing a Java program that authenticates users and passwords against
profile objects stored in
an LDAP server.  In most of the sample code I've seen where people are
accessing LDAP via JNDI,
this sort of username / password matching is accomplished right inside the
initial BIND method.

This strikes me as something of a shortcut that relies upon a particular
assumption: that users of the LDAP
system, clients, objects to which access control policies apply, are ALSO
stored as data within the
directory.  In most other databases, authenticatable clients are stored as
some sort of meta-data, apart from
the actual contents of the tables and rows -- which may have nothing to do
with people.  In fact, when LDAP
is used to host SNMP information, this is actually the case -- the actual
contents of the directory have nothing
to do with human beings.  How do 'bind' operations translate into
dn/password lookups then?  Is this 'users as data' assumption always true
for LDAP -- or does it arise from a particular configuration of the server?
Is doing a 'bind'
basically the equivalent of searching for the object corresponding to a
particular dn -- and if that thing is of the 'person' objectClass or one of
its subclasses, looking for a 'password' attribute?

Any insight onto these questions would be greatly appreciated.

-Scott Gross
scott@thinairapps.com