IAM: Авторизация в Linux (Ubuntu) через AD OpenLDAP (slapd)

Черновик — статья проходит проверку. 

В этой статье мы:

  1. Установим и настроим AD сервер на Linux (Ubuntu) машине
  2. Настроим авторизацию по ssh с возможность выполнения sudo в Linux машинах через AD

Что такое AD сервер и LDAP

AD — Active Directory

Если очень простыми словами: AD — это сервис для хранения учетных данных сотрудников. Это очень грубое объяснение. Но его вполне достаточно для понимания статьи.

Почему именно AD ? Конечно, вы можете, например, хранить учетки в базе данных. Тогда всем  приложениям придется дописать модули авторизации через вашу БД. Что порой бывает не то чтобы сложно, а даже невозможно, если ПО закрытое. А AD на сегодняшний день является стандартом. Большинство систем доступ к AD поддерживают из коробки.

LDAP — это протокол общения с AD сервером.

Мотивация или зачем?

Я опишу простой жизненный случай. Иногда мне приходится создавать сеть с несколькими машинами. Например, сервер с базой данных и сервер с приложением. Для доступа к ним  разработчиков, я создаю ssh ключи и аккаунты пользователей на каждом сервере. Если кто-то из пользователей уволился, я удаляю ключи с каждого сервера. Для двух машин это не проблема. Потом появляются сервера с сервисом мониторинга, с Jenkins, с Nexus и так далее. Машин становится больше. Создавание/удаление/обновление доступов для разработчиков уже превращается в проблему. Помимо доступа к самим серверам, еще нужны доступы в сами приложения Jenkins, Nexus. Тут уже очевидно, что всем этим управлять вручную — головная боль…

Эта проблема решается установкой AD сервера. В AD сервере мы заводим учетки пользователей и разрешения для доступа. И теперь каждый сервис или приложение авторизуются через AD сервер. Больше не нужно обновлять учетные данные на каждой машине. Достаточно зайти на AD и изменить учетку.

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

Окружение

  1. Машина Ubuntu 22.04 c ad-test
  2. Машина Ubuntu 22.04 c ad-client-test
  3. Название организации в примерах я буду использовать BlockWit. А домен blockwit.com.

Установка и настройка AD сервера

  1. Заходим на машину ad-test
  2. Устанавливаем демон slapd. Это реализация AD. И ставим утилиты для работы с AD сервером — ldap-utils.

    Во время установки попросят создать пароль. Это будет пароль администратора AD сервера.
  3. После установки нам необходимо выполнить начальную конфигурацию AD-сервера

  4. Тут отвечаем
    No
  5. Вводим домен организации. В моем случае это
    blockwit.com
  6. Вводим название организации. В моем случае это
    BlockWit
  7. Вводим пароль администратора, который создавали ранее
  8. Тут отвечаем
    No
  9. Тут отвечаем
    Yes
  10. Давайте подредактируем конфиг ldap. Укажем там правильный домен, URL нашего AD сервера. С помощью этих настроек утилиты ldap буду подключаться к AD серверу.


    Заменим все на. Не забывайте заменять домен на свой и название сервера ad-test на свои.

Создание сертификатов

Теперь нам необходимо установить и настроить TLS.

