So, I have downloaded the latest source of OpenLDAP, compiled with —-enable-sql, messed around with the slapd.conf, configured the odbc files, added the tables to my current DB, spend a week debugging slapd -d -1, and now MySQL users, have become LDAP users and are able to log in.
I need some help understanding the basic structure of an LDAP object.
From everything that I read, I am assuming that each object needs to belong to a structuralObjectClass and then each object can belong to many other objectClasses?
The only thing I need this LDAP server to do is just to authenticate users. There is no need for the users to edit their info. So I first laid out the following structure:
Institute
dn: dc=example,dc=org
dc: example
structuralObjectClass: dcObject
objectClass: organization
o: example
description: Example Company
Groups
Dn: ou=Groups,dc=example,dc=org
Ou: Groups
structuralObjectClass: organizationalUnit
dn: ou=Users,dc=example,dc=org
ou: Users
structuralObjectClass: organizationalUnit
dn: ou=marketing,ou=Groups,dc=example,dc=org
cn: marketing
gidNumber: 1554
structuralObjectClass: posixGroup
memberUid: user1
memberUid: userN
dn: ou=administration,ou=Groups,dc=example,dc=org
cn: administration
gidNumber: 1555
structuralObjectClass: posixGroup
memberUid: user1
memberUid: userN
Users
Dn: uid=user1,ou=Users,dc=example,dc=org
structuralObjectClass: inetOrgPerson
givenName:
displayName:
cn:
uidNumber:
homeDirectory:
sn:
gidNumber:
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
objectClass: shadowAccount
I believe OpenLDAP will add the missing top objectClass.
Since I already have a DB with these users, and I am more comfortable with RDBMSes instead of schemas in LDAP I have a bit of an issue understanding why when I try to log in, the ldapsearch utility goes through all the object classes that I have in the ldap_oc_mappings table instead of just searching the objectClass inetOrgPerson. This way there would not be any unecessary queries. Anyway, these are the tables:
ldap_attr_mappings
+----+-----------+---------------+-----------------------------------------------------------+---------------+---------------------------------+-------------+
| id | oc_map_id | name | sel_expr | from_tbls | join_where | param_order |
+----+-----------+---------------+-----------------------------------------------------------+---------------+---------------------------------+-------------+
| 3 | 1 | sn | users .lName | users | NULL | 3 |
| 4 | 1 | userPassword | concat('{MD5}',BASE64_ENCODE(unhex(users .password))) | users | NOT ISNULL(users .password) | 3 |
| 5 | 1 | displayName | concat(users .fName,' ',users .lName) | users | NULL | 3 |
| 6 | 1 | homeDirectory | users .homeDirectory | users | NULL | 3 |
| 7 | 1 | loginShell | users .loginShell | users | NULL | 3 |
| 8 | 1 | uidNumber | users .uidNumber | users | NULL | 3 |
| 9 | 1 | gidNumber | users .gidNumber | users | NULL | 3 |
| 10 | 1 | cn | users .loginName | users | NULL | 3 |
| 11 | 1 | uid | users .loginName | users | NULL | 3 |
| 12 | 3 | ou | ldap_groups.name | ldap_groups | NULL | 3 |
| 14 | 2 | o | ldap_org_unit.o | ldap_org_unit | NULL | 3 |
| 16 | 2 | dc | ldap_org_unit.o | ldap_org_unit | NULL | 3 |
| 17 | 2 | description | ldap_org_unit.Description | ldap_org_unit | NULL | 3 |
| 18 | 4 | gidNumber | ldap_groups.gid | ldap_groups | NULL | 3 |
| 19 | 4 | cn | ldap_groups.cn | ldap_groups | NULL | 3 |
+----+-----------+---------------+-----------------------------------------------------------+---------------+---------------------------------+-------------+
ldap_oc_mappings
+----+--------------------+---------------+--------------+
| id | name | keytbl | keycol |
+----+--------------------+---------------+--------------+
| 1 | inetOrgperson | users | userID |
| 2 | organization | ldap_org_unit | id |
| 3 | organizationalUnit | ldap_groups | gid |
| 4 | posixGroup | ldap_groups | gid |
+----+--------------------+---------------+--------------+
ldap_entry_objclasses
+----------+---------------+
| entry_id | oc_name |
+----------+---------------+
| 12216 | inetOrgPerson |
| 12216 | posixAccount |
| 12216 | shadowAccount |
+----------+---------------+
The objclasses entries are just for one user. Each user has these objectClasses assigned to them. This is a view not a table
ldap_org_unit
+----+-------------+---------------------------------+--------+---------------------+-----------+
| id | o | dn | parent | Description | oc_map_id |
+----+-------------+---------------------------------+--------+---------------------+-----------+
| 1 | Example | DC=Example,DC=org | 0 | Example Co | 2 |
| 2 | Users | ou=Users,DC=example,DC=org | 1 | | 3 |
| 3 | Groups | ou=Groups,DC=example,DC=org | 1 | | 3 |
+----+-------------+---------------------------------+--------+---------------------+-----------+
I think the parent values here might not be correct
ldap_groups
+------+----------------+----------------+-----------------------------------------------+
| gid | name | cn | dn |
+------+----------------+----------------+-----------------------------------------------+
| 1554 | Marketing | marketing | cn=marketing,ou=Groups,dc=example,dc=org |
| 1155 | administration | administration | cn=administration,ou=Groups,dc=example,dc=org |
+------+----------------+----------------+-----------------------------------------------+
Lastly: ldap_entries
+-------+-----------------------------------------------+-----------+--------+--------+
| id | dn | oc_map_id | parent | keyval |
+-------+-----------------------------------------------+-----------+--------+--------+
| 1 | DC=EXAMPLE,DC=ORG | 2 | 0 | 1 |
| 2 | OU=USERS,DC=EXAMPLE,DC=ORG | 3 | 1 | 2 |
| 3 | OU=GROUPS,DC=EXAMPLE,DC=ORG | 3 | 1 | 3 |
| 1554 | CN=MARKETING,OU=GROUPS,DC=EXAMPLE,DC=ORG | 4 | 3 | 1554 |
| 1155 | CN=ADMINISTRATION,OU=GROUPS,DC=EXAMPLE,DC=ORG | 4 | 3 | 1155 |
| 22963 | CN=ROOT,DC=EXAMPLE,DC=ORG | 1 | 1554 | 12963 |
| 12216 | CN=USER1,OU=USERS,DC=EXAMPLE,DC=ORG | 1 | 1555 | 2216 |
+-------+-----------------------------------------------+-----------+--------+--------+
Are the parent values here correct?
As I said this works and users are able to log in. But when I run ldasearch -b "dc=example,dc=org" "(objectclass=*)" it takes a very long time. I have read numerous articles stating that the reason why RDBMSes cannot and should not be used for LDAP backends is because mainly of this issue. But it is excruciatingly slow, which leads me to believe that there are some unnecessary queries and my table "relations" are not correct.
The first couple of result of the ldapsearch are:
# ROOT, EXAMPLE.ORG
dn: cn=ROOT,dc=EXAMPLE,dc=ORG
objectClass: inetOrgPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: root
sn: Admin
uid: root
gidNumber: 1554
uidNumber: 0
loginShell: /bin/bash
displayName: Domain Admin
userPassword:: *******
homeDirectory: /ldaphomes/root
# USER1, USERS, EXAMPLE.ORG
dn: cn=USER1,ou=USERS,dc=EXAMPLE,dc=ORG
objectClass: inetOrgPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: user1
sn: User 1
uid: user1
gidNumber: 0
uidNumber: 0
displayName: User 1
userPassword:: ******
As you can see here, the objectClass inetOrgPerson appears twice. This is for all users.
When I execute this: ldapsearch -b "dc=example,dc=org" "(cn=user1)" the result is returned in milliseconds which leads me to believe that there should be a way to tell OpenLDAP server to always search based on CN.
Mm, this was a long post/question(s). So any comments on the schema, parent values, or why the objectClasses are displayed twice, or maybe some guidance into optimizing this are welcomed.
Thanks
slapdandldapsearch.