[openldap] memberOf overlay does not work

[mohsensamiei]

Name and Version

bitnami/openldap:2.6.3

What steps will reproduce the bug?

Hey Hi have setup openldap with this docker-compose

version: "3.9"

volumes:
  openldap_data:

services:
  openldap:
    image: bitnami/openldap:2
    ports:
      - 1389:1389
      - 1636:1636
    environment:
      - LDAP_ROOT=dc=example,dc=com
      - LDAP_ADMIN_USERNAME=admin
      - LDAP_ADMIN_PASSWORD=adminpassword
    volumes:
      - openldap_data:/bitnami/openldap

So execute this:

dn: ou=groups,dc=example,dc=com
objectclass: organizationalUnit
ou: groups

dn: ou=users,dc= example,dc=com
objectclass: organizationalUnit
ou: users

dn: cn=user01,ou=users,dc= example,dc=com
cn: user01,
objectclass: inetOrgPerson
objectclass: top
sn: bar01
uid: user01

dn: cn=group01,ou=groups,dc= example,dc=com
cn: group01
member: cn= user01,ou=users,dc= example,dc=com
objectclass: groupOfNames
objectclass: top

dn: cn= group02,ou=groups,dc= example,dc=com
cn: group02
objectclass: groupOfUniqueNames
objectclass: top
uniquemember: cn= user01,ou=users,dc= example,dc=com

What is the expected behavior?

when i get user01, memberOf attribute does not set

dn: cn=user01,ou=users,dc= example,dc=com
cn: user01
createtimestamp: 20220719080619Z
creatorsname: cn=admin,dc=example,dc=com
entrycsn: 20220719080619.489607Z#000000#000#000000
entrydn: cn= user01,ou=users,dc= example,dc=com
entryuuid: 6a597960-9b85-103c-89c9-2986caa8c126
hassubordinates: FALSE
modifiersname: cn=admin,dc= example,dc=com
modifytimestamp: 20220719080619Z
objectclass: inetOrgPerson
objectclass: top
structuralobjectclass: inetOrgPerson
subschemasubentry: cn=Subschema
uid: user01

What do you see instead?

I want to see memberOf attribute also:

dn: cn=user01,ou=users,dc= example,dc=com
memberof: cn=group01,ou=groups,dc= example,dc=com
memberof: cn= group02,ou=groups,dc=example,dc=com
...

Additional information

Thanks for your help

[javsalgar]

Hi,

Could you share the exact commands that trigger the issue? We would like to properly reproduce it on our side.

[mohsensamiei]

Sure, but I'm golang developer and source of commands is in go docker-compose.yml

version: "3.9"

volumes:
  openldap_data:

services:
  openldap:
    image: bitnami/openldap
    ports:
      - 1389:1389
      - 1636:1636
    environment:
      - LDAP_ROOT=dc=example,dc=com
      - LDAP_ADMIN_USERNAME=admin
      - LDAP_ADMIN_PASSWORD=adminpassword
    volumes:
      - openldap_data:/bitnami/openldap

main.go

package main

import (
	"github.com/go-ldap/ldap/v3"
	"log"
	"strings"
)

func main() {
	conn, err := ldap.DialURL("ldap://localhost:1389")
	if err != nil {
		panic(err)
	}
	if err = conn.Bind("cn=admin,dc=example,dc=com", "adminpassword"); err != nil {
		panic(err)
	}
	defer conn.Close()

	if err = conn.Add(&ldap.AddRequest{
		DN: "ou=groups,dc=example,dc=com",
		Attributes: []ldap.Attribute{
			{
				Type: "objectClass",
				Vals: []string{"organizationalUnit"},
			},
		},
		Controls: nil,
	}); err != nil {
		panic(err)
	}

	if err = conn.Add(&ldap.AddRequest{
		DN: "cn=group01,ou=groups,dc=example,dc=com",
		Attributes: []ldap.Attribute{
			{
				Type: "objectClass",
				Vals: []string{"groupOfNames", "top"},
			},
			{
				Type: "member",
				Vals: []string{"cn=user01,ou=users,dc=example,dc=com"},
			},
		},
		Controls: nil,
	}); err != nil {
		panic(err)
	}

	if err = conn.Add(&ldap.AddRequest{
		DN: "cn=group02,ou=groups,dc=example,dc=com",
		Attributes: []ldap.Attribute{
			{
				Type: "objectClass",
				Vals: []string{"groupOfUniqueNames", "top"},
			},
			{
				Type: "uniqueMember",
				Vals: []string{"cn=user02,ou=users,dc=example,dc=com"},
			},
		},
		Controls: nil,
	}); err != nil {
		panic(err)
	}

	searchReq := ldap.NewSearchRequest("dc=example,dc=com",
		ldap.ScopeWholeSubtree,
		ldap.NeverDerefAliases,
		0,
		0,
		false,
		"(objectClass=inetOrgPerson)",
		[]string{"*", "+"},
		nil)
	result, err := conn.Search(searchReq)
	if err != nil {
		panic(err)
	}
	for _, entry := range result.Entries {
		for _, attribute := range entry.Attributes {
			if strings.ToLower(attribute.Name) == "memberof" {
				log.Print("Goal !!")
			}
		}
	}
}

