Все выпуски  

Системный администратор - секреты мастерства: гибрид ужа с ежом. LDAP, AD и почтовый сервер на Linux


Здравствуйте, уважаемые коллеги!

 

Сегодня мы затронем с вами тему гетерогенных компьютерных систем, т.е. систем, в которых успешно работают в единой связке приложения, управляемые разными ОС. В качестве примера мы рассмотрим почтовую систему на Linux, сопрягаемую с MS Active Directory посредством LDAP. Эта статья несколько дней назад публиковалась на моем сайте www.mednikov.ru , и все его посетители успели ознакомиться с ней и кое-какими другими материалами раньше вас. Сегодня исправим это досадное недоразумение (хотя если вы хотите оказаться в числе первых читателей, лучше подпишитесь на RSS на моем сайте).

Когда я только начинал осваивать Linux, буквосочетание LDAP вгоняло меня в ступор и наводило ужас одновременно. Мне почему-то казалось, что LDAP – это нечто монструозное, применяемое в гигантских сетях, а потому недоступное среднему сисадмину. Встречая заголовки статей, описывавших взаимодействие всевозможных служб с LDAP, я думал, что их авторы – редкостные извращенцы, призывающие «стрелять по воробьям из пушки». Так продолжалось до тех пор, пока однажды, натолкнувшись на очередную статью про скрещивание postfix и LDAP на почтовом сервере, я не решил разобраться, что же это за «зверь» такой, что о нем все говорят.

Энциклопедии Wikipedia.org тогда еще не было (а может и была, но я про нее ничего не знал), однако в Интернете нашлось изрядно статей, которые помогли разобраться. Мы же обратимся к тому, как описывает LDAP Wikipedia.org:

LDAP (Lightweight Directory Access Protocol — облегчённый протокол доступа к каталогам) — это сетевой протокол для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP. Для LDAP-сеансов, инкапсулированных в SSL, обычно используется порт 636.

Если вы ничего не поняли из этого определения, не переживайте. Давайте разбираться дальше. X.500 — серия стандартов для службы распределенного каталога сети. Каталоги X.500 предоставляют централизованную информацию обо всех именованных объектах сети  - ресурсах, приложениях и пользователях. Иными словами, каталоги были придуманы для упорядоченного хранения относительно редко изменяющейся информации, касающейся сети. Такими данными являются имена пользователей,  контактные данные, имена компьютеров и серверов, списки и уровни доступа. В связи с тем, что содержимое каталога меняется не очень часто, службы доступа к каталогам оптимизированы на поиск и чтение данных, что является основным их отличием от баз данных, ориентированных на динамический контент.

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

1. Упрощенное управление сетью.

  • централизованное управление информацией о пользователях;
  • централизованное управление сетевыми объектами и их конфигурацией;
  • централизованное управление аккаунтами пользователей;
  • уменьшение стоимости поддержки, за счет централизации.

2. Унифицировнный доступ к сетевым ресурсам.

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

3. Единое место хранения общей информации.

  • контактной информации;
  • местоположения сетевых ресурсов;
  • можно использовать для хранения любой информации.

4. Улучшенное управление данными.

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

5. Единый поисковый механизм для приложений и сервисов.

Если вы внимательно читали предыдущие два абзаца, то у вас внутри должна была зашевелиться мысль о том, что каталоги очень похожи на то, что компания Microsoft называет Active Directory. Собственно, скажете вы, Active Directory реализует все то, о чем сказано выше – и будете абсолютно правы. То, что подается компанией Microsoft как прорывная технология, на самом деле было придумано еще, как минимум, в 1993 году. Конечно, заслуг MS умалять нельзя – они построили на базе стандартов X.500 законченный продукт и подготовили его для использования конечными потребителями, однако ничего экстраординарного в AD нет. Это обычный каталог, построенный по стандарту X.500, доступ к которому может осуществляться стандартными средствами.

А вот с этого места, как говорится – поподробнее. Как уже было сказано выше, доступ к каталогам X.500 осуществляется посредством протокола LDAP. Из этого следует вывод, что при помощи протокола LDAP можно получать данные, содержащиеся в Active Directory, при этом нет никакой разницы, под управлением какой операционной системы будет работать LDAP-клиент, и кем он был написан. И это абсолютная правда. Иными словами, любая программа, поддерживающая получение данных из внешнего каталога при помощи протокола LDAP, может получать данные из Active Directory и использовать их для своих целей.

Всякая запись в каталоге LDAP состоит из одного или нескольких атрибутов и обладает уникальным именем (DN - Distinguished Name). Уникальное имя учетной записи сотрудника Ивана Петрова, находящегося в OU «Сотрудники» в домене example.com в нотации LDAP может выглядеть, например, следующим образом: «cn=Иван Петров, ou=Сотрудники, dc=example, dc=com». Уникальное имя состоит из одного или нескольких относительных уникальных имен (RDN — Relative Distinguished Name), разделённых запятой. Относительное уникальное имя имеет вид имяАтрибута=значение. На одном уровне каталога не может существовать двух записей с одинаковыми относительными уникальными именами. В силу такой структуры уникального имени записи в каталоге LDAP можно легко представить в виде дерева (что, собственно, и сделано в оснастке «Active Directory Users and Computers»).

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

