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" <die...@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 <jda...@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 



-- 



Jefferson K Davis 
Technology and Information Systems Manager 
Standard School District 
1200 North Chester Ave 
Bakersfield, CA 93308 
661.392.2110 ext 120 (office) 
http://district.standard.k12.ca.us 

District Users: Click here to report technology issues 


Reply via email to