OpenLDAP memberof Overlay - ldap

I am currently trying to create an OpenLDAP Server that has a memberOf attribute for users.
Using cn=config, I loaded the memberof Module (lsof says, it is really loaded) and added the overlay to my database.
Parts of ldapsearch -b cn=config -D 'cn=root,cn=config' -W:
# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/openldap
olcModuleLoad: {0}memberof
olcModuleLoad: {1}refint
# {1}bdb, config
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcDbDirectory: /var/lib/openldap/openldap-data
olcSuffix: dc=mydomain,dc=com
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=root,dc=mydomain,dc=com
olcRootPW: ***
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbCacheSize: 1000
olcDbConfig: {0}# $OpenLDAP$
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}set_cachesize 0 268435456 1
olcDbConfig: {17}
olcDbConfig: {18}# Data Directory
olcDbConfig: {19}#set_data_dir db
olcDbConfig: {20}
olcDbConfig: {21}# Transaction Log settings
olcDbConfig: {22}set_lg_regionmax 262144
olcDbConfig: {23}set_lg_bsize 2097152
olcDbConfig: {24}#set_lg_dir logs
olcDbConfig: {25}
olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: dc eq
olcDbIndex: sn pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
# {0}memberof, {1}bdb, config
dn: olcOverlay={0}memberof,olcDatabase={1}bdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
But even if I delete all users and groups and recreate them, no memberOf is generated.
# mydomain.com
dn: dc=mydomain,dc=com
objectClass: dcObject
objectClass: organization
dc: mydomain
o: My sample LDAP
# users, mydomain.com
dn: ou=users,dc=mydomain,dc=com
ou: users
objectClass: organizationalUnit
objectClass: top
# groups, mydomain.com
dn: ou=groups,dc=mydomain,dc=com
ou: groups
objectClass: organizationalUnit
objectClass: top
# admin, users, mydomain.com
dn: cn=admin,ou=users,dc=mydomain,dc=com
sn: tester
cn: admin
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
# users, groups, mydomain.com
dn: cn=users,ou=groups,dc=mydomain,dc=com
member: dc=com,dc=mydomain,ou=users,cn=admin
cn: users
objectClass: groupOfNames
objectClass: top
To verify the DN of the member attribute in the group, I installed Atlassian Stash and added the LDAP. It detects that the user belongs to this group.
Is there anything I did wrong?

member: dc=com,dc=mydomain,ou=users,cn=admin
That's back to front. It should be
member: cn=admin,ou-users,dc=mydomain,dc=com

Related

How to add OU in LDAP?

