Странный фильтр ldap (member‹==›CN=usera,OU=xxx,OU=xxx,DC=abc,DC=corp,DC=xyz,DC=com)

На контроллере домена я вижу этот запрос:

Клиент: 10.168.xy:51388 Начальный узел: DC=abc,DC=corp,DC=xyz,DC=com Фильтр: (member‹==>CN=usera,OU=xxx,OU=xxx,DC=abc,DC =corp,DC=xyz,DC=com) Область поиска: поддерево Выбор атрибута: имя Серверные элементы управления:

Посещенные записи: 55683 Возвращенные записи: 14 Используемые индексы: Ancestors_index:12171:N; Страниц, на которые ссылаются: 355546 Страниц, прочитанных с диска: 0 Предварительно прочитанных страниц с диска: 0 Чистых страниц изменено: 0 Грязных страниц изменено: 0 Время поиска (мс): 344 Атрибуты, препятствующие оптимизации: member
Пользователь: xx\usera

Этот запрос вызвал высокую загрузку ЦП на DC Win 2016.

Однако, когда я запускаю это в ldp, он не возвращает никакого результата. Если я использую файлер (member=…..), он возвращает какой-то результат. Но если я использую фильтр (member‹==>…….), он ничего не возвращает.

Такого фильтра я еще не встречал. Это правильный фильтр? Если это не так, почему это возвращает 14 записей, как видно из журнала событий?

Любая помощь приветствуется.


active-directory ldap cpu-usage domaincontroller
person Green Light    schedule 27.11.2019    source источник
comment
Это определенно недопустимый фильтр, но, вероятно, это обозначение, используемое в журналах для расширенного поиска, как указано @gabriel-luci.   -  person Ludovic Poitou    schedule 29.11.2019
comment
Спасибо, Габриэль. Я могу использовать :1.2.840.113556.1.4.1941: и получать записи.   -  person Green Light    schedule 29.11.2019

Ответы (1)


arrow_upward
1
arrow_downward

Я никогда не просматривал журналы сервера, но мне интересно, использовали ли они идентификатор объекта LDAP_MATCHING_RULE_IN_CHAIN (OID), и именно так он отображается в журналах. Запрос LDAP, который вы на самом деле использовали бы, выглядит следующим образом:

(member:1.2.840.113556.1.4.1941:=CN=usera,OU=xxx,OU=xxx,DC=abc,DC=corp,DC=xyz,DC=com)

Подробнее об этом можно узнать здесь , но в основном это будет искать любую группу, в которую входит пользователь, но рекурсивно. Таким образом, если Group A содержит Group B, а Group B содержит usera, то этот поиск вернет как Group A, так и Group B. Так что да, это был бы несколько нагруженный процессором поиск, но иногда он был бы очень полезным.

Так что попробуйте это и посмотрите, увидите ли вы то же самое в своих журналах, когда попробуете.

С точки зрения приложения, иногда такой поиск используется для разрешений, поскольку, если мы используем мой пример выше, если Group A предоставлены разрешения для приложения, то usera должно быть разрешено, даже если они не являются прямой участник.

Однако есть и другие способы сделать это, в зависимости от того, на чем написано приложение. Например, токен входа пользователя в Windows уже будет содержать рекурсивный список SID каждой группы, членом которой он является. Но может не быть доступного токена входа, когда эта информация необходима.

person Gabriel Luci    schedule 28.11.2019