К сожалению, быстрого способа отключить TLS для нашей задачи я не нашел. Да мне это и не требовалось. На самом деле можно собрать сервер AD — slapd без TLS. Опция —with-ssl в исходниках. Но мы будем работать со стандартной поставкой. Если читать знает как полностью отключить TLS, то буду рад информации.

  1. Устанавливаем утилиты для работы c  TLS

  2. Мы будем генерировать самоподписанные сертификаты.
  3. Сгенерируем приватный ключ, которым будем подписывать корневой сертификат

  4. Теперь давайте сделаем шаблон для генерации публичного корневого сертификата


    Добавим в этот файл (не забудьте заменить blockwit на свой домен):
  5. Теперь из шаблона с помощью приватного ключа сгенерируем самоподписанный корнневой сертификат. В дальнейшем мы будем добавлять этот сертификат как доверенный на машины, которые будут стучаться в наш AD сервер.

  6. Попросим систему обновить список доверенных корневых сертификатов

  7. Сгенерируем приватный ключ для создания сертификата нашего AD сервера

  8. Теперь создадим шаблон для генерации публичного сертификата нашего AD сервера


    Добавим в файл (не забываем менять blockwit на свой домен)
  9. На основе шаблона сгенерируем сертификат нашего AD сервера и подпишем его корневым сертификатом и приватным ключом AD.

  10. Сделаем аккаунту openldap (аккаунт от которого запускается AD сервер) владельцем папки с сертификатами AD.  Чтобы AD сервер смог читать сертификаты.

  11. А приватный ключ AD не должен видеть никто, кроме AD сервера

  12. Давайте проверим валидность нашего сертификата

Все сертификаты созданы. Теперь алгоритм подключения клиента к нашему AD серверу будет выглядеть так:

  1. Клиент просит сертификат у AD сервера
  2. AD сервер присылает свой публичный сертификат
  3. Клиент проверяет каким корневым сертификатом подписан этот сертификат
  4. Клиент проверяет что корневому сертификат, которым подписан сертификат AD, можно доверять. Для этого мы предварительно добавим корневой сертификат в доверенные на клиентской машине

Все выглядит гладко. Сертификаты есть. Однако, пока о них ничего не знает AD сервер. Давайте настроим AD сервер на использование наших сертификатов.

Добавление сертификатов на сервер AD

Изменения в базе данных AD проводятся специальными запросами. Эти запросы описываются в ldif файлах, которые затем выполняются на AD сервере.

  1. Давайте укажем, какие сертификаты использовать нашему AD серверу:

    Тут и дальше мы будем сохранять ldif файлы в /etc/ldap для удобства переиспользования. Но это совершенно не обязательно. После применения этих файлов к AD серверу, их можно удалять, если угодно.

    Добавим в файл

  2. Давайте теперь применим изменения к AD серверу (для применения ldif или измений в AD сервере может запрашиваться административный пароль, который Вы прописали при установке AD сервера)

  3. Теперь давайте откорректируем конфигурацию сервера AD

    Изменим параметр SLAPD_SERVICES

  4. Перезапустим наш AD сервер

  5. Проверим работоспособность AD сервера (обязательно замените название ad сервера на свое)

Отлично, теперь наш сервер готов к приему запросов c TLS.
Однако, теперь нам надо его наполнить данными.

Создание структуры учетных записей и организации в AD сервере

Сперва определимся, какие данные будем загружать. База данных AD представляет собой иерархию. Потому что так проще описывать сотрудников в организации. Например, в организации могут быть люди с разными правами. Например, группа администраторов может иметь все права. А группа бухгалтеров могут иметь только права для доступа на приложение «1С Бухгалтерия». Потом сотрудников можно разделить и по отделам, а не по правам. Важно понять, что в AD есть как объекты — например сотрудник, компьютер, принтер, группа с правами. Так и контейнеры для этих объектов. Пример такой структуры

Тут сотрудник Вася физически расположен по такому пути: Организация -> Сотрудники -> Внутренние ->  Вася. Путь до объекта называется DN.  Контейнеры называются OU — organization unit (кроме контейнера организации — он DC). А сами названия объектов CN. Итак, у объекта Вася

  1. DN — CN=Вася, OU=Внутренние, OU=Сотрудники, DC=Организация
  2. CN — Вася

Еще на диаграмме Вы можете увидеть прерывистые линии — это ссылки. У каждого все сущностей в AD есть атрибуты. Например у Васи может быть имя и фамилия. Какие атрибуты могут быть у каждого объекта — это описывается классом — objectClass. К примеру, если у Васи objectClass: person, то у Васи могут быть атрибуты — имя, фамилия, никнейм, и список групп, в которых он находится. Стрелочками на диаграмме показаны группы, в которых состоит Вася.

