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).
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.
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.
On Feb 21, 2014, at 14.14, Jefferson Davis jdavis@standard.k12.ca.us wrote:
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).
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.
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?)
refer to draft-howard-rfc2307bis-02 [doc/drafts/draft-howard-rfc2307bis-xx.txt], which defines posixgroup as aux. use the schema defined in this document instead of nis.
-ben
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
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
Philip Colmer philip.colmer@linaro.org schrieb am 24.02.2014 um 10:43 in
Nachricht
[...]
- 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.
[...]
So what did replace "rfc2307bis"? IMHO until there is a replacement, the old schema will continue to be used.
Regards, Ulrich
So what did replace "rfc2307bis"?
As far as I can tell, nothing replaced it. The schema wasn't adopted.
IMHO until there is a replacement, the old schema will continue to be
used.
You can certainly take that approach, but if the RFC isn't adopted, is that much different from making your own schema to solve a problem?
Regards
Philip
On 24 February 2014 12:16, Ulrich Windl Ulrich.Windl@rz.uni-regensburg.dewrote:
Philip Colmer philip.colmer@linaro.org schrieb am 24.02.2014 um
10:43 in Nachricht
[...]
- 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.
[...]
So what did replace "rfc2307bis"? IMHO until there is a replacement, the old schema will continue to be used.
Regards, Ulrich
Philip Colmer wrote:
This was an area where I also got stuck when researching this last year. My conclusions were:
- 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.
Nonsense. nss_ldap, nss-pam-ldapd, and nssov all support RFC2307bis.
Nonsense. nss_ldap, nss-pam-ldapd, and nssov all support RFC2307bis.
Just to clarify, then, are you saying that if I use RFC2307bis so that I can define a group that built from object classes posixGroup and groupOfNames, and I define the membership of that group using the groupOfNames member attribute then a Linux system configured to use LDAP will resolve a user's account name to their full DN for matching against that group? Are nested groups supported?
If that is the case, where can I find documentation for this, please?
Regards
Philip
On 24 February 2014 14:27, Howard Chu hyc@symas.com wrote:
Philip Colmer wrote:
This was an area where I also got stuck when researching this last year. My conclusions were:
- 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.
Nonsense. nss_ldap, nss-pam-ldapd, and nssov all support RFC2307bis.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Philip Colmer wrote:
Nonsense. nss_ldap, nss-pam-ldapd, and nssov all support RFC2307bis.
Just to clarify, then, are you saying that if I use RFC2307bis so that I can define a group that built from object classes posixGroup and groupOfNames, and I define the membership of that group using the groupOfNames member attribute then a Linux system configured to use LDAP will resolve a user's account name to their full DN for matching against that group? Are nested groups supported?
Yes, of course.
If that is the case, where can I find documentation for this, please?
You should consult the docs of your favourite NSS provider module/demon.
Ciao, Michael.
Philip Colmer wrote:
- 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.
Nope.
- 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.
Nope.
Nowadays most LDAP clients support to use rfc2307bis.
I also dropped using groupOfNames with MUST member and switched to use groupOfEntries with MAY member instead.
Ciao, Michael.
openldap-technical@openldap.org
-
btb＠bitrate.net -
Dieter Klünter -
Howard Chu -
Jefferson Davis -
Michael Ströder -
Philip Colmer -
Ulrich Windl