I have done LDAP setup on ubuntu, using apt install slapd ldap-utils
after doing all setup/configuration, added one test user also and here I get:
$ ldapsearch -x -b "dc=param,dc=co,dc=in"
# extended LDIF
#
# LDAPv3
# base <dc=param,dc=co,dc=in> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# param.co.in
dn: dc=param,dc=co,dc=in
objectClass: top
objectClass: dcObject
objectClass: organization
o: param
dc: param
# admin, param.co.in
dn: cn=admin,dc=param,dc=co,dc=in
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
# testuser, param.co.in
dn: uid=testuser,dc=param,dc=co,dc=in
cn: test
sn: test
mail: testuser#param.co.in
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: testuser
# search result
search: 2
result: 0 Success
# numResponses: 4
# numEntries: 3
Now I wanted to add OU with following ou.ldif file:
cn: ou=people,dc=param,dc=co,dc=in
objectClass: top
objectClass: organizationalUnit
ou: people
cn: ou=groups,dc=param,dc=co,dc=in
objectClass: top
objectClass: organizationalUnit
ou: groups
But it is giving no results i.e. no success neither error after adding this file using command:
$ ldapadd -x -W -D "cn=admin,dc=param,dc=co,dc=in" -f ou.ldif
Enter LDAP Password:
$
What wrong thing exactly am i doing here?
change 'cn' to 'dn' for distinguished name. 'cn' is common name which would just be 'people' or 'groups' (except OUs don't need a CN). so it would be:
dn: ou=people,dc=param,dc=co,dc=in
objectClass: top
objectClass: organizationalUnit
ou: people
dn: ou=groups,dc=param,dc=co,dc=in
objectClass: top
objectClass: organizationalUnit
ou: groups

How do I list all the entries in LDAP directory information tree?

I'm running OpenLDAP 2.4.42, and this is my configuration file:
include C:/OpenLDAP/schema/core.schema
include C:/OpenLDAP/schema/cosine.schema
include C:/OpenLDAP/schema/inetorgperson.schema
pidfile C:/data/slapd/pidfile.pid
database config
database monitor
access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,dc=my,dc=org" write
access to * by * write
database bdb
include C:/data/pwm/openldap.schema
directory C:/data/slapd/db/bdb
suffix dc=example,dc=it
rootdn cn=root,dc=example,dc=it
rootpw secret
access to * by * manage
index default pres,eq
index cn eq,sub
index sn pres,eq,sub
index objectClass eq
With this slapcat (cut) output:
dn: cn=paul,dc=example,dc=it
objectClass: organizationalRole
cn: paul
dn: l=somewhere,dc=example,dc=it
objectClass: top
objectClass: locality
l: somewhere
dn: cn=john,l=somewhere,dc=example,dc=it
objectClass: organizationalRole
cn: john
structuralObjectClass: organizationalRole
dn: ou=users,dc=example,dc=it
objectClass: organizationalUnit
ou: users
structuralObjectClass: organizationalUnit
dn: cn=charles,ou=users,dc=example,dc=it
objectClass: person
objectClass: pwmUser
cn: charles
sn: charles
userPassword:: bWFyY28y
structuralObjectClass: person
Why does this return results (actually the "charles" entry):
ldapsearch -W -D cn=root,dc=example,dc=it -b "ou=users,dc=example,dc=it"
while this gives "no such object"?
ldapsearch -W -D cn=root,dc=example,dc=it -b "dc=example,dc=it"
I would think that the latter is the most general version of a search, where I'm asking for everything under that suffix.

LDAP Replication centos 6

I am following reference from http://tech.cbjck.de/2013/03/25/ldap-replication/ for replication. I am running on Centos 6.
Now I am stuck at creating provider.ldif at provider side.
CLI:
ldapadd -Y EXTERNAL -H ldapi:/// -f /tmp/provider.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
ldapadd: wrong attributeType at line 5, entry "olcDatabase={2}bdb,cn=config"
Bellow is the provider.ldif code:
# new
dn: olcDatabase={2}bdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN eq
add: olcDbIndex
olcDbIndex: entryUUID eq
delete: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=Manager,dc=my-domain,dc=com" write by * none
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=Manager,dc=my-domain,dc=com" write by dn="cn=synchronisator,dc=my-domain,dc=com" read by * none
#Load the syncprov and accesslog modules.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
add: olcModuleLoad
olcModuleLoad: accesslog
# Accesslog database definitions
dn: olcDatabase={2}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}bdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=Manager,dc=my-domain,dc=com
olcBbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
olcAccess: to * by dn="cn=synchronisator,dc=my-domain,dc=com" write
# Accesslog db syncprov.
dn: olcOverlay=syncprov,olcDatabase={2}bdb,cn=config
changtype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
# syncrepl Provider for primary db
dn: olcOverlay=syncprov,olcDatabase={2}bdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
# accesslog overlay definitions for primary db
dn: olcOverlay=accesslog,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=accesslogi
olcAccessLogOps: writes
olcAccessLogSuccess: TRUE
olcAccessLogPurge: 02+00:00 00+00:01
Besides, I did openLDAP installation by following instruction http://docs.adaptivecomputing.com/vi...POnCentos6.htm
So my database is bdb I think.
This is my olcDatabase={2}bdb configuration:
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 6ee7367c
dn: olcDatabase={2}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcSuffix: dc=my-domain,dc=com
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=Manager,dc=my-domain,dc=com
olcRootPW: {SSHA}Jit0MhF2L+h7euITiPQLWlGq5g0qPeq+
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 1000
olcDbCheckpoint: 1024 15
olcDbConfig: {0}# $OpenLDAP$
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB datab
ases.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley
-db/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maW
xlPTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon
rebuilding
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}set_cachesize 0 268435456 1
olcDbConfig: {17}
olcDbConfig: {18}# Data Directory
olcDbConfig: {19}#set_data_dir db
olcDbConfig: {20}
olcDbConfig: {21}# Transaction Log settings
olcDbConfig: {22}set_lg_regionmax 262144
olcDbConfig: {23}set_lg_bsize 2097152
olcDbConfig: {24}#set_lg_dir logs
olcDbConfig: {25}
olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "q
uick"
olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdG
hlaXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass pres,eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: ou pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: loginShell pres,eq
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 5ec21964-8a8d-1035-8e79-750eecdc11b0
creatorsName: cn=config
createTimestamp: 20160330063542Z
entryCSN: 20160330063542.541411Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20160330063542Z
Could anyone help me find out how to solve this error? I would be grateful for your kindly help?
Get rid of all the {0}s, {1}s {2}s, etc. OpenLDAP will put them in itself as necessary,

