В настоящее время я работаю над интеграцией аутентификации LDAP в систему, и я хотел бы ограничить доступ на основе группы LDAP. Единственный способ сделать это - через поисковый фильтр, и поэтому я считаю, что мой единственный вариант - использование атрибута "memberOf" в моем поисковом фильтре. Насколько я понимаю, атрибут «memberOf» - это операционный атрибут, который может быть создан сервером для меня в любое время, когда для любой записи «groupOfNames» на сервере создается новый атрибут «member». Моя главная цель - иметь возможность добавить атрибут «member» к существующей записи «groupOfNames» и добавить соответствующий атрибут «memberOf» в DN, который я предоставляю.
Чего мне удалось достичь до сих пор:
Я все еще довольно новичок в администрировании LDAP, но, основываясь на том, что я нашел в руководстве администратора openldap, похоже, что обратное обслуживание членства в группе, называемое "memberof overlay", достигнет именно того эффекта, который я ищу.
Мой сервер в настоящее время выполняет установку пакета (slapd на Ubuntu) openldap 2.4.15, который использует конфигурацию времени исполнения в стиле «cn = config». Большинство примеров, которые я нашел, все еще ссылаются на более старый метод "slapd.conf" статической конфигурации, и я старался изо всех сил адаптировать конфигурации к новой модели на основе каталогов.
Я добавил следующие записи, чтобы включить оверлейный модуль memberof:
Включить модуль с помощью olcModuleLoad
cn=config/cn\=module\{0\}.ldif
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}memberof.la
structuralObjectClass: olcModuleList
entryUUID: a410ce98-3fdf-102e-82cf-59ccb6b4d60d
creatorsName: cn=config
createTimestamp: 20090927183056Z
entryCSN: 20091009174548.503911Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20091009174548Z
Включил оверлей для базы данных и позволил ей использовать настройки по умолчанию (groupOfNames, member, memberOf и т. Д.)
cn=config/olcDatabase={1}hdb/olcOverlay\=\{0\}memberof
dn: olcOverlay={0}memberof
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}memberof
structuralObjectClass: olcMemberOf
entryUUID: 6d599084-490c-102e-80f6-f1a5d50be388
creatorsName: cn=admin,cn=config
createTimestamp: 20091009104412Z
olcMemberOfRefInt: TRUE
entryCSN: 20091009173500.139380Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20091009173500Z
Мой текущий результат:
Используя вышеупомянутую конфигурацию, я могу добавить НОВЫЙ «groupOfNames» с любым количеством записей «member» и обновить все задействованные DN с помощью атрибута «memberOf». Это часть поведения, которое я ожидаю. Хотя я полагаю, что с оверлеем memberof должно быть выполнено следующее, я все еще не знаю, как сделать следующее, и я с радостью приветствую любые советы:
- Добавьте атрибут "member" в СУЩЕСТВУЮЩУЮ группу "groupOfNames" и создайте соответствующий атрибут "memberOf" автоматически.
- Удалите атрибут «member» и удалите соответствующий атрибут «memberOf» автоматически.
slapadd(на остановленную базу данных) не правильный способ сделать это?Недавно я написал об этом в своем блоге, www.jordaneunson.com, в который скопировал и вставил соответствующие части.
Мне нужно было остановить службу «slapd» на моем сервере LDAP, отредактировать файл slapd.conf и добавить следующие две строки.
У меня уже был groupOfNames с именем vpn, поэтому мне пришлось создать файл LDIF со следующим содержимым:
И добавил это в мою базу данных ldap
После этого я запустил сервер ldap в отладке, чтобы проверить ошибки
и проверил, чтобы членство в моей группе «vpn» было указано в моей записи пользователя.
и бац! Успех!
Поэтому я снова запустил сервис slapd и с тех пор добился большого успеха. Для нового инструмента управления графическим интерфейсом я использую phpLDAPAdmin, и у меня нет проблем с назначением и отменой назначения атрибута memberOf моим пользователям.
Последнее, на что следует обратить внимание, это то, что атрибут memberOf не является частью базовой схемы LDAP v3, и, следовательно, выполнение ldapsearch не покажет этот атрибут, если не будет запрошен конкретный запрос. Вот почему в моем примере выше он объявлен в конце параметров ldapsearch.
Надеюсь это поможет.
Изменить: Я только что проверил вашу проблему с Apache Directory Studio: до тех пор, пока я ввожу значение члена атрибута в целом, как упомянуто выше, он работает A-OK. Однако атрибут memberOf не отображается в пользовательской записи. Это связано с тем, что атрибут memberOf не является частью схемы LDAPv3. Чтобы убедиться в этом, используйте инструмент командной строки ldapsearch:
источник