Хорошо, поэтому я впервые изучаю и настраиваю openLDAP, частично основываясь на этом руководстве:
http://www.rjsystems.nl/en/2100-d6-openldap-provider.php
Я пытаюсь добавить примерного пользователя, но мне кажется, что я заметил тип в учебнике. В примере ldif автор использовал cn: Christopher. Я подумал, что cn должно быть более коротким именем, похожим на uid, если не совсем таким. Итак, в моем ldif я установил оба cn и gn (givenName), но я получаю сообщение об ошибке в отношении givenName:
ldap_add: Object class violation (65)
additional info: attribute 'givenName' not allowed
Вот мой ldif:
dn: cn=tarcuri,ou=groups,dc=example,dc=com
cn: jsmith
gidNumber: 20000
objectClass: top
objectClass: posixGroup
dn: uid=tarcuri,ou=people,dc=example,dc=com
uid: jsmith
uidNumber: 20000
gidNumber: 20000
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
cn: jsmith
gn: John
sn: Smith
loginShell: /bin/bash
homeDirectory: /home/jsmith
userPassword: john
Как мне изменить свой файл ldif, чтобы правильно установить 'givenName', потому что это похоже на person должен иметь возможность иметь имя. Занимает sn после всего.
Спасибо!!
ОБНОВИТЬ Итак, я попытался использовать inetOrgPerson, который включает заданное имя, но после использования ldapsearch для проверки результатов я вижу следующее:
givenName:: VGhvbWFzIA==
Когда у него должно быть имя, которое я использовал в файле ldif. Очевидно, что что-то происходит, у кого-нибудь есть понимание? Обратите внимание на два двоеточия после givenName.
Боюсь RFC 2256 и его потомки виноваты здесь: согласно RFC у человека нет заданного имени, и ваш сервер LDAP (правильно) отказывается позволить вам назначить этот атрибут.
У вас есть несколько вариантов: вы можете использовать cn (обычное имя) как только имя, добавьте дополнительный объектный класс (например, inetOrgPerson), который поддерживает givenName, или выберите другой структурный объектный класс (опять же, например, inetOrgPerson) для создания вашего объекта.
Вообще говоря, inetOrgPerson - это объектный класс, подобный «человеку», который вы все равно хотите использовать: он намного полезнее, чем обычный LDAP-объект.
Обновление Re: ваше обновление. Фантастическая строка, которую вы получаете в результате givenName фактически является строкой в кодировке base-64 (VGhvbWFzIA== => Thomas). Большинство клиентов смогут декодировать это автоматически, я не уверен, почему у вас этого не произошло (возможно, где-то произошла ошибка конфигурации).
Двойные двоеточия (::) указывают, что предоставленное значение было закодировано по основанию 64. Это часто может произойти при использовании некоторых версий более старого OpenLDAP. ldapmodify инструмент, особенно если в конце значения атрибута есть пробел. Конечные пробелы не допускаются в конце значений, но OpenLDAP ldapmodify не принимает во внимание этот факт и все равно отправляет запись и неправильный атрибут на сервер, в результате чего сервер правильно base64 кодирует значение атрибута.
Я не знаю, так ли это в вашем примере, но это возможно. Смотри мой запись в блоге на ldapmodify.
Вы должны проверить, включает ли объектный класс «person» атрибут «givenName». Если это не так (что, вероятно, так), попробуйте заменить «person» на «inetOrgPerson».
Сообщение об ошибке, которое вы цитируете, выдается, когда вы пытаетесь назначить атрибут объекту, где этот атрибут не входит ни в один из ObjectClasses этого объекта. Казалось бы, что gn не определен в схеме ни для одного из top, person, shadowAccount, или posixAccount.