Создание основной структуры организации

Давайте, опишем простую структуру нашей организации:

У нас будут два контейнера: пользователи и группы. И в нашей организации будет одна группа — администраторы. Администраторы смогут заходить на сервера и выполнять команды от имени администратора, т.е. с sudo.
В нашей организации будет один тестовый пользователь John Doe. Он будет членом группы администраторов. Такой структуры вполне достаточно.

Давайте приступим к созданию нашей структуры организации.

  1. Создадим файлик с описанием запроса на создание структуры. Пока пользователя создавать не будем:


    Добавим в файл. Не забывайте заменять домен организации, в том числе com , если необходимо.
    ВАЖНО: Копировать только специальной кнопкой в сверху справа от окошка текста! Иначе будут добавляться лишние символы.

    Осведомленный читатель может заметить, что в каждом объекте указан только один класс. Хотя в некоторых источниках описано, что AD нас обязывает указывать всю иерархию, вплоть до класса top. Современные реализации AD позволяют не указывать промежуточные классы. После добавления структуры современный AD сервер сам добавить промежуточные классы за Вас. В этом Вы сможете убедиться, если после добавления выполните команду (обязательно замените название ad сервера ad-test на свое)

    И Вы увидите помимо описанных нами классов, все промежуточные.

  2. Применяем наш файлик к AD серверу

Настроим возможность работать с sudo

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

  1. Стандартный sudo не поддерживает работу c LDAP, поэтому придется его заменить. (способ установки именно такой, потому что sudo по факту будет во время установки заменен)

  2. Добавляем sudo схему в AD сервер

  3. Редактируем файлик для создания групп и классов н а основе схемы sudoers:


    Он должен содержать (незабываем заменять домен организации dc=blockwit,dc=com на свой) :
    ВАЖНО: Копировать только специальной кнопкой в сверху справа от окошка текста! Иначе будут добавляться лишние символы.
  4. Добавляем наши группы в AD

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

Создание тестового пользователя

Наш пользователь будет иметь никнейм johndoe и пароль johndoe1987

  1. Создадим ldif для добавления пользователя


    Добавим в него (незабываем менять домен на свой):

    Тут мы видим строчку с домашней директорией, типа оболочки — все эти атрибуты относятся к классу posixAccount. Именно этот класс и описывает сущность аккаунта linux. Обратим внимание на пароль — он тут уже задан, но Вы сможете его сменить после добавления пользователя с помощью команды

    Эта команда сначала запросит пароль администратора. Не забудьте перед ее выполнением заменить название домена на свой.
  2. Добавим нашего пользователя в AD

Отлично, теперь у нас полностью настроен сервер AD и есть тестовый пользователь. Остается настроить авторизацию клиента.

Настройка авторизации linux клиента через AD

Под клиентом тут мы будем понимать любой сервер, которому нужна авторизация через AD. Т.е. эта инструкция должна выполняться и на самом физическом сервере AD. Ведь на сервере с AD наш John Doe также должен иметь возможность авторизоваться.
Поэтому инструкция справедлива для любого сервера, в том числе для сервера на котором стоит AD. Но мы будем производить настройку именно на сервере ad-client-test, чтобы убедиться, что все работает даже если авторизацию производим с другой машины.

Устанавливаем доверенный сертификат AD сервера на клиент

Можно не выполнять, если клиент — AD — сервер. Но если выполните, ничего не сломается (на тот случай если пишите универсальный скрипт)

  1. Авторизуемся на AD-сервере:

  2. Копируем сертификат с AD-сервера на клиент

  3. Выходим и авторизуемся на клиентской машине

  4. Копируем сертификат в правильное место и вызываем обновление доверенных сертификатов