run these commands:

docker compose up -d
go run .
docker compose down -v

Can this help you?

[mohsensamiei]

is there any updates?

[javsalgar]

Does the same issue happen when you use the OpenLDAP shell command equivalents?

[mohsensamiei]

OK Run bitnami openldap with this docker-compose.yml

version: "3.9"

volumes:
  openldap_data:

services:
  openldap:
    container_name: openldap
    image: bitnami/openldap
    ports:
      - 1389:1389
      - 1636:1636
    environment:
      - LDAP_ROOT=dc=example,dc=com
      - LDAP_ADMIN_USERNAME=admin
      - LDAP_ADMIN_PASSWORD=adminpassword
    volumes:
      - openldap_data:/bitnami/openldap

So by default it's create an OU with this DN ou=users,dc=example,dc=com and create 2 users with these DN user01,ou=users,dc=example,dc=com, user02,ou=users,dc=example,dc=com Then exec the container with docker exec -it openldap bash and create test ldif file with cat > test.ldif

dn: ou=groups,dc=example,dc=com
objectclass: organizationalUnit
ou: groups

dn: cn=group01,ou=groups,dc=example,dc=com
cn: group01
objectclass: groupOfNames
member: cn= user01,ou=users,dc=example,dc=com

dn: cn= group02,ou=groups,dc=example,dc=com
cn: group02
objectclass: groupOfUniqueNames
uniquemember: cn= user01,ou=users,dc=example,dc=com

and add test.ldif to ldap with ldapadd -H "ldapi:///" -D cn=admin,dc=example,dc=com -w adminpassword -f test.ldif, so see the result:

adding new entry "ou=groups,dc=example,dc=com"

adding new entry "cn=group01,ou=groups,dc=example,dc=com"

adding new entry "cn= group02,ou=groups,dc=example,dc=com"

and then search in ldap for user01 with ldapsearch -D cn=admin,dc=example,dc=com -w adminpassword -H "ldapi:///" -s base -b cn=user01,ou=users,dc=example,dc=com +, see the result:

# extended LDIF
#
# LDAPv3
# base <cn=user01,ou=users,dc=example,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: + 
#

# user01, users, example.com
dn: cn=user01,ou=users,dc=example,dc=com
structuralObjectClass: inetOrgPerson
entryUUID: 91f113ee-9d55-103c-8b5c-69baf3ded424
creatorsName: cn=admin,dc=example,dc=com
createTimestamp: 20220721152852Z
entryCSN: 20220721152852.391580Z#000000#000#000000
modifiersName: cn=admin,dc=example,dc=com
modifyTimestamp: 20220721152852Z
entryDN: cn=user01,ou=users,dc=example,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

So there is not memberOf attribute in entry :)

[mohsensamiei]

Do you think this problem can be fixed? @javsalgar

[carrodher]

We are going to transfer this issue to bitnami/containers

In order to unify the approaches followed in Bitnami containers and Bitnami charts, we are moving some issues in bitnami/bitnami-docker-<container> repositories to bitnami/containers.

Please follow bitnami/containers to keep you updated about the latest bitnami images.

More information here: https://blog.bitnami.com/2022/07/new-source-of-truth-bitnami-containers.html

[gongomgra]

Hi @mohsensamiei,

I reviewed our compilation process and I found out we are not setting the --enable-memberof flag in the compilation process of OpenLDAP, which I understand can cause this issue. I will open a new task for our engineering team to update the compilation process and release a new revision of the image. Unfortunately, we can't provide you with an estimation on when this will be updated, but our team will post a new message here once it is finished.

[zcahana]

I've just came across this issue myself as well. As an interim workaround until the memberOf support is compiled into the image, is there some way to configure the image to enable the memberOf overlay?

[fmulero]

You can enable memberOf feature with the following example, so there is no need to compile it with a special flag:

version: '2'

services:
  openldap:
    image: docker.io/bitnami/openldap:2.6
    ports:
      - '1389:1389'
      - '1636:1636'
    environment:
      - BITNAMI_DEBUG=yes
      - LDAP_ADMIN_USERNAME=admin
      - LDAP_ADMIN_PASSWORD=adminpassword
      - LDAP_ROOT=dc=example,dc=com
      - LDAP_GROUP=group01
      - LDAP_USERS=user01,user02
      - LDAP_PASSWORDS=password1,password2
      - LDAP_EXTRA_SCHEMAS=cosine,inetorgperson,nis,memberof
    volumes:
      - 'openldap_data:/bitnami/openldap'
      - './ldifs/memberof.ldif:/opt/bitnami/openldap/etc/schema/memberof.ldif'

volumes:
  openldap_data:
    driver: local

And the content of ldifs/memberof.ldif:

dn: cn=module,cn=config
cn: module
objectClass: olcModuleList
olcModulePath: /opt/bitnami/openldap/lib/openldap
olcModuleLoad: memberof.so
olcModuleLoad: refint.so

dn: olcOverlay=memberof,olcDatabase={2}mdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
olcOverlay: memberof

