ldapsearch

Материал из Xgu.ru

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

ldapsearch — утилита для поиска информации в службе каталога, доступной по протоколу LDAP.

[править] Примеры использования ldapsearch

Аутентифицироваться при подключении к каталогу под именем cn=admin,dc=mydc,dc=com (-D), использовать простую аутентификацию (-x), спросить пароль (-W); поиск выполнять начиная с dc=mydc,dc=com; результаты отфильтровать по выражению (ou=People), то есть показать только те записи, поле ou в которых имеет значение People:

Если мы хотим получить информацию об учётной записи пользователя, используем другой фильтр:

Буду найдены только те записи, у которых есть поле uid, и оно равно dor.

Если указать дополнительные аргументы в конце команды, они будут восприниматься как имена полей, которые должны быть выведены. Для найденных записей буду выводиться только те поля, имена которых указаны.

Вики IT-KB

Пошаговые руководства, шпаргалки, полезные ссылки.

Инструменты пользователя

Инструменты сайта

Боковая панель

Утилита ldapsearch (клиент OpenLDAP) и проверка подключения к контроллеру домена Active Directory

Проверку выполняем на примере Debian GNU/Linux 8 (Jessie). Сначала убедимся в том, что клиент OpenLDAP установлен в системе:

Исходные данные для проверки подключения клиента OpenLDAP к LDAP-каталогу на примере контроллера домена Active Directory (AD):

Проверка подключения по протоколу LDAP (TCP 389)

Используется подключение типа ldap:/. Учётные данные пользователя s-LDAP-Check-User передаются по сети в открытом виде:

Проверка подключения по протоколу LDAPS (TCP 636)

Используется подключение типа ldaps:/. LDAP-сессия шифруется с помощью SSL-сертификата, предоставляемого контроллером домена. Чтобы LDAP-клиент доверял сертификату контроллера домена, нам нужно создать файл, содержащий корневые сертификаты доменных Центров сертификации, которыми подписан сертификат контроллера домена. Назовём этот файл, например /etc/ssl/certs/cacerts.pem, и скопируем в него корневые сертификаты доменных ЦС в формате PEM и кодировке Base-64.

Изменим на время проверки конфигурационный файл клиента OpenLDAP /etc/ldap/ldap.conf, указав в переменной TLS_CACERT путь к созданному нами файлу с корневыми сертификатами доменных ЦС:

После этого можно попробовать выполнить поиск по протоколу LDAPS:

Проверка подключения по протоколу LDAP с защитой StartTLS (TCP 389)

Используется подключение типа ldap:/ с дополнительными ключами, включающими TLS : -Z и -ZZ. LDAP-сессия также шифруется с помощью SSL-сертификата, предоставляемого контроллером домена. Первичное подключение к контроллеру домена AD происходит по порту 389, затем создаётся отдельный защищённый TLS-туннель, внутри которого и происходит весь LDAP-обмен между клиентом и сервером. Используется настроенный нами ранее файл корневых сертификатов доменных ЦС.

Автор первичной редакции:
Алексей Максимов
Время публикации: 19.03.2017 18:04

LDAP-фильтры для поиска объектов в Active Directory. Часть 3

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

PowerShell

У командлетов Get-ADUser, Get-ADComputer, Get-ADGroup и Get-ADObject имеется параметр LdapFilter, специально предназначенный для использования LDAP-фильтров при поиске объектов в Active Directory. Для примера найдем всех пользователей с именем Vasya с помощью такой команды:

Get-ADUser -LdapFilter «(cn=Vasya)»

Большинство командлетов для поиска являются узкоспециализированными, т.е. предназначены только для определенного типа объектов (пользователи, компьютеры и т.п.). Исключение составляет командлет Get-ADObject, который может искать любые объекты. Например:

Get-ADObject -LdapFilter «(cn=Vasya)»

При использовании Get-ADObject мы получили не только пользователей, а все объекты с указанным в фильтре именем. Если требуется найти только пользователей, то надо в фильтре добавлять дополнительные параметры. Например:

