Форум проекта Pro-LDAP.ru
Общие вопросы по LDAP => Общий раздел => Тема начата: vokchaks от 19 Сентябрь 2013, 10:13:38
-
Доброго времени.
Настроил openldap как proxy к AD (т.к. принтер kyocera не принимает русские буквы и при запросе "DC=domen,DC=local"
выдает много служебных учеток в свою адресную книгу)
---- slapd.conf ----
database ldap
readonly yes
rebind-as-user yes
suffix "DC=domen,DC=local"
uri ldap://dc.domen.local/
idassert-bind bindmethod=simple
binddn="CN=ldap,OU=Services Users,DC=domen,DC=local"
credentials="password"
mode=self
idassert-authzFrom "dn:*"
overlay rwm
rwm-rewriteEngine on
rwm-suffixmassage "DC=domen,DC=local" "OU=Пользователи,DC=domen,DC=local"
--- end slapd.conf ----
если обращаюсь с запросом
ldapsearch -H ldap://localhost -x -b "dc=domen,dc=local"все выдается хорошо
Но если я пытаюсь добавить учетные данные к запросу
ldapsearch -H ldap://localhost -D "cn=ldap,ou=Services Users,dc=domen,dc=local" -b "dc=domen,dc=local" -LLL -w "password"то получаю ошибку :
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1
при другом запросе
ldapsearch -H ldap://localhost -D "ldap@domen.local" -b "dc=domen,dc=local" -LLL -w "password"ошибка:
ldap_bind: Invalid DN syntax (34)
additional info: invalid DN
оба этих запроса прекрасно проходят при замене localhost на dc.domen.local
Подскажите, пожалуйста, куда копать?
-
Здравствуйте! В обоих случаях отказа логика прослеживается. Если во втором случае
ldapsearch -H ldap://localhost -D "ldap@domen.local" -b "dc=domen,dc=local" -LLL -w "password"
она очевидна, поскольку ldap@domen.local -- это не DN, а чисто AD-шная приблуда, то в первом случае
ldapsearch -H ldap://localhost -D "cn=ldap,ou=Services Users,dc=domen,dc=local" -b "dc=domen,dc=local" -LLL -w "password"
за счёт наложения rwm при запросе к dc=domen,dc=local фактически идёт обращение к ou=Пользователи,dc=domen,dc=local, таким образом ветка ou=Services Users,dc=domen,dc=local со всеми своими пользователями просто не видна, о чём Вам и сообщает slapd. Если Вам обязательно нужно сделать rebind-as-user, то используйте DN из ветки ou=Пользователи, причём уже с подменой, то есть если у Вас в AD есть пользователь cn=user,ou=Пользователи,dc=domen,dc=local, то при запросе это будет
ldapsearch -x -LLL -H ldap://localhost -D "cn=user,dc=domen,dc=local" -b "dc=domen,dc=local" -w "userPassword"
Что касается того, что AD подобные запросы нормально отрабатывает, то удивляться тут нечему -- при обращении к AD напрямую никаких преобразований DN не происходит, так что все записи видны.
Егор
-
Спасибо Егор.
По поводу первой части -Вы абсолютно правы, это проходит из-за особенностей AD (жаль, что я этого сразу не знал и потерял много времени).
А вот по поводу второй части - мне это не подходит.
У меня нет пользователя от которого я делаю запросы с принтеров в ветке пользователей т.к. он служебный и находится в своей ветке дерева AD.
Я сделал полный debug запросов с ключом loglevel -1 и увидел все подробности запросов уходящих в AD.
Быстрое решение, которое я нашел - заменить запрос на принтерах и прописать в логине
"CN=ldap,OU=Services Users,DC=domen,DC=local"
и добавить две строчки в slapd.conf
rwm-rewriteContext BindDN
rwm-rewriteRule "(.*)" "" ":"
Теперь все запросы проходят одинаково с принтеров на прямую к AD и через openldap (только здесь отметается весь мусор).
Теперь достаточно изменить запись в DNS в случае отключения openldap и все вернется к прежнему решению.