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

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

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

Установим и настроим AD сервер на Linux (Ubuntu) машине
Настроим авторизацию по 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 серверов, которые реплицируются между собой для обеспечения отказоустойчивости. Но отказоустойчивая архитектура это уже другая тема.

Окружение

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

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

Заходим на машину ad-test

ssh ad-test

1

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

sudo apt install slapd ldap-utils

1

sudo apt install slapd ldap-utils

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

sudo dpkg-reconfigure slapd

1

sudo dpkg-reconfigure slapd
Тут отвечаем
No
Вводим домен организации. В моем случае это
blockwit.com
Вводим название организации. В моем случае это
BlockWit
Вводим пароль администратора, который создавали ранее
Тут отвечаем
No
Тут отвечаем
Yes
Давайте подредактируем конфиг ldap. Укажем там правильный домен, URL нашего AD сервера. С помощью этих настроек утилиты ldap буду подключаться к AD серверу.

sudo vim /etc/ldap/ldap.conf

1

sudo vim /etc/ldap/ldap.conf

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

BASE dc=blockwit,dc=com URI ldaps://ad-test TLS_CACERT /etc/ssl/certs/ca-certificates.crt

1
2
3

BASE dc=blockwit,dc=com
URI ldaps://ad-test
TLS_CACERT /etc/ssl/certs/ca-certificates.crt

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

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

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

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

sudo apt install gnutls-bin ssl-cert

1

sudo apt install gnutls-bin ssl-cert
Мы будем генерировать самоподписанные сертификаты.
Сгенерируем приватный ключ, которым будем подписывать корневой сертификат

sudo certtool --generate-privkey --bits 4096 --outfile /etc/ssl/private/ldap_ca_key.pem

1

sudo certtool --generate-privkey --bits 4096 --outfile /etc/ssl/private/ldap_ca_key.pem
Теперь давайте сделаем шаблон для генерации публичного корневого сертификата

sudo vim /etc/ssl/ldap_ca.info

1

sudo vim /etc/ssl/ldap_ca.info

Добавим в этот файл (не забудьте заменить blockwit на свой домен):

cn = blockwit ca cert_signing_key expiration_days = 3650

1
2
3
4

cn = blockwit
ca
cert_signing_key
expiration_days = 3650

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

sudo certtool --generate-self-signed --load-privkey /etc/ssl/private/ldap_ca_key.pem --template /etc/ssl/ldap_ca.info --outfile /usr/local/share/ca-certificates/ldap_ca_cert.crt

1	sudo certtool --generate-self-signed --load-privkey /etc/ssl/private/ldap_ca_key.pem --template /etc/ssl/ldap_ca.info --outfile /usr/local/share/ca-certificates/ldap_ca_cert.crt

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

sudo update-ca-certificates

1

sudo update-ca-certificates
Сгенерируем приватный ключ для создания сертификата нашего AD сервера

sudo certtool --generate-privkey --bits 2048 --outfile /etc/ldap/sasl2/ldap_slapd_key.pem

1

sudo certtool --generate-privkey --bits 2048 --outfile /etc/ldap/sasl2/ldap_slapd_key.pem
Теперь создадим шаблон для генерации публичного сертификата нашего AD сервера

sudo vim /etc/ssl/ldap.info

1

sudo vim /etc/ssl/ldap.info

Добавим в файл (не забываем менять blockwit на свой домен)

organization = blockwit cn = ad-test tls_www_server encryption_key signing_key expiration_days = 3650

1
2
3
4
5
6

organization = blockwit
cn = ad-test
tls_www_server
encryption_key
signing_key
expiration_days = 3650

На основе шаблона сгенерируем сертификат нашего AD сервера и подпишем его корневым сертификатом и приватным ключом AD.

sudo certtool --generate-certificate --load-privkey /etc/ldap/sasl2/ldap_slapd_key.pem --load-ca-certificate /etc/ssl/certs/ldap_ca_cert.pem --load-ca-privkey /etc/ssl/private/ldap_ca_key.pem --template /etc/ssl/ldap.info --outfile /etc/ldap/sasl2/ldap_slapd_cert.pem