Этот механизм используется таким известным продуктом как Microsoft Exchange Server. Все данные о почтовых пользователях хранятся в каталоге Active Directory и доступ к ним осуществляется при помощи того же LDAP. Exchange – очень мощный продукт, но вместе с тем весьма дорогой, ресурсоемкий и непростой в администрировании, что делает его не самым лучшим решением для малых и средних организаций. Его прекрасно заменит почтовый сервер на Linux. Конечно, он не позволит реализовать все до единой функции, существующие в Exchange, но с основной задачей – приемом и отправкой сообщений, справится великолепно. Чтобы максимально упростить процесс администрирования почтового Linux-сервера и избавить пользователя от необходимости помнить десяток паролей, воспользуемся возможностями протокола LDAP для получения всей необходимой для работы почтовика информации напрямую из Active Directory. Основная идея заключается в следующем:

Настраиваем почтовую службу на поддержку виртуальных доменов с использованием LDAP (и sendmail, и qmail, и postfix позволяют делать это). В качестве LDAP-сервера будет использоваться один из контроллеров домена. Создадим в AD учетную запись, которая будет использоваться почтовой службой для получения данных из AD посредством LDAP. Заполним поля e-mail в описании пользовательских профилей в AD актуальными почтовыми адресами. Естественно, все почтовые ящики должны быть в одном домене, однако имя домена AD может не совпадать с именем почтового домена. Например, домен AD может называться kontora.local, а почтовый домен иметь имя kontora.ru.

Наш почтовый сервер будет использовать SMTP-авторизацию и, естественно, нужно как-то организовать авторизацию в AD для сервисов POP3 и/или IMAP. Для этой цели лучше всего подойдет SASL (демон saslauthd), который прекрасно взаимодействует с LDAP. Цепочка аутентификации выглядит примерно следующим образом: ваш почтовый клиент передает учетные данные почтовой службе на сервере, та в свою очередь отдает их демону SASL. Демон связывается с каталогом Active Directory по протоколу LDAP и пытается найти в каталоге учетную запись, которой соответствует атрибут, переданный почтовым клиентом в качестве логина. Далее он сравнивает пароль, переданный клиентом, с паролем, присвоенным учетной записью в Active Directory. Поиск по AD можно производить по любому атрибуту, являющемуся частью схемы каталога, например логин пользователя (атрибут sAMAccountName) или e-mail (атрибут mail). Если в AD не найдено ни одной записи, которой бы соответствовал атрибут, или пароль, переданный почтовиком, не совпадает с паролем учетной записи AD, аутентификация заканчивается с ошибкой.

При приеме почты почтовая служба должна обращаться к Active Directory через LDAP и пытается найти там учетную запись, атрибут mail которой совпадает с адресом получателя сообщения. Если результат поиска положительный, письмо доставляется в почтовый ящик, в противном случае оно возвращается с пометкой “Recipient Unknown”. Этот момент является самым узким местом во всей модели. Дело в том, что LDAP от Microsoft работает довольно медленно, и каждое обращение к Active Directory отнимает много времени по машинным меркам. Учитывая ситуацию с количеством спама, приходящего из Сети, можно представить, какую нагрузку будет испытывать контроллер домена Windows, на который сыплется нескончаемый град LDAP-запросов. Кстати, именно этот факт делает почтовые серверы на Exchange, установленные на недостаточно производительных машинах, довольно уязвимым для атак на отказ в доступе. Чтобы излишне не нагружать AD запросами от почтового сервера, нам необходимо принять серьезные меры, направленные на выявление спама до момента доставки сообщения конечному получателю. Впрочем, эти меры в любом случае придется принимать.

Некоторые администраторы предлагают решать проблему возможной перегрузки контроллера домена LDAP-запросами путем создания промежуточной MYSQL-базы, которая обслуживает почтовый сервис и автоматически синхронизируется с каталогом AD на предмет почтовых адресов и паролей. Естественно, и сам почтовик, и SMTP и POP, и IMAP-аутентификация должны быть в этом случае настроены на работу с MYSQL. Но здесь возникает другое затруднение. AD хранит пароли пользователей в виде результатов применения к ним хэш-функции, и вытащить их в базу данных будет проблематично, поэтому придется создавать отдельный набор паролей для почтового сервера. С одной стороны, это поднимает безопасность системы, а с другой – усложняет управление. Впрочем, почтовые пароли можно хранить там же – в профиле пользователя в AD, используя для этого свободный параметр (например, комментарий или номер пейджера, или что-то еще неактуальное для наших реалий). Синхронизацию нужно производить автоматически, при помощи скрипта, читающего параметры в AD и помещающего их в базу MYSQL. Частота выполнения скрипта должна быть небольшой, т.к. вряд ли вы заводите новых пользователей хотя бы раз в час.

Кстати, сценарий с mysql-базой будет полезен тем, кто занимается размещением клиентских почтовых служб на своих мощностях. Теперь вы можете синхронизировать записи о почтовых ящиках с каталогами AD клиентов и автоматически подстраивать почтовую службу под изменения, произошедшие у клиентов. Сценарий следующий:

  1. Устанавливаете VPN-соединение с контроллером домена клиента
  2. Синхронизируете свою БД с каталогом AD клиента
  3. Разрываете VPN-соединение

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

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

На сегодня это все. В следующий раз мы рассмотрим основы windows-скриптинга и разберем некоторые простые скрипты и их практическое применение. Кроме того на www.mednikov.ru выходят статьи, посвященные ИТ-аутсорсингу в малом бизнесе. Они будут интересны тем, кто задумывается о старте своего дела в ИТ-области.

 

С уважением,
Павел Медников


В избранное