[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Oracle OpenLDAP PPolicy ppolicy and the hierarchy

Arthur de Jong wrote:

On Wed, 2013-12-25 at 15:27 +0100, Michael StrÃder wrote:

Arthur de Jong wrote:

Additionally, if you plan to use the contents of the tree
as Unix users and want to have reasonable performance for
large trees, you should either:

- use memberUid attributes
- user member or uniqueMember with user with uid in the DN


I strongly disagree here.

1. memberUid does not allow to use the same group in OpenLDAP ACLs
Also it's not possible to use slapo-refint to check/update the
reference. Furthermore slapo-memberOf only works with DN-based
attributes. This old group scheme should die, die, die.


I know using DNs in groups can have some benefits in some ACLs and
internal LDAP state. Also, these methods allow for group nesting which
can be very convenient in some scenario's. But for external uses of LDAP
data such as Unix groups (posixGroup) the memberUid attribute is much
simpler to handle.
It's the job of the NSS driver to map LDAP data to POSIX data. No other applications have any legitimate reason to know about it. LDAP identifiers/references are DNs. The LDAP namespace is hierarchical; simple flat names are meaningless.
The fundamental flaw in the original RFC2307 was that it stored NIS data verbatim instead of storing the semantic meaning of the data. E.g., it stored password change and expiration times as /etc/shadow integers instead of actual "time" values. This is the wrong way to use LDAP. It made RFC2307 only directly useful for Solaris (and later Linux), as the stored values were incompatible with the corresponding concepts in e.g. AIX, HPUX, and various other OSs. The purpose of storing information in a distributed database like LDAP is to make it universally useful. The reason there are standardized syntaxes is to maximize the reusability of stored data. RFC2307 ignored the majority of these standards. It is a vivid example of how not to design an LDAP schema. 


2. As explained many times on this list the LDAP syntax
1.3.6.1.4.1.1466.115.121.1.34 (Name And Optional UID) is seriously
broken - especially when adding the arbitrary UID part behind a DN
with DirectoryString syntax in top-level DN part.


I haven't seen "Name And Optional UID" before. I was talking about
having a DN with the uid attribute in it such as
   uid=joe,ou=people,dc=example,dc=com
instead of
   cn=Joe Black,ou=people,dc=example,dc=com

With the first DN style for users you can extract the uid attribute from
the DN. This has some problems, when e.g. a posixAccount has multiple
uid attributes but that causes so many other nasty side-effects that you
don't want that anyway.

With the second form, you always have to do an extra lookup.


Not with the Deref control.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/