1	sudo certtool --generate-certificate --load-privkey /etc/ldap/sasl2/ldap_slapd_key.pem --load-ca-certificate /etc/ssl/certs/ldap_ca_cert.pem --load-ca-privkey /etc/ssl/private/ldap_ca_key.pem --template /etc/ssl/ldap.info --outfile /etc/ldap/sasl2/ldap_slapd_cert.pem

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

sudo chown openldap. -R /etc/ldap/sasl2

1

sudo chown openldap. -R /etc/ldap/sasl2
А приватный ключ AD не должен видеть никто, кроме AD сервера

sudo chmod 0640 /etc/ldap/sasl2/ldap_slapd_key.pem

1

sudo chmod 0640 /etc/ldap/sasl2/ldap_slapd_key.pem
Давайте проверим валидность нашего сертификата

openssl verify -CAfile /etc/ssl/certs/ldap_ca_cert.pem /etc/ldap/sasl2/ldap_slapd_cert.pem

1

openssl verify -CAfile /etc/ssl/certs/ldap_ca_cert.pem /etc/ldap/sasl2/ldap_slapd_cert.pem

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

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

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

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

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

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

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

sudo vim /etc/ldap/schema/cert.ldif

1	sudo vim /etc/ldap/schema/cert.ldif

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

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/ldap_ca_cert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/sasl2/ldap_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/sasl2/ldap_slapd_key.pem

dn: cn=config

add: olcTLSCACertificateFile

olcTLSCACertificateFile: /etc/ssl/certs/ldap_ca_cert.pem

add: olcTLSCertificateFile

olcTLSCertificateFile: /etc/ldap/sasl2/ldap_slapd_cert.pem

add: olcTLSCertificateKeyFile

olcTLSCertificateKeyFile: /etc/ldap/sasl2/ldap_slapd_key.pem

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

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cert.ldif

1

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cert.ldif
Теперь давайте откорректируем конфигурацию сервера AD

sudo vim /etc/default/slapd

1

sudo vim /etc/default/slapd

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

SLAPD_SERVICES="ldaps:/// ldapi:///"

1

SLAPD_SERVICES="ldaps:/// ldapi:///"
Перезапустим наш AD сервер

sudo systemctl restart slapd

1

sudo systemctl restart slapd
Проверим работоспособность AD сервера (обязательно замените название ad сервера на свое)

ldapsearch -x -H ldaps://ad-test

1

ldapsearch -x -H ldaps://ad-test

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

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

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

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

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

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

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

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

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

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

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

sudo vim /etc/ldap/schema/rootOU.ldif

1	sudo vim /etc/ldap/schema/rootOU.ldif

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

dn: ou=Users,dc=blockwit,dc=com
objectClass: organizationalUnit
ou: Users

dn: ou=Groups,dc=blockwit,dc=com
objectClass: organizationalUnit
ou: Groups

dn: cn=administrators,ou=Groups,dc=blockwit,dc=com
objectClass: posixGroup
cn: administrators
gidNumber: 5000

dn: ou=Users,dc=blockwit,dc=com

objectClass: organizationalUnit

ou: Users

dn: ou=Groups,dc=blockwit,dc=com

objectClass: organizationalUnit

ou: Groups

dn: cn=administrators,ou=Groups,dc=blockwit,dc=com

objectClass: posixGroup

cn: administrators

gidNumber: 5000

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

ldapsearch -x -H ldaps://ad-test

1

ldapsearch -x -H ldaps://ad-test

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

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

ldapadd -x -D cn=admin,dc=blockwit,dc=com -W -f /etc/ldap/schema/rootOU.ldif

1

ldapadd -x -D cn=admin,dc=blockwit,dc=com -W -f /etc/ldap/schema/rootOU.ldif

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

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

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

export SUDO_FORCE_REMOVE=yes sudo -E bash -c 'apt install sudo-ldap'

