Нарушение LDAP при перемещении пользователя
С тех пор, как я работал в этой компании, у нас была очень простая установка AD. Пользователи входят в пользовательский CN, и есть несколько OU для компьютеров, таких как настольные компьютеры и серверы.
Недавно я планировал более комплексный дизайн, позволяющий настраивать индивидуальные параметры GP (в частности, принтеры). Я хочу переместить пользователей в подразделения, созданные для каждого отдела. Судя по результатам моего тестирования, все, за исключением одного приложения, работало нормально.
JReport - это приложение для создания отчетов, в котором есть настройка LDAP для импорта пользователей. Затем он реализует единый вход, используя эту информацию. Отлично работает с нашими текущими настройками, но когда я перемещаю пользователя из CN = Users в OU = XYZ, он больше не может аутентифицироваться.
Вот скриншот настроек приложения: 
Как видите, это довольно простая установка. Если я проверю соединение, у менеджера каталогов будет доступ. Если я запрошу пользователей, я могу увидеть пользователей, которые находятся в новом подразделении. Но если я попытаюсь получить доступ к отчету, это не сработает. Даже если я ввожу учетные данные вручную.
Итак, я думаю, мой вопрос: может ли кто-нибудь придумать какую-либо причину, по которой перемещение пользователя в новое подразделение может нарушить это?
Обнюхивайте трафик LDAP во время попытки аутентификации, чтобы увидеть, что он на самом деле делает. Это лучший способ понять это.
Я рискну и немного порассуждаю. Поскольку вы говорите об «импорте» пользователей, мне интересно, не поддерживает ли он постоянную запись старого DN пользователя и, когда вы перемещаете пользователя, новый DN не запрашивается в процессе аутентификации.
Перемещаются ли группы из CN пользователей?
Я не уверен, что за cn=users вещь под Group Schema будет выполняться в контексте сопоставления полей и фильтрации, которые он должен делать ... но, может быть, это базовое DN для групп относительно глобального базового DN («Корневая запись»), установленного для каталога?
Было бы больше смысла использовать в качестве сопоставления атрибутов, и в этом случае это должно быть distinguishedName (и пока мы это делаем, "Тип члена группы" должен быть member если я правильно истолковываю их формулировки).
Попробуйте очистить отличительное имя группы, предполагая, что это базовое DN, и посмотрите, к чему это приведет.