Вопрос или проблема
Я создал LDAP-алиас, следуя FAQ:
dn: uid=alias,ou=People,dc=example,dc=net
objectclass: alias
objectclass: extensibleObject
uid: alias
aliasedobjectname: uid=target,ou=Retired People,dc=example,dc=com
Проблема, с которой я сталкиваюсь, заключается в том, что это должно запрашиваться приложением (которое я не контролирую), которое запрашивает LDAP в поисках определенного objectClass, вот так:
(&(objectClass=person)(uid=alias))
Этот запрос не находит алиас, полагаю, потому что объект алиаса имеет только “alias” и “extensibleObject” в качестве классов… Ожидается ли это? Есть ли способ обойти это на стороне сервера? Я имею в виду, сказать серверу LDAP искать “алиасированные” свойства?
(Я использую slapd 2.4.57)
Ответ или решение
Для того чтобы успешно выполнить запрос через LDAP на алиас, необходимо учитывать, что сам по себе алиас не имеет нужного объектного класса, который запрашивается вашей приложением (в данном случае person), а вместо этого только классы alias и extensibleObject.
Когда ваше приложение производит поиск с фильтром (&(&(objectClass=person)(uid=alias))), оно ожидает, что объект, который оно ищет, будет иметь класс person в своей иерархии объектных классов, однако алиасы не наследуют другие объектные классы, поэтому поиск возвращает пустой результат.
Варианты решения проблемы:
-
Создание вспомогательного объекта:
Если возможно, вы можете создать объект в LDAP с нужным объектным классом, который будет использоваться вместо алиаса. Например, вы можете создать новый объект типаperson, который будет содержать информацию о целевом объекте. Затем используйте этот объект в своих запросах. -
Использование сервера LDAP для создания виртуальных объектов:
Некоторые серверы LDAP позволяют использовать подстановочные объекты или виртуальные объекты. Однако в OpenLDAP этой возможности нет из коробки. Это необходимо реализовать через плугины, такие какslapo-ppolicy, но они могут не поддерживать полное решение вашей задачи. -
Изменение обеспечения поиска на уровне приложения:
Если вы имеете доступ к разработчикам приложения, которое отправляет запрос, вы можете предложить обновленный подход для обработки алиасов. Вместо того чтобы жёстко запрашивать определенные классы, можно заранее извлекать алиасы, а затем, по значениюaliasedObjectName, дополнительно извлекать фактические объекты, чтобы получить нужные данные. Это может потребовать дополнительных изменений в логике приложения. -
Обходной путь с помощью LDAP-прокси:
Если у вас есть возможность настройки прокси-сервера LDAP, вы можете создать слой, который будет перехватывать запросы и изменять их на уровне прокси, адаптируя их к вашему LDAP-серверу. -
Пользовательские фильтры и расширения:
Проверьте, возможно ли использовать пользовательские фильтры или расширительные механизмы на стороне клиента, которые могут интерпретировать алиасы и правильно обращать к целевым объектам.
Заключение:
К сожалению, LDAP и его стандарты сильно ограничены в их гибкости в работе с алиасами. Если вы сможете изменить способ работы вашего приложения или создать "настоящий" объект этого класса, это, вероятно, будет наилучшее решение. Надеюсь, эти рекомендации помогут вам пересмотреть вашу структуру LDAP и соответствующие запросы для достижения необходимых результатов.