1
2

export SUDO_FORCE_REMOVE=yes
sudo -E bash -c 'apt install sudo-ldap'
Добавляем sudo схему в AD сервер

sudo cp /usr/share/doc/sudo-ldap/schema.olcSudo /etc/ldap/schema/ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/schema.olcSudo

1
2

sudo cp /usr/share/doc/sudo-ldap/schema.olcSudo /etc/ldap/schema/
sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/schema.olcSudo

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

sudo vim /etc/ldap/schema/sudoers.ldif

1	sudo vim /etc/ldap/schema/sudoers.ldif

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

dn: ou=Sudoers,dc=blockwit,dc=com
objectClass: organizationalUnit
objectClass: top
ou: Sudoers

dn: cn=defaults,ou=Sudoers,dc=blockwit,dc=com
objectClass: sudoRole
objectClass: top
cn: defaults
sudoOption: env_reset
sudoOption: mail_badpass
sudoOption: secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

dn: cn=%administrators,ou=Sudoers,dc=blockwit,dc=com
objectClass: top
objectClass: sudoRole
cn: %administrators
sudoUser: %administrators
sudoHost: ALL
sudoCommand: ALL

dn: ou=Sudoers,dc=blockwit,dc=com

objectClass: organizationalUnit

objectClass: top

ou: Sudoers

dn: cn=defaults,ou=Sudoers,dc=blockwit,dc=com

objectClass: sudoRole

objectClass: top

cn: defaults

sudoOption: env_reset

sudoOption: mail_badpass

sudoOption: secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin

dn: cn=%administrators,ou=Sudoers,dc=blockwit,dc=com

objectClass: top

objectClass: sudoRole

cn: %administrators

sudoUser: %administrators

sudoHost: ALL

sudoCommand: ALL

Добавляем наши группы в AD

ldapadd -x -D cn=admin,dc=blockwit,dc=com -W -f /etc/ldap/schema/sudoers.ldif

1

ldapadd -x -D cn=admin,dc=blockwit,dc=com -W -f /etc/ldap/schema/sudoers.ldif

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

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

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

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

vim /etc/ldap/schema/addUser.ldif

1	vim /etc/ldap/schema/addUser.ldif

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

dn: uid=johndoe,ou=Users,dc=blockwit,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: johndoe
sn: Doe
givenName: John
cn: John Doe
displayName: John Doe
uidNumber: 10000
gidNumber: 5000
userPassword: {SSHA}4dAi5Oaf1KTF+BWB2ISNvNXPw17MrbkT
gecos: John Doe
loginShell: /bin/bash
homeDirectory: /home/johndoe

dn: uid=johndoe,ou=Users,dc=blockwit,dc=com

objectClass: inetOrgPerson

objectClass: posixAccount

objectClass: shadowAccount

uid: johndoe

sn: Doe

givenName: John

cn: John Doe

displayName: John Doe

uidNumber: 10000

gidNumber: 5000

userPassword: {SSHA}4dAi5Oaf1KTF+BWB2ISNvNXPw17MrbkT

gecos: John Doe

loginShell: /bin/bash

homeDirectory: /home/johndoe

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

ldappasswd -x -D cn=admin,dc=blockwit,dc=com -W -S uid=johndoe,ou=Users,dc=blockwit,dc=com

1	ldappasswd -x -D cn=admin,dc=blockwit,dc=com -W -S uid=johndoe,ou=Users,dc=blockwit,dc=com

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

Добавим нашего пользователя в AD

ldapadd -x -D cn=admin,dc=blockwit,dc=com -W -f /etc/ldap/schema/addUser.ldif

1

ldapadd -x -D cn=admin,dc=blockwit,dc=com -W -f /etc/ldap/schema/addUser.ldif

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

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

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

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

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

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

ssh ad-test

1

ssh ad-test
Копируем сертификат с AD-сервера на клиент

scp /usr/local/share/ca-certificates/ldap_ca_cert.crt ad-client-test:~/

1