Настраиваем авторизацию через AD

  1. Авторизуемся на клиенте
  2. Устанавливаем утилиты авторизации и создаем пустой файлик конфига

  3. Отредактируем файлик конфига:


    Добавим туда (обязательно поменяйте название домена с blockwit и com на свои, и замените название ad сервера ad-test на свой):
  4. Перезапускаем SSSD

  5. Есть одна маленькая деталь. Дело в том при авторизации домашняя директория по умолчанию не создается. Давайте это поправим:

  6. Давайте теперь настроим параметры соединения для утилиты ldap:


    Заменим на (незабываем менять названия домена и ad-сервера на свои):
  7. Проверяем работоспособность утилиты ldap (ad-test — название ad-сервера замените на свой, blockwit, com — домен в команде также замените на свой)

  8. Теперь проверяем авторизацию

  9. Проверим работу команды sudo из-под нашего пользователя

  10. Выходим

Отлично, теперь пользователи внутри машины могут авторизовываться через AD. Однако, если мы попробуем зайти машину  ad-client-test по SSH, то ничего у нас это не выйдет.

Доступ по SSH

По умолчанию в SSH отключен метод интерактивного ввода пароля через клавиатуру. Давайте его включим:

  1. Открываем настройки SSH:


    Ищем параметр KbdInteractiveAuthentication и ставим его в yes:

  2.  Перезапускаем ssh сервер
  3. Проверяем

Если Вы дошли до этого этапа, то поздравляю — теперь у Вас настроена авторизация через AD.

Возможные проблемы и их решения

  •  Посмотреть логи авторизации на клиенте
  • Посмотреть логи AD на сервере

Если в логах Вы видите

1.3.6.1.4.1.1466.20037 — это проблема с TLS (SSL), там еще указывается код ошибки. Их можно посмотреть в исходниках gnuutils тут.

Содержимое на момент написание статьи такое:

 

Проверить, что действительно проблема с TLS (SSL), а не с самим AD или LDAP можно c помощью утилиты gnutils

Проверяем:

В моем случае частыми ошибками были:

  • Невнимательно написания доменов и URL’ов — иногда вместо ldaps писал ldap
  • Забывал настраивать ldap.conf, slapd.conf
  • Забывал добавлять доверенный корневой сертификат на клиентской машине. В этом случае gnutils-cli вам напишет о том, что соединение failed потому что не доверяет пришедшему с AD сертификату.

Резюме

На основе этой инструкции Вы можете:

  • Единожды настроить AD сервер
  • Единожды настроить каждую машину, которая будет авторизовываться через AD
  •  Управлять пользователями через AD сервер — как добавлять пользователя, описано в статье, как удалять — уже придется поискать самим.
  • Можете указывать AD сервер в настройках Jenkins, Nexus, Kafka-UI, Grafana, ELK и других и централизовано управлять политиками безопасности и аккаунтами

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

  • ApacheDS — десктопный клиент AD, в которым можно подключиться к AD серверу и увидеть  всю структуру. Инструмент скорее для IT-администраторов сервера AD. Так как работать в терминах записей деревьев AD будет не удобно для бизнеса.
  • Keycloak — полноценный IAM сервис. Очень мощный инструмент,  который умеет работать с AD в бизнес-терминах. Т.е. именно в терминах аккаунтов, а не в терминах деревьев  AD.

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

  1. Вики — ну как же без нее)
    https://ru.wikipedia.org/wiki/Active_Directory
  2. Наиболее актуальная инструкция. Основная часть материала была составлена на ее базе — https://www.labsrc.com/setting-up-openldap-sssd-w-sudo-on-ubuntu-22-04/
  3. В целом полезный ресурс про LDAP и про группы и классы (но самые интересные статьи про POSIX аккаунты пустые)
    https://pro-ldap.ru/books/diving/groups/index.html
  4. Документация по SLAPD (демон OpenLDAP)
    https://www.openldap.org/doc/admin25/

Добавить комментарий