Get-ADObject -LdapFilter «(&(objectCategory=person)(objectClass=user)(cn=Vasya))»

При помощи LDAP-фильтра нельзя указать область поиска. Для примера найдем всех пользователей, у которых в описании (Description) имеется слово Руководитель:

Get-ADObject -LdapFilter «(Title=Руководитель*)» -Properties * | ft -a DisplayName,Title

Эта команда произведет поиск по всему домену и выдаст всех найденных пользователей, вне зависимости от их местоположения.

Для уточнения области поиска есть параметр SearchBase, с помощью которого можно указать для поиска конкретное подразделение (OU), например:

Get-ADObject -LdapFilter «(Title=Руководитель*)» -Properties * -SearchBase «OU=Employees,DC=Test,DC=local | ft -a DisplayName,Title

Еще один полезный параметр Subtree, с помощью которого можно ограничить глубину поиска. Этот параметр может принимать 3 значения:

• Base (0) — поиск только по указанному в запросе объекту. В результате поиска возвращается либо один объект, либо ничего. Данная область, как правило, используется для проверки наличия объекта.
• One level (1) — поиск только по дочерним объектам указанного объекта. Поиск по вложенным объектам не производится, также в результаты поиск не попадает сам базовый объект.
• Subtree (2) — поиск по всем дочерним объектам, включая вложенные. Сам базовый объект в поиск не попадает. Это значение используется по умолчанию.

Для примера возьмем предыдущую команду и ограничим поиск верхним уровнем (OneLevel):

Get-ADObject -LdapFilter «(Title=Руководитель*)» -Properties * -SearchBase «OU=Employees,DC=Test,DC=local -SearcScope OneLevel | ft -a DisplayName,Title,DistinguishedName

А затем зададим поиск по всем вложенным объектам (Subtree):

Get-ADObject -LdapFilter «(Title=Руководитель*)» -Properties * -SearchBase «OU=Employees,DC=Test,DC=local -SearcScope SubTree | ft -a DisplayName,Title,DistinguishedName

Как видите, разница очевидна.

Для работы с Active Directory из командной строки существует великое множество различных утилит. Мы рассмотрим две наиболее часто используемые для поиска — dsquery и dsget.

Утилита dsquery возвращает различающееся имя (Distinquished Name) объекта, подходящего под заданные параметры, а для LDAP-фильтров у нее имеется параметр filter. К примеру, предыдущий запрос с использованием dsquery будет выглядеть так:

dsquery * OU=Employees,DC=test,DC=local -filter «(&(objectCategory=person)(objectClass=user)(Title=Руководитель*))» -Scope OneLevel

Утилита dsget получает на входе различающееся имя объекта и выдает для него значение указанного атрибута или атрибутов. Зачастую обе эти утилиты используются совместно, например:

dsquery * OU=Employees,DC=test,DC=local -filter «(&(objectCategory=person)(objectClass=user)(Title=Руководитель*))» | dsget user -display -title -dn

ADSIEdit

Переходим к графическим утилитам. Оснастка ADSIEdit поддерживает использование LDAP-фильтров. Для добавления фильтра надо кликнуть по выбраному контексту именования (NC) и в контекстном меню выбрать пункт New — Query…

В открывшемся окне указываем имя запроса, выбираем область поиска (Root of Search) и в поле Query String добавляем нужный фильтр. Для примера отберем всех отключенных пользователей. Дополнительно можно выбрать глубину поиска Subtree или One level.

В результате получим что то вроде этого.

Active Directory Users and Computers

В оснастке Active Directory Users and Computers (ADUC) имеется функция Saved Queries, которая представляет из себя сохраненные LDAP-фильтры. Для создания сохраненного запроса кликаем правой клавишей мыши и выбираем New — Query.