dn: olcOverlay=refint,olcDatabase={2}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
objectClass: top
olcOverlay: refint
olcRefintAttribute: memberof member manager owner

Now if you run the command ldapsearch -D cn=admin,dc=example,dc=com -w adminpassword -H "ldapi:///" -s base -b cn=user01,ou=users,dc=example,dc=com + you will see something like this:

# extended LDIF
#
# LDAPv3
# base <cn=user01,ou=users,dc=example,dc=com> with scope baseObject
# filter: (objectclass=*)
# requesting: +
#

# user01, users, example.com
dn: cn=user01,ou=users,dc=example,dc=com
structuralObjectClass: inetOrgPerson
entryUUID: 7c16f16c-b3dd-103c-9bfe-e3c7b80ddf65
creatorsName: cn=admin,dc=example,dc=com
createTimestamp: 20220819073712Z
entryCSN: 20220819073712.866203Z#000000#000#000000
modifyTimestamp: 20220819073712Z
memberOf: cn=group01,ou=users,dc=example,dc=com
modifiersName: cn=admin,dc=example,dc=com
entryDN: cn=user01,ou=users,dc=example,dc=com
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

[github-actions[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions[bot]]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

[xuzheng0017]

If the type of group is groupOfUniqueNames, try this config:

dn: cn=module,cn=config
cn: module
objectClass: olcModuleList
olcModulePath: /opt/bitnami/openldap/lib/openldap
olcModuleLoad: memberof.so
olcModuleLoad: refint.so

dn: olcOverlay=memberof,olcDatabase={2}mdb,cn=config
objectClass: olcConfig
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfUniqueNames
olcMemberOfMemberAD: uniqueMember
olcMemberOfMemberOfAD: memberOf

dn: olcOverlay=refint,olcDatabase={2}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
objectClass: top
olcOverlay: refint
olcRefintAttribute: memberof uniqueMember manager owner

[tylerstanczak]

I'm deploying this container on OpenShift and I don't see the memberOf attribute for the user...

$ ldapsearch -H "ldapi:///" -D "cn=admin,dc=example,dc=org" -w admin -s children -b "dc=example,dc=org"
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=org> with scope children
# filter: (objectclass=*)
# requesting: ALL
#

# users, example.org
dn: ou=users,dc=example,dc=org
objectClass: organizationalUnit
ou: users

# user, users, example.org
dn: cn=user,ou=users,dc=example,dc=org
cn: User1
cn: user
sn: Bar1
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
userPassword:: dXNlcg==
uid: user
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/user

# group-test, users, example.org
dn: cn=group-test,ou=users,dc=example,dc=org
cn: group-test
objectClass: groupOfNames
member: cn=user,ou=users,dc=example,dc=org

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3

I created a new group to see if it would have any different behavior, but memberOf is still not present on the user object.

$ ldapadd -H "ldapi:///" -D "cn=admin,dc=example,dc=org" -w admin
dn: cn=mygroup,ou=users,dc=example,dc=org
objectClass: groupofnames
cn: mygroup
description: All users
member: cn=user,ou=users,dc=example,dc=org

adding new entry "cn=mygroup,ou=users,dc=example,dc=org"

Search user object again:

$ ldapsearch -H "ldapi:///" -D "cn=admin,dc=example,dc=org" -w admin -s base -b "cn=user,ou=users,dc=example,dc=org"
# extended LDIF
#
# LDAPv3
# base <cn=user,ou=users,dc=example,dc=org> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#

# user, users, example.org
dn: cn=user,ou=users,dc=example,dc=org
cn: User1
cn: user
sn: Bar1
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
userPassword:: dXNlcg==
uid: user
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/user

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

[robigan]

It isn't working for me either, I can see the module being loaded and the entries regarding the oldModuleLoad etc. but no memberOf field

[robigan]

Nvm, somehow now it wishes to work

[thomas-mc-work]

Thanks, @fmulero, your example is working for me! But sadly not the one from @xuzheng0017. I'm working in a fresh instance, so no side effects to impair the result.

[Dzordzu]

For onlookers:

If you want to use it with groupOfNames, go on with @fmulero config

In case of groupOfUnqiueNames use this (modified and working version of this answer)

dn: cn=module,cn=config
cn: module
objectClass: olcModuleList
olcModulePath: /opt/bitnami/openldap/lib/openldap
olcModuleLoad: memberof.so
olcModuleLoad: refint.so

dn: olcOverlay=memberof,olcDatabase={2}mdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
olcOverlay: memberof
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfUniqueNames
olcMemberOfMemberAD: uniqueMember
olcMemberOfMemberOfAD: memberOf

dn: olcOverlay=refint,olcDatabase={2}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
objectClass: top
olcOverlay: refint
olcRefintAttribute: memberof uniqueMember manager owner

[wotsyula]

I'm going to post my workaround in case anyone needs it:

00-modules.ldif

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: memberof
olcModuleLoad: refint

01-memberof.ldif

dn: olcOverlay=memberof,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcConfig
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf

02-refint.ldif

dn: olcOverlay=refint,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
objectClass: top
olcOverlay: refint
olcRefintAttribute: memberof member manager owner