Active Directory не поддерживает фильтры на основе OU.В данном случае это «расширяемый фильтр соответствий», который поддерживается некоторыми реализациями LDAP, но не всеми (включая AD). Больше информации здесь .
Кстати, вы не можете выполнить поиск по шаблону на distinguishedName
, если у вас возникнет желание попробовать.
Бытьчестно, вот почему лучше иметь все ваши «личные» учетные записи пользователей в одном подразделении (может быть подразделены дальше вниз), группы в другом и т. д. В вашем случае, если вы можете, это может быть хорошей идеей перенести ваш »синхронизация "учетных записей подразделений под новым подразделением.Если у вас есть корпоративная среда, вы должны быть осторожны, чтобы не было никаких зависимостей от структуры OU, прежде чем вносить такие изменения.Или, что вы можете определить любые такие зависимости и исправить их до или во время внесения изменений.
В противном случае вам нужно будет сделать свою базу поиска корневым для домена.Если у вас есть другие атрибуты учетной записи пользователя, которые вы можете использовать для поиска, например, названия отделов или аналогичные, это будет работать.Если это учетные записи сотрудников, у них всех есть общее заполненное поле, например «employeeID» или «streetAddress» или что-то еще?Или учетные записи, которые вы хотите исключить, имеют определенный формат имени (например, все учетные записи служб, начинающиеся с "SVC")?Комбинируя подобные вещи, вы, как правило, можете получить это довольно неплохо.
Наконец, для поиска обычных учетных записей пользователей, более эффективный базовый запрос:
(samAccountType=805306368)
Ваш запрос (objectCategory=person)
возвращает Пользователь и Контактные объекты.Обычный способ определения его свойства - (&(objectClass=user)(objectCategory=person))
, но два условия делают его менее эффективным, чем моя рекомендация (которая также использует индексированный атрибут).