scp /usr/local/share/ca-certificates/ldap_ca_cert.crt ad-client-test:~/
Выходим и авторизуемся на клиентской машине

exit ssh ad-test-client

1
2

exit
ssh ad-test-client
Копируем сертификат в правильное место и вызываем обновление доверенных сертификатов

sudo cp ldap_ca_cert.crt /usr/local/share/ca-certificates/ldap_ca_cert.crt sudo update-ca-certificates

1
2

sudo cp ldap_ca_cert.crt /usr/local/share/ca-certificates/ldap_ca_cert.crt
sudo update-ca-certificates

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

Авторизуемся на клиенте

ssh ad-client-test

1

ssh ad-client-test
Устанавливаем утилиты авторизации и создаем пустой файлик конфига

sudo apt install sssd-ldap ldap-utils libsss-sudo sudo install -m 600 /dev/null /etc/sssd/sssd.conf

1
2

sudo apt install sssd-ldap ldap-utils libsss-sudo
sudo install -m 600 /dev/null /etc/sssd/sssd.conf

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

sudo vim /etc/sssd/sssd.conf

1	sudo vim /etc/sssd/sssd.conf

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

[sssd]
config_file_version = 2
domains = blockwit.com

[domain/blockwit.com]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ad-test
cache_credentials = True
ldap_search_base = dc=blockwit,dc=com

[sssd]

config_file_version = 2

domains = blockwit.com

[domain/blockwit.com]

id_provider = ldap

auth_provider = ldap

ldap_uri = ldaps://ad-test

cache_credentials = True

ldap_search_base = dc=blockwit,dc=com

Перезапускаем SSSD

sudo systemctl restart sssd

1

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

sudo pam-auth-update --enable mkhomedir

1

sudo pam-auth-update --enable mkhomedir
Давайте теперь настроим параметры соединения для утилиты ldap:

sudo vim /etc/ldap/ldap.conf

1

sudo vim /etc/ldap/ldap.conf

Заменим на (незабываем менять названия домена и ad-сервера на свои):

BASE dc=blockwit,dc=com URI ldaps://ad-test TLS_CACERT /etc/ssl/certs/ca-certificates.crt

1
2
3

BASE dc=blockwit,dc=com
URI ldaps://ad-test
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
Проверяем работоспособность утилиты ldap (ad-test — название ad-сервера замените на свой, blockwit, com — домен в команде также замените на свой)

ldapsearch -x -H ldaps://ad-test -b "dc=blockwit,dc=com"

1

ldapsearch -x -H ldaps://ad-test -b "dc=blockwit,dc=com"
Теперь проверяем авторизацию

su johndoe

1

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

sudo ls -la

1

sudo ls -la
Выходим

exit

1

exit

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

Доступ по SSH

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

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

sudo vim /etc/ssh/sshd_config

1

sudo vim /etc/ssh/sshd_config

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

KbdInteractiveAuthentication yes

1

KbdInteractiveAuthentication yes
Перезапускаем ssh сервер

sudo systemctl restart sshd

1

sudo systemctl restart sshd
Проверяем

ssh johndoe@ad-client-test

1

ssh johndoe@ad-client-test

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

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

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

sudo tail -f /var/log/auth.log

1

sudo tail -f /var/log/auth.log
Посмотреть логи AD на сервере

sudo journalctl --follow -xau slapd

1

sudo journalctl --follow -xau slapd

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

unsupported operation "1.3.6.1.4.1.1466.20037"

1	unsupported operation "1.3.6.1.4.1.1466.20037"

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

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