What's the "Invalid syntax" in this LDAP automount command/file?

I want to use LDAP to automount the user's home and the nfs. I followed this tutorial to configure ldap and automount. (automount information: fstype=nfs,hard,intr,nodev,nosuid,rw 192.168.0.1:/home/serveur/dupont)
dn: cn=dupont, ou=nfs, ou=services, dc=projet, dc=sys
objectClass: top
objectClass: automount
cn: dupont
I have a syntax error when trying to add this file.
$ ldapadd -x -f au.ldif -W -D cn=admin,dc=projet,dc=sys
ldap_add: Invalid syntax (21)
additional info: objectClass: value #1 invalid per syntax
I can't seem to find the source of this error.
$ ldapsearch -x
# extended LDIF
#
# LDAPv3
# base <dc=projet,dc=sys> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# projet.sys
dn: dc=projet,dc=sys
objectClass: top
objectClass: dcObject
objectClass: organization
o: nsalab
dc: projet
# admin, projet.sys
dn: cn=admin,dc=projet,dc=sys
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
# people, projet.sys
dn: ou=people,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: people
description: Branche gens
# etudiants, people, projet.sys
dn: ou=etudiants,ou=people,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: etudiants
description: Branche etudiants
# personnel, people, projet.sys
dn: ou=personnel,ou=people,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: personnel
description: Branche personnel
# services, projet.sys
dn: ou=services,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: services
description: Branche services
# groupes, services, projet.sys
dn: ou=groupes,ou=services,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: groupes
description: Branche groupes
# nfs, services, projet.sys
dn: ou=nfs,ou=services,dc=projet,dc=sys
objectClass: top
objectClass: organizationalUnit
ou: nfs
description: Branche nfs
# mongroupe, groupes, services, projet.sys
dn: cn=mongroupe,ou=groupes,ou=services,dc=projet,dc=sys
objectClass: top
objectClass: posixGroup
cn: mongroupe
gidNumber: 1111
description: groupe de test mongroupe
# dupont, etudiants, people, projet.sys
dn: uid=dupont,ou=etudiants,ou=people,dc=projet,dc=sys
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: dupont
cn: Dupont Jean
sn: Dupont
givenName: Jean
uidNumber: 1100
gidNumber: 1111
homeDirectory: /home/aware/dupont
loginShell: /bin/bash
mail: dupont#projet.sys
l: France
ou: mongroupe
# search result
search: 2
result: 0 Success
# numResponses: 11
# numEntries: 10
I had to activate the right schema.
The autofs-ldap.schema file needs to be converted to LDIF format. You
can do this with the slapcat utility as described in the
OpenLDAPServer guide, or you can just visit
launchpadlibrarian.net/55451730/autofs.ldif and grab this one
that's already been converted (rename it autofs-ldap.ldif and put it
in /etc/ldap/schema for consistency's sake).
And use ldapadd to import it into the database.
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/autofs-ldap.ldif
You have to activate the right schema:
The autofs-ldap.schema file needs to be converted to LDIF format. You can do this with the slapcat utility as described in the OpenLDAPServer guide, or you can just visit launchpadlibrarian.net/55451730/autofs.ldif and grab this one that's already been converted (rename it autofs-ldap.ldif and put it in /etc/ldap/schema for consistency's sake).
And use ldapadd to import it into the database.
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/autofs-ldap.ldif