Даем запросу понятное имя и описание, в Query root выбираем область поиска и отмечаем пункт Include subconteiners (аналог Subtree) для поиска по всем вложенным объектам. Затем жмем кнопку Define Query.

Оснастка поддерживает несколько режимов и в принципе вовсе не обязательно писать текст фильтра вручную. Для наиболее часто встречающихся ситуаций достаточно выбрать нужный пункт и\или поставить галочку. Например, для показа всех пользователей с бессрочным паролем можно просто отметить чекбокс Non expiring passwords

Но мы не ищем легких путей, поэтому зададим фильтр руками. Для этого выбираем режим Custom Search и на вкладке Advanced вводим текст фильтра.

В результате в папке Saved Queries появляется список пользователей, у которых пароль не истекает. Таким же образом можно отслеживать множестао различных параметров пользователей, компьютеров и т.д.

А полученные результаты можно экспортировать в виде списка. Очень удобный и полезный функционал.

Примеры LDAP-фильтров

В заключение приведу примеры наиболее часто используемых LDAP-фильтров. Для удобства фильтры сгруппированы по типу объектов (пользователи, компьютеры, группы и прочие непонятные сущности).

Все пользователи:

Фильтр с использованием sAMAccountType более эффективен для объекта пользователь.

Все отключенные (Disabled) пользователи:

Все пользователи кроме отключенных:

Заблокированные (Locked) пользователи:

Здесь используется атрибут badPwdCount, в котором хранится количество неудачных попыток ввода пароля пользователем. Значение нужно указывать в соответствии с политиками безопасности вашего домена.

Пользователи, не менявшие пароль более 3 месяцев:

Атрибут pwdlastSet содержит в себе дату и время последней смены пароля пользователем. Он имеет тип Integer8 и представляет собой число временных интервалов длительностью 100 наносекунд, прошедших с 12:00 01.01.1601 (UTC). Получить требуемое значение можно с помощью PowerShell, например:

Пользователи, у которых пароль не истекает (Password newer expires):

Пользователи, обязанные сменить пароль при следующем входе в систему:

Если значение атрибута pwdlastSet равно 0 и при этом в свойствах учетной записи не отмечен пункт Password newer expires, то пользователь должен сменить пароль при следующем входе.

Пользователи, у которых не требуется пароль:

Пользователи с ограниченным сроком действия учетной записи:

Пользователи, у которых срок действия учетной записи не ограничен:

Атрибут accountExpires содержит дату истечения срока действия учетной записи и тоже представляет из себя число 100нс интервалов, прошедших с 01.01.1601 (UTC). Значение 0 или 9223372036854775807 (максимально возможное 64-битное число) означает, что срок действия учетной записи никогда не истечет.

Пользователи, созданные за определенный период:

В первом случае мы указываем только начальный период, во втором ограничиваем и начальный и конечный. Формат даты используется следующий:

YYYY MM DD HH mm ss.s Z

2020 01 01 00 00 00.0 Z

Кстати, таким образом можно искать не только пользователей, но и любые другие объекты в AD (компьютеры, группы и т.п.).

Пользователи, не заходившие в систему более чем 3 месяца:

Атрибуты lastLogon и lastLogonTimeStamp имеют такой же кривой тип, как pwdLastSet, и вычисляются таким же образом. Но между ними есть кардинальные различия, о которых необходимо знать.

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

lastLogonTimeStamp также изменяется при входе пользователя, при этом он реплицируется на все контроллеры домена. Но сама репликация происходит с большой задержкой, порядка 9-14 дней. Поэтому полученные с его помощью данные могут быть не очень актуальны.

Пользователи, никогда не заходившие в систему:

Пользователи с почтовыми ящиками:

Пользователи, скрытые из адресной книги:

Все компьютеры:

Все компьютеры с определенной ОС:

Вместо Windows 7 можно поставить любую требуемую ОС.

Все серверы (компьютеры с серверной ОС):

Все контроллеры домена:

Контроллеры домена, доступные только для чтения:

Все серверы, не являющиеся контроллерами домена:

