PHP/LDAP: фильтр плохих результатов (OU с амперсандом)

Question

Я недавно написал класс аутентификации ldap (работающий с Active Directory) и недавно создал новое веб-приложение для другого отдела, который использует этот класс проверки подлинности ,

В основном пользователь вводит свои учетные данные, мой скрипт связывается с AD и проверяет, является ли пользователь членом определенной группы. Аутентификация пароля работает каждый раз, но проверка членства в группах работает только, если пользователь не находится в подразделении или ниже него с амперсандом в его имени.

Проблема заключается в том, что название отдела содержит амперсанд, и поэтому организационная единица тоже делает это. Несмотря на то, что у меня есть разрешения в AD для изменения имени, наиболее вероятно, что другие приложения получают доступ к этому OU по имени, поэтому я не могу его изменить (также я не знаю, существуют ли другие OU с амперсандами в их именах, такая же проблема может возникнуть позже).

Смешная вещь: Если я использую ldp.exe под окнами, я могу использовать тот же самый фильтр поиска без каких-либо проблем, поэтому я думаю, что это проблема с правильной передачей самого символа (мое приложение использует UTF-8 и амперсанд символы отображаются правильно, когда вытащили из AD и печататься, поэтому я не думаю, что это проблема кодирования)

линии я использую для создания фильтра является:

$filter = "(&(objectClass=group)(member:1.2.840.113556.1.4.1941:=".$userdn."))";

где userdn происходит от другого ldap_search до, где я успешно проверил пароль пользователя.

Я действительно споткнулся, потому что на самом деле я использую DN, который я использую для группового запроса из активного каталога (и, похоже, он правильно экранирован), но не может использовать его в другом ldap_search.

Я уже пытался убежать/замену & -symbol с некоторыми альтернативами:

\&

&

%26

и множества вариантов тех, но все они eturn то же самое ошибка «плохого фильтра».

(PHP Version 5.3.2-1ubuntu4.17)

Может кто-нибудь сказать мне, что я делаю неправильно здесь?

Answer 1

Я наконец понял (после нескольких дополнительных часов) - проблема не была амперсандом в конце концов, но это была проблема с экранированием - DN моего пользователя также содержал запятую, которая уже сбежала (так что я сделал я действительно думаю об этом).

На самом деле мне пришлось преобразовать escape-символ() в chr (0x5c). Эта статья (krivokuca.net/2012/08/...) имела решение.

Смешная вещь: у меня уже была функция экранирования, которая конвертировала «\» в «\ 5c», но эта проблема не помогла с этой конкретной проблемой.

Спасибо за усилия, чтобы помочь мне :)