So I've read, however, there is very little documentation on implementation, at least that I've been able to find.
From: "Dieter KlÃnter" <dieter@dkluenter.de>
To: openldap-technical@openldap.org
Sent: Friday, February 21, 2014 10:55:58 PM
So I've read, however, there is very little documentation on implementation, at least that I've been able to find.
Subject: Re: strategy for getting groupOfNames (AD) and posixAccount (Unix) to coexist?
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
--