So I've read, however, there is very little documentation on implementation, at least that I've been able to find.
----- Original Message -----
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