|
Навигация
|
Главная » IBM Работа с данными Active Directory c помощью сценариев: Часть 2. Совместное использование Bourne Shell и утилиты ldapsearchИсточник: ibm Рашид Ачилов ВведениеВ данной статье мы попробуем решить конкретную задачу: с помощью программы Sarg сформировать так называемый usertab-файл, в котором определяется соответствие учетных записей пользователей, использованных в процессе аутентификации в squid, и их настоящих имен. В результате должен быть получен отчет примерно такого вида:
Для этого потребуется выполнить действия, практически аналогичные действиям, выполнявшимся в предыдущей статье вручную:
Нас интересуют только поля displayName и sAMAccountName. Сценарий будет называться ldapshtest. Так как это демонстрационный сценарий, а не полная версия (которая должна содержать больше элементов и исполняться в соответствующем окружении), то некоторые фрагменты будут опущены и рассматриваться будут только те фрагменты, которые непосредственно отвечают за выполнение интересующих действий. Данный сценарий будет использовать конфигурационный файл типового формата, показанный в листинге 1, в котором собраны настройки подключения к LDAP. Листинг 1. Конфигурационный файл сценария ldapshtest
В листинге 6 все должно быть понятно кроме пароля. Он записан в таком странном формате по нескольким причинам. Конечно, не следует хранить пароли в открытом виде. Но в то же время трудно найти обратимую функцию, чтобы надежно зашифровать пароль и потом также надежно его расшифровать. Поэтому был выбран компромисс - простейшее преобразование формата, а не шифр. Точнее говоря, это преобразование Base64, у которого отброшены заполнители и вместо них проставлено их количество. Этот пароль можно привести к исходному состоянию с помощью несложной процедуры, приведенной в листинге 2. Листинг 2. Процедура обратного преобразования пароля
Особых пояснений этот код тоже не требует: если второй параметр не нуль, то циклом в конец строки дописывается столько символов заполнителей, сколько было передано во втором параметре, а затем строка декодируется. Внешняя переменная $util_mmencode содержит путь к программе mmencode. Алгоритм работы создаваемого сценария состоит из нескольких этапов. После предварительной части (загрузка конфигурационного файла, разбор командной строки, поиск необходимых программ) сценарий "расшифровывает" пароль и создает временный каталог для работы. Потом выполняется подключение к LDAP, откуда загружаются учетные записи и имена пользователей, которые сохраняются во временных файлах. Часть кода опущена, ссылку на полную версию можно найти в разделе "Материалы для скачивания". В листинге 3 приведен только код, представляющий интерес. Листинг 3. Основная процедура сценария
Код до начала сравнения списков интуитивно понятен: идут вызовы процедур для получения данных из LDAP и их последующего преобразования. Далее выполняются два вложенных цикла для сравнения двух списков. Первый список - это список полученных из LDAP учетных записей, второй - список учетных записей пользователей, уже присутствующих в файле. Он получается с помощью простейшей команды на awk. Суть его в том, что оба списка считываются в переменные, затем берется один элемент "внешнего" списка и последовательно сравнивается со всеми элементами "внутреннего" списка. Когда находится совпадение, выполняются необходимые действия, потом внешний цикл (в Bourne Shell можно указать оператору break или continue число уровней вложенности, на которые он одновременно воздействует) переходит к следующему элементу.Во внешнем цикле, идущем по списку учетных записей из LDAP обнуляется счетчик, отмечающий позицию учетной записи в списке. Внутренний цикл идет по списку пользователей, уже присутствующих в файле. Если учетная запись из LDAP уже присутствует в файле, то незачем искать её дальше и можно переходить к следующей. Если она отсутствует, то берется имя пользователя из списка имен (отступив с помощью tail на значение счетчика позиции и взяв оттуда одну строку), после чего формируется строка вывода и дописывается в список пользователей Sarg.Основной интерес представляют процедуры ldap_data_query() и ldap_data_deconvert() . Первая процедура всего лишь вызывает утилиту ldapsearch, передавая ей все необходимые параметры из конфигурационного файла и список переданных параметров. Единственное, что выполняется перед вызовом ldapsearch - это замена запятых в списке запрашиваемых полей на пробелы. Код процедуры ldap_data_query() приведен в листинге 4.Листинг 4. Процедура ldap_data_query()
В листинге 5 приведены вспомогательные процедуры unspace() и make_tempdir() .Листинг 5. Процедуры unspace() и make_tempdir()
Процедура unspace() удаляет из файла, заданного первым параметром, все пробелы и все строки, начинающиеся с символа "# ". В итоге на выходе будут только строки вывода ldapsearch. Процедура make_tempdir() создает временный каталог с уникальным именем, если такового еще не было создано. Сделано это для удобства использования данного сценария из других сценариев, чтобы избежать гонок (race condition).Заключение В данной статье был рассмотрен основной алгоритм выполнения запросов к LDAP через сценарии оболочки с помощью утилиты ldapsearch. В следующей статье мы рассмотрим дополнительные аспекты обращения к LDAP из сценариев Bourne Shell. Загрузка
Гибкая разработка программного обеспечения с применением уже имеющихся инструментов CCM. Решение IBM Rational для разработки технических систем и встраиваемого ПО. Какой ты программист?. Пять полезных советов по использованию гибких методов при разработке критически важных систем. IBM Business Process Manager Standard. Главная » IBM |
© 2024 Team.Furia.Ru.
Частичное копирование материалов разрешено. |