I'm working on implementing LDAP on my small 7-user home-network as
a learning practice. Eventually, I want to set up LDAP so that I
can write an open-source LDAP-to-OpenID bridge. I'm using OpenLDAP
2.3, and if these questions are better directed at that list let me
know.
It's been pretty easy so far (I've used LDAP as a programmer, but
not implemented it from scratch as an administrator), but I'm
hitting a wall that's basically just a lack of knowledge about how
LDAP implements (or can implement) groups.
Go nss and pull it from the OS.
Not an option, see below
One application that I use wants groups to have a multivalued
attribute containing the DN of each of its members. Another one
(nss_ldap on FreeBSD) wants groups to have a multivalued attribute
containing the UID of of each of its members (POSIX-style groups).
I am really curious on what is going on here. Sounds like that one
program is badly designed if it tries to pull group info that way
instead of from the OS.
It's a server in Java (written by the company that I work for), which
can't really pull that information from the OS. This isn't the only
application like this, other applications that I've tried to use with
LDAP (Drupal springs to mind) really want a multivalued attribute
containing the DN
1. I'd like to avoid duplicating this information over two
attributes 2. I'd really rather store the (unchanging) principalid
of each user and somehow have a dynamic attribute that will return
the memberuid or memberdn of each member when asked for these
attributes. 3. It might also be possible to convince nss_ldap to
determine groups based on a different attribute than the memberuid.
Is it? 4. I'd like to have somehow have referential integrity (like
foreign keys in SQL) that ensures that a given member actually
exists on creation. Is that possible in OpenLDAP?
1: Does not sound possible in this case do to what sounds like crappy
design of a program to stupid to properlly retrieve group info.
2: Not sure what you are asking.
I was asking whether these sorts of dynamic attributes are possible
3: AFAIK it is possible and easy. There should be a option for that
in the config, but why?
4: Not on any LDAP server I am aware of.
OpenLDAP 3.2 has a "referential integrity overlay". I was more asking
whether this was normal or an obviously bad idea
I'd be willing to give up any of these if it makes my schema more
common or standard, and likely to work with more applications in
the future that I might try out (drupal, GUI LDAP tools, sendmail,
etc). Having a weird or nonstandard LDAP schema seems like a bad
thing, especially if it's because I made it because I didn't
understand The LDAP Way(tm)
I've read a number of LDAP-related articles and most seem to walk
me through setting up POSIX style groups, which may be the easiest
to set up but seems to be the hardest to use in real applications
outside of nss_ldap. Does the answer lie in the inetorgperson,
Cosine, or OpenLDAP schemas, or something similar?
In most cases you will want POSIX groups. LDAP groups are largely
for administrative purposes... for like assign read write permissions
to stuff. If you have openldap installed, check out slapd.access(5).
POSIX groups are great when you're only using them to log in with
POSIX OSs.
Is there a simple article that I can read that can tell me about
this stuff? It seems that most articles online assume that I'm an
LDAP guru or totally new to the idea of directory services, with no
in- between. Are there any recommendable books directed at this
intermediate level of skill?
POSIX groups are cool. I also suggest using nss_ldap instead of
having a application try to talk directly to
I agree, wherever possible :)
Maybe I'm misunderstanding something about my company's product and
its interaction with LDAP. I (fortunately) did not write that code,
so I'll look further and see if I'm correct about it insisting on an
attribute containing the DN
---
You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
