Блог

Я использую filter как (cn=${prefix}*) , где $prefix = 'a'; но все равно он говорит, что найдено 0 записей.

В то время как, когда я выполняю простой поиск без этого фильтра, я нахожу много записей, начинающихся с 'a' .

вот некоторая часть кода: — мой $ prefix = shift(); мой $result = $ldap-> поиск (base => «$ldapbase», scope => «sub», filter => «(objectclass=)(cn= $prefix)», attrs => [‘*’]) или die «дерево поиска ошибок: $ @ n»;

my $ldapbase предоставляет мне подробную информацию обо всех сотрудниках, и я хочу только те, которые начинаются с 'a' .

Возможно, было бы разумно предупредить администратора LDAP о том, что вы собираетесь отправлять запросы, связанные с использованием подстрок. Администратор LDAP может иметь возможность индексировать CN для поиска по подстроке, чтобы поиск был быстрее. Фильтр '(cn=a*)' является фильтром подстрок и должен возвращать все атрибуты CN из вашей базы поиска ‘downward’ (в примере вы используете область поддерева), которые начинаются с букв ‘a’ или ‘A’ (CN, вероятно, является типом DirectoryString и может не учитывать регистр).

С практической точки зрения, некоторым старым серверам каталогов требуется более одного символа перед '*' символом подстроки, чтобы индексы подстрок работали, например, '(cn=ab*)' на некоторых серверах могут использоваться индексы, тогда как '(cn=a*)' индексы могут не использоваться.

В вашем примере кода вы указываете фильтр '(objectClass=)(cn=$prefix)' , который не является законным фильтром поиска LDAP. Возможно, вы имели в виду '(amp;(objectClass=inetOrgPerson)(cn=${prefix}*))' (inetOrgPerson может быть каким-то другим классом объектов), и приведенный код является опечаткой. Если вам нужен только DNS записей, которые начинаются с ‘a’ или ‘A’, вы можете запросить ‘специальный’ атрибут ‘1.1’, таким образом, возвращается только DN записи и никаких атрибутов.

Часто, когда мы обнаруживаем, что наши клиенты ищут CN, начинающиеся с a, следующий поиск, который мы видим от них, касается CN, начинающихся с aa. Раньше, до того, как у нас было так много пользователей, следующим поиском были CNS, начинающиеся с b.

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

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

Иногда эти приложения можно настроить на использование внешнего LDAP в режиме наложения, их просто нужно настроить для этого. В каждом случае, когда меня просили помочь в подобной ситуации, в документации приложения явно говорилось, что это может сделать, но это просто было не в терминах, которые администратор приложения распознал как говорящие это.

В большинстве случаев пользовательская база приложения намного меньше, чем вся компания, и они пытаются привлечь всех пользователей компании, когда им действительно нужно менее 1% из них. Возможность запрашивать что-то еще, что просто выбирает желаемых пользователей, например, как (departmentnumber=7159) , обычно работала бы намного оптимальнее.