This discussion is archived
1 Reply Latest reply: May 11, 2009 6:56 AM by 433455 RSS

OpenLDAP integration with posixGroup

snmdla Explorer
Currently Being Moderated
Dear apiculturists,

with an OpenLDAP directory install on SuSE enterprise linux,
LDAP-based administration of groups appears to be based on the
structural objectclass posixGroup, which has plain usernames in the
attribute memberUid, e.g.

dn: cn=agroup,ou=group,dc=mycorp,dc=com
objectClass: posixGroup
objectClass: sambaGroupMapping
cn: agroup
gidNumber: 1076
sambaSID: S-1-0-11-0815081508-44905045-1282156110-2119
sambaGroupType: 2
displayName: agroup
description: adescription
memberUid: amember
memberUid: bmember
memberUid: cmember

At our site, several applications (not only SLES) make use of this
structure.

Now it appears that beehive requires the syntax of the objectclass
groupOfNames, with dns in the attribute member, e.g.:

dn: cn=agroup,ou=group4beehive,dc=mycorp,dc=com
objectClass: groupOfNames
cn: agroup
description: adescription
member: uid=required_member_for_empty_group,ou=people,dc=mycorp,dc=com
member: uid=ambember,ou=people,dc=mycorp,dc=com
member: uid=bmember,ou=people,dc=mycorp,dc=com
member: uid=cmember,ou=people,dc=mycorp,dc=com

Through Oracle Support we found out that currently nothing can be said
if and when beehive 1.x might support posixGroup entries, too (there
is an enhancement request 8278412 "ALLOW GROUP MEMBERSHIP
SYNC BASED ON UID").

Our workaround will probably be writing a filtering procedure
transforming the posixGroup structure in
"dn: cn=agroup,ou=group,dc=mycorp,dc=com"
to an equivalent groupOfNames structure within
"dn: cn=agroup,ou=group4beehive,dc=mycorp,dc=com"

Are there other current or potential beehive customers with
OpenLDAP that are facing the same problem?
Did perhaps even some of you also implement a workaround? Would be
interested to know or discuss this, as this is quite an
issue for us.

Regards, Thomas

P.S.

-groupOfNames is insufficient for managing Unix groups as it does not
provide a gidNumber

-PosixGroup and groupOfNames are mutually exclusive, so we cannot
store the gidNumber where the groupOfNames info lives

-SuSE Linux appears to have no mechanisms to automatically sync such
two separate group entries (one carrying PosixGroup, the other
carrying groupOfNames info)

-implementing the rfc2307bis Schema could bring posixGroup and
groupOfNames info together, but still the would need to get synched.

-implementing nss_map_attribute in /etc/libnss-ldap.conf could make
SuSE use groupOfNames, but we saw that the other applications using
the directory are all tuned to read posixGroup format

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points