/**
 * gnutls_certificate_status_t:
 * @GNUTLS_CERT_INVALID: The certificate is not signed by one of the
 *   known authorities or the signature is invalid (deprecated by the flags 
 *   %GNUTLS_CERT_SIGNATURE_FAILURE and %GNUTLS_CERT_SIGNER_NOT_FOUND).
 * @GNUTLS_CERT_SIGNATURE_FAILURE: The signature verification failed.
 * @GNUTLS_CERT_REVOKED: Certificate is revoked by its authority.  In X.509 this will be
 *   set only if CRLs are checked.
 * @GNUTLS_CERT_SIGNER_NOT_FOUND: The certificate's issuer is not known. 
 *   This is the case if the issuer is not included in the trusted certificate list.
 * @GNUTLS_CERT_SIGNER_NOT_CA: The certificate's signer was not a CA. This
 *   may happen if this was a version 1 certificate, which is common with
 *   some CAs, or a version 3 certificate without the basic constrains extension.
 * @GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE: The certificate's signer constraints were
 *   violated.
 * @GNUTLS_CERT_INSECURE_ALGORITHM:  The certificate was signed using an insecure
 *   algorithm such as MD2 or MD5. These algorithms have been broken and
 *   should not be trusted.
 * @GNUTLS_CERT_NOT_ACTIVATED: The certificate is not yet activated.
 * @GNUTLS_CERT_EXPIRED: The certificate has expired.
 * @GNUTLS_CERT_REVOCATION_DATA_SUPERSEDED: The revocation data are old and have been superseded.
 * @GNUTLS_CERT_REVOCATION_DATA_ISSUED_IN_FUTURE: The revocation data have a future issue date.
 * @GNUTLS_CERT_UNEXPECTED_OWNER: The owner is not the expected one.
 * @GNUTLS_CERT_MISMATCH: The certificate presented isn't the expected one (TOFU)
 * @GNUTLS_CERT_PURPOSE_MISMATCH: The certificate or an intermediate does not match the intended purpose (extended key usage).
 * @GNUTLS_CERT_MISSING_OCSP_STATUS: The certificate requires the server to send the certificate status, but no status was received.
 * @GNUTLS_CERT_INVALID_OCSP_STATUS: The received OCSP status response is invalid.
 * @GNUTLS_CERT_UNKNOWN_CRIT_EXTENSIONS: The certificate has extensions marked as critical which are not supported.
 *
 * Enumeration of certificate status codes.  Note that the status
 * bits may have different meanings in OpenPGP keys and X.509
 * certificate verification.
 */
typedef enum {
	GNUTLS_CERT_INVALID = 1 << 1,
	GNUTLS_CERT_REVOKED = 1 << 5,
	GNUTLS_CERT_SIGNER_NOT_FOUND = 1 << 6,
	GNUTLS_CERT_SIGNER_NOT_CA = 1 << 7,
	GNUTLS_CERT_INSECURE_ALGORITHM = 1 << 8,
	GNUTLS_CERT_NOT_ACTIVATED = 1 << 9,
	GNUTLS_CERT_EXPIRED = 1 << 10,
	GNUTLS_CERT_SIGNATURE_FAILURE = 1 << 11,
	GNUTLS_CERT_REVOCATION_DATA_SUPERSEDED = 1 << 12,
	GNUTLS_CERT_UNEXPECTED_OWNER = 1 << 14,
	GNUTLS_CERT_REVOCATION_DATA_ISSUED_IN_FUTURE = 1 << 15,
	GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE = 1 << 16,
	GNUTLS_CERT_MISMATCH = 1 << 17,
	GNUTLS_CERT_PURPOSE_MISMATCH = 1 << 18,
	GNUTLS_CERT_MISSING_OCSP_STATUS = 1 << 19,
	GNUTLS_CERT_INVALID_OCSP_STATUS = 1 << 20,
	GNUTLS_CERT_UNKNOWN_CRIT_EXTENSIONS = 1 << 21
} gnutls_certificate_status_t;