SQL серверы:

Exchange серверы:

Все группы:

Все локальные (Domain local) группы:

Все глобальные (Global) группы:

Все универсальные (Universal) группы:

Все группы безопасности (Security):

Все группы рассылки (Distribution):

Во втором случае ищутся все группы, имеющие почтовый адрес. Напомню, что группы безопасности также могут иметь почтовый адрес и использоваться для рассылки.

Все локальные группы безопасности:

Атрибуты userAccountControl и groupType принимают целочисленные 32-битные значения, т.е. лежат в диапазоне от -2 31 (-2147483648) до 2 31 (2147483647). Значение атрибутов является результатом операции побитового ИЛИ. Например, значение groupType для локальной группы безопасности определяется путем применения операции ИЛИ к маске локальной группы (4) и группы безопасности (2147483648). В результате получается число 2147483652. Поскольку данное значение превышает максимально возможное для 32-битного числа, то оно конвертируется в отрицательное путем вычитания из него 2 32 (4294967296). Получается 2147483652 — 4294967296 = -2 147 483 644.

Теоретически правильно использовать отрицательное значение, на практике работают оба.

Все глобальные группы безопасности:

Все универсальные группы безопасности:

Все встроенные группы (BuiltIn):

Все глобальные группы рассылки:

У группы безопасности восьмой бит должен быть установлен в 1, соответственно значение маски равно 2147483648. У группы рассылки этот бит установлен в о, соответственно и значение маски равно 0. Отсюда получаем значение 0 (Distribution) + 2 (Global) = 2 (Global Distribution Group).

Все локальные группы рассылки:

Все универсальные группы рассылки:

Все члены группы (без учета вложенности):

Все члены группы с учетом вложенности:

Все пользователи, не являющиеся членами группы (с учетом вложенности):

Все группы, в которые входит пользователь:

Все группы, в которые входит пользователь (с учетом вложенности):

Все пустые группы:

Все подразделения (OU):

Все контейнеры (CN):

Все встроенные контейнеры:

Все объекты групповой политики:

Все отношения доверия:

Все связи между сайтами в контейнере конфигурации:

Для запросов к атрибутам конфигурации нужно использовать поиск по контейнеру Configuration (напр. cn=Configuration,dc=test,dc=local).

Объекты, защищенные AdminSDHolder:

AdminSDHolder — это механизм защиты административных учетных записей. Если пользователь является членом защищенной группы (Domain Admins, Enterprise Admins и т.п.) то его учетной записи назначаются разрешения, установленные в объекте AdminSDHolder, а атрибуту adminCount пользователя присваивается значение 1.

Обратите внимание, что при удалении пользователя из защищенной группы его атрибут adminCount не возвращается к прежнему значению, соответственно запрос выдаст всех, кто когда либо входил в одну из этих групп.

Объекты, которые не могут быть удалены:

Атрибут systemFlags определяет дополнительные свойства объекта и представляет из себя битовую маску.

Объекты, которые не могут быть перенесены:

Объекты, которые не могут быть переименованы:

Атрибуты, помеченные в схеме как конфиденциальные:

Атрибут searchFlags определяет правила поиска и индексации для атрибута и представляет из себя битовую маску.

Атрибуты, сохраняемые в объекте захоронении (tombstone) при удалении объекта:

Объекты nTDSDSA связанные с глобальным каталогом:

С помощью этого запроса можно найти серверы глобального каталога. Поиск нужно проводить по контейнеру конфигурации. Подробнее об объектах nTDSDSA и их атрибутах.

Объекты nTDSDSA связанные с ролями FSMO:

Для ролей PDC Emulator, RID Master и Infrastructure Master нужно опрашивать домен. Владельца роли Schema Master нужно искать в контейнере Schema (напр. cn=Schema,cn=Configuration,dc=test,dc=local), а владельца Domain Naming Master — в контейнере Configuration (напр. cn=Configuration,dc=test,dc=local).