Назад | Перейти на главную страницу

Проблемы openldap с добавлением атрибута

Я новичок в serverfault, но я уже использую поиск Google и serverfault, но не могу найти ответ на свою проблему. Мне нужно добавить новый атрибут в ldap, называемый разрешением, и иметь возможность устанавливать уровни привилегий.

Нашел несколько "способов сделать", но ни один из них не работает. Застрял точно так же, как здесь добавить новый атрибут для пользователей ldap и отправить в ldap

Пытаюсь

dn: cn=core,cn=schema,cn=config
changetype: modify
add: olcAttributeTypes
olcAttributeTypes: <new value>

dn: cn=core,cn=schema,cn=config
changetype: modify
add: olcAttributeTypes
olcAttributeTypes: ( 1.2.3.4.5.6.7 
 NAME ( 'test' 'test' ) 
 DESC 'test' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
 SINGLE-VALUE )

Но в лучшем случае я получаю

modifying entry "cn=core,cn=schema,cn=config"
ldap_modify: No such object (32)
    matched DN: cn=schema,cn=config 

ldap_modify: Invalid syntax (21)
additional info: attributetypes: value #0 normalization failed

или

ldap_add: Undefined attribute type (17)
    additional info: add: attribute type undefined

И у меня нет идей, как добавить этот атрибут: /

Поскольку я должен это сделать, я все еще пытаюсь (также создать новый сервер) и получаю следующие результаты
dn: cn = config
changetype: добавить
olcAttributeTypes: (2.5.4.66 ИМЯ 'разрешение'
DESC 'RFC2256: для пользователей Supermicro'
СИНТАКСИС 1.3.6.1.4.1.1466.115.121.1.15 {255})

ldap_add: Object class violation (65)
additional info: no objectClass attribute

Итак, добавляем objectClass
ldap_add: нарушение класса объекта (65)
дополнительная информация: класс объекта 'person' требует атрибута 'sn'

И что теперь ? Конечно, я хочу, чтобы это разрешение было частью объектного класса человека, как МОЖЕТ, но до сих пор не знаю, как изменить объектный класс
Результат
ldapsearch -H ldap: //ldap.ogicom.net -x -s base -b "" +
base <> с областью действия baseObject
# фильтр: (objectclass = *)
# запрос: +
dn:
structureObjectClass: OpenLDAProotDSE
configContext: cn = config
namingContexts: частный
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.3.6.1.1.22
supportedControl: 1.2.840.113556.1.4.319
ПоддерживаетсяКонтроль: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
поддерживаемое расширение: 1.3.6.1.4.1.4203.1.11.3
supportedExtension: 1.3.6.1.1.8
ПоддерживаемыеФункции: 1.3.6.1.1.14
ПоддерживаемыеФункции: 1.3.6.1.4.1.4203.1.5.1
ПоддерживаемыеФункции: 1.3.6.1.4.1.4203.1.5.2
ПоддерживаемыеФункции: 1.3.6.1.4.1.4203.1.5.3
ПоддерживаемыеФункции: 1.3.6.1.4.1.4203.1.5.4
ПоддерживаемыеФункции: 1.3.6.1.4.1.4203.1.5.5
поддерживаетсяLDAPВерсия: 3
поддерживаетсяSASLМеханизмы: DIGEST-MD5
поддерживаетсяSASLМеханизмы: NTLM
поддерживаетсяSASLМеханизмы: CRAM-MD5
entryDN:
subschemaSubentry: cn = Подсхема

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Хорошо, давайте немного поправим:

  1. ldapmodify могут оба Создайте и модифицировать узлы в вашем дереве LDAP. Такое поведение определяется параметром changetype. Итак, если вы используете changetype: add вы пытаетесь добавить новый узел. Очевидно, вам нужно будет присвоить этому новому узлу объектный класс, поэтому вы получили ошибку ldap_add: Object class violation (65) additional info: no objectClass attribute (тем не менее, эта операция была бы неудачной, потому что dn cn=config уже существует).
  2. Прежде всего вам нужно выяснить, какой узел содержит класс объекта (например, мой узел cn={0}core,cn=schema,cn=config содержит объектный класс person, тогда как inetOrgPerson находится в cn={3}inetorgperson,cn=schema,cn=config). Фигурные скобки перед первым атрибутом dn (в данном случае «core» или «inetorgperson») устанавливаются OpenLDAP для определения порядка, в котором загружаются узлы. Кстати: вот почему вы получили ldap_modify: No such object (32) при поиске cn = core, ... - скобки не попали :)
  3. Классы объектов и типы атрибутов хранятся в узлах с классом объекта olcSchemaConfig как атрибуты с типом атрибута olcObjectClasses или olcAttributeTypes соответственно. Просто посмотрите на свои схемы (например, ldapsearch -xLLLWD cn=admin,cn=config -b cn=schema,cn=config -s one или ldapsearch -xLLLWD cn=admin,cn=config -b cn={0}core,cn=schema,cn=config -s base), и вы получите представление, как это выглядит. Так что четко сформулируйте, что вы хотите сделать: вы пытаетесь модифицировать узел в форме, которую вы заменить один из атрибутов olcObjectClasses (в той форме, в которой вы его переопределяете, включая тип вашего атрибута. Если тип атрибута не был определен ранее, вам нужно будет добавить его как другой атрибут типа olcAttributeTypes либо в том же узле, либо в другом olcSchemaConfig). Вы бы сделали это с

