This was an area where I also got stuck when researching this last year. My conclusions were:

1. UNIX needs group membership to be UIDs and not DNs, so attempts to use a class that defines members with DNs are likely to fail.
2. UNIX doesn't support nesting of groups. If you implement a solution that does support nested groups, e.g. using groupOf(Unique)Names, then confusion may arise when group membership doesn't behave the way you want it to.
3. rfc2307bis has expired so there won't be much (any?) application support for it. One of my key criteria when designing how our LDAP system was set up was to use classes that applications/systems were expecting to find.

In the end, I wrote a script that synced from posixGroup to groupOf(Unique)Names. The script is triggered automatically by the web front-end we use (LDAP Account Manager) when changes are made, plus a cron job runs the script every night to do a full re-sync of the groups in case an edit was made outside of the web front-end.

The script, for what it is worth, can be found here: http://people.linaro.org/~philip.colmer/floss2014/convert-secgrps.pl

Regards

Philip

On 22 February 2014 06:55, Dieter Klünter <dieter@dkluenter.de> wrote:
Am Fri, 21 Feb 2014 11:14:12 -0800 (PST)
schrieb Jefferson Davis <jdavis@standard.k12.ca.us>:

> This has been beating me like a red-headed stepchild...
>
> In the AD world, groupOfNames is expected (in combination with the
> member attribute, provides for reverse group resolution, ie users by
> group membership AND groups by member inclusion).

This can be achieved by overlay memberOf, man slapo-memberof(5).

> On the unix side of the fence, groups REQUIRE a gidNumber in order to
> resolve group membership, using posixGroup structural OC in
> conjunction with memberUID.

The rfc2307bis.schema provides auxiliary object classes to solve this.
In addition you may use the groupOfNames objectclass.

> In attempting to future-proof our ldap services, and to accommodate
> the AD-Focused nature of commercial products, I'm attempting to get
> this to all work automatically, ie use the same group setup for both
> (probably naive and ill-advised?). But you CANNOT have multiple
> structural objectclasses in a single entry. So these requirements put
> group structures in direct opposition of one another.
>
> Has anyone resolved this successfully, and if so, how? Overlays
> (which ones, examples)? Schema mods (examples?)
>
> Splitting groups off as unix groups vs windows groups (sync could get
> ugly) and could run into other issues with respect to file and dir
> permissions.
>
> I also need to avoid breaking smbldap-tools, which at the moment
> appears NOT to support the groupofnames model.


>
> Building this on CentOS 6, OpenLDAP 2.4.23-34, and migrating from
> older OpenLDAP version. I'm somewhat open to considering a different
> LDAP service (389/Apache/OpenDJ) though I've found java to be a
> resource pig in the extreme, and would prefer to avoid if possible.
>
> If you have this working I would love to see the relevant
> configuration files.

-Dieter

--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E