Openldap memberof overlay memberof- attributes not working. Why? - openldap
I'm using CentOs 6.x 64 bit version and I'm trying to set the memberof attributes for the memberof overlay in openldap, but it doesn't appear to be working. I'm sure it's something I'm doing, but I haven't found out why.
A snippet from my backup ldif look like this:
dn: dc=two,dc=example,dc=com
description: Example.Com, your trusted non-existent corporation.
dc: two
o: Two.Example.Com
objectClass: top
objectClass: dcObject
objectClass: organization
structuralObjectClass: organization
entryUUID: db07fc76-375c-1034-9316-31842acd382b
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150123150421Z
entryCSN: 20150123150421.520657Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150123150421Z
dn: ou=Users,dc=two,dc=example,dc=com
ou: Users
description: Two.Example.Com Users
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: db0fb5ba-375c-1034-9317-31842acd382b
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150123150421Z
entryCSN: 20150123150421.571271Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150123150421Z
dn: ou=Groups,dc=two,dc=example,dc=com
ou: Groups
description: Two.Example.Com Groups
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: db13850a-375c-1034-9318-31842acd382b
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150123150421Z
entryCSN: 20150123150421.596246Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150123150421Z
dn: ou=System,dc=two,dc=example,dc=com
ou: System
description: Special accounts usedd by software applications.
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: db161c5c-375c-1034-9319-31842acd382b
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150123150421Z
entryCSN: 20150123150421.613008Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150123150421Z
dn: uid=matt2,ou=Users,dc=two,dc=example,dc=com
ou: Users
cn: Matt2 Butcher
sn: Butcher
givenName: Matt2
givenName: Matthew2
displayName: Matt2 Butcher
title: Systems Integrator
description: Systems Integration and IT for Example.Com
employeeType: Employee
departmentNumber: 001
employeeNumber: 001-08-98
mail: mbutcher2# two.example.com
mail: matt2# two.example.com
roomNumber: 301
telephoneNumber: + 1 555 555 4321
mobile: + 1 555 555 6789
st: Illinois
l: Chicago
street: 1234 Cicero Ave.
homePhone: + 1 555 555 9876
homePostalAddress: 1234 home street $ Chicago, IL $ 60699-1234
preferredLanguage: en-us, en-gb
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
structuralObjectClass: inetOrgPerson
uid: matt2
entryUUID: db1758d8-375c-1034-931a-31842acd382b
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150123150421Z
userPassword:: c2VjcmV0Mg==
entryCSN: 20150212215925.305826Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150212215925Z
dn: uid=barbara2,ou=Users,dc=two,dc=example,dc=com
ou: Users
uid: barbara2
sn: Jensen
cn: Barbara2 Jensen
givenName: Barbara
displayName: Barbara2 Jensen
mail: barbara# two.example.com
userPassword:: c2VjcmV0Mg==
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
structuralObjectClass: inetOrgPerson
entryUUID: db1b2904-375c-1034-931b-31842acd382b
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150123150421Z
entryCSN: 20150123150421.646304Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150123150421Z
dn: cn=LDAP Admins,ou=Groups,dc=two,dc=example,dc=com
cn: LDAP Admins
ou: Groups
description: Users who are LDAP administrators
uniqueMember: uid=barbara2,ou=Users,dc=two,dc=example,dc=com
uniqueMember: uid=matt2,ou=Users,dc=two,dc=example,dc=com
objectClass: groupOfUniqueNames
structuralObjectClass: groupOfUniqueNames
entryUUID: db1c6a26-375c-1034-931c-31842acd382b
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150123150421Z
entryCSN: 20150212205145.765939Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150212205145Z
dn: uid=authenticate,ou=System,dc=two,dc=example,dc=com
uid: authenticate
ou: System
description: Special account for authenticating users
userPassword:: c2VjcmV0Mg==
objectClass: account
objectClass: simpleSecurityObject
structuralObjectClass: account
entryUUID: db1dbbe2-375c-1034-931d-31842acd382b
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150123150421Z
entryCSN: 20150123150421.663007Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150123150421Z
dn: cn=PentahoAdmin,dc=two,dc=example,dc=com
cn: PentahoAdmin
description: PentahoAdmin Group
objectClass: groupOfUniqueNames
structuralObjectClass: groupOfUniqueNames
entryUUID: a2b8ea68-45aa-1034-9bad-9b580235c5b1
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150210195624Z
uniqueMember: uid=barbara2,ou=Users,dc=two,dc=example,dc=com
entryCSN: 20150212205241.018162Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150212205241Z
dn: cn=PentahoPowerUser,dc=two,dc=example,dc=com
cn: PentahoPowerUser
description: PentahoPowerUser Group
objectClass: groupOfUniqueNames
structuralObjectClass: groupOfUniqueNames
entryUUID: a2bd52f6-45aa-1034-9bae-9b580235c5b1
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150210195624Z
uniqueMember: uid=matt2,ou=Users,dc=two,dc=example,dc=com
entryCSN: 20150212205232.847745Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150212205232Z
dn: cn=PentahoUser,dc=two,dc=example,dc=com
cn: PentahoUser
uniqueMember: uid=barbara2,ou=Users,dc=two,dc=example,dc=com
uniqueMember: uid=matt2,ou=Users,dc=two,dc=example,dc=com
uniqueMember: uid=test1,ou=People,dc=two,dc=example,dc=com
description: PentahoUser Group
objectClass: groupOfUniqueNames
structuralObjectClass: groupOfUniqueNames
entryUUID: a2be5214-45aa-1034-9baf-9b580235c5b1
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150210195624Z
entryCSN: 20150220200228.971207Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150220200228Z
dn: ou=Group,dc=two,dc=example,dc=com
objectClass: organizationalUnit
ou: Group
structuralObjectClass: organizationalUnit
entryUUID: 5f75e188-480d-1034-84d8-d19f432d9181
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150213204813Z
entryCSN: 20150213204813.728965Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150213204813Z
dn: ou=People,dc=two,dc=example,dc=com
objectClass: organizationalUnit
ou: People
structuralObjectClass: organizationalUnit
entryUUID: 5f79f37c-480d-1034-84d9-d19f432d9181
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150213204813Z
entryCSN: 20150213204813.755642Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150213204813Z
dn: uid=test1,ou=People,dc=two,dc=example,dc=com
objectClass: account
uid: test1
structuralObjectClass: account
entryUUID: 5f7af9e8-480d-1034-84da-d19f432d9181
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150213204813Z
entryCSN: 20150213204813.762359Z#000000#000#000000
modifyTimestamp: 20150213204813Z
memberOf: cn=testgroup,ou=Group,dc=two,dc=example,dc=com
memberOf: cn=PentahoUser,dc=two,dc=example,dc=com
modifiersName: cn=Manager,dc=two,dc=example,dc=com
dn: cn=testgroup,ou=Group,dc=two,dc=example,dc=com
objectClass: groupOfNames
cn: testgroup
structuralObjectClass: groupOfNames
entryUUID: 5f7c3fce-480d-1034-84db-d19f432d9181
creatorsName: cn=Manager,dc=two,dc=example,dc=com
createTimestamp: 20150213204813Z
member: uid=test1,ou=People,dc=two,dc=example,dc=com
entryCSN: 20150213213917.067904Z#000000#000#000000
modifiersName: cn=Manager,dc=two,dc=example,dc=com
modifyTimestamp: 20150213213917Z
My slapd.conf snippet looks like this:
##########################
# Database Configuration #
##########################
database hdb
suffix "dc=two,dc=example,dc=com"
rootdn "cn=Manager,dc=two,dc=example,dc=com"
rootpw secret2
directory /var/lib/ldap
# directory /usr/local/var/openldap-data
index objectClass,cn eq
overlay memberof
memberof-group-oc groupOfUniqueNames
memberof-member-ad uniqueMember
memberof-refint true
When I perform an ldapsearch for uid=test1 and request the memberOf attribute it returns two groups. But, When I perform the same search for uid=barbara2 is doesn' return anything.
What am I doing wrong? Why does it appear that the memberof attributes in my slapd.conf are being ignored?
The attribute is only maintained for new entries or updates performed after it was installed. It does nothing to existing entries. If you want those to work you'll have to dump and reload the DIT.
Related
Error: Missing schema location in RootDSE while setting up OpenLdap server
I have done setup of OpenLdap 2.6.3 on CentOS8. I followed all the steps and I am trying to connect in Apache Directory Studio. It throws the error "Error while opening connection
-Missing schema location in RootDSE, using default schema". Please could you help me in this.
The input given in RootDN is:
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/lib/openldap/slapd.args
olcPidFile: /var/lib/openldap/slapd.pid
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/libexec/openldap
olcModuleload: back_mdb.la
# Include more schemas in addition to default core
include: file:///etc/openldap/schema/core.ldif
include: file:///etc/openldap/schema/cosine.ldif
include: file:///etc/openldap/schema/nis.ldif
include: file:///etc/openldap/schema/inetorgperson.ldif
include: file:///etc/openldap/schema/sudo.ldif
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
olcAccess: to dn.base="cn=Subschema" by * read
olcAccess: to *
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none
dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootDN: cn=config
olcAccess: to *
by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none
and the input given in binddnuser.ldif:
dn: ou=system,dc=ldapmaster,dc=connectors,dc=com
objectClass: organizationalUnit
objectClass: top
ou: system
dn: cn=readonly,ou=system,dc=ldapmaster,dc=connectors,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: readonly
userPassword: {SSHA}p8Ivp9Qc3YQr1hO3DHuX2GMvTGAbdBux
description: Bind DN user for LDAP Operations
iNetOrgPerson doesn't exist in Openldap?
I'm triing to create a user with openldap 2.4 dn: uid=rrrrrr,ou=users,dc=my-domain,dc=com objectClass: iNetOrgPerson uid: iiiiii but it doesn't seem recognize the objectClass producing this error: adding new entry "uid=rrrrrr,ou=users,dc=my-domain,dc=com" ldap_add: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax Using other object classes is ok. What's the problem?
creating openldap proxy cache str2add(olcDbURI): attribute type undefined
I'm trying to add openlda proxy cache using ldiff, top section below
dn: olcDatabase={2}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {2}ldap
olcSuffix: dc=example,dc=com
olcRootDN: dc=example,dc=com
olcDbURI: "ldaps://ldap.example.com:636"
When I try to do slapadd I get str2add(olcDbURI): attribute type undefined, while clearly it is in the ldif. Any ideas?
Link people to organizational Units in a LDAP DIT tree
I am constructing a LDAP just to learn about it. I am new working with LDAP. I have a representation of the people inside a company in a individual group called "people". Now I would like put (link) this people in the different ous, for example Mike pertain a energy sector, member of board_directors and seniors. Sue pertain a water sector, member of board_directors and Peter pertain a water sector, member of assembly group and seniors. Is it possible?, How can I link this people under branch ou=people to another ous? I have a LDAP DIT Tree like this: dn: dc=company,dc=xd,dc=com objectClass: top objectClass: dcObject objectClass: organization o: xd dc: company dn: ou=people,dc=company,dc=xd,dc=com ou: people objectClass: organizationalUnit description: people working in my company dn: ou=areas,dc=company,dc=xd,dc=com ou: areas objectClass: organizationalUnit description: distinct zones in my company dn: ou=sectors,dc=company,dc=xd,dc=com ou: sectors objectClass: organizationalUnit description: distinct sectors dn: ou=water,ou=sectores,dc=company,dc=xd,dc=com ou: water objectClass: organizationalUnit description: reference to water sector dn: ou=energy,ou=sectores,dc=company,dc=xd,dc=com ou: energy objectClass: organizationalUnit description: reference to energy sector dn: ou=orga,dc=company,dc=xd,dc=com ou: orga objectClass: organizationalUnit description: distintos organismos da organizacion dn: ou=board_directors,ou=orga,dc=company,dc=xd,dc=com ou: board_directors objectClass: organizationalUnit description: The company board of directors dn: ou=assembly,ou=orga,dc=company,dc=xd,dc=com ou: assembly objectClass: organizationalUnit description: weekly assembly organizators dn: ou=seniors,ou=orga,dc=company,dc=xd,dc=com ou: seniors objectClass: organizationalUnit description: main company seniors dn: ou=it,dc=company,dc=xd,dc=com ou: it objectClass: organizationalUnit description: it resources dn: ou=data,ou=it,dc=company,dc=xd,dc=com ou: data objectClass: organizationalUnit description: data dn: ou=apps,ou=it,dc=company,dc=xd,dc=com ou: apps objectClass: organizationalUnit description: applications dn: ou=machines,ou=it,dc=company,dc=xd,dc=com ou: machines objectClass: organizationalUnit description: something mechanic dn: uid=Sue,ou=people,dc=company,dc=xd,dc=com objectClass: inetOrgPerson objectClass: posixAccount description: User posix Sue sn: Reyes givenName: Sue cn: Sue Reyes displayName: Sue Reyes homeDirectory: /home/Sue uid: Sue uidNumber: 1003 gidNumber: 1003 userPassword:: MTIzNA== dn: uid=peter,ou=people,dc=company,dc=xd,dc=com uid: peter objectClass: inetOrgPerson objectClass: posixAccount description: user posix peter sn: Griffin givenName: Peter cn: peter griffin displayName: Peter Griffin uidNumber: 1001 gidNumber: 1001 homeDirectory: /home/peter userPassword:: MTIzNA== dn: uid=mike,ou=people,dc=company,dc=xd,dc=com uid: mike objectClass: inetOrgPerson objectClass: posixAccount description: user posix Mike sn: Larson givenName: Mike cn: Mike Larson displayName: Mike Larson uidNumber: 1002 gidNumber: 1002 homeDirectory: /home/Mike userPassword:: MTIzNA==
Well, you almost answered your own question. Your users are in a container called people. You want to put them in different groups. Rather than create containers for all of your different organizational units (i.e. board_directors, it, etc) you could create groups for those things. dn: ou=groups,dc=company,dc=xd,dc=com ou: groups objectClass: organizationalUnit dn: cn=board_directors,ou=groups,dc=company,dc=xd,dc=com objectclass: top objectClass: groupOfUniquenames uniqueMember: uid=Sue,ou=people,dc=company,dc=xd,dc=com uniqueMember: uid=Mike,ou=people,dc=company,dc=xd,dc=com dn: cn=it,ou=groups,dc=company,dc=xd,dc=com objectclass: top objectClass: groupOfUniquenames uniqueMember: uid=Peter,ou=people,dc=company,dc=xd,dc=com It may be that not all of your organizational units fir neatly into groups. Perhaps it might be necessary to organize groups under organizations for instance. dn: ou=groups,ou=orga,dc=company,dc=xd,dc=com ou: groups objectClass: organizationalUnit dn: cn=board_directors,ou=groups,ou=orga,dc=company,dc=xd,dc=com objectclass: top objectClass: groupOfUniquenames uniqueMember: uid=Mike,ou=people,dc=company,dc=xd,dc=com dn: cn=board_directors,ou=groups,ou=orgb,dc=company,dc=xd,dc=com objectclass: top objectClass: groupOfUniquenames uniqueMember: uid=Sue,ou=people,dc=company,dc=xd,dc=com These are just examples but I would lean towards using the groupOfUniqueNames objectclass to group people together.
You need to define the usage for your LDAP instance. If this is used for authentication and as an attribute repository, then you should keep all your "people" entries in one container and manage each "attribute" to determine the type, department, location, etc. Then, if required, place the users into groups based on the attribute values. -jim
openldap "no global superior knowledge"
When I: ldapadd -f pop01.ldif -x -D "cn=Manager,dc=ldap,dc=beonegroup,dc=be" -w 1234 I get: adding new entry "dc=ldap,dc=beonegroup,dc=org" ldapadd: Server is unwilling to perform (53) additional info: no global superior knowledge Here is my slapd.conf: database bdb suffix "dc=ldap,dc=beonegroup,dc=be" rootdn "cn=Manager,dc=ldap,dc=beonegroup,dc=be" rootpw 1234 directory /var/lib/ldap/beoneDirectory index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub And my file used to populate: [root#local beoneDirectory]# pwd /var/lib/ldap/beoneDirectory [root#local beoneDirectory]# cat pop01.ldif dn: dc=ldap,dc=beone,dc=org objectClass: top objectClass: dcObject objectClass: organization dc: beone o: beone description: ldap.beone.be dn: o=beone objectClass: top objectClass: organization o: beone description: Beone dn: cn=Manager,o=beone objectClass: organizationalRole cn: Manager description: LDAP Directory Administrator dn: ou=Employes,o=beone ou: Employes objectClass: top objectClass: organizationalUnit description: Employes beone dn: ou=Clients,o=beone ou: Clients objectClass: top objectClass: organizationalUnit description: Clients beone #1ere entrée dn: cn=Benoit Le,ou=Employes,o=beonegroup cn: Benoit Le objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson mail: benoit#beone.be givenname: Benoit sn: Lecomte ou: Employes street: 29 rue de cp l: jumet postalCode: 6040 telephoneNumber: 04942311 mobile: 01234345 #2eme employé dn: cn=Matteo Di,ou=Employes,o=beonegroup cn: Matteo Di objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson mail: mat#beone.be I know this is a slapd.conf related issue, openldap doesn't know where to insert my entries but I don't really see how to specify it
Your database is named (has suffix): dc=ldap,dc=beonegroup,dc=be You are in the ldif trying to add stuff to dn: dc=ldap,dc=beone,dc=org This is somewhat equivalent of makeing a directory called /something, then trying to create the file /some/file. It won't work since the directory /some doesn't exist. Remember LDAP data is organized in a hierarchical structure, i.e. the form of a tree like directories and files are. The word superior refers to the level above (closer to top), similar to parent directory (closer to root) in the filesystem example. In the filesystem you would get the error message /some/file: No such file or directory The LDAP error could probably have been worded better, but to fix this you have to either change the suffix in your slapd.conf or change the stuff you want to add. They have to match. (Thanks to lilalinux for in the comments also specifying how to fix)
The domain component structure what you have defined "dc=ldap,dc=beonegroup,dc=be" in not matching with your input entry in pop01.ldif first line. Try to change the first line in your pop01.ldif from dc=org to dc=be and try again.