Итак, я загрузил последний исходный код OpenLDAP, скомпилированный с помощью —-enable-sql, возился с slapd.conf, настроил файлы odbc, добавил таблицы в мою текущую БД, потратил неделю на отладку slapd -d -1, а теперь и пользователи MySQL, стали пользователями LDAP и могут войти в систему.
Мне нужна помощь в понимании базовой структуры объекта LDAP. Из всего, что я прочитал, я предполагаю, что каждый объект должен принадлежать structuralObjectClass и тогда каждый объект может принадлежать многим другим objectClasses?
Единственное, что мне нужно, чтобы этот сервер LDAP делал, это просто аутентифицировал пользователей. Пользователям не нужно редактировать свою информацию. Итак, я сначала выложил следующую структуру:
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
Я считаю, что OpenLDAP добавит недостающие top objectClass. Поскольку у меня уже есть БД с этими пользователями, и мне удобнее использовать РСУБД вместо схем в LDAP, у меня есть небольшая проблема с пониманием того, почему, когда я пытаюсь войти в систему, ldapsearch утилита просматривает все классы объектов, которые у меня есть в таблице ldap_oc_mappings, вместо того, чтобы просто искать объектный класс inetOrgPerson. Так не будет лишних запросов. Во всяком случае, это таблицы:
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 |
+----------+---------------+
Записи objclasses предназначены только для одного пользователя. Каждому пользователю назначены эти объектные классы. Это вид, а не таблица
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 |
+----+-------------+---------------------------------+--------+---------------------+-----------+
Я думаю, что родительские значения здесь могут быть неправильными
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 |
+-------+-----------------------------------------------+-----------+--------+--------+
Верны ли здесь родительские значения?
Как я уже сказал, это работает, и пользователи могут входить в систему. Но когда я запускаю ldasearch -b "dc=example,dc=org" "(objectclass=*)" это занимает очень много времени. Я прочитал множество статей, в которых говорилось, что причина, по которой СУБД не могут и не должны использоваться для серверных программ LDAP, в основном связана с этой проблемой. Но это мучительно медленно, что заставляет меня думать, что есть несколько ненужных запросов и что "отношения" моей таблицы неверны. Первая пара результата ldapsearch являются:
# 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:: ******
Как вы можете видеть здесь, объектный класс inetOrgPerson появляется дважды. Это для всех пользователей.
Когда я выполняю это: ldapsearch -b "dc=example,dc=org" "(cn=user1)" результат возвращается в миллисекундах, что наводит меня на мысль, что должен быть способ указать серверу OpenLDAP всегда выполнять поиск на основе CN.
Мм, это был длинный пост / вопрос (ы). Поэтому приветствуются любые комментарии к схеме, родительским значениям или тому, почему объектные классы отображаются дважды, или, может быть, некоторые рекомендации по их оптимизации.
Спасибо