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 схем:

Windows Server VersionDirectory Schema Version
Windows Server 201687
Windows Server 2012R269
Windows Server 201256
Windows Server 2008R247
Samba VersionHighest Supported Schema Version
4.11 and later69
4.5 – 4.1069 *
4.0 – 4.447

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

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

sources.list

deb http://ftp.ru.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.ru.debian.org/debian/ testing main contrib non-free
deb http://ftp.ru.debian.org/debian/ testing-updates main contrib non-free
deb-src http://ftp.ru.debian.org/debian/ testing-updates main contrib non-free
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free

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 (по идее, можно было бы сделать до создания домена):

/etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto enp0s3
allow-hotplug enp0s3
iface enp0s3 inet static
address 172.16.0.16/24
gateway 172.16.0.1
dns-nameservers 127.0.0.1
/etc/resolv.conf:
search ad.it-lux.ru
nameserver 127.0.0.1

На всякий случай уточню, что файл 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:

smb.conf

# 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
bind interfaces only = yes # слушать только на указанных интерфейсах
interfaces = 127.0.0.1 172.16.0.16
dns forwarder = 8.8.8.8 # вышестоящий DNS-сервер
allow dns updates = nonsecure and secure # разрешает nonsecure запросы
ldap server require strong auth = no # необходимо для авторизации
domain master = yes # Для указания того, что данный КД является мастером при наличии других
local master = yes
preferred master = yes
vfs objects = acl_xattr # для настройки share используя ACL на Unix. По умолчанию включен, но всё равно прописал для наглядности
map acl inherit = yes
store dos attributes = yes
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[netlogon]
path = /var/lib/samba/sysvol/ad.it-lux.ru/scripts
read only = No

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

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

Посредством команд hosts и wbinfo можно провести ряд проверок, результат выполнения которых должен быть без ошибок:

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

Дополнительно со стороны клиентов, которые подключаются к серверу с Samba AD по LDAPS, необходимо импортировать корневой сертификат. Для клиентов с Centos скопировать корневой сертификат ca.pem на клиентскую ОС по пути /etc/pki/ca-trust/source/anchors и выполнить команду импорта сертификата в ОС:

update-ca-trust

После этого можно подключаться через защищенное соединение. Для проверки работы TLS можно воспользоваться утилитой ldapsearch из пакета ldap-clients с расширенным дебагом:

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 или samba-tool:

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

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

вывод samba-tool domain join

Finding a writeable DC for domain ‘samdom.example.com’
Found DC dc1.samdom.example.com
Password for [SAMDOM\administrator]:
workgroup is SAMDOM
realm is samdom.example.com
Adding CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com
Adding CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
Adding CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
Adding SPNs to CN=DC2,OU=Domain Controllers,DC=samdom,DC=example,DC=com
Setting account password for DC2$
Enabling account
Calling bare provision
Looking up IPv4 addresses
Looking up IPv6 addresses
No IPv6 address will be assigned
Setting up share.ldb
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
A Kerberos configuration suitable for Samba 4 has been generated at /usr/local/samba/private/krb5.conf
Provision OK for domain DN DC=samdom,DC=example,DC=com
Starting replication
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1550] linked_values[0/0]
Schema-DN[CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com] objects[1550/1550] linked_values[0/0]
Analyze and apply schema objects
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[402/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[804/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1206/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1608/1618] linked_values[0/0]
Partition[CN=Configuration,DC=samdom,DC=example,DC=com] objects[1618/1618] linked_values[42/0]
Replicating critical objects from the base DN of the domain
Partition[DC=samdom,DC=example,DC=com] objects[100/100] linked_values[23/0]
Partition[DC=samdom,DC=example,DC=com] objects[386/286] linked_values[23/0]
Done with always replicated NC (base, config, schema)
Replicating DC=DomainDnsZones,DC=samdom,DC=example,DC=com
Partition[DC=DomainDnsZones,DC=samdom,DC=example,DC=com] objects[44/44] linked_values[0/0]
Replicating DC=ForestDnsZones,DC=samdom,DC=example,DC=com
Partition[DC=ForestDnsZones,DC=samdom,DC=example,DC=com] objects[19/19] linked_values[0/0]
Committing SAM database
Sending DsReplicaUpdateRefs for all the replicated partitions
Setting isSynchronized and dsServiceName
Setting up secrets database
Joined domain SAMDOM (SID S-1-5-21-469703510-2364959079-1506205053) as a DC

После успешного подключения к домену в качестве контроллера домена, можно запустить демон самбы, который уже запустит все остальное необходимое (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
вывод samba-tool drs showrepl

samba-tool drs showrepl
Default-First-Site-Name\DC2
DSA Options: 0x00000001
DSA object GUID: c14a774f-9732-4ec2-b9fa-2156c95c4e48
DSA invocationId: 7bdb135c-6868-4dd9-9460-33dea4b6b87b

==== INBOUND NEIGHBORS ====

CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ Sat May 13 02:52:36 2017 CEST was successful
0 consecutive failure(s).
Last success @ Sat May 13 02:52:36 2017 CEST

DC=DomainDnsZones,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ Sat May 13 02:52:36 2017 CEST was successful
0 consecutive failure(s).
Last success @ Sat May 13 02:52:36 2017 CEST

CN=Configuration,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ Sat May 13 02:52:36 2017 CEST was successful
0 consecutive failure(s).
Last success @ Sat May 13 02:52:36 2017 CEST

DC=ForestDnsZones,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ Sat May 13 02:52:36 2017 CEST was successful
0 consecutive failure(s).
Last success @ Sat May 13 02:52:36 2017 CEST

DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ Sat May 13 02:52:36 2017 CEST was successful
0 consecutive failure(s).
Last success @ Sat May 13 02:52:36 2017 CEST

==== OUTBOUND NEIGHBORS ====

CN=Schema,CN=Configuration,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

DC=DomainDnsZones,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

CN=Configuration,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

DC=ForestDnsZones,DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

DC=samdom,DC=example,DC=com
Default-First-Site-Name\DC1 via RPC
DSA object GUID: 4a6bd92a-6612-4b15-aa8c-9ec371e8994f
Last attempt @ NTTIME(0) was successful
0 consecutive failure(s).
Last success @ NTTIME(0)

==== KCC CONNECTION OBJECTS ====

Connection —
Connection name: fb03f58b-1654-4a02-8e11-f0ea120b60cc
Enabled : TRUE
Server DNS name : DC1.samdom.example.com
Server DN name : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com
TransportType: RPC
options: 0x00000001
Warning: No NC replicated for Connection!

Ошибку 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:

Заключение

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

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

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

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

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

Понравилась статья? Поделиться с друзьями:
Комментарии: 2
  1. Алексей

    Расскажите как подключится к AD для управления c Windows7 посредством RSAT.

    1. admin (автор)

      Поищите в интернете, мануалов очень много. Например, https://winitpro.ru/index.php/2010/12/06/ustanovka-rsat-v-windows-7/

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

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: