Debian 10: Установка и настройка Samba Active Directory

Службы каталогов

В любой организации наступает период, когда появляется множество клиентов, серверов, сервисов – всё это требует сложности администрирования: разделение прав, создание\удаление учетных записей. Чем больше народу приходит в компанию, тем больше болит голова у админа. Очевидным решением становится использование службы каталогов – средства иерархического представления ресурсов с централизованным управлением. К сведению, первые службы каталогов появились ещё в 1984 году и продолжили своё развитие в различных вариациях. А когда Microsoft выпустила NTDS  (в дальнейшем переименован в Active Directory), то данный инструмент стал негласным стандартом и одним из самых распространенных в своём классе.

LDAP – протокол, который лёг в основу служб каталогов и используется в различных LDAP-совместимых реализациях служб каталогов. К примеру, таковыми являются (самые популярные и известные):

• Active Directory;
• OpenLDAP;
• Samba Domain;
• И прочие другие коммерческие.

Все записи LDAP представляются атрибутами в следующем виде:

cn=petrov,ou=office,dc=example,dc=com

где “petrov” – уникальная запись в Object Unit “office” домена example.com

Samba как DC

Но за всё надо платить, ибо самый популярный для таких целей Windows Server с Active Direcory на борту не бесплатный, а потому в последнее время с развитием пакета программ Samba 4 есть возможность использования Samba в качестве контроллера домена с применением групповых политик. О Samba 4 и последующей настройке и будет дальнейшее содержание данной статьи.

По своей сути Samba 4 есть Open-Source реализация Active Directory и, согласно документации, является стабильным вариантом применения в качестве домен-контроллера в production-среде.

Одним из минусов является отсутствие поддержки репликации Sysvol через DFS-R (условно говоря, sysvol – это директория с параметрами групповых политик, сценариев входа\выхода из системы и при использовании нескольких контроллеров домена, должна быть реплицирована на все имеющиеся контроллеры в домене). Samba пока что так не умеет, а потому есть решения с использованием rsync или более сложные и гибкие варианты. Но об этом в данном материале рассказано не будет.

В ранних версиях было ограничение размера БД до 4 гб в Samba при использовании в качестве контроллера домена, но данный вопрос был решён в версии 4.9 – реализован бэкенд LDB (экспериментальный), основанный на библиотеке LMDB, что в итоге позволяет создавать базы данных объемом свыше 4 гб. Для включения данного параметра нужно использовать ключ –backend-store=mdb. В данной статье, дабы не усложнять материал, обойдемся без данного ключа.

Перед установкой

Наименование домена

Перед началом инсталляции необходимо определиться с именем сервера и домена. В рамках данной статьи сервер с Samba на борту будет иметь полное имя (FQDN) dc0.ad.rmn-lux.ru, а сам домен – ad.rmn-lux.ru.

Кратко поясню, почему выбран именно такой формат именования.

• Никаких названий а-ля PDC или BDC использовать не стоит – это пережитки прошлого;
• Также не стоит использовать test.local и т.п. домены:
  • подобные имена противоречат rfc 6762
  • для такого домена не получится получить публичный TLS-сертификат
  • такое имя будет недоступно из внешней сети
• Можно было бы назвать AD домен также, как основной домен сайта. Для примера, в таком случае имя домена было бы как и домен моего сайта – it-lux.ru. Это правильно, но в таком случае пришлось бы следить за публичной и внутренней зоной DNS, что не всегда удобно, т.к. может возникнуть рассинхрон.
• В качестве имени можно выбрать домен из другой зоны, который не будет конфликтовать с основным доменом. В моём случае это может быть, например, it-lux.online или аналогичный домен в другой доменной зоне.

Исходя из вышесказанного, наиболее правильным, как мне кажется, использовать поддомен ad.rmn-lux.ru для названия домена AD, т.к. это будет консолидировано в рамках одного домена.

AD Schema

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

Информация с оф. сайта Samba по поддержке AD схем:

Последняя стабильно поддерживаемая AD схема в Samba на момент написания данного материала – 69, а подходящая версия Samba для этого – 4.11 и выше.

Одним из нюансов является то, что в стабильных репозиториях Debian 10 доступна Samba версии только 4.9. Но хотелось бы использовать последние доступные возможности схемы домена, поэтому я на свой страх и риск подключил тестовые репозитории и произвёл дальнейшую установку Samba 4.11.3 из них:

DNS

Для домена необходимо использование DNS-сервера. Я остановился на распространённом варианте – использование встроенного в Samba DNS Internal. Допустимо использование BIND, но в рамках данной статьи его применение рассматриваться не будет.

Samba Internal DNS имеет следующие недостатки:

• нельзя использовать как кеширующий сервер
• не поддерживает рекурсивные запросы
• нет shared-key transaction signature (TSIG)
• нет зоны-заглушки
• не поддерживает zone transfers
• нет Round Robin балансировки между DC’s

Не смотря на вышеперечисленное, на практике это не доставляет проблем.

Подразумевается, что в сети, где разворачивается Samba AD, уже используется один или более DNS-серверов (например, тот же BIND, который не связан с Samba или внешние гугл\яндекс сервера). На этот DNS-сервер будут перенаправляться запросы клиентов Samba, т.е. он будет выбран в качестве forwarder.

Настройка hosts

Также сервер dc0.ad.rmn-lux.ru должен иметь статический IP-адрес и файл /etc/hosts со следующим содержимым:

127.0.0.1     localhost
172.16.0.16     dc0.ad.it-lux.ru     dc0

Удаление существующих файлов

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

mv /etc/samba/smb.conf /tmp && mv /etc/krb5.conf /tmp

Запущенные экземпляры Samba и сервисов

Перед началом установки надо проверить, что не запущена samba и её сервисы после установки пакетов:

ps ax | egrep "samba|smbd|nmbd|winbindd"

Если под фильтр попадает что-то из запущенного, нужно остановить:

systemctl stop samba-ad-dc smbd nmbd winbind

Скрыть юниты, чтобы они не могли быть запущены:

systemctl mask samba-ad-dc smbd nmbd winbind

И отключить:

systemctl disable samba-ad-dc smbd nmbd winbind

Установка

Для своих серверов я всегда использую Centos, но здесь пришлось сделать исключение и выбрать Debian, т.к. Samba, доступная из основных пакетов в Centos, не может выступать в роли AD.

Вариантов установки на Centos было несколько: собрать из пакетов (что на продуктивном сервере совсем некошерно) или установить из сторонних репозиториев (например, tissamba), но решил попробовать Debian, т.к. не хотелось искать обходные пути.

Но и с Debian оказался нюанс, т.к. в основных стабильных репозиториях не было нужной мне версии. Тем не менее, вариант установки из официальных репозиториев, пусть и тестовых, меня более чем устроил.

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

Зависимости, необходимые для Samba AD в Debian:

apt-get install acl attr autoconf bind9utils bison build-essential \
  debhelper dnsutils docbook-xml docbook-xsl flex gdb libjansson-dev krb5-user \
  libacl1-dev libaio-dev libarchive-dev libattr1-dev libblkid-dev libbsd-dev \
  libcap-dev libcups2-dev libgnutls28-dev libgpgme-dev libjson-perl \
  libldap2-dev libncurses5-dev libpam0g-dev libparse-yapp-perl \
  libpopt-dev libreadline-dev nettle-dev perl perl-modules pkg-config \
  python-all-dev python-crypto python-dbg python-dev python-dnspython \
  python3-dnspython python-markdown python3-markdown \
  python3-dev xsltproc zlib1g-dev liblmdb-dev lmdb-utils

В оф. документации указаны пакеты python-gpgme python3-gpgme для зависимостей, но в Debian 10 его больше нет, так что его я не устанавливал.

Настройка домена

Для установки Samba в Debian 10 нужны следующие пакеты:

apt-get install acl attr samba samba-dsdb-modules samba-vfs-modules winbind libpam-winbind libnss-winbind libpam-krb5 krb5-config krb5-user

Напоминаю, что мне нужна была версия 4.11, поэтому после установки нужно убедиться, что будет использоваться пакет нужной версии:

samba-tool --version

4.11.3-Debian

Теперь непосредственно настройка домена:

samba-tool domain provision --server-role=dc --use-rfc2307 --dns-backend=SAMBA_INTERNAL --realm=AD.IT-LUX.RU --domain=AD --adminpass=Password

