Hi all,
I've spent days trying to figure out how could I enable the memberOf overlay, and it doesn't seem to be easy for an LDAP-noob. I've read like 50+ tutorials which didn't help me get it working.
Use case: I want to have 2 main groups which control access to different services on my network. A "unixusers" which is a minimum to log in to Linux servers (having a hostObject entry for the user is another requirement, which is irrelevant to this question, as I already solved that problem); and a "cloudusers" group which enables log in to my ownCloud instance.
The groups should enforce the following rules: – Only users in "cloudusers" should be allowed to log in to ownCloud. – Users in "unixusers" are allowed to log in to a set of Linux servers controlled by "host" (hostObject) entries. – Users not in the "unixusers" group may not log in to any Linux systems, even if they have "host" entries.
Problems: – ownCloud complains that the memberOf overlay is not enabled, hence it doesn't let me restrict access to the "cloudusers" group. It would allow any users regardless of any group memberships, which is not acceptable. – I have a similar problem on Linux with PAM: I can't really get it to consider "unixusers" membership for user logins, although I got the "host" entries working correctly, so at least I can already restrict access with that.
My guess is that it all boils down to the lack of memberOf overlay. I also figured that memberOf would need groupOfNames groups, while I need posixGroup type groups. I evaluated the possibility to use groupOfNames, but it lacks the necessary gidNumber attribute which is a requirement for Unix groups. But anyway, I can't enable memberOf even for groupOfNames. I can't enable memberOf by any means.
My OpenLDAP uses the new configuration method and it completely ignores slapd.conf, so the config must be injected with ldapadd to cn=config.
Could you please help me with this?
Regards, MegaBrutal
On Wed, Sep 07, 2016 at 11:10:30PM +0200, MegaBrutal wrote:
I also figured that memberOf would need groupOfNames groups, while I need posixGroup type groups. I evaluated the possibility to use groupOfNames, but it lacks the necessary gidNumber attribute which is a requirement for Unix groups.
This is the key issue.
A draft schema known as "rfc2307bis" exists, which replaces (!) the published RFC2037 schema with one compatible with groupOfNames.
A published solution to this problem does not currently exist. In the past year there have been some discussions on the ldapext list. You can find the archives of that list at:
Le 08/09/2016 à 04:52, Ryan Tandy a écrit :
On Wed, Sep 07, 2016 at 11:10:30PM +0200, MegaBrutal wrote:
I also figured that memberOf would need groupOfNames groups, while I need posixGroup type groups. I evaluated the possibility to use groupOfNames, but it lacks the necessary gidNumber attribute which is a requirement for Unix groups.
This is the key issue.
A draft schema known as "rfc2307bis" exists, which replaces (!) the published RFC2037 schema with one compatible with groupOfNames.
A published solution to this problem does not currently exist. In the past year there have been some discussions on the ldapext list. You can find the archives of that list at:
Hi,
as a workaround, I often create a small connector that synchronises posixGroup objects into groupOfNames. It's really easy to do with LSC (http://www.lsc-project.org).
With this, you only manage POSIX groups, and standard groups are updated automatically. You can then use the memberOf overlay on groupOfNames.
Le 08/09/2016 à 09:45, Clément OUDOT a écrit :
Le 08/09/2016 à 04:52, Ryan Tandy a écrit :
On Wed, Sep 07, 2016 at 11:10:30PM +0200, MegaBrutal wrote:
I also figured that memberOf would need groupOfNames groups, while I need posixGroup type groups. I evaluated the possibility to use groupOfNames, but it lacks the necessary gidNumber attribute which is a requirement for Unix groups.
This is the key issue.
A draft schema known as "rfc2307bis" exists, which replaces (!) the published RFC2037 schema with one compatible with groupOfNames.
A published solution to this problem does not currently exist. In the past year there have been some discussions on the ldapext list. You can find the archives of that list at:
Hi,
as a workaround, I often create a small connector that synchronises posixGroup objects into groupOfNames. It's really easy to do with LSC (http://www.lsc-project.org).
With this, you only manage POSIX groups, and standard groups are updated automatically. You can then use the memberOf overlay on groupOfNames.
In case this solution interest someone, I wrote a small tutorial to configure LSC for it: https://lsc-project.org/documentation/tutorial/synchronizeposixgroupstogroup...
Hi,
We usually maintain both the posixGroup and groupOfNames in two separate subtrees. They have the same members, but each of them is using its own way to list the members. Our MidPoint is a great tool that can do that quite easily. It can make sure that both groups are created/deleted, that user is member of both groups, it can manage sequence of gidNumbers ... and much more. But any decent IDM should work as well. I strongly recommend this approach. You will need something to manage the directory content in the long run anyway. IDM systems are designed to do that.
Ryan Tandy wrote:
On Wed, Sep 07, 2016 at 11:10:30PM +0200, MegaBrutal wrote:
I also figured that memberOf would need groupOfNames groups, while I need posixGroup type groups. I evaluated the possibility to use groupOfNames, but it lacks the necessary gidNumber attribute which is a requirement for Unix groups.
This is the key issue.
A draft schema known as "rfc2307bis" exists, which replaces (!) the published RFC2037 schema with one compatible with groupOfNames.
A published solution to this problem does not currently exist. In the past year there have been some discussions on the ldapext list. You can find the archives of that list at:
Yet another approach: ;-)
In Æ-DIR I've declared hybrid groups derived from posixGroup (RFC 2307) and groupOfEntries for empty groups (see [1]) to accommodate legacy components not capable of being configured to RFC2307bis:
# This allows mixed group schema # also "dynamic groups" based on groupOfURLs/memberURL objectclass ( ae-dir-oc:1 NAME 'aeGroup' X-ORIGIN 'AE-DIR' DESC 'AE-DIR: Group entry' STRUCTURAL SUP ( groupOfEntries $ posixGroup $ groupOfURLs $ aeObject ) MUST ( description ) )
Furthermore a constraint to ensure consistency of 'member' and 'memberUID':
constraint_attribute memberUID,member set "this/memberUID & this/member/uid" restrict="ldap:///ou=ae-dir??sub"
[1] https://tools.ietf.org/html/draft-findlay-ldap-groupofentries
Ciao, Michael.
Thanks for the suggestions, but due to my inexperience in LDAP, these solutions seem to be too complicated for me. I'm thinking whether I should use hostObject to restrict access to ownCloud too. I tested, it is possible: I could easily add an LDAP filter in ownCloud to test for the "host" attribute. Maybe I will stick with that. However, I think I'm misusing the "host" attribute with this, as in my understanding it should be used for controlling shell-access, and not website-access. Is there a similar schema/attribute to control access to web services, or should I stick with hostObject?
openldap-technical@openldap.org
-
Clément OUDOT -
MegaBrutal -
Michael Ströder -
Radovan Semancik -
Ryan Tandy