LINUX.ORG.RU
Форум — Admin  

Добавить атрибуты в OpenLDAP

 


1

2

Всем привет! Мы юзали старый SUN Directory Server Enterprise Edition и потребовалось переехать на OpenLDAP, всем понятно наверное почему. Для SUN Directory у меня был ldiff с уникальными атрибутами, которые мне требуется запилить по аналогии в OpenLDAP. 

dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
cn: schema
aci: (target="ldap:///cn=schema")(targetattr !="aci")(version 3.0;acl "anonymo
 us, no acis"; allow (read, search, compare) userdn = "ldap:///anyone";)
modifiersName: cn=admin,cn=administrators,cn=dscc
modifyTimestamp: 20140825092336Z
attributeTypes: ( firstName-oid NAME 'firstName' DESC 'First name of a person'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
attributeTypes: ( privateEmail-oid NAME 'privateEmail' DESC 'Private email of
 a person' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 X-ORIGIN 'user defined' )
attributeTypes: ( userOid-oid NAME 'userOid'  SYNTAX 1.3.6.1.4.1.1466.115.121.
 1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
attributeTypes: ( isTrusted-oid NAME 'isTrusted' DESC 'Determines if user is t
 rusted' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'user defi
 ned' )
objectClasses: ( myUser-oid NAME 'myUser' DESC 'user for my entity' SUP
 top STRUCTURAL MUST ( uid $ isTrusted $ nsAccountLock $ firstName ) MAY ( la
 stName $ userPassword $ privateEmail $ otpContact $ otp
 AuthnFlag $ privatePhone $ userOid ) X-ORIGIN 'user defined' )
nsSchemaCSN: 53fb0098000000000000

У OpenLDAP вот такой формат ldif для организации схемы: 

olcAttributeTypes: ( 0.9.2342.19200300.100.1.25
  NAME ( 'dc' 'domainComponent' )
  DESC 'RFC1274/2247: domain component'
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
Как мне переделать мои атрибуты в файлике ldif под OpenLDAP мне в упор непонятно

  • 1. Я не понимаю какой мне OID указывать в случае с OpenLDAP типа 0.9.2342.19200300.100.1.25, когда для SUN Directory у меня указывался OID в формате userOid-oid
  • 2. Я не понимаю что такое SINGLE-VALUE X-ORIGIN и нужны ли они мне в OpenLDAP
  • 3. Для моего Sun Directory путь размещения атрибутов: 
    dn: cn=schema
objectClass: top
objectClass: ldapSubentry
objectClass: subschema
cn: schema
    а какой dn и objectClass мне в ldif для OpenLDAP указать?


Последнее исправление: trider (всего исправлений: 2)
← Apache mpm_prefork, cgi-bin, php, mysql
Jenkins: git plugin: Error cloning remote repo 'origin' →

. Я не понимаю какой мне OID указывать в случае с OpenLDAP типа 0.9.2342.19200300.100.1.25, когда для SUN Directory у меня указывался OID в формате userOid-oid

Если не собираешься активно искать и использовать чужие схемы, то можешь любой использовать. Например: 331.332.333.1. Делай более менее длинным и рандомным, но особо можешь не заморачиваться, вероятность пересечения крайне мала, и это не смертельно.

Я не понимаю что такое SINGLE-VALUE X-ORIGIN и нужны ли они мне в OpenLDAP

За x-origin не знаю, single-value указывает, что атрибут может быть только один. Например, двух значений 'isTrusted' у одной записи быть не может.

а какой dn и objectClass мне в ldif для OpenLDAP указать?

Я для своей схемы делал так: 

dn: cn=myschema,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: myschema
olcObjectIdentifier: {0}my 192.168.0
olcObjectIdentifier: {1}myAttrs my:1
olcObjectIdentifier: {2}myClass my:2
olcObjectIdentifier: {3}myAttrsEnrol myAttrs:3
olcAttributeTypes: ( myAttrsEnrol:0 NAME ('enrol' 'enrolment') SUP distinguishedName DESC 'enrolment' )

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Ivan_qrt

Всем спасибо! ldif для организации новых атрибутов и схемы получилось сформировать для OpenLDAP и он захавал ldif: 

dn: cn=myschema,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: myschema
olcAttributeTypes: ( 331.332.333.1 NAME 'firstName' DESC 'First name of a person'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)
olcAttributeTypes: ( 331.332.333.2 NAME 'privateEmail' DESC 'Private email of
 a person' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 X-ORIGIN 'user defined' )
olcAttributeTypes: ( 331.332.333.3 NAME 'userOid'  SYNTAX 1.3.6.1.4.1.1466.115.121.
 1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
olcAttributeTypes: ( 331.332.333.4  NAME 'isTrusted' DESC 'Determines if user is t
 rusted' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'user defi
 ned' )
olcAttributeTypes: ( 331.332.333.6 NAME 'gender' DESC 'Person gender (M,F or U)' SYN
 TAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
olcAttributeTypes: ( 331.332.333.7 NAME 'middleName' DESC 'Middle name of a pers
 on' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined
 ' )
olcAttributeTypes: ( 331.332.333.8 NAME 'privatePhone'  SYNTAX 1.3.6.1.4.1.146
 6.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
olcAttributeTypes: ( 331.332.333.11 NAME 'lastName' DESC 'Last name of a person' SY
 NTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
olcAttributeTypes: ( 2.16.840.1.113730.3.1.610 NAME 'nsAccountLock' DESC 'Operati
 onal attribute for Account Inactivation' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SIN
 GLE-VALUE )
olcObjectClasses: ( 331.332.333.12 NAME 'myUser' DESC 'user for My entity' SUP
 top STRUCTURAL MUST ( uid $ isTrusted $ nsAccountLock $ firstName ) MAY ( mi
 ddleName $ lastName $ userPassword $ privateEmail $ otp AuthnFlag $ private
 Phone $ userOid ) X-ORIGIN 'user defined' )

Появилась другая проблема, при добавлении пользователя непосредственно, который юзает данную схему: 

# ldapadd -x -W -D "uid=Administrator,cn=Administrators,dc=my,dc=domain,dc=ru" -f /root/test_user_add.ldif
Enter LDAP Password:
adding new entry "uid=OID.1234567890,cn=Users,dc=my,dc=domain,dc=ru"
ldap_add: Invalid syntax (21)
        additional info: isTrusted: value #0 invalid per syntax
Вывливается ошибка 'invalid per syntax' и что там с синтаксисом не так - мне непонятно. Вот содержимое /root/test_user_add.ldif: 
dn: OID.1234567890,cn=Users,dc=my,dc=domain,dc=ru
privatePhone: +7(777)7777777
userPassword: {SSHA}VknJuTKNtw7Eacnd00w9jZwHCDMMYURbtENXFA==
privateEmail: test@test.ru
objectClass: myUser
objectClass: top
userOid: 1234567890
creatorsName: uid=administrator,cn=administrators,dc=my,dc=domain,dc=ru
nsAccountLock: false
isTrusted: true
uid: OID.1234567890
lastName: Test
firstName: Test

trider
() автор топика
Ответ на: комментарий от trider

В логе slapd.log включена пока что всё отладочная информация, ошибка вот такая: 

Mar  3 13:43:22 Myldap-server01 slapd[29858]: send_ldap_result: conn=1026 op=1 p=3
Mar  3 13:43:22 Myldap-server01 slapd[29858]: send_ldap_result: err=21 matched="" text="isTrusted: value #0 invalid per syntax"
Mar  3 13:43:22 Myldap-server01 slapd[29858]: send_ldap_response: msgid=2 tag=105 err=21
Mar  3 13:43:22 Myldap-server01 slapd[29858]: conn=1026 op=1 RESULT tag=105 err=21 text=isTrusted: value #0 invalid per syntax

trider
() автор топика
Ответ на: комментарий от trider

dn: OID.1234567890,cn=Users,dc=my,dc=domain,dc=ru

По логике у тебя uid= в начале dn пропущен. Замени на 

dn: uid=OID.1234567890,cn=Users,dc=my,dc=domain,dc=ru

Почему на isTrusted ругается хз. Вроде всё так. Посмотри на пробелы, может есть лишние.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Ivan_qrt

Да с uid= я ошибся в данном сообщение, а что касается пробелов, то перепроверил - нашёл, удалил схему в /etc/openldap/slapd.d/cn\=config/cn\=schema/, перезапустил slapd, залили схему заново и ошибка при добавлении пользователя сохраняется (((

trider
() автор топика
Ответ на: комментарий от Ivan_qrt

Разобрался, значения атрибута с OID '1.3.6.1.4.1.1466.115.121.1.7' в OpenLDAP чувствительны к регистру и требовалось всего лишь в '/root/test_user_add.ldif' указать: 

isTrusted: TRUE
вместо 
isTrusted: true

Появилась другая проблема после добавления записи. Запись пользователя успешно добавлена, вижу её, но когда делаем выборку на OpenLDAP записи не видно: 

# ldapsearch -D "uid=Administrator,cn=Administrators,dc=my,dc=domain,dc=ru" -w adminpass -h Myldap-server01 -p 389 -b cn="Users,dc=my,dc=domain,dc=ru" "privateEmail=test@test.ru"
# extended LDIF
#
# LDAPv3
# base <cn=Users,dc=my,dc=domain,dc=ru> with scope subtree
# filter: privateEmail=test@test.ru
# requesting: ALL
#

# search result
search: 2
result: 0 Success

Такой же запрос в SUN Directory отрабатывает корректно: 

# ldapsearch -D "uid=Administrator,cn=Administrators,dc=my,dc=domain,dc=ru" -w administratorpass -h Myldap-sun-server01 -p 1389 -b cn="Users,dc=my,dc=domain,dc=ru" "privateEmail=test@test.ru"
# extended LDIF
#
# LDAPv3
# base <cn=Users,dc=my,dc=domain,dc=ru> with scope subtree
# filter: privateEmail=test@test.ruu
# requesting: ALL
#

# OID.1234567890, Users, my.domain.ru
dn: uid=OID.1234567890,cn=Users,dc=my,dc=domain,dc=ru
privatePhone: +7(777)7777777
userPassword:: e1NTSEF9VmtuSnVUS050dzdFYWNuZDAwdzlqWndIQ0RNTVlVUmJ0RU5YRkE9PQ=
 =
privateEmail: test@test.ru
objectClass: myUser
objectClass: top
userOid: 1234567890
isTrusted: true
uid: OID.1234567890
lastName:: VGVzdA==
firstName:: VGVzdA==

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Собственно я не могу под этой учёткой аутетнтифицироваться в приложении через OpenLDAP

trider
() автор топика
Ответ на: комментарий от trider

Надо смотреть в сторону olcAccess в olcDatabase={2}hdb,cn=config (твоё название базы может отличаться).

Попробуй поискать под rootdn (задаётся olcrootdn, olcrootpw). Если под ним находит, то дело в правах доступа. Если нет, то выкладывай лог slapd для данного запроса.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Ivan_qrt

Ещё один момент, что по полю uid например поиск проходит, а под privateEmail - нет: 

# ldapsearch -D "uid=Administrator,cn=Administrators,dc=my,dc=domain,dc=ru" -w administratorpassword -h Myldap-server01 -p 389 -b cn="Users,dc=my,dc=domain,dc=ru" "uid=OID.1234567890"
# extended LDIF
#
# LDAPv3
# base <cn=Users,dc=my,dc=domain,dc=ru> with scope subtree
# filter: uid=OID.1234567890
# requesting: ALL
#

# OID.1234567890, Users, my.domain.ru
dn: uid=OID.1234567890,cn=Users,dc=my,dc=domain,dc=ru
objectClass: myUser
objectClass: top
privatePhone: +7(777)7777777
userPassword:: e1NTSEF9d2dLT3pldXA1SGNxMWNoRzJFNC85UDFxM3RwR2YrWnRzelFzZHc9PQ=
 =
privateEmail: test@test.ru
userOid: 1234567890
isTrusted: TRUE
uid: OID.1234567890
lastName:: VGVzdA==
firstName:: VGVzdA==
nsAccountLock: false

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


"uid=Administrator,cn=Administrators,dc=my,dc=domain,dc=ru" -w administratorpassword -h Myldap-server01 -p 389 -b cn="Users,dc=my,dc=domain,dc=ru" "privateEmail=test@test.ru"
# extended LDIF
#
# LDAPv3
# base <cn=Users,dc=my,dc=domain,dc=ru> with scope subtree
# filter: privateEmail=test@test.ru
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1
trider
() автор топика
Ответ на: комментарий от trider

Он и без индексов должен искать. Только дольше. Проиндексировать все атрибуты, по которым ведётся поиск, разумеется, нужно. Но проблема не в этом.

От rootdn проверял? Где лог slapd?

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Ivan_qrt

Лог slapd.log на момент поиска privateEmail=test@test.ru: http://www.paste.org/83907

Ещё отрабатывает фильтр 'privateEmail=*', выдаёт мою единственную запись в ldap, но с конкретным e-mail не работает, ну и та же ситуация с поиском по другими атрибутам, privatePhone....

От rootdn проверял?

А что в параметрах ldapsearch -b надо указать, не очень понял как корень обозначить

trider
() автор топика
Ответ на: комментарий от trider

Чё-то не понятно. В логе есть:

begin get_filter
EQUALITY
get_ava: illegal value for attributeType privateEmail 
end get_filter 0

Не уверен, что тут имеется ввиду, возможно данным атрибутом не поддерживается equality. Тип privatemail у тебя postaladdress. Я postaladdress никогда не пользовался, и ему не доверяю. Можно попробовать заменить на обычную строку.

В общем что тут можно сделать:

  • Попробовать поискать по «privatemail=tes*»
  • Добавить индексы, возможно дело всё-таки в них.
  • Изменить тип privatemail на 1.3.6.1.4.1.1466.115.121.1.15.

Ну и раз с privatephone тоже не работает, хотя он, как-раз, обычная строка, то выложи лог и для него.

На rootdn забей, с правами всё хорошо.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от Ivan_qrt

Попробовать поискать по «privatemail=tes*»

Тоже выдаёт result: 0

Добавить индексы, возможно дело всё-таки в них.

Ооо, там тоже лес дремучий, на stackoverflow уже завёл тему: http://stackoverflow.com/questions/42651056/equality-index-of-attribute-priva...

Изменить тип privatemail на 1.3.6.1.4.1.1466.115.121.1.15.

Ситуация не изменилась, остановил sdlapd, удалил схему из /etc/openldap/slap.d/cn=config/cn=schema, запустил slapd, добавил изменённую схему заново: 

[root@Myldap-server01 ~]# slapadd -n 0 -l /root/my.ldif
_#################### 100.00% eta   none elapsed            none fast!
Closing DB...
Затем добавил мою тестовую запись и вся симптоматика осталась, поиск по uid работает, по фильтру privateEmail=*, по конкретному e-mail - нет...

trider
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Apache mpm_prefork, cgi-bin, php, mysql
Admin
Jenkins: git plugin: Error cloning remote repo 'origin' →