ldapsearch for users работает для одного пользователя, но не для другого, хотя ADSI Edit показывает, что все атрибуты есть и корректны

Question

Я пытаюсь использовать ldapsearch для устранения причин, по которым у меня возникают странные проблемы с пользователями.

Я могу выполнить следующий запрос и найти пользователя в AD:

ldapsearch -h <my_host> -p 389 -x -b "cn=users,dc=domain,dc=name" -s sub "name=test 01"

Это возвращает с информацией для пользователя, как я ожидал. Если я запускаю ту же команду, но переключаю test01 на test02, я получаю «результат: 32 такого объекта нет».

Я вошел в AD и вижу, что пользователь находится в той же структуре / папке, что и другие. пользователь. Они имеют одинаковые точные разрешения. Я открыл обоих пользователей бок о бок в редакторе ADSI, и я вижу, что атрибут «имя» является правильным. Я отключил и снова включил пользователя. Я даже построчно прочесывал ADSI Edit между работающим пользователем и тем, кто не работает, и они выглядят одинаково. Я попытался выполнить поиск по другим атрибутам, таким как sAMAAccountName, и он все еще не работает для этого отдельного пользователя. Я гарантировал, что я использую учетную запись администратора с adsi, и нет никакой разницы в структуре того, где живет пользователь

Этот пользователь работал правильно до недавнего времени. Единственное, что мне удалось найти, это использовать ldapsearch, и он не смог найти объект (поскольку все, что я искал в AD, выглядело правильно). Если я запускаю весь поиск (без опции -s), я вижу, что он находит:

# test 02, Users, domain.name
dn: CN=test 02, CN=Users,DC=domain,DC=name

, но ничего больше для пользовательских атрибутов. У других пользователей, которых я вижу, есть возвращаемые объектные классы и все другие атрибуты, которые я вижу в редакторе ADSI под их записью. Я видел, как это произошло с парой учетных записей за последние несколько месяцев, и единственный обходной путь, который у меня есть, - это просто создать новую учетную запись для пользователя ... Очевидно, плохой обходной путь.

Я упускаю что-то очевидное или что может происходить?

Answer 1

На вкладке безопасности учетных записей, которые не возвращают данные, проверьте, есть ли какие-либо записи контроля доступа «DENY». Запрет имеет приоритет, поэтому одноразовый запрет может помешать отображению информации там, где есть запись разрешения на более высоком уровне.

Проверьте, включено ли наследование. В некоторых случаях это программно отключено - администраторы домена - и вам необходимо изменить набор разрешений на AdminSDHolder , чтобы ввести изменения разрешений для управляемых объектов. Если наследование отключено, но учетные записи не являются администраторами, к которым применяется AdminSDHolder, добавьте анонимное разрешение на чтение для объекта (ваше сообщение указывает, что вы хотите анонимное чтение для пользовательских объектов). Или риск, позволяющий наследовать.

Если ничего не помогает, используйте «Дополнительно» на вкладке «Безопасность» и выберите вкладку «Эффективный доступ». Нажмите, чтобы выбрать пользователя и введите «Аноним». Принять. Затем нажмите «Просмотреть эффективный доступ». Сравните анонимный и эффективный доступ как к рабочему, так и к нерабочему аккаунту.

Answer 2

У меня недавно была такая проблема, когда пользователь перестал появляться в веб-приложении. Который синхронизирует пользователей из AD.

Потратив пару дней на то, что не так с пользователем и сравнив его с рабочими. Мое решение было просто.

" Удалите этого пользователя из группы пользователей домена, отключите его, затем включите и добавьте обратно в группу пользователей домена ."

после выполнения вышеуказанного действия пользователь снова начал синхронизацию, как прежде .

Answer 3

Ваш фильтр для поиска должен быть:

ldapsearch -h <my_host> -p 389 -x -b "cn=users,dc=domain,dc=name" -s sub "CN=test 01"

или

ldapsearch -h <my_host> -p 389 -x -b "cn=users,dc=domain,dc=name" -s sub "samacountname=test 01"