Указывается роль – domain controller, использование необходимого rfc2307, согласно оф. документации – для возможности хранения атрибутов Unix в AD, встроенный DNS, имя домена – обязательно заглавными буквами и NetBIOS имя домена одним словом без точки, а также указание админского пароля.

Теперь надо сконфигурировать /etc/resolv.conf, чтобы в качестве резолвера использовался DNS из Samba (по идее, можно было бы сделать до создания домена):

На всякий случай уточню, что файл resolve.conf может затираться NetworkManager`ом или установленной утилитой resolvconf после рестарта, стоит это иметь ввиду.

Kerberos

Kerberos – это сетевой протокол, который будет использоваться для аутентификации.

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

cp /var/lib/samba/private/krb5.conf /etc/krb5.conf

И проверить его содержимое (на всякий случай):

cat /etc/krb5.conf

[libdefaults]
        default_realm = AD.IT-LUX.RU
        dns_lookup_realm = false
        dns_lookup_kdc = true

После успешного создания домена (не должно быть никаких ошибок при выполнении), нужно вернуть настройки юнита самбы, т.к. делался mask. Сейчас же при старте возникает такая ошибка:

systemctl enable samba-ad-dc

Synchronizing state of samba-ad-dc.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable samba-ad-dc
Failed to enable unit: Unit file /etc/systemd/system/samba-ad-dc.service is masked.

Симлинк, ведущий в /dev/null, нужно удалить и выполнить перезагрузку сервисов systemd:

rm /etc/systemd/system/samba-ad-dc.service && systemctl daemon-reload

И запустить самбу, которая подтянет уже всё остальное, что ей нужно:

systemctl enable --now samba-ad-dc

Правка конфигурационного файла Samba

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

# Global parameters
[global]
        dns forwarder = 127.0.0.1
        netbios name = DC0
        realm = AD.IT-LUX.RU
        server role = active directory domain controller
        workgroup = AD-IT-LUX
        idmap_ldb:use rfc2307 = yes

[sysvol]
        path = /var/lib/samba/sysvol
        read only = No

[netlogon]
        path = /var/lib/samba/sysvol/ad.it-lux.ru/scripts
        read only = No

Но по своему опыту скажу, что штатный конфиг нужно поправить, местами упростив настройки. Ниже кратко опишу опции конфигурационного файла /etc/samba/smb.conf:

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

systemctl restart samba-ad-dc

LDAPS: TLS и CA

Вышеописанные инструкции по настройке в том или ином виде можно найти в интернете и особых сложностей не возникает. Но мало где описывают настройку TLS\SSL для Samba. При LDAP-авторизации трафик ходит незащищённым, а потому может возникнуть требование по настройке протокола LDAPS.

Samba при начальной установке автоматически генерирует ключ и сертификат для работы AD и корневой сертификат. Корневой сертификат имеет срок годности 2 года и длину ключа 4096 бит + непонятно где находится приватный ключ корневого сертификата. Для более прозрачного администрирования ниже будет описан процесс создания собственного центра сертификации (CA-сертификата и приватного ключа), с помощью которого будет выписан сертификат для работы Samba AD и прочих клиентов при необходимости.

Samba должна быть остановлена, а текущие ключи перемещены во временную директорию:

systemctl stop samba-ad-dc
mv {ca,cert,key}.pem /tmp/

• На сервере должен быть установлен пакет для работы с openssl 
• Все сертификаты будут генерироваться по пути /var/lib/samba/private/tls/

Настройка CA и сертификатов

Сгенерировать ключ для CA с алгоритмом RSA, длина ключа — 4096 бит:

openssl genrsa -out /var/lib/samba/private/tls/ca.key 4096

Сгенерировать корневой сертификат на основе ключа сроком на 10 лет. Дополнительно указывается CN (Common Name), которое должно быть наименованием домена, точнее его FQDN в верхнем регистре. Например, так:

openssl req -new -x509 -nodes -days 3650 -key ca.key -out /var/lib/samba/private/tls/ca.pem -subj "/O=Home Inc/OU=Samba CA cert/CN=dc0.ad.rmn-lux.ru"

Теперь, когда создан собственный CA, необходимо создать серверный сертификат для Samba AD. По аналогии с CA сначала создается ключ (с именем сервера для удобства), длина ключа может быть уже меньше:

openssl genrsa -out dc0.ad.rmn-lux.ru.key 2048

Далее запрос на подпись (CSR):

openssl req -new -sha256 -key dc0.ad.rmn-lux.ru.key -subj "/O=Home inc/OU=Samba AD cert/CN=dc0.ad.rmn-lux.ru" -out dc0.ad.rmn-lux.ru.csr

ВАЖНО! Наименование OU для сертификатов CA и Samba должны быть разными. В командах выше subj содержит разные значения. CN в идеале тоже должно быть разным, но в данном случае не критично.

И подписать CSR корневым ключом и сертификатом:

openssl x509 -req -in dc0.ad.rmn-lux.ru.csr -CA /var/lib/samba/private/tls/ca.pem -CAkey /var/lib/samba/private/tls/ca.key -CAcreateserial -out dc0.ad.rmn-lux.ru.pem -days 3650

Выполнить проверку полученного сертификата с использованием корневого сертификата. Это важный этап, никаких ошибок быть не должно:

openssl verify -CAfile ca.pem dc0.ad.rmn-lux.ru.pem

dc0.ad.rmn-lux.ru.pem: OK

Конфигурация Samba

В конфигурационном файле /etc/samba/smb.conf внести следующие изменения, указав пути до сертификатов и ключа:

[global]
...
 
# TLS
        tls enabled  = yes
        tls keyfile  = tls/dc0.ad.rmn-lux.ru.key
        tls certfile = tls/dc0.ad.rmn-lux.ru.pem
        tls cafile   = tls/ca.pem

После внесения изменений запустить демон и убедиться, что нет ошибок и что самба принимает соединения на порту 636 по LDAPS:

systemctl start samba-ad-dc
netstat -tulpn | grep 636

Проверка настроек

Теперь, когда всё настроено, нужно выполнить ряд проверок, чтобы убедиться в корректной работе всех компонентов Samba.

Общая проверка выполняется командой testparm

host -t A dc0.ad.it-lux.ru
dc0.ad.it-lux.ru has address 172.16.0.16
host -t A ad.it-lux.ru
ad.it-lux.ru has address 172.16.0.16
wbinfo -t
checking the trust secret for domain AD-IT-LUX via RPC calls succeeded
wbinfo -p
Ping to winbindd succeeded
wbinfo -P
checking the NETLOGON for domain[AD-IT-LUX] dc connection to "dc0.ad.it-lux.ru" succeeded

Проверка БД Samba
samba-tool dbcheck
Исправление ошибок с БД
samba-tool dbcheck --fix
Проверка прав доступа к sysvol
samba-tool ntacl sysvolcheck
При наличии ошибок с sysvol - исправление
samba-tool ntacl sysvolreset

update-ca-trust

ldapsearch -d 1 -H ldaps://dc0.ad.rmn-lux.ru:636

samba-tool domain info dc0.ad.it-lux.ru
Forest           : ad.it-lux.ru
Domain           : ad.it-lux.ru
Netbios domain   : AD-IT-LUX
DC name          : dc0.ad.it-lux.ru
DC netbios name  : DC0
Server site      : Default-First-Site-Name
Client site      : Default-First-Site-Name

wbinfo -u
AD-IT-LUX\administrator
AD-IT-LUX\guest
AD-IT-LUX\krbtgt

samba-tool user list

wbinfo -g
AD-IT-LUX\cert publishers
AD-IT-LUX\ras and ias servers
AD-IT-LUX\allowed rodc password replication group
AD-IT-LUX\denied rodc password replication group
AD-IT-LUX\dnsadmins
AD-IT-LUX\enterprise read-only domain controllers
AD-IT-LUX\domain admins
AD-IT-LUX\domain users
AD-IT-LUX\domain guests
AD-IT-LUX\domain computers
AD-IT-LUX\domain controllers
AD-IT-LUX\schema admins
AD-IT-LUX\enterprise admins
AD-IT-LUX\group policy creator owners
AD-IT-LUX\read-only domain controllers
AD-IT-LUX\dnsupdateproxy

samba-tool group list

samba-tool computer list

DC0$

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

samba-tool user create newuser

Задать ему пароль:

samba-tool user setpassword newuser

Деактивировать пользователя:

samba-tool user disable newuser

Прочие команды можно посмотреть, выполнив:

samba-tool --help

через samba-tool также настраивается DNS.

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

Бэкап

В официальной документации подробно всё описано, поэтому первоначально стоит ознакомиться с информацией там.

После настройки благоразумно будет обеспечить резервное копирование Samba. Есть несколько типов резервирования: “Online” и “Offline”.

Online делает копию работающей базы DC:

samba-tool domain backup online --targetdir=<output-dir> --server=<DC-server> -UAdministrator

Offline создает резервные копии файлов Samba:

samba-tool domain backup offline --targetdir=<output-dir>

Каждая команда создает файл резервной копии .tar.bz2, который содержит полную резервную копию домена (на основе данного DC). Затем файл резервной копии можно использовать для восстановления домена с помощью команды «samba-tool domain backup restore».

Использовать ту или иную схему бэкапа нужно в зависимости от ситуации. В обычных случаях Online-бэкап самый простой и быстрый, но в случае каких-то неполадок и для их расследования и устранения лучше подойдёт Offline-бэкап, т.к. содержит в себе дополнительные данные.

В идеале можно комбинировать оба способа, настроив бэкап по крону с созданием нужного кол-ва копий.

Настройка Samba secondary domain controller

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

Стоит понимать, что в терминологии контроллеров домена нет понятия master\slave, т.е. все контроллеры равны, но один из них выступает владельцем ролей FSMO. Для проверки, какой из контроллеров является владельцем, можно выполнить команду samba-tool fsmo show

Важно остановить демон samba и сделать umask перед вводом сервера в домен.

На обоих контроллерах домена должно быть одинаковое время, поэтому необходимо проверить этот момент. Например, через timedatectl timesync-status

Подключение второго домена, как secondary, выполняется следующей командой:

samba-tool domain join ${DOMAIN_NAME} DC -U"DOMAIN\Administrator" --option="dns forwarder=${DNS_SRV}" --option='idmap_ldb:use rfc2307 = yes'

1. Задать имя домена в ${DOMAIN_NAME}
2. Обратить внимание на флаг “DC” после имени домена – это указывает, что подключаемый сервер будет иметь роль контроллера домена
3. При использовании dns internal, необходимо указать значение ${DNS_SRV} – dns forwarder, чтобы на новом сервере с КД была настроена пересылка запросов. Форвардером может быть как вышестоящий DNS-сервер организации или публичные от гугла или яндекса.
4. Если первичный КД создавался с ключом –rfc2307, то и для текущего необходимо это учесть, указав “idmap_ldb:use rfc2307 = yes”

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

samba-tool domain join samdom.example.com DC -k yes
samba-tool domain join samdom.example.com DC --krb5-ccache=/tmp/krb5cc_0

При успешном выполнении команды, вывод должен быть примерно следующий:

После успешного подключения к домену в качестве контроллера домена, можно запустить демон самбы, который уже запустит все остальное необходимое (winbindd, smbd):

rm /etc/systemd/system/samba-ad-dc.service && systemctl daemon-reload
systemctl enable samba-ad-dc --now

Проверка работы DNS

При вводе в работу второго КД и использовании Samba версии 4.7 и выше, все необходимые записи в DNS создаются автоматически. Тем не менее, необходимо проверить и убедиться, что они были созданы корректно:

host -t A srv-name.domain.name

Все объекты в AD имеют уникальный идентификатор objectGUID, который не может быть изменён. Samba также автоматически создаёт его, поэтому необходимо выполнить проверку. Для этого понадобится утилита ldbsearch из пакета ldb-tools. Она обращается к файлу /var/lib/samba/private/sam.ldb:

ldbsearch -H /var/lib/samba/private/sam.ldb '(invocationId=*)' --cross-ncs objectguid
# record 1
dn: CN=NTDS Settings,CN=AD-SRV,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
objectGUID: 7fba6e01-8e83-4f71-997d-5d89ca79c82b
 
# record 2
dn: CN=NTDS Settings,CN=AD-SRV1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=local
objectGUID: 18406914-1f17-4d28-b262-04edd907bcb0
 
# returned 2 records
# 2 entries
# 0 referrals

В результате выше видно, что создалась вторая запись с objectGUID 18406914-1f17-4d28-b262-04edd907bcb0 – это второй контроллер домена.

В DNS также создается служебная CNAME запись с этим идентификатором, которая указывает на имя нового контроллера домена. Для получения этой записи нужно выполнить команду, подставив objectGUID  из вывода ldbsearch:

host -t CNAME 18406914-1f17-4d28-b262-04edd907bcb0._msdcs.domain.local.

Проверка репликации

Теперь необходимо выполнить команду по проверке репликации каталогов DRS (Directory Replication Service). Она включает в себя следующие объекты:

DC=Forest_Root_Domain
CN=Configuration,DC=Forest_Root_Domain
CN=Schema,CN=Configuration,DC=Forest_Root_Domain
DC=ForestDnsZones,DC=Forest_Root_Domain
DC=DomainDnsZones,DC=Forest_Root_Domain

Т.е. между контроллерами будут реплицированы схема, DNS-записи, группы, пользователи. Первоначально репликация может занимать около 15 минут, поэтому нужно подождать, пока knowledge consistency checker (KKC в Samba) выполнит все необходимые процедуры.

Проверка статуса репликации со второго контроллера домена:

samba-tool drs showrepl

Ошибку No NC replicated for Connection! можно смело игнорировать – об этом написано в документации

Обратить стоит внимание на KCC CONNECTION OBJECTS, статус должен быть ENABLED: TRUE, а также на статус реплицируемых объектов, при успешной процедуре везде должна быть запись вида “Last attempt @ NTTIME(0) was successful”.

Если никаких ошибок нет, то выполнить аналогичную команду по проверке репликации на первом контроллере домена – там также не должно быть проблем:

samba-tool drs showrepl

В случае каких-либо проблем можно попробовать перезапустить сервис Samba на обоих КД.

Ещё одним способом является сравнение количества объектов каталогов в домене на всех КД с помощью ldapcmp:

samba-tool ldapcmp ldap://dc1.test.local ldap://dc2.test.local -Uadministrator

После того, как репликация успешно запущена и работает, на новом контроллере домена необходимо указать использование первым своего локального DNS-сервера, а вторым – исходный сервер AD

Репликация SysVol

Основную функцию по репликации каталогов Samba выполняет из коробки и в целом проблем с этим не возникает. Но при необходимости реплицировать скрипты при логине в систему, файлы с рабочих столов и прочее – этого Samba не умеет. Т.к. в рамках данной статьи рассматривается настройка дублирующего контроллера домена только для репликации каталогов, то ниже будут приведены ссылки на официальную документацию с инструкциями по выполнению репликации SysVol:

• https://wiki.samba.org/index.php/Rsync_based_SysVol_replication_workaround
• https://wiki.samba.org/index.php/Bidirectional_Rsync/Unison_based_SysVol_replication_workaround
• https://wiki.samba.org/index.php/Bidirectional_Rsync/osync_based_SysVol_replication_workaround
• https://wiki.samba.org/index.php/Robocopy_based_SysVol_replication_workaround

Заключение

В рамках статьи был рассмотрен вариант установки Samba AD в качестве контроллера домена в количестве двух инстансов для отказоустойчивости. Данный вариант в большинстве своём подойдет для небольшого и среднего офиса, особенно если потребуется проверенное временем решение, а также если взят курс на импортозамещение – Samba в текущем виде может заменить Active Directory от Microsoft хотя бы в том, что как минимум не требует вложений в лицензии Windows. Для “глубокого продакшена”, разумеется, лучше использовать более надёжные решения, которые позволяют получать поддержку от вендора.

В качестве альтернативы есть ещё решения, как openldap и FreeIPA, но с ними не приходилось сталкиваться.

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

Или же подключить RADIUS для авторизации на VPN-сервере через доменную учётную запись, а также доменную авторизацию ко всем внутренним сервисам для централизованного управления.

Используемые источники

• https://dev.tranquil.it/samba/en/samba_fundamentals/samba_history.html