/**

* gnutls_certificate_status_t:

* @GNUTLS_CERT_INVALID: The certificate is not signed by one of the

* known authorities or the signature is invalid (deprecated by the flags

* %GNUTLS_CERT_SIGNATURE_FAILURE and %GNUTLS_CERT_SIGNER_NOT_FOUND).

* @GNUTLS_CERT_SIGNATURE_FAILURE: The signature verification failed.

* @GNUTLS_CERT_REVOKED: Certificate is revoked by its authority. In X.509 this will be

* set only if CRLs are checked.

* @GNUTLS_CERT_SIGNER_NOT_FOUND: The certificate's issuer is not known.

* This is the case if the issuer is not included in the trusted certificate list.

* @GNUTLS_CERT_SIGNER_NOT_CA: The certificate's signer was not a CA. This

* may happen if this was a version 1 certificate, which is common with

* some CAs, or a version 3 certificate without the basic constrains extension.

* @GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE: The certificate's signer constraints were

* violated.

* @GNUTLS_CERT_INSECURE_ALGORITHM: The certificate was signed using an insecure

* algorithm such as MD2 or MD5. These algorithms have been broken and

* should not be trusted.

* @GNUTLS_CERT_NOT_ACTIVATED: The certificate is not yet activated.

* @GNUTLS_CERT_EXPIRED: The certificate has expired.

* @GNUTLS_CERT_REVOCATION_DATA_SUPERSEDED: The revocation data are old and have been superseded.

* @GNUTLS_CERT_REVOCATION_DATA_ISSUED_IN_FUTURE: The revocation data have a future issue date.

* @GNUTLS_CERT_UNEXPECTED_OWNER: The owner is not the expected one.

* @GNUTLS_CERT_MISMATCH: The certificate presented isn't the expected one (TOFU)

* @GNUTLS_CERT_PURPOSE_MISMATCH: The certificate or an intermediate does not match the intended purpose (extended key usage).

* @GNUTLS_CERT_MISSING_OCSP_STATUS: The certificate requires the server to send the certificate status, but no status was received.

* @GNUTLS_CERT_INVALID_OCSP_STATUS: The received OCSP status response is invalid.

* @GNUTLS_CERT_UNKNOWN_CRIT_EXTENSIONS: The certificate has extensions marked as critical which are not supported.

* Enumeration of certificate status codes. Note that the status

* bits may have different meanings in OpenPGP keys and X.509

* certificate verification.

typedef enum {

GNUTLS_CERT_INVALID = 1 << 1,

GNUTLS_CERT_REVOKED = 1 << 5,

GNUTLS_CERT_SIGNER_NOT_FOUND = 1 << 6,

GNUTLS_CERT_SIGNER_NOT_CA = 1 << 7,

GNUTLS_CERT_INSECURE_ALGORITHM = 1 << 8,

GNUTLS_CERT_NOT_ACTIVATED = 1 << 9,

GNUTLS_CERT_EXPIRED = 1 << 10,

GNUTLS_CERT_SIGNATURE_FAILURE = 1 << 11,

GNUTLS_CERT_REVOCATION_DATA_SUPERSEDED = 1 << 12,

GNUTLS_CERT_UNEXPECTED_OWNER = 1 << 14,

GNUTLS_CERT_REVOCATION_DATA_ISSUED_IN_FUTURE = 1 << 15,

GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE = 1 << 16,

GNUTLS_CERT_MISMATCH = 1 << 17,

GNUTLS_CERT_PURPOSE_MISMATCH = 1 << 18,

GNUTLS_CERT_MISSING_OCSP_STATUS = 1 << 19,

GNUTLS_CERT_INVALID_OCSP_STATUS = 1 << 20,

GNUTLS_CERT_UNKNOWN_CRIT_EXTENSIONS = 1 << 21

} gnutls_certificate_status_t;

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

sudo apt install gnutls-bin

1	sudo apt install gnutls-bin

Проверяем:

gnutls-cli --starttls-proto=ldaps ad-test:636

1	gnutls-cli --starttls-proto=ldaps ad-test:636

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

Невнимательно написания доменов и 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.

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

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

inaword

Блог о разработке и современных технологиях

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

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

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

Окружение

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

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

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

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

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

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

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

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

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

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

Доступ по SSH

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

Резюме

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

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

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

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

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

Окружение

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

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

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

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

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

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

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

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

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

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

Доступ по SSH

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

Резюме

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

Читайте также

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