Add 'memberOf' attribute to ApacheDS

I am trying to simulate Active Directory's memberOf attribute in Apache Directory. I have added the following entry for memberOf to my LDIF file:
dn: m-oid=1.3.6.1.4.1.18060.0.4.3.2.1,ou=attributeTypes,cn=other,ou=schema
m-usage: USER_APPLICATIONS
m-equality: distinguishedNameMatch
objectClass: metaAttributeType
objectClass: metaTop
objectClass: top
m-name: memberOf
m-oid: 1.3.6.1.4.1.18060.0.4.3.2.1
m-obsolete: FALSE
m-noUserModification: FALSE
m-syntax: 1.3.6.1.4.1.1466.115.121.1.27
When I start ApacheDS the following warning is logged:
WARN [ContainerBackgroundProcessor[StandardEngine[Catalina]]] entry.ServerStringValue - Cannot normalize the value :Encountered name based id of memberOf which was not found in the OID registry
This causes problems later on because my application tries to user the memberOf attribute as a search filter.
Is anything wrong with the way I specified the LDIF entry?
For my integration test cases on top of embedded Apache Directory Server I've added both memberOf and sAMAccountName attributes defined in Microsoft Active Directory server.
#########################################################
# MICROSOFT SCHEMA for sAMAccountName and memberOf
# these two attributes are not defined in Apache Directory Server
#########################################################
dn: cn=microsoft, ou=schema
objectclass: metaSchema
objectclass: top
cn: microsoft
dn: ou=attributetypes, cn=microsoft, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: attributetypes
dn: m-oid=1.2.840.113556.1.4.221, ou=attributetypes, cn=microsoft, ou=schema
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-oid: 1.2.840.113556.1.4.221
m-name: sAMAccountName
m-equality: caseIgnoreMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
m-singleValue: TRUE
dn: m-oid=1.2.840.113556.1.4.222, ou=attributetypes, cn=microsoft, ou=schema
objectclass: metaAttributeType
objectclass: metaTop
objectclass: top
m-oid: 1.2.840.113556.1.4.222
m-name: memberOf
m-equality: caseIgnoreMatch
m-syntax: 1.3.6.1.4.1.1466.115.121.1.15
m-singleValue: FALSE
dn: ou=objectclasses, cn=microsoft, ou=schema
objectclass: organizationalUnit
objectclass: top
ou: objectClasses
dn: m-oid=1.2.840.113556.1.5.6, ou=objectclasses, cn=microsoft, ou=schema
objectclass: metaObjectClass
objectclass: metaTop
objectclass: top
m-oid: 1.2.840.113556.1.5.6
m-name: simulatedMicrosoftSecurityPrincipal
m-supObjectClass: top
m-typeObjectClass: AUXILIARY
m-must: sAMAccountName
m-may: memberOf
#######################################################
# Megacorp employees
#######################################################
dn: cn=EmployeeABC,ou=nl_users,DC=corp,DC=megacorp,DC=COM
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectclass: simulatedMicrosoftSecurityPrincipal
cn: EmployeeABC
sn: EmployeeABC
givenName: EmployeeABC
mail: EmployeeABC#megacorp.com
MEMBEROF: CN=just-users,OU=mc_groups,DC=corp,DC=megacorp,DC=com
MEMBEROF: CN=best-users,OU=mc_groups,DC=corp,DC=megacorp,DC=com
SAMACCOUNTNAME: employeeabc
The ApacheDS team is aware of the desire for the memberOf virtual attribute. They mention that it will be part of the 2.1.0 release:
Le 5/20/13 5:53 PM, Danielsen, Jay a écrit :
I see from the January 2013 archives that memberOf virtual attribute is not yet supported.
Are there any plans or work-in-progress to support memberOf in an upcoming release ? Morst certainly in 2.1.0.
We are currently busy cleaning the 150 remaining issues before a
2.0.0-RC1 release, so I think this is something we can have in the next 6 months.
You can create a JIRA to request such a feature.
Thanks !
-- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
And here is the JIRA request.
You may need to add the schema that contains 'memberOf' into the ApacheDS configuration.