OpenLDAP как PROXY к AD

[vokchaks]

Доброго времени.
Настроил 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

Подскажите, пожалуйста, куда копать?

[egor]

Здравствуйте! В обоих случаях отказа логика прослеживается. Если во втором случае

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 не происходит, так что все записи видны.

Егор

[vokchaks]

Спасибо Егор.

По поводу первой части -Вы абсолютно правы, это проходит из-за особенностей 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 и все вернется к прежнему решению.