dn: cn={0}core,cn=schema,cn=config changetype: modify replace: olcObjectClasses olcObjectClasses: {4}( 2.5.6.6 NAME 'person'...

ТЕМ НЕ МЕНИЕ:

Вы не хотите этого делать. Серьезно, не надо. Никогда не стоит связываться с уже существующими классами и атрибутами.

Вместо этого есть лучшие варианты, которые намного чище, и их следует выбирать вместо них:

  1. Быстрый способ: при создании следующего пользовательского узла вы можете использовать структурный объектный класс (например, "человек") и добавьте вспомогательный объектный класс «extensibleObject» в микс; это позволяет вам добавлять атрибуты любого существующего типа атрибута.
  2. Правильный способ: вы можете легко определить свои собственные классы объектов. То, что вы хотели бы сделать таким образом, - это либо создать свой собственный структурный class (который может унаследовать от любого другого класса объекта и быть расширен вашим атрибутом), который вы затем использовали бы для своего узла в качестве только объектный класс, или вы также можете создать вспомогательный объектный класс, который содержит атрибут и который будет использоваться как дополнительный класс объекта. Если вы выберете этот способ, убедитесь, что вы используете пространство имен (числа в определении, например, «2.5.4.66»), которое не будет конфликтовать с существующими классами и / или атрибутами. Вот как это будет выглядеть:

ldapadd -xWD cn=admin,cn=config dn: cn=<schemaName>,cn=schema,cn=config objectClass: olcSchemaConfig cn: <schemaName> olcAttributeTypes: ( <your namespace>.01.01 NAME <attributeTypeName> DESC <description> EQUALITY <equalitySettings> SYNTAX <syntaxSettings> ) olcObjectClasses: ( <your namespace>.02.01 NAME <objectClassName> DESC <description> AUXILIARY MUST <attributeTypeName> )

Изучение того, как обрабатывать cn = config, может сначала немного сбить с толку, но как только вы поймете концепции, лежащие в основе этого, вы поймете, что это намного круче, чем было раньше. Его определенно стоит изучить.

Радоваться, веселиться!

Ну, это не моя идея, но у меня есть ответ. Я делаю это ужасно

· Редактировать файл конфигурации,

$ vim /etc/ldap/schema/core.schema

· Добавить тип атрибута,

attributetype ( 2.5.4.66 NAME 'permission'

        DESC 'my desc '

        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} )

· Добавить "разрешение" к объектному классу "человек"

objectclass ( 2.5.6.6 NAME 'person'

        DESC 'RFC2256: a person'

        SUP top STRUCTURAL

        MUST ( sn $ cn )

        MAY ( userPassword $ telephoneNumber $ seeAlso $ description $ permission ) )

· Создать файл core.conf

$ vim /etc/ldap/core.conf

· Добавить строку ниже в core.conf

include /etc/ldap/schema/core.schema

· Удалите или сделайте резервную копию старого файла /etc/ldap/slapd.d/cn=config/cn=schema/cn={0}core.ldif

$ rm /etc/ldap/slapd.d/cn=config/cn=schema/cn={0}core.ldif

· Создать новый /etc/ldap/slapd.d/cn=config/cn=sch

$ slaptest -f /etc/ldap/core.conf -F /etc/ldap/slapd.d