Ошибка при получении instanceType для базы — поиск LDAP

Я подключаюсь к серверу AD из своего приложения, используя LDAP. Я успешно прошел аутентификацию, но когда я ищу пользователя, он выдает исключение с кодом ошибки LDAP 32 в acl_read: instanceType для базы.

javax.naming.NameNotFoundException: [LDAP: error code 32 - acl_read: Error retrieving instanceType for base. at ../source4/dsdb/samdb/ldb_modules/acl_read.c:362]
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)

Я проверил baseDN, доменное имя и порт, они верны, и мы можем подключиться к нему.

Я получил строку запроса из журналов и проверил ее в пользовательском поиске в браузере AD. Кажется, он работает нормально и возвращает результаты.

Query from Logs: (&(objectClass=user)(objectCategory=person)(|(|(sAMAccountname=*MSUser1*)(givenName=*MSUser1*)(sn=*MSUser1*))))

Не уверен, что здесь происходит не так. Может ли кто-нибудь помочь мне в выявлении и устранении этой проблемы.

Спасибо


active-directory ldap ldap-query
person samuelebe    schedule 14.11.2017    source источник
comment
Что-то не так с вашим baseDN. Предложите попробовать использовать ИЗВЕСТНЫЙ хороший браузер LDAP или утилиту ldapssearch. (Мне нравится directory.apache.org/studio )   -  person jwilleke    schedule 14.11.2017
comment
Спасибо, я использовал AD Browser с тем же baseDN, и это сработало. Тем не менее, я собираюсь попробовать с Apache.   -  person samuelebe    schedule 14.11.2017
comment
Я пробовал с браузером Apache, и он работал с тем же baseDN. Пользовательский поиск также дал мне результаты. Любые другие мысли, пожалуйста?   -  person samuelebe    schedule 14.11.2017
comment
Как будет выглядеть точный запрос с использованием команды ldasearch?   -  person EricLavault    schedule 14.11.2017
comment
Я только что попытался найти администратора в браузере Apache LDAP, и это сработало. это точный запрос, который я использовал в поиске LDAP. Тот же запрос из приложения для того же baseDN дает ошибку.   -  person samuelebe    schedule 14.11.2017
comment
Это только фильтрующая часть. Обычно эта ошибка означает неверный базовый DN, возможно, синтаксическую ошибку или опечатку. Как выглядит база dn?   -  person EricLavault    schedule 14.11.2017
comment
это мой baseDN CN=Users,DC=awssiladev,DC=mycomp,DC=com   -  person samuelebe    schedule 14.11.2017
comment
Какое приложение вы используете? Некоторые приложения используют «базу поиска пользователей» относительно базового DN. Если вы находитесь в этой ситуации, правильная конфигурация будет выглядеть примерно так: base dn: 'dc=awssiladev,dc=mycomp,dc=com' и user base: 'cn=Users'   -  person EricLavault    schedule 14.11.2017
comment
Мы используем приложение MetricStream, и я вижу, что в файле свойств есть три параметра. TOP_LEVEL_OU_OR_GROUP_DN=DC=awssiladev,DC=mycomp,DC=com USER_OU_OR_GROUP_DN=CN=Users,DC=awssiladev,DC=mycomp,DC=com DN_PREFIX=DC=awssiladev,DC=mycomp   -  person samuelebe    schedule 14.11.2017
comment
DN_PREFIX кажется странным, я бы попробовал DN_PREFIX=CN= (или DN_PREFIX=CN)   -  person EricLavault    schedule 14.11.2017
comment
Это сработало. Наряду с этим есть другое место, где baseDN определяется фиктивным значением в файле свойств. Это перезаписывает наше DN. Исправление, которое помогло нам без проблем подключиться. Спасибо за вашу помощь.   -  person samuelebe    schedule 14.11.2017

Ответы (1)


arrow_upward
0
arrow_downward

Проблема связана с самим baseDN. Мы правильно настроили LDAP, но где-то в коде есть файл свойств, который перезаписывает baseDN, указанный в настройках. Его было очень сложно идентифицировать, потому что он нигде не задокументирован, и нам пришлось декомпилировать все файлы классов, чтобы добраться до деталей этого файла.

Вместе с этим мы изменили наши TOP_OU и USERS_OU и DN_PREFIX, после чего он начал подтягивать всех пользователей.

TOP_LEVEL_OU_OR_GROUP_DN=DC=awssiladev,DC=mycomp,DC=com
USER_OU_OR_GROUP_DN=CN=Users,DC=awssiladev,DC=mycomp,DC=com
DN_PREFIX=CN=
person samuelebe    schedule 14.11.2017