Доменная инфраструктура на базе Samba

Руководство администратора

Редакция ноябрь, 2024

Аннотация

Samba может выступать в роли контроллера домена и сервиса Active Directory.

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

1. Введение

1.1. Основные сведения о логической модели AD
1.2. Схема стенда

2. Создание контроллера домена Active Directory на базе Samba

2.1. Подготовка системы к установке сервера Samba AD DC

2.1.1. Системные требования к контроллеру домена Samba AD
2.1.2. Синхронизация времени
2.1.3. Требования к портам

2.2. Создание домена

2.2.1. Параметры команды разворачивания домена
2.2.2. Настройка NTP-сервера
2.2.3. Установка имени контроллера домена
2.2.4. Установка пакетов
2.2.5. Внутренний DNS-сервер Samba (SAMBA_INTERNAL)
2.2.6. Домен с BIND9_DLZ

2.3. Настройка Kerberos

2.4. Проверка работоспособности домена

2.5. Присоединение к домену в роли контроллера домена

2.5.1. Заведение дополнительного контроллера домена c бэкендом SAMBA_INTERNAL
2.5.2. Заведение дополнительного контроллера домена c бэкендом BIND9_DLZ
2.5.3. Проверка результатов присоединения

2.6. Контроллер домена на чтение (RODC)

2.6.1. Установка и настройка RODC
2.6.2. Политики репликации и кеширования паролей на RODC
2.6.3. Проверка репликации пароля пользователя на сервере RODC

2.7. Редактирование существующего домена

2.7.1. Повышение уровня схемы, функционального уровня домена
2.7.2. Включение RFC2307 после разворачивания домена
2.7.3. Изменение DNS бэкенда контроллера домена Active Directory

2.8. Отладочная информация

2.8.1. Настройка уровня журналирования Samba
2.8.2. Управление процессами
2.8.3. DNS

2.9. Удаление контроллера домена

2.9.1. Понижение роли онлайн-контроллера домена
2.9.2. Понижение автономного контроллера домена
2.9.3. Проверка

3. Репликация

3.1. Настройка репликации

3.2. Проверка статуса репликации

3.2.1. Отображение статуса репликации на контроллере домена Samba
3.2.2. Отображение статусов репликации на контроллере домена Windows

3.3. Двунаправленная репликация SysVol

3.3.1. Настройка двунаправленной репликации SysVol на базе Rsync/Unison
3.3.2. Настройка двунаправленной репликации SysVol на базе Rsync/osync
3.3.3. Сопоставление встроенных идентификаторов пользователей и групп

4. Клиенты Альт Домен

4.1. SSSD vs Winbind

4.2. Подготовка системы к вводу в домен

4.2.1. Установка пакетов
4.2.2. Синхронизация времени
4.2.3. Настройка DNS

4.3. Присоединение к домену в роли участника

4.3.1. Команда system-auth
4.3.2. Подключение к домену AD с помощью SSSD
4.3.3. Подключение к AD с помощью Samba Winbind

4.4. Вход пользователя

4.5. Отображение глобальных групп на локальные

4.6. Отладочная информация

4.6.1. Настройка уровня журналирования Samba
4.6.2. Ошибка при подключении к IP-адресу 127.0.0.1
4.6.3. getent не показывает доменных пользователей и группы

4.7. Удаление клиента AD

4.8. Повторная регистрация клиента

4.9. Настройка аутентификации доменных пользователей на DC

4.9.1. Winbind
4.9.2. SSSD
4.9.3. Генерация keytab-файла
4.9.4. Службы
4.9.5. Настройка ролей
4.9.6. Групповые политики
4.9.7. Настройка SSH

4.10. Настройка обновления паролей аккаунтов машин

4.10.1. Локальная политика смены пароля
4.10.2. Включение обновления пароля
4.10.3. Отключение обновления пароля
4.10.4. Диагностика
4.10.5. Восстановление работоспособности

5. Доверительные отношения (Трасты)

5.1. Настройка доверия

5.1.1. Общие сведения
5.1.2. Особенности доверительных отношений в Samba

5.2. Настройка DNS

5.2.1. Два домена Samba
5.2.2. Samba DC и Windows Server с AD

5.3. Создание доверительного отношения

5.3.1. Два домена Samba
5.3.2. Samba AD и Windows Server с AD

5.4. Управление пользователями и группами

5.4.1. Список пользователей и групп
5.4.2. Тестирование аутентификации
5.4.3. Просмотр доверия в Windows

5.5. Использование трастов на LINUX-клиентах

5.5.1. Настройка Winbind
5.5.2. Настройка SSSD

5.6. Удаление доверия

5.6.1. На стороне Samba
5.6.2. На стороне Windows Server с AD

6. Администрирование Samba

6.1. Управление пользователями и группами

6.1.1. В ADMC
6.1.2. С помощью samba-tool

6.2. Администрирование DNS

6.2.1. DNS-записи при вводе машины в домен
6.2.2. Утилита samba-tool
6.2.3. nsupdate
6.2.4. Oснастка DNS в RSAT
6.2.5. Динамическое обновление DNS-записей
6.2.6. Обновление IP-адресов вручную
6.2.7. Известные проблемы

6.3. Администрирование сайтов и подсетей

6.3.1. Утилита samba-tool

6.4. Управление парольными политиками

6.4.1. Глобальные парольные политики
6.4.2. Объекты настроек паролей (PSO)

6.5. Резервное копирование и восстановление Samba AD DC

6.5.1. Резервное копирование и восстановление из резервной копии
6.5.2. Восстановление произвольного контроллера домена после фатального сбоя

6.6. Роли FSMO

6.6.1. Семь ролей FSMO
6.6.2. Просмотр и передача ролей FSMO

6.7. Настройка Samba для привязки к определённым интерфейсам

6.8. Создание keytab-файла

6.8.1. Назначение и формат SPN
6.8.2. Создание SPN и генерация keytab с помощью samba-tool

6.9. Настройка DHCP-сервера для обновления DNS-записей

6.9.1. Настройка DHCP-сервера
6.9.2. Настройка переключения DHCP

6.10. Аутентификация других сервисов в Samba AD

6.10.1. Настройка аутентификации Kerberos для веб-сервера Apache
6.10.2. Настройка аутентификации Kerberos для веб-сервера Nginx
6.10.3. Настройка браузеров для SSO

6.11. Distributed File System

6.11.1. Пространство DFS-имен
6.11.2. Настройка DFS на сервере Samba

6.12. Настройка SSSD

6.12.1. Журналирование SSSD
6.12.2. Настройки SSSD в ЦУС
6.12.3. Включение автономной аутентификации

6.13. Файловый сервер

6.14. Монтирование общих ресурсов samba

6.14.1. Подключение с использованием gio
6.14.2. Подключение с использованием pam_mount
6.14.3. Подключение с использованием Autofs

6.15. Журналирование в Samba

6.15.1. Настройка бэкендов
6.15.2. Настройка файлов журнала
6.15.3. Уровни журналирования
6.15.4. Настройка ведения журнала аудита
6.15.5. Интерпретация журналов аудита JSON

6.16. Усиление безопасности DC

6.16.1. Возможность анонимного получения списка пользователей, групп
6.16.2. Отключение Netbios
6.16.3. Отключение роли сервера печати
6.16.4. Отключение NTLMv1
6.16.5. Генерация дополнительных хешей паролей
6.16.6. Защита DNS-записей wpad и isatap
6.16.7. Ограничение диапазона динамических портов
6.16.8. Аудит запросов к каталогам SYSVOL и NetLogon
6.16.9. Отправка логов аудита в rsyslog

6.17. Планирование и настройка диапазонов идентификаторов UID и GID (Winbind/IDMapping)

6.17.1. Планирование диапазонов идентификаторов
6.17.2. Домен * по умолчанию
6.17.3. Использование tdb
6.17.4. Использование ad
6.17.5. Использование rid
6.17.6. Использование autorid

6.18. Установка RSAT

6.18.1. Windows Server
6.18.2. Windows 10 (1809 и более поздних версиях)
6.18.3. Windows Vista и 7

6.19. Инструменты командной строки

6.19.1. samba-tool
6.19.2. wbinfo
6.19.3. net
6.19.4. adcli
6.19.5. ldapsearch
6.19.6. sssctl
6.19.7. testparm

6.20. Конфигурационные файлы

6.20.1. smb.conf
6.20.2. krb5.conf
6.20.3. sssd.conf
6.20.4. resolv.conf
6.20.5. Bind

7. Решение проблем

7.1. Диагностика

7.1.1. Инструмент диагностики состояния контроллера домена
7.1.2. Инструмент диагностики клиента домена
7.1.3. ALT Diagnostic Tool

8. Примечания

8.1. Настройка беспарольного доступа по ssh
8.2. Центр управления системой

⁠Глава 1. Введение

1.1. Основные сведения о логической модели AD
1.2. Схема стенда

⁠1.1. Основные сведения о логической модели AD

Домен

Группа компьютеров, пользователей, принтеров и других объектов, совместно использующих общую БД каталога.

Дерево доменов

Иерархическая система доменов, имеющая единый корень (корневой домен).

Лес доменов

Множество деревьев доменов, находящихся в различных формах доверительных отношений.

Сервер

Компьютер, выполняющий определённые роли в домене.

Контроллер домена

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

Организационное подразделение (OU)

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

Группа

Объекты, являющиеся участниками системы безопасности (security principals) и предназначенные для управления доступом к ресурсам. Каждой группе присваивается уникальный идентификатор безопасности (Security Identifier, SID), который сохраняется в течение всего срока службы.

Группы — это объекты, являющиеся участниками системы безопасности (security principals) и предназначенные для управления доступом к ресурсам. Каждой группе присваивается уникальный идентификатор безопасности (Security Identifier, SID), который сохраняется в течение всего срока службы.

⁠1.2. Схема стенда

⁠

Таблица 1.1. Состав технических и программных средств стенда

№ ПЭВМ	Программная среда	Описание
1	ОС «Альт Сервер»	Контроллер домена test.alt
2	ОС «Альт Сервер»	Дополнительный контроллер домена test.alt
3	ОС Альт («Альт Рабочая станция», «Альт Рабочая станция K», «Альт Образование»)	Рабочая станция
4	ОС Альт («Альт Рабочая станция», «Альт Рабочая станция K», «Альт Образование»)	Рабочая станция
5	ОС Microsoft Windows Server 2012	Контроллер домена win.alt
6	ОС «Альт Сервер»	Контроллер домена example.alt
7	ОС «Альт Сервер»	Веб-сервер, прокси-сервер
8	ОС «Альт Сервер»	Контроллер домена test.alt только для чтения (RODC)
9	ОС Альт («Альт Рабочая станция», «Альт Рабочая станция K», «Альт Образование»)	Рабочая станция

Параметры домена:

домен AD — test.alt;
сервер AD (ОС ALT) — dc1.test.alt (192.168.0.122);
дополнительный сервер AD (ОС ALT) — dc2.test.alt (192.168.0.123);
RODC (ОС ALT) — rodc.test.alt (192.168.0.124);
веб-сервер, прокси-сервер (ОС ALT) — web.test.alt (192.168.0.150);
рабочая станция 1 (ОС ALT) — host-01.test.alt (192.168.0.125);
рабочая станция 2 (ОС ALT) — host-02.test.alt (192.168.0.126);
рабочая станция 3 (ОС ALT) — host-03.test.alt (192.168.0.127);
имя пользователя-администратора — Administrator;
пароль администратора — Pa$$word.

Дополнительные домены:

win.alt: сервер AD (ОС Windows) — dc1.win.alt (192.168.0.190);
example.alt: сервер AD (ОС ALT) — s1.example.alt (192.168.0.172).

⁠Глава 2. Создание контроллера домена Active Directory на базе Samba

2.1. Подготовка системы к установке сервера Samba AD DC

2.1.1. Системные требования к контроллеру домена Samba AD
2.1.2. Синхронизация времени
2.1.3. Требования к портам

2.2. Создание домена

2.2.1. Параметры команды разворачивания домена
2.2.2. Настройка NTP-сервера
2.2.3. Установка имени контроллера домена
2.2.4. Установка пакетов
2.2.5. Внутренний DNS-сервер Samba (SAMBA_INTERNAL)
2.2.6. Домен с BIND9_DLZ

2.3. Настройка Kerberos

2.4. Проверка работоспособности домена

2.5. Присоединение к домену в роли контроллера домена

2.5.1. Заведение дополнительного контроллера домена c бэкендом SAMBA_INTERNAL
2.5.2. Заведение дополнительного контроллера домена c бэкендом BIND9_DLZ
2.5.3. Проверка результатов присоединения

2.6. Контроллер домена на чтение (RODC)

2.6.1. Установка и настройка RODC
2.6.2. Политики репликации и кеширования паролей на RODC
2.6.3. Проверка репликации пароля пользователя на сервере RODC

2.7. Редактирование существующего домена

2.7.1. Повышение уровня схемы, функционального уровня домена
2.7.2. Включение RFC2307 после разворачивания домена
2.7.3. Изменение DNS бэкенда контроллера домена Active Directory

2.8. Отладочная информация

2.8.1. Настройка уровня журналирования Samba
2.8.2. Управление процессами
2.8.3. DNS

2.9. Удаление контроллера домена

2.9.1. Понижение роли онлайн-контроллера домена
2.9.2. Понижение автономного контроллера домена
2.9.3. Проверка

Использование Samba 4 в роли контроллера домена Active Directory позволяет вводить Windows 7/8 в домен без манипуляций с реестром.

Поддерживаются следующие базовые возможности Active Directory:

аутентификация рабочих станций Windows и Linux и служб;
авторизация и предоставление ресурсов;
групповые политики (GPO);
перемещаемые профили (Roaming Profiles);
поддержка инструментов Microsoft для управления серверами (Remote Server Administration Tools) с компьютеров под управлением Windows;
поддержка протоколов SMB2 и SMB3 (в том числе с поддержкой шифрования).

⁠2.1. Подготовка системы к установке сервера Samba AD DC

В этом разделе перечислены требования для установки сервера Samba AD DC. Перед установкой необходимо убедиться, что система соответствует этим требованиям.

Примечание

Для установки контроллера домена Samba AD нужны привилегии суперпользователя.

Примечание

При применении Samba в качестве DC AD в условиях реальной эксплуатации рекомендуется использовать два или более контроллера домена для обеспечения отказоустойчивости.

⁠2.1.1. Системные требования к контроллеру домена Samba AD

⁠2.1.1.1. RAM

Для демонстрационной/тестовой системы рекомендуется 2 ГБ.

Для производственной установки рекомендуется не менее 4 ГБ ОЗУ, а затем 2 ГБ на каждую дополнительную 1000 пользователей.

Примечание

Параметр, который оказывает наибольшее влияние на требования к памяти, — это количество одновременных открытий сеансов.

⁠2.1.1.2. Размеры хранилища

10 ГБ достаточно для доменов с несколькими сотнями пользователей.

При планировании размера хранилища также необходимо учесть:

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

⁠2.1.1.3. CPU

Для нескольких сотен пользователей достаточно 4 vCPUs.

Некоторые процессы Samba не являются многопоточными, поэтому увеличение числа процессоров не повысит производительность.

Чтобы сбалансировать нагрузку, необходимо создать второй контроллер домена в репликации с первым и применить политику балансировки нагрузки на уровне клиента.

Необходимое количество контроллеров домена зависит от нескольких параметров:

количество сторонних приложений LDAP, подключенных к AD;
качество кода сторонних LDAP-приложений, подключенных к AD;
количество запросов к файловым серверам.

⁠2.1.1.4. DNS

Не следует использовать существующий домен, если вы не являетесь владельцем домена. Рекомендуется использовать зарезервированный домен верхнего уровня RFC2606 (https://tools.ietf.org/html/rfc2606) для частных тестовых установок, например, alt.test.

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

Важно

Необходимо избегать суффиксов .local. При указании домена, имеющего суффикс .local, потребуется на сервере и подключаемых компьютерах под управлением Linux отключить службу avahi-daemon.

Примечание

Имя как контроллера домена, так и всех ПК членов домена не должно превышать 15 символов (ограничение связано с sAMAccountName в Active Directory).

⁠2.1.2. Синхронизация времени

Для аутентификации Kerberos необходима точная синхронизация времени между рабочими станциями членов домена и контроллером домена. Максимально допустимое отклонение времени по умолчанию составляет 5 минут. Если член домена или DC имеет большую разницу во времени, доступ будет запрещен. В результате пользователь не сможет получить доступ к общим папкам или выполнить запрос к каталогу.

На всех DC домена должен быть настроен сервер времени NTP.

Samba поддерживает как ntpd, так и chrony в качестве сервера NTP. Демон синхронизирует время с внешними источниками и позволяет клиентам получать время с сервера, на котором запущен демон.

Из схемы синхронизации времени видно, что только DC с ролью Эмулятор PDC получает свое время от внешних серверов времени, все остальные DC получают время от эмулятора PDC, все рабочие станции получают время от любого DC. Клиенты Windows в конечном итоге получают свое время от DC эмулятора PDC через DC, и если DC эмулятора PDC отключается, другие DC будут продолжать его искать, и время может смещаться. В качестве обходного пути следует установить одинаковые внешние серверы времени на всех DC. В этом случае, если эмулятор PDC отключится и его нельзя будет легко перезапустить, нужно передать или захватить роль эмулятора PDC другому DC.

⁠2.1.3. Требования к портам

Для корректной работы службы Samba на контроллере домена должны быть открыты порты, указанные в табл. Порты, используемые Samba AD DC.

⁠

Таблица 2.1. Порты, используемые Samba AD DC

Служба	Порт	Протокол	Примечание
DNS	53	TCP и UDP	Для DNS от контроллера домена к контроллеру домена и от клиента к контроллеру домена. Может быть предоставлен внутренним DNS-сервером Samba или DNS-сервером Bind9
Kerberos	88	TCP и UDP	Для аутентификации Kerberos
NTP	123	UDP (Опционально)	Если на контроллере домена настроен и работает NTP
End Point Mapper (DCE/RPC Locator Service)	135	TCP	Для операций клиента с контроллером домена
NetBIOS Name Service	137	UDP
NetBIOS Datagram	138	UDP	Для службы репликации файлов между контроллерами домена
NetBIOS Session	139	TCP	Для службы репликации файлов между контроллерами домена
LDAP	389	TCP и UDP	Для обработки регулярных запросов от клиентских компьютеров к контроллерам домена
SMB over TCP	445	TCP	Для службы репликации файлов
Kerberos	464	TCP и UDP	Используется `kadmin` для установки и смены пароля Kerberos
LDAPS	636	TCP	Если в файле `smb.conf` установлен параметр `tls enabled = yes` (по умолчанию)
Global Catalog	3268	TCP	Для глобального каталога от клиента к контроллеру домена
Global Catalog SSL	3269	TCP	Если в файле `smb.conf` установлен параметр `tls enabled = yes` (по умолчанию)
Dynamic RPC Ports	49152-65535	TCP	Диапазон соответствует диапазону портов, используемому в Windows Server 2008 и более поздних версиях. Чтобы вручную установить диапазон портов в Samba, необходимо задать требуемый диапазон в параметре `rpc server port` в файле `smb.conf`. Подробности см. в описании параметра на справочной странице `man smb.conf`.

Примечание

В зависимости от состава используемых служб для работы Samba могут потребоваться и другие порты.

⁠2.2. Создание домена

Служба DNS в «Альт Домен» используется для:

разрешения имен;
обнаружения служб;
обнаружения контроллеров домена.

Для управления службой DNS Samba поддерживает работу с двумя DNS-бэкендами:

SAMBA_INTERNAL — встроенный сервер имен:
- поддерживает базовую функциональность, необходимую для работы домена;
- используется по умолчанию при подготовке нового домена, присоединении к существующему домену;
- прост в настройке и не требует дополнительного ПО или знаний о DNS;
- следует использовать для простых настроек DNS;
SAMBA_INTERNAL не поддерживает следующий функционал:
- роль кеширующего DNS-сервера (caching resolver);
- обработку рекурсивных запросов (но может пересылать их другому рекурсивному серверу DNS);
- аутентификацию DNS-транзакций с использованием общих ключей (TSIG);
- работу с зонами-заглушками (stub zones);
- передачу зон DNS (zone transfers);
- балансировку нагрузки циклического перебора между контроллерами домена (Round Robin load balancing among DC's);
- условную пересылку DNS-запросов (conditional DNS forwarding).
BIND9_DLZ — использует Samba AD для хранения информации о зоне:
- требуется BIND 9.8 или более поздняя версия, установленная и настроенная локально на контроллере домена (DC) Samba Active Directory (AD);
- необходимы знания о DNS-сервере BIND и о том, как настроить службу;
- следует использовать для сложных сценариев DNS, которые нельзя настроить во внутреннем DNS.

Примечание

Внутренний DNS-сервер Samba не управляет кешем, поэтому он будет отправлять запрос серверу пересылки для каждого DNS-запроса, который не соответствует его домену. Бэкенд BIND9_DLZ использует кеш Bind для рекурсивных запросов. Запросы на сам домен каждый раз передаются модулю DLZ, кеша на этом уровне у него нет.

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

необходимость условной пересылки DNS-запросов. Если не требуется — можно использовать встроенный сервер имен (SAMBA_INTERNAL). Если требуется и при этом нежелательно использовать выделенный DNS-сервер — DNS-сервер на основе BIND 9;
уже имеющаяся инфраструктура. В случае, если уже есть настроенные DNS-серверы, на которые могут быть возложены функции перенаправления, можно использовать выделенный DNS-сервер на основе BIND 9.

Важно

Бэкенд DNS BIND9_FLATFILE не поддерживается.

⁠2.2.1. Параметры команды разворачивания домена

Команда samba-tool domain provision имеет множество опций, которые можно использовать для предоставления дополнительной информации при установке сервера. Эти опции также можно использовать в скриптах.

Ниже описаны некоторые опции. Для получения более подробной информации следует обратиться к man странице samba-tool(8).

⁠

Таблица 2.2. Основные опции для samba-tool domain provision

Опция	Описание
-d DEBUGLEVEL, --debuglevel=DEBUGLEVEL	Включить отладку
--interactive	Запрашивать ввод данных у пользователя (интерактивное создание домена)
--domain=DOMAIN	Имя домена NetBIOS (имя рабочей группы)
--domain-guid=GUID	Установить domainguid (иначе используется случайное значение)
--domain-sid=SID	Установить domainsid (иначе используется случайное значение)
--ntds-guid=GUID	Установить GUID объекта NTDS (иначе используется случайное значение)
--host-name=HOSTNAME	Установить имя хоста
--host-ip=IPADDRESS	Установить IPv4 IP-адрес
--host-ip6=IP6ADDRESS	Установить IPv6 IP-адрес
--adminpass=PASSWORD	Пароль основного администратора домена (иначе используется случайное значение)
--krbtgtpass=PASSWORD	Пароль krbtgtpass (иначе используется случайное значение)
--dns-backend=NAMESERVER-BACKEND	Бэкенд DNS-сервера: SAMBA_INTERNAL — встроенный сервер имен (по умолчанию), BIND9_FLATFILE — использует текстовую базу данных bind9 для хранения информации о зоне, BIND9_DLZ — использует Samba AD для хранения информации о зоне, NONE — полностью пропускает настройку DNS (не рекомендуется).
--dnspass=PASSWORD	Пароль dns (иначе используется случайное значение)
--server-role=ROLE	Позволяет указать тип серверной роли: domain controller, dc (по умолчанию), member server, member или standalone
--function-level=FOR-FUN-LEVEL	Позволяет указать уровень домена и леса: 2000, 2003, 2008, 2008_R2 (по умолчанию) или 2016
--base-schema=BASE-SCHEMA	Версия базовой схемы домена. По умолчанию 2019
--use-rfc2307	Позволяет поддерживать расширенные атрибуты типа UID и GID в схеме LDAP и ACL на файловой системе Linux
--machinepass=PASSWORD	Пароль для машины (иначе используется случайное значение)
--plaintext-secrets	Сохранять конфиденциальные данные в виде обычного текста на диске (по умолчанию конфиденциальные данные шифруются)
--realm=REALM	Задаёт область Kerberos (LDAP), и DNS имя домена
--option=OPTION	Позволяет установить параметры `smb.conf` из командной строки
-s FILE, --configfile=FILE	Позволяет указать файл конфигурации

⁠2.2.2. Настройка NTP-сервера

Настроить сервер времени chrony в качестве NTP-сервера:

Установить пакет chrony:
```
# apt-get install chrony
```
Включить доступ к серверу chrony:
```
# control chrony server
```
Установить синхронизацию с российским пулом NTP:
```
# sed -i -r 's/^(pool.*)/#\1\npool ru.pool.ntp.org iburst/' /etc/chrony.conf
```
или указать серверы NTP в директиве server или pool в файле конфигурации NTP /etc/chrony.conf:
```
pool pool.ntp.org iburst
```
Примечание
Параметр iburst используется для ускорения начальной синхронизации.
Запустить и включить автоматический запуск для службы chronyd:
```
# systemctl enable --now chronyd
```
Убедиться в нормальной работе NTP-сервера:
```
# systemctl status chronyd.service
```

⁠2.2.3. Установка имени контроллера домена

Для сервера, на котором будет разворачиваться контроллер домена, должен быть назначен статический IP-адрес и установлено правильное имя узла.

Для установки имени узла и домена следует выполнить команды:

# hostnamectl set-hostname <имя узла>
# domainname <имя домена>

Например:

# hostnamectl set-hostname dc1.test.alt
# domainname test.alt

Примечание

В системах, в которых управление сетью осуществляется через etcnet и используется SysVinit вместо systemd, полное доменное имя (FQDN) необходимо указать в в файл /etc/sysconfig/network:

HOSTNAME=dc1.test.alt

Во все остальных случаях параметр HOSTNAME игнорируется.

Примечание

После изменения имени компьютера могут перестать запускаться приложения. Для решения этой проблемы необходимо перезагрузить систему.

⁠2.2.4. Установка пакетов

Samba поддерживает две реализации Kerberos — Heimdal и MIT.

Установить пакет task-samba-dc для Samba DC на базе Heimdal Kerberos:

# apt-get install task-samba-dc

или task-samba-dc-mitkrb5 для Samba DC на базе MIT Kerberos:

# apt-get install task-samba-dc-mitkrb5

Примечание

Samba на базе Heimdal Kerberos использует KDC несовместимый с MIT Kerberos, поэтому на контроллере домена на базе Heimdal Kerberos из пакета samba-dc, для совместимости с клиентской библиотекой libkrb5, в krb5.conf (в блоке — libdefaults) необходимо отключить использование ядерного кеша ключей — KEYRING:persistent:%{uid}:

# control krb5-conf-ccache default

Так как Samba в режиме контроллера домена (Domain Controller, DC) использует свой сервер LDAP, свой центр распределения ключей Kerberos и свой сервер DNS (если не включен плагин BIND9_DLZ), перед установкой необходимо остановить конфликтующие службы krb5kdc и slapd, а также bind:

# for service in smb nmb krb5kdc slapd bind; do systemctl disable $service; systemctl stop $service; done

Примечание

Выключить автозагрузку служб и отключить службы можно в ЦУС (Система → Системные службы).

⁠2.2.5. Внутренний DNS-сервер Samba (SAMBA_INTERNAL)

Контроллер домена (DC) Samba Active Directory (AD) предоставляет внутренний DNS-сервер, который поддерживает основные функции, необходимые для AD. Он прост в настройке и не требует дополнительного программного обеспечения или знаний о DNS. Создание домена с внутренним DNS-сервером рекомендуется для простых настроек DNS.

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

нельзя использовать как кеширующий сервер;
не поддерживает рекурсивные запросы;
не поддерживает подпись транзакции с общим ключом (TSIG) (shared-key transaction signature);
нет зоны-заглушки (stub zones);
не поддерживает zone transfers;
не поддерживает балансировку нагрузки циклического перебора между контроллерами домена (Round Robin load balancing among DC's).

Внутренний DNS-сервер может разрешать только DNS-зоны Active Directory (AD). Чтобы включить рекурсивные запросы других зон, следует в параметре dns forwarder в файле smb.conf указать один или несколько IP-адресов DNS-серверов, поддерживающих рекурсивное разрешение. Например:

dns forwarder = 192.168.0.190

Примечание

Samba 4.5 и более поздние версии в параметре dns forwarder поддерживают несколько IP-адресов, разделенных пробелами. Старые версии поддерживают один IP-адрес. Обращение ко второму и последующим DNS-серверам произойдёт только в том случае, если первый не вернул никакого ответа.

Примечание

Внешний DNS-сервер можно указать при создании домена.

При создании домена с внутренним DNS-сервером нужно использовать параметр --dns-backend=SAMBA_INTERNAL или не указывать этот параметр вообще.

⁠2.2.5.1. Настройка файла /etc/resolvconf.conf

Для корректного распознавания всех локальных DNS-запросов в файле /etc/resolvconf.conf должна присутствовать строка:

name_servers=127.0.0.1

Если этой строки в файле /etc/resolvconf.conf нет, то в конец этого файла следует добавить строку:

name_servers=127.0.0.1

и перезапустить сервис resolvconf:

# resolvconf -u

⁠2.2.5.2. Восстановление к начальному состоянию Samba

Необходимо очистить базы и конфигурацию Samba (домен, если он создавался до этого, будет удалён):

# rm -f /etc/samba/smb.conf
# rm -rf /var/lib/samba
# rm -rf /var/cache/samba
# mkdir -p /var/lib/samba/sysvol

Предупреждение

Перед созданием домена необходимо обязательно удалить /etc/samba/smb.conf: rm -f /etc/samba/smb.conf

⁠2.2.5.3. Интерактивное создание домена

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

# samba-tool domain provision

В ответе на первые два вопроса нужно указать доменное имя и имя рабочей группы:

Realm [TEST.ALT]:
Domain [TEST]:

Примечание

Чтобы принять значение по умолчанию, необходимо нажать Enter.

Далее нужно указать тип серверной роли и бэкенд DNS-сервера:

Server Role (dc, member, standalone) [dc]:
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]:

При запросе DNS forwarder IP address можно указать внешний DNS-сервер, чтобы DC мог разрешать внешние доменные имена:

DNS forwarder IP address (write 'none' to disable forwarding) [127.0.0.1]:  8.8.8.8

Задать пароль для администратора:

Administrator password:
Retype password:

Примечание

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

Начнется процесс конфигурации:

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
Adding DomainDN: DC=test,DC=alt
Adding configuration container
Setting up sam.ldb schema
Setting up sam.ldb configuration data
Setting up display specifiers
Modifying display specifiers and extended rights
Adding users container
Modifying users container
Adding computers container
Modifying computers container
Setting up sam.ldb data
Setting up well known security principals
Setting up sam.ldb users and groups
Setting up self join
Adding DNS accounts
Creating CN=MicrosoftDNS,CN=System,DC=test,DC=alt
Creating DomainDnsZones and ForestDnsZones partitions
Populating DomainDnsZones and ForestDnsZones partitions
Setting up sam.ldb rootDSE marking as synchronized
Fixing provision GUIDs
The Kerberos KDC configuration for Samba AD is located at /var/lib/samba/private/kdc.conf
A Kerberos configuration suitable for Samba AD has been generated at /var/lib/samba/private/krb5.conf
Merge the contents of this file with your system krb5.conf or replace it with this one. Do not create a symlink!
Once the above files are installed, your Samba AD server will be ready to use
Server Role:           active directory domain controller
Hostname:              dc1
NetBIOS Domain:        TEST
DNS Domain:            test.alt
DOMAIN SID:            S-1-5-21-3617232745-2316959539-2936900449

⁠2.2.5.4. В пакетном режиме

Пример команды создания контроллера домена test.alt в пакетном режиме:

# samba-tool domain provision --realm=test.alt --domain=test \
--adminpass='Pa$$word' --dns-backend=SAMBA_INTERNAL \
--option="dns forwarder=8.8.8.8" \
--server-role=dc --use-rfc2307

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

--realm REALM_NAME — имя области Kerberos (LDAP) и DNS имя домена;
--domain=DOMAIN — имя домена (имя рабочей группы);
--adminpass=PASSWORD — пароль основного администратора домена;
dns forwarder=forwarder_ip_address — внешний DNS-сервер, чтобы DC мог разрешать внешние доменные имена;
--server-role=ROLE — тип серверной роли;
--dns-backend=NAMESERVER-BACKEND — бэкенд DNS-сервера;
--use-rfc2307 — позволяет поддерживать расширенные атрибуты типа UID и GID в схеме LDAP и ACL на файловой системе Linux.

Примечание

Если уровень не указан, то домен разворачивается на уровне 2008_R2. Для разворачивания домена на другом уровне, уровень необходимо явно указать, например:

# samba-tool domain provision --realm=test.alt --domain=test \
--adminpass='Pa$$word' --dns-backend=SAMBA_INTERNAL \
--option="dns forwarder=8.8.8.8" --option="ad dc functional level = 2016" \
--server-role=dc --function-level=2016

Примечание

Если необходим уровень 2012_R2, то следует сначала развернуть домен на уровне 2008_R2, а затем повысить его до 2012_R2 (см. Повышение уровня схемы, функционального уровня домена).

Примечание

Некоторые параметры команды samba-tool domain provision приведены в в табл. Основные опции для samba-tool domain provision. Полный список параметров можно увидеть, запустив команду:

# samba-tool domain provision --help

⁠2.2.5.5. Создание домена в ЦУС

При инициализации домена в веб-интерфейсе Центра управления системой (см. ЦУС) следует выполнить следующие действия:

В модуле Ethernet-интерфейсы указать имя компьютера и DNS 127.0.0.1:
В модуле Домен указать имя домена, отметить пункт Active Directory, указать IP-адреса внешних DNS-серверов, задать пароль администратора домена и нажать кнопку Применить:

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

⁠2.2.5.6. Запуск службы каталогов

Установить службу по умолчанию и запустить её:

# systemctl enable --now samba

Примечание

Если служба после установки никаким способом не запускается, необходимо перезагрузить сервер.

Примечание

Пример файла /etc/samba/smb.conf после создания домена с SAMBA_INTERNAL:

 Global parameters
[global]
        dns forwarder = 8.8.8.8
        netbios name = DC1
        realm = TEST.ALT
        server role = active directory domain controller
        workgroup = TEST
        idmap_ldb:use rfc2307 = yes

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

[netlogon]
        path = /var/lib/samba/sysvol/test.alt/scripts
        read only = No

⁠2.2.6. Домен с BIND9_DLZ

В состав Samba входит модуль BIND9_DLZ, позволяющий использовать в качестве DNS-сервера решение с открытым исходным кодом BIND 9.

BIND 9 представляет собой полнофункциональную реализацию протокола DNS, включающую поддержку DNSSEC, DNS over HTTPS (DoH) и DNS over TLS (DoT).

Служба DNS может разворачиваться как на отдельном сервере, так и на контроллере домена совместно с Samba.

Работа с внешним сервером DNS осуществляется с помощью бэкенда BIND9_DLZ и используется в следующих случаях:

сложная схема зон DNS;
поддержка более одного сервера форвардинга (параметр dns forwarder на бэкенде SAMBA_INTERNAL работает только с одним адресом).

Если планируется настроить контроллер домена Samba AD с использованием серверной части BIND9_DLZ, необходимо сначала установить и настроить DNS-сервер BIND.

⁠2.2.6.1. Настройка DNS-сервера BIND

На сервере должны быть установлены пакеты bind и bind-utils:

# apt-get install bind bind-utils

Примечание

Пакет bind содержит различные утилиты, связанные с DNS, например:

named-checkconf — проверка синтаксиса файлов конфигурации;
named-checkzone — проверка файлов зон DNS;
rndc — инструмент управления службой DNS.

Пакет bind-utils содержит следующие утилиты:

dig — многофункциональный инструмент для опроса DNS-серверов;
host — позволяет получить информацию о DNS-связях между доменными именами и IP-адресами;
nslookup — позволяет получить информацию DNS об удаленном сервере;
nsupdate — инструмент для динамического обновления записей DNS.

Примечание

Основные файлы настройки DNS и некоторые параметры конфигурационного файла bind описаны в разделе Bind. Для получения более подробной информации следует обратиться к man странице named.conf(5).

⁠ Настройка BIND9 для работы с Samba AD:

Отключить chroot:
```
# control bind-chroot disabled
```

Отключить KRB5RCACHETYPE:

# grep -q KRB5RCACHETYPE /etc/sysconfig/bind || echo 'KRB5RCACHETYPE="none"' >> /etc/sysconfig/bind

Подключить плагин BIND_DLZ:

# grep -q 'bind-dns' /etc/bind/named.conf || echo 'include "/var/lib/samba/bind-dns/named.conf";' >> /etc/bind/named.conf

Отредактировать файл /etc/bind/options.conf:
- в раздел options добавить строки:
  tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab"; minimal-responses yes;
- в параметре forwarders указать сервера, куда будут перенаправляться запросы, на которые нет информации в локальной зоне (если этой информации нет в файле /etc/bind/resolvconf-options.conf):
  forward first; forwarders { 8.8.8.8; };
- в параметр listen-on добавить IP-адрес DNS-сервера, на котором он будет принимать запросы;
- раскомментировать параметр allow-query и указать в нём подсети, из которых разрешено подавать запросы;
- раскомментировать параметр allow-recursion и указать в нём подсети, из которых будут обрабатываться рекурсивные запросы;
- в раздел logging добавить строку:
  category lame-servers {null;};
Пример файла /etc/bind/options.conf:
```
options {
        version "unknown";
        directory "/etc/bind/zone";
        dump-file "/var/run/named_dump.db";
        statistics-file "/var/run/named.stats";
        recursing-file "/var/run/recursing";


        // disables the use of a PID file
        pid-file none;
        tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab";
        minimal-responses yes;

        listen-on { 127.0.0.1; 192.168.0.122; };
        listen-on-v6 { ::1; };

        include "/etc/bind/resolvconf-options.conf";

        allow-query { localnets; 192.168.0.0/24; };
        allow-recursion { localnets; 192.168.0.0/24; };

        //max-cache-ttl 86400;

};

logging {
        category lame-servers {null;};
};
```
В файле /etc/bind/resolvconf-options.conf в параметре forwarders должен быть указан DNS-сервер, на который будут перенаправляться запросы клиентов;
Выполнить остановку bind:
```
# systemctl stop bind
```

Если в роли DNS-сервера Samba используется Bind, то при создании домена нужно использовать параметр --dns-backend=BIND9_DLZ.

⁠2.2.6.2. Восстановление к начальному состоянию Samba

Необходимо очистить базы и конфигурацию Samba (домен, если он создавался до этого, будет удалён):

# rm -f /etc/samba/smb.conf
# rm -rf /var/lib/samba
# rm -rf /var/cache/samba
# mkdir -p /var/lib/samba/sysvol

Предупреждение

Перед созданием домена необходимо обязательно удалить /etc/samba/smb.conf: rm -f /etc/samba/smb.conf

⁠2.2.6.3. Интерактивное создание домена

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

# samba-tool domain provision

В ответе на первые два вопроса нужно указать доменное имя и имя рабочей группы:

Realm [TEST.ALT]:
Domain [TEST]:

Примечание

Чтобы принять значение по умолчанию, необходимо нажать Enter.

Далее нужно указать тип серверной роли и бэкенд DNS-сервера:

Server Role (dc, member, standalone) [dc]:
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: BIND9_DLZ

Задать пароль для администратора:

Administrator password:
Retype password:

Примечание

Начнётся процесс конфигурации:

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
Adding DomainDN: DC=test,DC=alt
Adding configuration container
Setting up sam.ldb schema
Setting up sam.ldb configuration data
Setting up display specifiers
Modifying display specifiers and extended rights
Adding users container
Modifying users container
Adding computers container
Modifying computers container
Setting up sam.ldb data
Setting up well known security principals
Setting up sam.ldb users and groups
Setting up self join
Adding DNS accounts
Creating CN=MicrosoftDNS,CN=System,DC=test,DC=alt
Creating DomainDnsZones and ForestDnsZones partitions
Populating DomainDnsZones and ForestDnsZones partitions
See /var/lib/samba/bind-dns/named.conf for an example configuration include file for BIND
and /var/lib/samba/bind-dns/named.txt for further documentation required for secure DNS updates
Setting up sam.ldb rootDSE marking as synchronized
Fixing provision GUIDs
The Kerberos KDC configuration for Samba AD is located at /var/lib/samba/private/kdc.conf
A Kerberos configuration suitable for Samba AD has been generated at /var/lib/samba/private/krb5.conf
Merge the contents of this file with your system krb5.conf or replace it with this one. Do not create a symlink!
Once the above files are installed, your Samba AD server will be ready to use
Server Role:           active directory domain controller
Hostname:              dc1
NetBIOS Domain:        TEST
DNS Domain:            test.alt
DOMAIN SID:            S-1-5-21-3684382553-2825304832-3399765044

⁠2.2.6.4. В пакетном режиме

Пример команды создания контроллера домена test.alt в пакетном режиме:

# samba-tool domain provision --realm=test.alt --domain test --adminpass='Pa$$word' --dns-backend=BIND9_DLZ --server-role=dc

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

--realm REALM_NAME — имя области Kerberos (LDAP) и DNS имя домена;
--domain=DOMAIN — имя домена (имя рабочей группы);
--adminpass=PASSWORD — пароль основного администратора домена;
--server-role=ROLE — тип серверной роли;
--dns-backend=NAMESERVER-BACKEND — бэкенд DNS-сервера;
--use-rfc2307 — позволяет поддерживать расширенные атрибуты типа UID и GID в схеме LDAP и ACL на файловой системе Linux.

Примечание

# samba-tool domain provision --realm=test.alt --domain=test --adminpass='Pa$$word' --dns-backend=BIND9_DLZ --option="ad dc functional level = 2016" --server-role=dc --function-level=2016

Примечание

# samba-tool domain provision --help

⁠2.2.6.5. Запуск служб samba и bind

Установить службы samba и bind по умолчанию и запустить их:

# systemctl enable --now samba
# systemctl enable --now bind

Примечание

Если служба samba после установки никаким способом не запускается, необходимо перезагрузить сервер.

Примечание

Пример файла /etc/samba/smb.conf после создания домена с BIND9_DLZ:

# Global parameters
[global]
        netbios name = DC1
        realm = TEST.ALT
        server role = active directory domain controller
        server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
        workgroup = TEST

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

[netlogon]
        path = /var/lib/samba/sysvol/test.alt/scripts
        read only = No

⁠2.2.6.6. Проверка зон

Следующие примеры запрашивают службу DNS о локальном хосте (127.0.0.1).

Проверка зоны перенаправления localhost:

# host -t A localhost 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
localhost has address 127.0.0.1

Проверка реверсивной зоны 0.0.127.in-addr.arpa.:

# host -t PTR 127.0.0.1 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
1.0.0.127.in-addr.arpa domain name pointer localhost.

⁠2.3. Настройка Kerberos

Внести изменения в файл /etc/krb5.conf. В файле следует раскомментировать строку default_realm и содержимое разделов realms и domain_realm и указать название домена (следует обратить внимание на регистр символов), в строке dns_lookup_realm должно быть установлено значение false:

includedir /etc/krb5.conf.d/

[logging]
# default = FILE:/var/log/krb5libs.log
# kdc = FILE:/var/log/krb5kdc.log
# admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_kdc = true
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = TEST.ALT
# default_ccache_name = KEYRING:persistent:%{uid}

[realms]
TEST.ALT = {
default_domain = test.alt
}

[domain_realm]
dc = TEST.ALT

Примечание

В момент создания домена Samba конфигурирует шаблон файла krb5.conf для домена в каталоге /var/lib/samba/private/. Можно просто заменить этим файлом файл, находящийся в каталоге /etc/:

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

⁠2.4. Проверка работоспособности домена

Просмотр общей информации о домене:

# samba-tool domain info 127.0.0.1
Forest           : test.alt
Domain           : test.alt
Netbios domain   : TEST
DC name          : dc1.test.alt
DC netbios name  : DC1
Server site      : Default-First-Site-Name
Client site      : Default-First-Site-Name

Просмотр предоставляемых служб:

# smbclient -L localhost -Uadministrator
Password for [TEST\administrator]:

    Sharename       Type      Comment
    ---------       ----      -------
    sysvol          Disk
    netlogon        Disk
    IPC$            IPC       IPC Service (Samba 4.19.6)
SMB1 disabled -- no workgroup available

Создаваемые по умолчанию общие ресурсы netlogon и sysvol нужны для функционирования сервера AD и создаются в smb.conf в процессе развертывания/модернизации.

Проверка конфигурации DNS:

Проверка наличия nameserver 127.0.0.1 в /etc/resolv.conf:

# cat /etc/resolv.conf
# Generated by resolvconf
# Do not edit manually, use
# /etc/net/ifaces/<interface>/resolv.conf instead.
search test.alt
nameserver 127.0.0.1

# host test.alt
test.alt has address 192.168.0.122

Проверка имён хостов:
- адрес _kerberos._udp.*адрес домена с точкой:
  # host -t SRV _kerberos._udp.test.alt. _kerberos._udp.test.alt has SRV record 0 100 88 dc1.test.alt.
- адрес _ldap._tcp.*адрес домена с точкой:
  # host -t SRV _ldap._tcp.test.alt. _ldap._tcp.test.alt has SRV record 0 100 389 dc1.test.alt.
- адрес адрес хоста.*адрес домена с точкой:
  # host -t A dc1.test.alt. dc1.test.alt has address 192.168.0.122
Если имена не находятся, следует проверить выключение службы bind (если не включен плагин BIND9_DLZ).

Проверка Kerberos (имя домена должно быть в верхнем регистре):

# kinit administrator@TEST.ALT
Password for administrator@TEST.ALT:
Warning: Your password will expire in 15 days on Пт 12 апр 2024 11:46:29

Просмотр полученного билета:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@TEST.ALT

Valid starting       Expires              Service principal
27.03.2024 14:14:36  28.03.2024 00:14:36  krbtgt/TEST.ALT@TEST.ALT
	renew until 28.03.2024 14:14:32

⁠2.5. Присоединение к домену в роли контроллера домена

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

Системные требования к дополнительному DC такие же, как и для первого DC (см. Системные требования к контроллеру домена Samba AD).

Примечание

В терминологии контроллеров домена нет понятия PDC/BDC, т.е. все контроллеры равны, но один из них выступает владельцем ролей FSMO (см. Просмотр и передача ролей FSMO).

На дополнительном домене необходимо настроить NTP для работы в режиме сервер (см. Настройка NTP-сервера).

Заведение дополнительного контроллера домена выполняется путём присоединения дополнительного DC к существующему домену.

Команда присоединения к домену в роли контроллера домена:

# samba-tool domain join <dnsdomain> [DC|RODC|MEMBER] [options]

Некоторые параметры, используемые в команде samba-tool domain join:

--realm REALM_NAME — имя области Kerberos (LDAP), и DNS имя домена;
--dns-backend=NAMESERVER-BACKEND — бэкенд DNS-сервера: SAMBA_INTERNAL — встроенный сервер имен (по умолчанию), BIND9_DLZ — использует Samba AD для хранения информации о зоне, NONE — полностью пропускает настройку DNS (этот DC не будет DNS-сервером);
Примечание
На втором DC необходимо иметь DNS-бэкенд аналогичный первому DC.
Примечание
При использовании SAMBA_INTERNAL, необходимо указать значение dns forwarder, чтобы на новом сервере была настроена пересылка запросов:
```
--option="dns forwarder=forwarder_ip_address"
```
Форвардером может быть как вышестоящий DNS-сервер организации, так и публичные от google или yandex, например:
```
--option="dns forwarder=8.8.8.8"
```
--option='idmap_ldb:use rfc2307 = yes' — если первый контроллер домена создавался с ключом --rfc2307, то и для текущего необходимо это учесть, указав данный параметр;
--site=SITE — привязка контроллера домена к определенному сайту AD;
--option="interfaces= lo eth0" --option="bind interfaces only=yes" — привязка Samba к указанным сетевым интерфейсам сервера (если их несколько); указание данной опции позволяет samba-tool зарегистрировать корректный IP-адрес при присоединении;
--option="ad dc functional level = LEVEL" — функциональный уровень AD. Возможные значения: 2008_R2 (по умолчанию), 2012, 2012_R2.
Примечание
При присоединении к существующему домену рекомендуется указывать функциональный уровень не выше текущего уровня домена.

Примечание

Для получения дополнительной информации о параметрах команды samba-tool domain join можно воспользоваться командой:

# samba-tool domain join --help

⁠

Таблица 2.3. Параметры контроллеров домена

	IP-адрес	Полное доменное имя (FQDN)
Существующий DC	192.168.0.122	dc1.test.alt
Добавляемый DC	192.168.0.123	dc2.test.alt

Установить имя узла можно, выполнив команду:

# hostnamectl set-hostname dc2.test.alt

Примечание

⁠2.5.1. Заведение дополнительного контроллера домена c бэкендом SAMBA_INTERNAL

Все действия, указанные ниже, выполняются на узле dc2.test.alt (192.168.0.123), если не указано иное.

Примечание

Для выполнения операции присоединения к домену требуется пароль администратора домена.

Этапы настройки сервера и присоединения к домену в роли контроллера домена:

Установить пакет task-samba-dc, который установит все необходимое:
```
# apt-get install task-samba-dc
```

На добавляемом DC в /etc/resolv.conf обязательно должен быть добавлен первый DC как nameserver:

# echo "name_servers=192.168.0.122" >> /etc/resolvconf.conf
# echo "search_domains=test.alt" >> /etc/resolvconf.conf
# resolvconf -u
# cat /etc/resolv.conf
search test.alt
nameserver 192.168.0.122
nameserver 8.8.8.8

Остановить конфликтующие службы krb5kdc и slapd, а также bind:

# for service in smb nmb krb5kdc slapd bind; do systemctl disable $service; systemctl stop $service; done

Очистить базы и конфигурацию Samba (домен, если он создавался до этого, будет удалён):
```
# rm -f /etc/samba/smb.conf
# rm -rf /var/lib/samba
# rm -rf /var/cache/samba
# mkdir -p /var/lib/samba/sysvol
```
На существующем контроллере домена завести IP-адрес для нового DC (команда выполняется на узле dc1.test.alt):
```
# samba-tool dns add 192.168.0.122 test.alt DC2 A 192.168.0.123 -Uadministrator
Password for [TEST\administrator]:
Record added successfully
```
Предупреждение
Указание аутентифицирующей информации (имени пользователя и пароля) обязательно!
Примечание
Синтаксис команды samba-tool dns add см. в разделе Администрирование DNS
На новом контроллере домена установить следующие параметры в файле конфигурации клиента Kerberos (/etc/krb5.conf):
```
[libdefaults]
default_realm = TEST.ALT
dns_lookup_realm = false
dns_lookup_kdc = true
```

Запросить билет Kerberos администратора домена:

# kinit administrator@TEST.ALT
Password for administrator@TEST.ALT:

Предупреждение

Имя домена должно быть указано в верхнем регистре.

Убедиться, что билет получен:

# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: administrator@TEST.ALT

Valid starting       Expires              Service principal
27.03.2024 14:14:36  28.03.2024 00:14:36  krbtgt/TEST.ALT@TEST.ALT
	renew until 28.03.2024 14:14:32

Ввести дополнительный DC в домен test.alt в качестве контроллера домена:
```
# samba-tool domain join test.alt DC -Uadministrator \
--realm=test.alt --option="dns forwarder=8.8.8.8"
```
Если всё нормально, в конце будет выведена информация о присоединении к домену:
```
Joined domain TEST (SID S-1-5-21-80639820-2350372464-3293631772) as a DC
```
Установить службу samba запускаемой по умолчанию и запустить её:
```
# systemctl enable --now samba
```

⁠2.5.2. Заведение дополнительного контроллера домена c бэкендом BIND9_DLZ

Все действия, указанные ниже, выполняются на узле dc2.test.alt (192.168.0.123), если не указано иное.

Примечание

Для выполнения операции присоединения к домену требуется пароль администратора домена.

Этапы настройки сервера и присоединения к домену в роли контроллера домена:

Установить пакет task-samba-dc, который установит все необходимое:
```
# apt-get install task-samba-dc
```
Установить и настроить DNS-сервер BIND (см. Настройка BIND9 для работы с Samba AD);

На добавляемом DC в /etc/resolv.conf обязательно должен быть добавлен первый DC как nameserver:

# echo "name_servers=192.168.0.122" >> /etc/resolvconf.conf
# echo "search_domains=test.alt" >> /etc/resolvconf.conf
# resolvconf -u
# cat /etc/resolv.conf
search test.alt
nameserver 192.168.0.122
nameserver 8.8.8.8

Остановить конфликтующие службы krb5kdc и slapd, а также bind:

# for service in smb nmb krb5kdc slapd bind; do systemctl disable $service; systemctl stop $service; done

Очистить базы и конфигурацию Samba (домен, если он создавался до этого, будет удалён):
```
# rm -f /etc/samba/smb.conf
# rm -rf /var/lib/samba
# rm -rf /var/cache/samba
# mkdir -p /var/lib/samba/sysvol
```
На существующем контроллере домена завести IP-адрес для нового DC (команда выполняется на узле dc1.test.alt):
```
# samba-tool dns add 192.168.0.122 test.alt DC2 A 192.168.0.123 -Uadministrator
Password for [TEST\administrator]:
Record added successfully
```
Предупреждение
Указание аутентифицирующей информации (имени пользователя и пароля) обязательно!

Примечание
Синтаксис команды samba-tool dns add см. в разделе Администрирование DNS
На новом контроллере домена установить следующие параметры в файле конфигурации клиента Kerberos (/etc/krb5.conf):
```
[libdefaults]
default_realm = TEST.ALT
dns_lookup_realm = false
dns_lookup_kdc = true
```

Запросить билет Kerberos администратора домена:

# kinit administrator@TEST.ALT
Password for administrator@TEST.ALT:

Предупреждение

Имя домена должно быть указано в верхнем регистре.

Убедиться, что билет получен:

# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: administrator@TEST.ALT

Valid starting       Expires              Service principal
27.03.2024 14:14:36  28.03.2024 00:14:36  krbtgt/TEST.ALT@TEST.ALT
	renew until 28.03.2024 14:14:32

Ввести дополнительный DC в домен test.alt в качестве контроллера домена:
```
# samba-tool domain join test.alt DC -Uadministrator \
--realm=test.alt --dns-backend=BIND9_DLZ
```
Если всё нормально, в конце будет выведена информация о присоединении к домену:
```
Joined domain TEST (SID S-1-5-21-80639820-2350372464-3293631772) as a DC
```
Установить службы samba и bind по умолчанию и запустить их:
```
# systemctl enable --now samba
# systemctl enable --now bind
```

⁠2.5.3. Проверка результатов присоединения

Примечание

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

Проверка корректности присоединения:

Проверить работу DNS:
```
# host -t A test.alt
test.alt has address 192.168.0.122
test.alt has address 192.168.0.123
```
В списке адресов должен отображаться IP-адрес добавленного контроллера домена.
Проверить статус репликации между контроллерами домена. Для этого на добавленном DC выполнить команду:
```
# samba-tool drs showrepl --summary
```
В случае успешного выполнения репликации в каждом из блоков в разделах «INBOUND NEIGHBORS» и «OUTBOUND NEIGHBORS» отображаются сообщения вида:
```
Default-First-Site-Name\DC1 via RPC
    DSA object GUID: 10e22808-960e-4cb3-8724-abd2223555cd
    Last attempt @ Sat Jun 15 10:27:21 2024 EET was successful
    0 consecutive failure(s).
    Last success @ Sat Jun 15 10:27:21 2024 EET
```
В пункте Last attempt должны стоять актуальные дата и время, идентичные указанным в строке Last success (отображает время последней репликации). Также должно быть «0 consecutive failure(s)».
Подробнее о настройке репликации см. в разделе Репликация.
На добавленном DC создать нового пользователя домена:
```
# samba-tool user add testuser --random-password
User 'testuser' added successfully
```
Убедиться, что учетная запись созданного пользователя доступна на первом контроллере домена:
```
# samba-tool user list | grep testuser
testuser
```

⁠2.6. Контроллер домена на чтение (RODC)

При присоединении к домену для контроллера может быть выбрана роль RODC (read-only domain controller).

Основная цель контроллера домена, доступного только на чтение, — возможность безопасной установки собственного контроллера домена в удаленных филиалах, в которых сложно обеспечить физическую защиту сервера. Контроллер домена RODC содержит копию базы AD, доступную только на чтение. Это означает, что никто, даже при получении физического доступа к такому контроллеру домена, не сможет изменить данные в AD (в том числе сбросить пароль администратора домена).

Основные отличия RODC от обычных контроллеров домена, доступных для записи (RWDC):

RODC хранит копию базы AD, доступную только для чтения. Клиенты не могут вносить изменения в базу такого контроллера домена;
RODC не реплицирует данные AD на другие контроллеры домена (RWDC) (используется односторонняя репликация);
контроллер RODC хранит полную копию базы AD, за исключением хешей паролей объектов AD и других атрибутов, содержащих чувствительную информацию;
при получении контроллером RODC запроса на аутентификацию от пользователя, он перенаправляет этот запрос на ближайший RWDC контроллер;
контроллер RODC может кешировать учетные данные некоторых пользователей (это ускоряет аутентификацию и позволяет пользователям авторизоваться на контроллере домена, даже при отсутствии связи с RWDC);
DNS служба на RODС работает только на чтение.

Требования, которые должны быть выполнены для разворачивания RODС:

на сервере должен быть назначен статический IP-адрес;

уровень леса и домена должен соответствовать 2008R2. Это можно проверить, выполнив следующую команду на контроллере домена:

# samba-tool domain level show
Domain and forest function level for domain 'DC=test,DC=alt'

Forest function level: (Windows) 2008 R2
Domain function level: (Windows) 2008 R2
Lowest function level of a DC: (Windows) 2008 R2

в качестве DNS сервера должен быть указан ближайший RWDC контроллер.

⁠2.6.1. Установка и настройка RODC

⁠

Таблица 2.4. Параметры контроллеров домена

	IP-адрес	Полное доменное имя (FQDN)
Существующий RWDC	192.168.0.122	dc1.test.alt
Добавляемый RODC	192.168.0.124	rodc.test.alt

Установить имя узла можно, выполнив команду:

# hostnamectl set-hostname rodc.test.alt

Примечание

На добавляемом RODC в /etc/resolv.conf обязательно должен быть добавлен первый DC как nameserver:

# echo "name_servers=192.168.0.122" >> /etc/resolvconf.conf
# echo "search_domains=test.alt" >> /etc/resolvconf.conf
# resolvconf -u
# cat /etc/resolv.conf
search test.alt
nameserver 192.168.0.122
nameserver 8.8.8.8

Все дальнейшие действия выполняются на узле rodc.test.alt (192.168.0.124), если не указано иное.

Этапы настройки сервера и присоединения к домену в роли RODC:

Установить пакет task-samba-dc, который установит все необходимое:
```
# apt-get install task-samba-dc
```

На RODC в /etc/resolv.conf должен быть добавлен первый DC как nameserver:

# echo "name_servers=192.168.0.122" >> /etc/resolvconf.conf
# echo "search_domains=test.alt" >> /etc/resolvconf.conf
# resolvconf -u
# cat /etc/resolv.conf
search test.alt
nameserver 192.168.0.122
nameserver 8.8.8.8

Остановить конфликтующие службы krb5kdc и slapd, а также bind:

# for service in smb nmb krb5kdc slapd bind; do systemctl disable $service; systemctl stop $service; done

Очистить базы и конфигурацию Samba (домен, если он создавался до этого, будет удалён):
```
# rm -f /etc/samba/smb.conf
# rm -rf /var/lib/samba
# rm -rf /var/cache/samba
# mkdir -p /var/lib/samba/sysvol
```
На существующем контроллере домена завести IP-адрес для RODC (команда выполняется на узле dc1.test.alt):
```
# samba-tool dns add 192.168.0.122 test.alt RODC A 192.168.0.124 -Uadministrator
Password for [TEST\administrator]:
Record added successfully
```
Предупреждение
Указание аутентифицирующей информации (имени пользователя и пароля) обязательно!

Примечание
Синтаксис команды samba-tool dns add см. в разделе Администрирование DNS

На RODC установить следующие параметры в файле конфигурации клиента Kerberos (/etc/krb5.conf):

[libdefaults]
default_realm = TEST.ALT
dns_lookup_realm = false
dns_lookup_kdc = true

[realms]
TEST.ALT = {
kdc = rodc.test.alt
kdc = dc1.test.alt
default_domain = TEST.ALT
}

Для проверки настройки запросить билет Kerberos для администратора домена:
```
# kinit administrator@TEST.ALT
Password for administrator@TEST.ALT:
```
Предупреждение
Имя домена должно быть указано в верхнем регистре.

Убедиться, что билет получен:

# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: administrator@TEST.ALT

Valid starting       Expires              Service principal
27.03.2024 14:14:36  28.03.2024 00:14:36  krbtgt/TEST.ALT@TEST.ALT
	renew until 28.03.2024 14:14:32

Ввести данный DC в домен test.alt в качестве контроллера домена, доступного только для чтения (RODC):
```
# samba-tool domain join test.alt RODC -Uadministrator@TEST.ALT \
--realm=test.alt --option="dns forwarder=8.8.8.8"
```
Если всё нормально, в конце будет выведена информация о присоединении к домену:
```
Joined domain TEST (SID S-1-5-21-578923263-1107570656-1287136478) as an RODC
```
Примечание
При использовании SAMBA_INTERNAL, необходимо указать значение dns forwarder, чтобы на новом сервере была настроена пересылка запросов. Форвардером может быть как вышестоящий DNS-сервер организации, так и публичные от google или yandex, например:
```
--option="dns forwarder=8.8.8.8"
```
Если первый контроллер домена создавался с ключом --rfc2307, то и для текущего необходимо это учесть, указав параметр:
```
--option='idmap_ldb:use rfc2307 = yes'
```
Сделать службу samba запускаемой по умолчанию и запустить её:
```
# systemctl enable --now samba
```

Примечание

Для получения дополнительной информации о параметрах команды samba-tool domain join можно воспользоваться командой:

# samba-tool domain join --help

⁠2.6.2. Политики репликации и кеширования паролей на RODC

На RODC можно задать список пользователей, чьи хеши паролей можно или нельзя реплицировать на данный контроллер домена.

Примечание

Все пользователи в кеше RODC смогут аутентифицироваться на этом контроллере домена, даже если отсутствует связь с RWDC.

По умолчанию в домене создаются две новые глобальные группы:

Allowed RODC Password Replication Group
Denied RODC Password Replication Group

Первая группа по умолчанию пуста, а во второй содержатся административные группы безопасности, пароли пользователей которых нельзя реплицировать и кешировать на RODC. В группу Denied RODC Password Replication Group по умолчанию входят группы:

Cert Publishers
Domain Admins
Domain Controllers
Enterprise Admins
Group Policy Creator Owners
Read-only Domain Controllers
Schema Admins
учётная запись krbtgt

Участники группы Denied RODC Password Replication Group

Примечание

Список участников групп Denied RODC Password Replication Group и Allowed RODC Password Replication Group:

# samba-tool group listmembers "Denied RODC Password Replication Group"
Read-only Domain Controllers
Domain Admins
Enterprise Admins
Domain Controllers
Schema Admins
krbtgt
Group Policy Creator Owners
Cert Publishers
# samba-tool group listmembers "Allowed RODC Password Replication Group"

В группу Allowed RODC Password Replication Group обычно добавляются группы пользователей филиала, в котором находится RODC.

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

# samba-tool rodc preload (<SID>|<DN>|<accountname>)+ ... [опции]

Возможные опции:

--server — обычный контроллер домена, который будет выступать источником данных при репликации;
--file — имя файла со списком реплицируемых объектов, либо «-» для ввода списка через стандартный поток ввода (stdin);
--ignore-errors — игнорировать ошибки репликации при загрузке нескольких объектов.

Эта команда запускает процесс репликации данных указанных объектов с переданного в параметре --server контроллера домена. Для идентификации объектов могут использоваться идентификаторы безопасности (SID), DN или имена учетных записей SAM (samAccountName). Для передачи списка объектов может использоваться:

перечисление объектов списком через пробел;
файл (одна строка соответствует одному объекту);
stdin (одна строка соответствует одному объекту).

Примечание

Для получения дополнительной информации о параметрах команды samba-tool rodc preload можно воспользоваться командой:

# samba-tool rodc preload --help

⁠2.6.3. Проверка репликации пароля пользователя на сервере RODC

Тестирование репликации пароля пользователя на сервере RODC:

На обычном контроллере домена (в примере DC1) создать пользователя и добавить его в группу Allowed RODC Password Replication Group (пароли пользователей/групп, входящих в группу Allowed RODC Password Replication Group разрешено реплицировать на RODC). Например:
```
# samba-tool user add ivanov --given-name='Иван' \
--surname='Иванов' --mail-address='ivanov@test.alt'

New Password:
Retype Password:
User 'ivanov' added successfully

# samba-tool group addmembers "Allowed RODC Password Replication Group" ivanov

Added members to group Allowed RODC Password Replication Group
```

На RODC проверить возможность загрузки кеша пароля, выполнив команду:

# samba-tool rodc preload ivanov --server=dc1.test.alt

Replicating DN CN=Иван Иванов,CN=Users,DC=test,DC=alt
Exop on[CN=Иван Иванов,CN=Users,DC=test,DC=alt] objects[1] linked_values[0]

Пример получения билета при отсутствии связи с RWDC (пользователь ivanov есть в кеше RODC, а пользователь kim — нет):

$ kinit ivanov
Password for ivanov@TEST.ALT:

$ kinit kim
kinit: A service is not available that is required to process the request while getting initial credentials

⁠2.7. Редактирование существующего домена

⁠2.7.1. Повышение уровня схемы, функционального уровня домена

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

# samba-tool domain level show
Domain and forest function level for domain 'DC=test,DC=alt'

Forest function level: (Windows) 2008 R2
Domain function level: (Windows) 2008 R2
Lowest function level of a DC: (Windows) 2008 R2

Для повышения уровня домена необходимо выполнить следующие действия:

Указать функциональный уровень AD, который будет поддерживаться контроллером домена, в параметре ad dc functional level файла /etc/samba/smb.conf. Возможные значения:
- 2008_R2 — аналог функционального уровня Windows 2008 R2 (по умолчанию);
- 2012 — аналог функционального уровня Windows 2012;
- 2012_R2 — аналог функционального уровня Windows 2012 R2;
- 2016 — аналог функционального уровня Windows 2016.
Обновить схему домена, выполнив команду:
```
# samba-tool domain schemaupgrade --schema=<SCHEMA>
```
где SCHEMA — схема, до которой необходимо выполнить обновление (по умолчанию 2019).
Подготовить функциональный уровень домена, выполнив команду:
```
# samba-tool domain functionalprep --function-level=<FUNCTION_LEVEL>
```
где FUNCTION_LEVEL — функциональный уровень, к которому нужно подготовиться (по умолчанию 2016).
Указать функциональные уровни домена и леса, выполнив команду:
```
# samba-tool domain level raise --domain-level=<DOMAIN_LEVEL> --forest-level=<FOREST_LEVEL>
```
где:
- FOREST_LEVEL — уровень работы леса. (возможные значения: 2003, 2008, 2008_R2, 2012, 2012_R2, 2016);
- DOMAIN_LEVEL — уровень работы домена. (возможные значения: 2003, 2008, 2008_R2, 2012, 2012_R2, 2016).

Примечание

При установке значения параметра ad dc functional level в файле /etc/samba/smb.conf вручную, защита от несовпадения функций между контроллерами домена снижается. Поэтому на всех контроллерах домена должна использоваться одна и та же версия Samba, чтобы гарантировать, что поведение, наблюдаемое клиентом, будет одинаковым независимо от того, к какому контроллеру домена осуществляется соединение.

Пример повышения уровня домена до 2016:

в раздел [global] файла /etc/samba/smb.conf добавить строку:
```
ad dc functional level = 2016
```
перезагрузить службу samba:
```
# systemctl restart samba.service
```

обновить схему домена:

# samba-tool domain schemaupgrade --schema=2019

подготовить функциональный уровень домена:
```
# samba-tool domain functionalprep --function-level=2016
```

повысить функциональные уровни домена и леса до 2016:

# samba-tool domain level raise --domain-level=2016 --forest-level=2016
Domain function level changed!
Forest function level changed!
All changes applied successfully!

убедиться, что уровни домена и леса повышены:

# samba-tool domain level show
Domain and forest function level for domain 'DC=test,DC=alt'

Forest function level: (Windows) 2016
Domain function level: (Windows) 2016
Lowest function level of a DC: (Windows) 2016

⁠2.7.2. Включение RFC2307 после разворачивания домена

Примечание

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

Проверка того, что расширения NIS установлены в AD:

# ldbsearch -H /var/lib/samba/private/sam.ldb -s base -b CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,DC=test,DC=alt cn

# record 1
dn: CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,DC=test,DC=alt
cn: ypservers

# returned 1 records
# 1 entries
# 0 referrals

Если команда ldbsearch возвращает одну запись (returned 1 records), расширения NIS установлены и больше ничего делать не нужно.

Предупреждение

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

Для установки расширения NIS необходимо выполнить следующие действия:

Найти контроллер домена (DC) с ролью (FSMO) хозяина схемы:
```
# samba-tool fsmo show | grep SchemaMasterRole
SchemaMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
```
В выводе команды показано имя DC, которому принадлежит эта роль. Все дальнейшие дествия следует выполнять на этом DC.
Остановить службу samba:
```
# systemctl stop samba
```
Создать копию файла схемы ypServ30.ldif, например:
```
# cp /usr/share/samba/setup/ypServ30.ldif /tmp/
```
Заменить переменные в скопированном файле LDIF именем домена (DN), именем NetBIOS и доменом NIS вашей установки, например:
```
# sed -i -e 's/\${DOMAINDN}/DC=test,DC=alt/g' -e 's/\${NETBIOSNAME}/DC/g' -e 's/\${NISDOMAIN}/test/g' /tmp/ypServ30.ldif
```
Импортировать измененный файл LDIF в локальную базу данных Samba AD /var/lib/samba/private/sam.ldb:
```
# ldbmodify -H /var/lib/samba/private/sam.ldb /tmp/ypServ30.ldif --option="dsdb:schema update allowed"=true
```
В файл /etc/samba/smb.conf в секцию [global] добавить параметр:
```
idmap_ldb:use rfc2307 = yes
```
Запустить службу каталогов:
```
# systemctl start samba
```

AD реплицирует обновленную схему на все контроллеры домена в лесу.

⁠2.7.3. Изменение DNS бэкенда контроллера домена Active Directory

Samba позволяет переключаться между бэкендом SAMBA_INTERNAL и BIND9_DLZ на контроллере домена Active Directory без потери данных.

⁠2.7.3.1. Миграция с SAMBA_INTERNAL на BIND9_DLZ

Для переключения с SAMBA_INTERNAL на BIND9_DLZ на контроллере домена необходимо выполнить следующие шаги:

Установить и настроить DNS-сервер BIND (см. Настройка BIND9 для работы с Samba AD);
Остановить службу samba:
```
# systemctl stop samba
```

Выполнить миграцию:

# samba_upgradedns --dns-backend=BIND9_DLZ

Отключить модуль SAMBA_INTERNAL в файле /etc/samba/smb.conf:
- если в файле нет параметра server services, добавить в секцию global строку:
  server services = -dns
- если в секции global есть параметр server services, удалить опцию dns, например:
  server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate
Запустить службу bind и сделать её запускаемой по умолчанию:
```
# systemctl enable --now bind
```
Запустить службу samba:
```
# systemctl start samba
```

⁠2.7.3.2. Миграция с BIND9_DLZ на SAMBA_INTERNAL

Для переключения с BIND9_DLZ на SAMBA_INTERNAL на контроллере домена необходимо выполнить следующие шаги:

Остановить службу bind и убрать её из автозагрузки:
```
# systemctl disable --now bind
```
Остановить службу samba:
```
# systemctl stop samba
```

Выполнить миграцию:

# samba_upgradedns --dns-backend=SAMBA_INTERNAL

Отключить модуль BIND9_DLZ в файле /etc/samba/smb.conf:
- если в параметре server services есть только опция -dns, удалить этот параметр из файла (удалить всю строку):
  server services = -dns
- если в секции global есть параметр server services, добавить в него опцию dns, например:
  server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbindd, ntp_signd, kcc, dnsupdate, dns
Запустить службу samba:
```
# systemctl start samba
```

Примечание

Так как SAMBA_INTERNAL — это одна из настроек по умолчанию для параметра server services, удаление параметра server services включает все серверы по умолчанию, включая DNS-сервер.

⁠2.8. Отладочная информация

⁠2.8.1. Настройка уровня журналирования Samba

Дополнительные сведения см. в разделе Уровни журналирования.

⁠2.8.2. Управление процессами

Для проверки выполнения процессов Samba можно использовать утилиту ps:

# ps axf | grep -E "samba|smbd|winbindd"
…
3078 ?        S      0:00 /usr/sbin/samba --no-process-group
   3091 ?        S      0:00  \_ /usr/sbin/samba --no-process-group
   3092 ?        S      0:00  |   \_ /usr/sbin/samba --no-process-group
   3096 ?        S      0:00  |       \_ /usr/sbin/samba --no-process-group
   3101 ?        Ss     0:00  |           \_ /usr/sbin/smbd -D --option=server role check:inhibit=yes --foreground
   3138 ?        S      0:00  |               \_ /usr/sbin/smbd -D --option=server role check:inhibit=yes --foreground
   3139 ?        S      0:00  |               \_ /usr/sbin/smbd -D --option=server role check:inhibit=yes --foreground
   3149 ?        S      0:00  |               \_ /usr/sbin/smbd -D --option=server role check:inhibit=yes --foreground
   3150 ?        S      0:00  |               \_ /usr/sbin/smbd -D --option=server role check:inhibit=yes --foreground
…
   3127 ?        Ss     0:00  |           \_ /usr/sbin/winbindd -D --option=server role check:inhibit=yes --foreground
   3140 ?        S      0:00  |               \_ /usr/sbin/winbindd -D --option=server role check:inhibit=yes --foreground
…

Все процессы samba, smbd и winbindd должны быть дочерними процессами одного процесса samba.

Если структура процесса не отображается:

следует проверить файлы журнала Samba. Для подробного вывода можно увеличить уровень журнала (см. раздел Уровни журналирования);
можно запустить Samba в интерактивном режиме и посмотреть на результат:
```
# samba -i
```

⁠2.8.3. DNS

⁠2.8.3.1. Устранение неполадок, связанных с серверной частью DNS

⁠2.8.3.1.1. Внутренний DNS-сервер Samba (SAMBA_INTERNAL)

Если клиенты не могут разрешать записи из зоны DNS AD, необходимо убедиться, что на клиенте указан IP-адрес DNS-сервера, способного разрешать зону AD DNS.

Если конфигурация клиента правильная, следует убедиться, что DNS-сервер Samba работает.

Если DNS-сервер Samba не запускается, необходимо убедиться, что ни один другой процесс не использует TCP- и UDP-порт 53:

проверить файлы журнала Samba на наличие ошибок, связанных с DNS;
убедиться, что никакой другой процесс не прослушивает TCP- и UDP-порт 53, например:
```
# ss -tulpn | grep ":53"
```

Если порт 53 занят другим процессом, необходимо:

остановить службу, прослушивающую порт 53, и отключить её автоматический запуск во время загрузки;
перезапустить службу каталогов.

⁠2.8.3.1.2. Samba с BIND9_DLZ

Каталог /var/lib/samba/bind-dns создается только в том случае, если произошло одно из следующих трёх событий:

при создании контроллера домена использовался параметр --dns-backend=BIND9_DLZ;
при подключении к домену использовался параметр --dns-backend=BIND9_DLZ;
домен был обновлён до Bind9 с помощью команды samba_upgradedns и опции --dns-backend=BIND9_DLZ.

⁠2.9. Удаление контроллера домена

В некоторых ситуациях необходимо навсегда удалить контроллер домена из Active Directory. Если для обычного участника домена достаточно просто удалить соответствующую учётную запись, то чтобы удалить контроллер из домена требуется понизить его роль (demoting).

Если роль контроллера домена будет понижена неправильно, домен может стать нестабильным. Например:

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

⁠2.9.1. Понижение роли онлайн-контроллера домена

Если удаляемый контроллер домена всё ещё работает правильно, для понижения его роли необходимо выполнить следующие действия (в примере понижается роль DC3):

Авторизоваться на контроллере домена под локальным пользователем.

Убедиться, что контроллер не владеет никакими ролями FSMO:

# samba-tool fsmo show
SchemaMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
InfrastructureMasterRole owner: CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
RidAllocationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
DomainNamingMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
DomainDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
ForestDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt

Если контроллеру домена принадлежит одна или несколько ролей FSMO, передать их другому контроллеру домена (см. Просмотр и передача ролей FSMO).

Вывести objectGUID контроллера домена:
```
# ldbsearch -H /var/lib/samba/private/sam.ldb '(invocationId=*)' --cross-ncs objectguid | grep -A1 DC3
dn: CN=NTDS Settings,CN=DC3,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
objectGUID: 512f03b4-7042-434d-93c0-61dd6a2ea895
```
Для того чтобы убедиться, что все записи DNS были удалены после понижения роли контроллера домена, необходимо знать имя хоста, IP-адрес и objectGUID контроллера домена.

Понизить DC:

# samba-tool domain demote -Uadministrator
Using dc1.test.alt as partner server for the demotion
Password for [TEST\administrator]:
Deactivating inbound replication
Asking partner server dc1.test.alt to synchronize from us
Changing userControl and container
Removing Sysvol reference: CN=DC3,CN=Enterprise,CN=Microsoft System Volumes,CN=System,CN=Configuration,DC=test,DC=alt
Removing Sysvol reference: CN=DC3,CN=test.alt,CN=Microsoft System Volumes,CN=System,CN=Configuration,DC=test,DC=alt
Removing Sysvol reference: CN=DC3,CN=Domain System Volumes (SYSVOL share),CN=File Replication Service,CN=System,DC=test,DC=alt
Removing Sysvol reference: CN=DC3,CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=test,DC=alt
updating ForestDnsZones.test.alt keeping 2 values, removing 1 values
updating test.alt keeping 6 values, removing 1 values

…
Demote successful

Остановить службу каталогов:
```
# systemctl stop samba
```
Если этот контроллер работал как доменный сервер DNS:
- остановить службу DNS:
  # systemctl stop bind
- убедиться, что члены домена и контроллеры домена больше не используют этот хост для разрешения зон AD DNS.

⁠2.9.2. Понижение автономного контроллера домена

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

Важно

Эта процедура должна выполняться только в том случае, если контроллер домена, который нужно понизить, больше не подключен к AD, и его нельзя понизить так, как описано в разделе Понижение роли онлайн-контроллера домена. Это гарантирует, что все изменения (например, изменения паролей) будут реплицированы на другой контроллер домена. В противном случае такие изменения будут потеряны. Список изменений можно получить с помощью Samba-инструмента ldapcmp. При описанной ниже процедуре все изменения (например, изменения паролей) не будут реплицированы на работающий DC.

Важно

Нельзя понизить статус автономного удаленного контроллера домена с контроллера домена, на котором работает Samba 4.4 или более ранней версии.

Для понижения статуса неработающего контроллера домена необходимо выполнить следующие действия (в примере понижается статус DC3):

Авторизоваться на работающем контроллере домена.

Убедиться, что понижаемый контроллер не владеет никакими ролями FSMO:

# samba-tool fsmo show
SchemaMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
InfrastructureMasterRole owner: CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
RidAllocationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
DomainNamingMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
DomainDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
ForestDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt

Если понижаемому контроллеру домена принадлежит одна или несколько ролей FSMO, захватить их локальным контроллером домена (см. Захват роли FSMO).

Убедиться, что понижаемый контроллер домена отключён.
Вывести objectGUID контроллера домена:
```
# ldbsearch -H /var/lib/samba/private/sam.ldb '(invocationId=*)' --cross-ncs objectguid | grep -A1 DC3
dn: CN=NTDS Settings,CN=DC3,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
objectGUID: 512f03b4-7042-434d-93c0-61dd6a2ea895
```
Для того чтобы убедиться, что все записи DNS были удалены после понижения роли контроллера домена, необходимо знать имя хоста, IP-адрес и objectGUID контроллера домена.
Понизить статус удалённого контроллера домена:
```
# samba-tool domain demote --remove-other-dead-server=DC3
```
Если пониженный контроллер работал как доменный сервер DNS, убедиться, что члены домена и контроллеры домена больше не используют этот хост для разрешения зон AD DNS.

Важно

Не следует подключать к сети контроллер, выведенный по данной процедуре. Иначе ваш домен станет несогласованным.

⁠2.9.3. Проверка

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

На машине, введённой в домен, запустить модуль удалённого управления базой данных конфигурации (ADMC) (подробнее см. Модуль удалённого управления базой данных конфигурации). Выбрать запись Domain Controllers и убедиться, что пониженный контроллер домена был удален:

ADMC. Просмотр списка контроллеров домена

Проверить, что контроллер домена был понижен, можно также в RSAT (см. Установка RSAT). Для этого на машине Windows введённой в домен:

Открыть приложение Пользователи и компьютеры Active Directory, перейти к записи Контроллеры домена и убедиться, что пониженный контроллер домена был удален:
Если запись всё ещё присутствует в списке, её можно удалить вручную, выбрав в контекстном меню записи пункт Удалить.
Открыть приложение Сайты и службы Active Directory, и убедиться, что контроллер домена с пониженным статусом больше не указан ни в одной записи сайта Active Directory:
Если запись всё ещё присутствует в списке, её можно удалить вручную, выбрав в контекстном меню записи пункт Удалить.
Открыть приложение DNS, и убедиться, что имя хоста, IP-адрес и objectGUID контроллера домена больше не используются ни в одной записи DNS в любой зоне AD DNS. Например:
Если записи всё ещё присутствуют в списке, их можно удалить вручную, выбрав в контекстном меню записи пункт Удалить.

⁠Глава 3. Репликация

3.1. Настройка репликации

3.2. Проверка статуса репликации

3.2.1. Отображение статуса репликации на контроллере домена Samba
3.2.2. Отображение статусов репликации на контроллере домена Windows

3.3. Двунаправленная репликация SysVol

3.3.1. Настройка двунаправленной репликации SysVol на базе Rsync/Unison
3.3.2. Настройка двунаправленной репликации SysVol на базе Rsync/osync
3.3.3. Сопоставление встроенных идентификаторов пользователей и групп

Репликация Active Directory — метод, посредством которого изменения в базе службы каталогов на одном контроллере домена передаются другим контроллерам.

В Samba всё, что хранится внутри AD, реплицируется между контроллерами домена (пользователи, группы и записи DNS).

В настоящее время Samba не поддерживает протокол репликации распределенной файловой системы (DFS-R), используемый для репликации Sysvol. Методы решения этой проблемы см. в разделе Двунаправленная репликация SysVol.

⁠3.1. Настройка репликации

Предупреждение

Без успешной двунаправленной репликации в течение 14 дней DC исключается из домена.

Начиная с версии samba 3.5 топология репликации выстраивается автоматически.

Примечание

При настройке репликации указание аутентифицирующей информации (имени пользователя и пароля) обязательно!

Команда репликации:

# samba-tool drs replicate <destinationDC> <sourceDC> <NC> [options]

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

Репликация с первого контроллера домена на второй:
```
# samba-tool drs replicate dc2.test.alt \
dc1.test.alt dc=test,dc=alt -Uadministrator

Password for [TEST\administrator]:
Replicate from dc1.test.alt to dc2.test.alt was successful.
```
Сначала указывается приемник, затем источник, после этого реплицируемая ветка в LDAP.
Репликация на первый контроллер домена со второго:
```
# samba-tool drs replicate dc1.test.alt \
dc2.test.alt dc=test,dc=alt -Uadministrator

Password for [TEST\administrator]:
Replicate from dc2.test.alt to dc1.test.alt was successful.
```
Сначала указывается приемник, затем источник, после этого реплицируемая ветка в LDAP.
Примечание
Имя домена в именах серверов можно опустить (если они одинаковые).
Для просмотра статуса репликации можно запустить команду на DC (подробнее см. Проверка статуса репликации):
```
# samba-tool drs showrepl
```

Примечание

Если репликация на Windows не работает, следует добавить в Active Directory Sites and Services новое соединение Active Directory, реплицировать на DC, подождать минут 5 и попробовать реплицировать с Samba на Windows.

⁠3.2. Проверка статуса репликации

⁠3.2.1. Отображение статуса репликации на контроллере домена Samba

Команда samba-tool drs showrepl отображает установленные связи с другими контроллерами домена в лесу AD. Соединения отображаются с точки зрения контроллера домена, на котором запускается команда. Пример:

# samba-tool drs showrepl
Default-First-Site-Name\DC2
DSA Options: 0x00000001
DSA object GUID: 26a8d3d0-66b3-4f6c-8457-0def172d4af3
DSA invocationId: 83fb4bbf-9f63-44d6-acbd-c0db4e9e839a

==== INBOUND NEIGHBORS ====

CN=Schema,CN=Configuration,DC=test,DC=alt
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: e72594f1-4986-4ac9-8cdd-9481cff5e243
		Last attempt @ Wed May 22 15:38:51 2024 EET was successful
		0 consecutive failure(s).
		Last success @ Wed May 22 15:38:51 2024 EET

CN=Configuration,DC=test,DC=alt
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: e72594f1-4986-4ac9-8cdd-9481cff5e243
		Last attempt @ Wed May 22 15:38:51 2024 EET was successful
		0 consecutive failure(s).
		Last success @ Wed May 22 15:38:51 2024 EET

DC=ForestDnsZones,DC=test,DC=alt
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: e72594f1-4986-4ac9-8cdd-9481cff5e243
		Last attempt @ Wed May 22 15:38:50 2024 EET was successful
		0 consecutive failure(s).
		Last success @ Wed May 22 15:38:50 2024 EET

DC=DomainDnsZones,DC=test,DC=alt
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: e72594f1-4986-4ac9-8cdd-9481cff5e243
		Last attempt @ Wed May 22 15:38:51 2024 EET was successful
		0 consecutive failure(s).
		Last success @ Wed May 22 15:38:51 2024 EET

DC=test,DC=alt
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: e72594f1-4986-4ac9-8cdd-9481cff5e243
		Last attempt @ Wed May 22 15:38:51 2024 EET was successful
		0 consecutive failure(s).
		Last success @ Wed May 22 15:38:51 2024 EET

==== OUTBOUND NEIGHBORS ====

CN=Schema,CN=Configuration,DC=test,DC=alt
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: e72594f1-4986-4ac9-8cdd-9481cff5e243
		Last attempt @ NTTIME(0) was successful
		0 consecutive failure(s).
		Last success @ NTTIME(0)

CN=Configuration,DC=test,DC=alt
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: e72594f1-4986-4ac9-8cdd-9481cff5e243
		Last attempt @ NTTIME(0) was successful
		0 consecutive failure(s).
		Last success @ NTTIME(0)

DC=ForestDnsZones,DC=test,DC=alt
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: e72594f1-4986-4ac9-8cdd-9481cff5e243
		Last attempt @ NTTIME(0) was successful
		0 consecutive failure(s).
		Last success @ NTTIME(0)

DC=DomainDnsZones,DC=test,DC=alt
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: e72594f1-4986-4ac9-8cdd-9481cff5e243
		Last attempt @ NTTIME(0) was successful
		0 consecutive failure(s).
		Last success @ NTTIME(0)

DC=test,DC=alt
	Default-First-Site-Name\DC1 via RPC
		DSA object GUID: e72594f1-4986-4ac9-8cdd-9481cff5e243
		Last attempt @ NTTIME(0) was successful
		0 consecutive failure(s).
		Last success @ NTTIME(0)

==== KCC CONNECTION OBJECTS ====

Connection --
	Connection name: 56a02972-69f5-42fb-965a-7125f09c96d1
	Enabled        : TRUE
	Server DNS name : dc1.test.alt
	Server DN name  : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
		TransportType: RPC
		options: 0x00000001
Warning: No NC replicated for Connection!

Связи отображаются в разделах INBOUND NEIGHBORS и OUTBOUND NEIGHBORS. В каждом разделе должно быть по 5 пунктов:

CN=Schema,CN=Configuration,DC=test,DC=alt
DC=ForestDnsZones,DC=test,DC=alt
DC=test,DC=alt
DC=DomainDnsZones,DC=test,DC=alt
CN=Configuration,DC=test,DC=alt

В разделе INBOUND NEIGHBORS в пункте Last attempt должны стоять актуальные дата и время, идентичные указанным в строке Last success (отображает время последней репликации). Должно быть 0 consecutive failure(s).

Если в разделе INBOUND NEIGHBORS есть записи:

Last attempt @ NTTIME(0) was successful
…
Last success @ NTTIME(0)

необходимо подождать (соединение устанавливается).

В разделе KCC CONNECTION OBJECTS быть приведён список всех контроллеров домена, чьи KCC установили соглашения о репликации с текущим контроллером домена. В случае когда контроллер домена только только был добавлен в домен и запущен, может пройти до 15 минут до того, как соглашения будут установлены.

Примечание

Предупреждение

No NC replicated for Connection!

можно игнорировать. Оно появляется из-за того, что при регистрации нового DC Samba неверно устанавливает некоторые флаги репликации.

Можно также проверить репликацию LDAP:

# samba-tool ldapcmp ldap://dc1.test.alt ldap://dc2.test.alt -Uadministrator
Password for [TEST\administrator]:

* Comparing [DOMAIN] context...

* Objects to be compared: 274

* Result for [DOMAIN]: SUCCESS

* Comparing [CONFIGURATION] context...

* Objects to be compared: 1625

* Result for [CONFIGURATION]: SUCCESS

* Comparing [SCHEMA] context...

* Objects to be compared: 1739

* Result for [SCHEMA]: SUCCESS

* Comparing [DNSDOMAIN] context...

* Objects to be compared: 41

* Result for [DNSDOMAIN]: SUCCESS

* Comparing [DNSFOREST] context...

* Objects to be compared: 18

* Result for [DNSFOREST]: SUCCESS

Данная команда сравнит значения атрибутов объектов всего каталога на DC1 и DC2. В ряде случаев атрибуты объектов на разных контроллерах могут отличаться, и в выводе команды это будет видно. Но не во всех случаях это будет признаком проблемы с репликацией.

⁠3.2.2. Отображение статусов репликации на контроллере домена Windows

Для отображения статуса входящей репликации на контроллере домена Windows можно использовать утилиту repadmin:

> repadmin /showrepl

Windows не поддерживает отображение статусов исходящих подключений репликации. Чтобы обойти эту проблему, можно отобразить статусы входящих подключений на контроллерах домена Samba, на которые реплицируется контроллер домена Windows:

Найти в AD всех партнеров репликации Windows DC. Например, чтобы отобразить партнеров по репликации контроллера домена с именем WindowsDC:
```
# ldbsearch -H /var/lib/samba/private/sam.ldb '(fromServer=*CN=WindowsDC*)' --cross-ncs dn
# record 1
dn: CN=a46c895e-658b-463e-9ab5-a1c237fca4b1,CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt

# returned 1 records
# 1 entries
# 0 referrals
```
В этом примере возвращается один партнер по репликации (имя хоста: DC2). Имя хоста партнера по репликации является частью возвращаемого отличительного имени (DN).
На каждом контроллере домена Samba, полученном на предыдущем шаге, выполнить команду samba-tool drs showrepl для отображения статуса репликации каталога.
Необходимо убедиться, что каждый реплицируемый контейнер каталогов указан для контроллера домена Windows в разделе INBOUND NEIGHBORS на контроллере домена Samba, а статусы успешны.

⁠3.3. Двунаправленная репликация SysVol

Каталог Sysvol присутствует на всех контроллерах домена AD и используется для хранения логон скриптов и объектов групповых политик. Отсутствие репликации этого каталога приведет к неправильной работе групповых политик и сценариев входа.

Samba в своем текущем состоянии не поддерживает репликацию SysVol через DFS-R (репликация распределенной файловой системы) или более старую FRS (службу репликации файлов), используемую в Windows Server 2000/2003 для репликации SysVol. В настоящее время для репликации SysVol можно использовать один из следующих обходных путей:

двунаправленная репликация SysVol на основе Rsync/Unison (только Samba DC);
двунаправленная репликация SysVol на основе Rsync/osync (только Samba DC).

Важно

Следует синхронизировать idmap.ldb из контроллера домена, имеющего роль FSMO PDC_Emulator, со всеми другими контроллерами домена. Это гарантирует, что все контроллеры домена будут использовать одни и те же идентификаторы. Если файл idmap.ldb не синхронизируется, на каждом контроллере домена будут разные идентификаторы.

Cинхронизировать idmap.ldb (см. раздел Сопоставление встроенных идентификаторов пользователей и групп) необходимо при первом присоединении к новому контроллеру домена, а затем периодически (для того чтобы гарантировать постоянство идентификаторов не нужно синхронизировать idmap.ldb каждый раз при синхронизации SysVol, но это следует делать периодически).

⁠3.3.1. Настройка двунаправленной репликации SysVol на базе Rsync/Unison

Исходные данные:

все команды выполняются от пользователя root;
первый контроллер домена — DC1;
второй контроллер домена — DC2 (уже присоединён к домену);
sysvol расположен в /var/lib/samba/ как на DC1, так и на DC2;
rsync расположен в /usr/bin/rsync;
unison расположен в /usr/bin/unison;
журнал sysvolsync пишется в файл /var/log/sysvol-sync.log;
настроено беспарольное взаимодействие между rootами всех контроллеров домена (см. Настройка беспарольного доступа по ssh).

На первом контроллере домена (DC1):

Установить пакеты rsync и unison:
```
# apt-get install rsync unison
```
При низких скоростях в сети, unison может некорректно работать. Для того чтобы при повторной работе unison использовал существующее SSH-соединение вместо установки нового, необходимо выполнить следующие команды:
```
# mkdir ~/.ssh/ctl
# cat << EOF > ~/.ssh/config
Host *
ControlMaster auto
ControlPath ~/.ssh/ctl/%h_%p_%r
ControlPersist 1
EOF
```
Эти строки настраивают OpenSSH на использование ControlMaster для всех SSH-соединений и сохранение сокетов управления в каталоге ~/.ssh/ctl.
Создать каталог /root/.unison/:
```
# mkdir /root/.unison
```

Для определения политики синхронизации создать файл конфигурации unison /root/.unison/default.prf со следующим содержимым:

# Список каталогов, которые будут синхронизированы
root = /var/lib/samba
root = ssh://root@DC2.test.alt//var/lib/samba
# Список подкаталогов, которые нужно синхронизировать
path = sysvol
# Список подкаталогов, которые нужно игнорировать
#ignore = Path
auto=true
batch=true
perms=0
rsync=true
maxthreads=1
retry=3
confirmbigdeletes=false
servercmd=/usr/bin/unison
copythreshold=0
copyprog = /usr/bin/rsync -XAavz --rsh='ssh -p 22' --inplace --compress
copyprogrest = /usr/bin/rsync -XAavz --rsh='ssh -p 22' --partial --inplace --compress
copyquoterem = true
copymax = 1

# Сохранять журнал с результатами работы в отдельном файле
logfile = /var/log/sysvol-sync.log

Создать файл для записи журнала репликации (необходимо настроить ротацию логов для этого файла, так как размер журнала не контролируется):
```
# touch /var/log/sysvol-sync.log
```

На втором контроллере домена (DC2) установить пакеты rsync и unison:

# apt-get install rsync unison

Важно

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

Запустить команду синхронизации:

# /usr/bin/rsync -XAavz --log-file /var/log/sysvol-sync.log \
--delete-after -f"+ */" -f"- *" /var/lib/samba/sysvol \
root@dc2.test.alt:/var/lib/samba && /usr/bin/unison

В этой команде утилита rsync создает структуры каталогов с расширенными атрибутами, а затем утилита unison копирует только эти расширенные атрибуты файлов.

На DC1 включить синхронизацию по расписанию:

# crontab -e
*/5 * * * * /usr/bin/unison -silent

Повторная синхронизация каталога:

отключить синхронизацию по расписанию на DC1;
rsync и unison не должны выполняться в данный момент (можно проверить командой ps -aux);
удалить хеш-файлы unison на DC1 и DC2 в каталоге /root/.unison;
проверить sysvol и повторить синхронизацию;
убедиться, что синхронизация выполнена успешно;
включить синхронизацию по расписанию на DC1.

Если контроллеров домена больше чем два, можно создать больше заданий для cron на DC1:

Скопировать файл /root/.unison/default.prf в другой файл, например: /root/.unison/sync_dc2.prf.
В файле /root/.unison/dc2.prf изменить значение параметра root.
Повторить шаги 1 и 2 для всех контроллеров домена.
Изменить задание на синхронизацию по расписанию на DC1:
```
* * * * * /usr/bin/unison sync_dc2 -silent
* * * * * /usr/bin/unison sync_dc3 -silent
…
```

⁠3.3.2. Настройка двунаправленной репликации SysVol на базе Rsync/osync

Исходные данные:

все команды выполняются от пользователя root;
первый контроллер домена — DC1;
второй контроллер домена — DC2 (уже присоединён к домену);
sysvol расположен в /var/lib/samba/ как на DC1, так и на DC2;
rsync расположен в /usr/bin/rsync;
osync расположен в /usr/bin/osync;
журнал sysvolsync пишется в файл /var/log/osync_*.log;
настроено беспарольное взаимодействие между rootами всех контроллеров домена (см. Настройка беспарольного доступа по ssh).

На первом контроллере домена (DC1):

Установить пакеты rsync и osync:
```
# apt-get install rsync osync
```

Отредактировать файл /etc/osync/sync.conf:

#!/usr/bin/env bash
INSTANCE_ID="sync_sysvol"
 # Путь до SysVol на текущем сервере
INITIATOR_SYNC_DIR="/var/lib/samba/sysvol"
 # Путь до SysVol на удалённом сервере
TARGET_SYNC_DIR="ssh://root@DC2:22//var/lib/samba/sysvol"
 # ssh ключ root
SSH_RSA_PRIVATE_KEY="/root/.ssh/id_ed25519"
 # Удалённые хосты которые osync пингует перед стартом
REMOTE_3RD_PARTY_HOSTS=""
 # Сохранять xattr
PRESERVE_ACL=yes
 # Сохранять xattr
PRESERVE_XATTR=yes
 # Сохранять резервную копию удалённых файлов
SOFT_DELETE=yes
DESTINATION_MAILS="your@test.alt"
REMOTE_RUN_AFTER_CMD="/usr/bin/samba-tool ntacl sysvolreset"

На втором контроллере домена (DC2) установить пакет rsync:

# apt-get install rsync

Важно

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

Запустить команду синхронизации:

# /usr/bin/osync.sh /etc/osync/sync.conf --dry --verbose

Если команда выполнилась без ошибок, можно удалить параметр --dry и запустить команду синхронизации снова:

# /usr/bin/osync.sh /etc/osync/sync.conf --verbose

В результате sysvol будет синхронизирован на обоих серверах.

Примечание

Если в файле sysvol параметры SOFT_DELETE (сохранять резервные копии удалённых файлов) и CONFLICT_BACKUP (сохранять резервные копии файлов на целевой реплике, если они обновлены из исходной реплики) установлены в значение yes, то на источнике и получателе репликации необходимо создать каталоги .osync_workdir/deleted и .osync_workdir/backup:

# mkdir /var/lib/samba/sysvol/.osync_workdir/deleted
# mkdir /var/lib/samba/sysvol/.osync_workdir/backup

На DC1 включить синхронизацию по расписанию:

# crontab -e
*/5 * * * * root  /usr/bin/osync.sh /etc/osync/sync.conf --silent

Если при попытке синхронизировать каталог возникают проблемы необходимо:

отключить синхронизацию по расписанию на DC1;
убедиться, что rsync и osync не выполняются в данный момент (можно проверить, выполнив команду ps -aux| grep sync);
удалить хеш-файлы .osync_workdir на DC1 и DC2 в /var/lib/samba/sysvol/;
проверить sysvol и повторить синхронизацию;
убедиться, что синхронизация выполнена успешно;
включить синхронизацию по расписанию на DC1.

Если контроллеров домена больше чем два, можно создать больше заданий для cron на DC1:

Скопировать файл /etc/osync/sync.conf в другой файл, например: /etc/osync/sync_dc3.conf.
В файле /etc/osync/sync_dc3.conf изменить значение параметра TARGET_SYNC_DIR.
Повторить шаги 1 и 2 для всех контроллеров домена.

Изменить задание на синхронизацию по расписанию на DC1:

# crontab -e
*/5 * * * * root  /usr/bin/osync.sh /etc/osync/sync.conf --silent
*/5 * * * * root  /usr/bin/osync.sh /etc/osync/sync_dc3.conf --silent
…

⁠3.3.3. Сопоставление встроенных идентификаторов пользователей и групп

По умолчанию контроллер домена Samba сохраняет идентификаторы пользователей и групп в атрибутах xidNumber в idmap.ldb. Из-за особенностей работы idmap.ldb нельзя гарантировать, что каждый контроллер домена будет использовать один и тот же идентификатор для данного пользователя или группы.

Ниже описана процедура синхронизации idmap.ldb с контроллера домена, на котором установлена роль FSMO Эмулятор PDC (см. Роли FSMO), со всеми остальными контроллерами домена. Для достижения наилучших результатов следует регулярно синхронизировать idmap.ldb.

На контроллере домена, имеющего роль FSMO Эмулятор PDC:

Установить пакет ldb-tools, если он еще не установлен:
```
# apt-get install ldb-tools
```

Создать резервную копию файла /var/lib/samba/private/idmap.ldb:

# rm -f /var/lib/samba/private/idmap.ldb.bak
# tdbbackup -s .bak /var/lib/samba/private/idmap.ldb

Создать ежедневное задание cron:

#Создание резервной копии idmap.ldb
0 3 * * * rm -f /var/lib/samba/private/idmap.ldb.bak && tdbbackup -s .bak /var/lib/samba/private/idmap.ldb >/dev/null 2>&1

На контроллерах домена, которые не выполняют роль эмулятора PDC:

Скопировать файл резервной копии, созданный на DC с ролью Эмулятор PDC (в примере dc1), в каталог /var/lib/samba/private/ с удалением суффикса .bak (заменить существующий файл):
```
# rsync -a dc1:/var/lib/samba/private/idmap.ldb.bak /var/lib/samba/private/idmap.ldb
```
Запустить очистку кеша:
```
# net cache flush
```
Проверить разрешения ACL SysVol и при необходимости сбросить их:
```
# if ! samba-tool ntacl sysvolcheck; then samba-tool ntacl sysvolreset; fi
```

Если всё прошло успешно, создать ежедневное задание cron:

#Синхронизация idmap.ldb
15 4 * * * rsync -a  dc1:/var/lib/samba/private/idmap.ldb.bak  /var/lib/samba/private/idmap.ldb && net cache flush && if ! samba-tool ntacl sysvolcheck; then samba-tool ntacl sysvolreset; fi >/dev/null 2>&1

Важно

После синхронизации idmap.ldb необходим перезапуск Samba (systemctl restart samba.service), т.к. этот файл держится открытым процессами Samba.

Синхронизации idmap.ldb можно избежать, если на всех контроллерах добавить следующие параметры в smb.conf в секции [sysvol] (и в [netlogon]) строки:

acl_xattr:ignore system acls = yes
acl_xattr:default acl style = windows

При использовании этих параметров значения расширенных атрибутов файлов (xattr security.NTACL) на всех контроллерах будут одинаковы, независимо от uid/gid. Именно это и является проблемой при использовании rsync, т.к. при синхронизации rsync передаёт имена пользователей/групп и они разыменовываются в uid/gid уже «на месте», а xattr security.NTACL остаётся неизменным и, в конфигурации по умолчанию (без вышеуказанных параметров), зависит от значений uid/gid/facl.

⁠Глава 4. Клиенты Альт Домен

4.1. SSSD vs Winbind

4.2. Подготовка системы к вводу в домен

4.2.1. Установка пакетов
4.2.2. Синхронизация времени
4.2.3. Настройка DNS

4.3. Присоединение к домену в роли участника

4.3.1. Команда system-auth
4.3.2. Подключение к домену AD с помощью SSSD
4.3.3. Подключение к AD с помощью Samba Winbind

4.4. Вход пользователя

4.5. Отображение глобальных групп на локальные

4.6. Отладочная информация

4.6.1. Настройка уровня журналирования Samba
4.6.2. Ошибка при подключении к IP-адресу 127.0.0.1
4.6.3. getent не показывает доменных пользователей и группы

4.7. Удаление клиента AD

4.8. Повторная регистрация клиента

4.9. Настройка аутентификации доменных пользователей на DC

4.9.1. Winbind
4.9.2. SSSD
4.9.3. Генерация keytab-файла
4.9.4. Службы
4.9.5. Настройка ролей
4.9.6. Групповые политики
4.9.7. Настройка SSH

4.10. Настройка обновления паролей аккаунтов машин

4.10.1. Локальная политика смены пароля
4.10.2. Включение обновления пароля
4.10.3. Отключение обновления пароля
4.10.4. Диагностика
4.10.5. Восстановление работоспособности

Клиентами Альт Домен могут быть серверы и рабочие станции под управлением Windows, Linux («Альт», Astra Linux) и других операционных систем, поддерживающих стандартные протоколы LDAP, Kerberos, DNS и SMB.

Важно

Механизмы применения групповых политик оптимизированы для семейства ОС «Альт». Аутентификация в домене рабочих станций под управлением других ОС, построенных на ядре Linux, возможна, но поддержка механизмов применения групповых политик на таких машинах ограничена и требует соответствующее ПО, не входящее в комплект Альт Домен.

⁠4.1. SSSD vs Winbind

Существует несколько способов включения операционных систем на базе ядра Linux в AD домен. В этом разделе описаны функции и возможности двух вариантов интеграции: решение на основе Samba Winbind и решение на базе SSSD.

Машины под управлением ОС «Альт» рекомендуется вводить в домен AD с помощью SSSD, но есть несколько исключений:

Если в сети уже развернуты системы Linux, которые уже используют Samba Winbind для целей интеграции.
Если используется AD с включенным протоколом NTLM (так как SSSD не поддерживает протокол NTLM).
Если SSSD не поддерживает определенную функцию, которую поддерживает Winbind (например, SSSD не поддерживает доверительные отношения AD между лесами при прямом подключении к AD).

Ниже рассмотрены преимущества и недостатки интеграции на основе Samba Winbind и на базе SSSD.

Преимущества варианта интеграции с использованием Samba Winbind:

Samba Winbind эмулирует клиент Windows в системе Linux и использует преимущества собственных протоколов Windows и расширений протокола LDAP;
Winbind понимает концепцию доменов и лесов, а также работает с доверием между доменами и лесами;
Winbind может обнаруживать серверы, используя DNS;
Winbind может переключиться на другой сервер, если контроллер домена AD становится недоступным;
Winbind может динамически выполнять сопоставление идентификаторов на основе идентификаторов объектов AD (SID) или использовать атрибуты POSIX, хранящиеся в AD (если эти расширения были загружены);
Winbind хорошо интегрируется с клиентом Samba FS и CIF;
безопасность соединения основана на идентификации клиентской системы и ключах Kerberos, выданных этой системе.

Ограничения Samba Winbind:

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

SSSD это группа служб, обеспечивающих аутентификацию, авторизацию и другие действия, используя взаимодействие с различными службами каталогов и серверами аутентификации. SSSD может взаимодействовать с Samba AD, FreeIPA, MS AD или любыми другими стандартными реализациями сервера LDAP и/или Kerberos.

Единственным серьезным ограничением для интеграции с использованием SSSD является поддержка (старого) протокола NTLM. SSSD не реализует этот протокол, потому что по современным стандартам NTLM больше не является безопасным для развертывания. Наилучшей практикой является отказ от использования NTLM.

Преимущества SSSD:

возможность загрузки и применения политик управления доступом на основе хоста с использованием объектов групповой политики, управляемых в Samba AD;
может взаимодействовать с разными источниками идентификации, а не только с AD;
поддерживает очистку DNS (т.е. обнаруживает, были ли удалены или обновлены записи DNS для серверов);
предоставляет расширенные интерфейсы идентификации на локальной шине сообщений (D-Bus). Этот интерфейс можно использовать для лучшей интеграции приложений, работающих в ОС Linux, с корпоративными источниками идентификации, такими как AD и FreeIPA.

⁠

Таблица 4.1. Сравнение Winbind и SSSD

Категория	Описание	Winbind	SSSD
Аутентификация	Проверка подлинности с использованием Kerberos	Да	Да
	Проверка подлинности LDAP	Да	Да
	Поддержка нескольких доменов AD	Да	Да
	Поддержка лесов AD	Да	Да
	Поддержка гетерогенных сетей AD/FreeIPA	Нет	Да
Безопасность	Простота настройки безопасной конфигурации	Нет	Да
	Система имеет идентификатор и её ключ используется для защиты доступа к центральному серверу	Да	Да
	Поддержка NTLM	Да	Нет
Поиск и сопоставление идентификаторов	Динамическое сопоставление идентификаторов AD SID	Да	Да
Поиск и сопоставление идентификаторов	Использование преимуществ конкретных расширений и протоколов AD	Да	Да
DNS	Обновление и очистка DNS AD	Нет	Да
DNS	Поддержка сайтов AD DNS	Да	Да
Обмен файлами	Интеграция с Samba FS	Да	Да
Обмен файлами	Интеграция с клиентом CIFS	Да	Да
Служба печати	Сервер печати CUPS с использованием Kerberos	Да	Да
Политики	Централизованное управление контролем доступа на основе хоста через GPO	Нет	Да
Интеграция с другими сервисами и приложениями	Интеграция с основными утилитами, такими как SSH, sudo, automount	Нет	Да
	Расширенные интерфейсы идентификации по локальной шине сообщений D-Bus	Нет	Да
	Специальные функции для приложений (Docker, Cockpit, GSS Proxy и др.)	Нет	Да

⁠4.2. Подготовка системы к вводу в домен

⁠4.2.1. Установка пакетов

Установить пакет task-auth-ad-sssd:

# apt-get install task-auth-ad-sssd

⁠4.2.2. Синхронизация времени

Синхронизация времени с контроллером домена производится автоматически.

⁠4.2.3. Настройка DNS

AD использует DNS для обнаружения других контроллеров домена и служб, таких как Kerberos. Поэтому, члены и серверы домена AD должны иметь возможность разрешать зоны AD DNS.

Для ввода компьютера в домен, на нём должен быть доступен сервер DNS, имеющий записи про контроллер домена Active Directory. При получении IP-адреса по DHCP данные о сервере DNS также должны быть получены от DHCP-сервера.

Ниже приведен пример настройки сетевого интерфейса со статическим IP-адресом.

⁠4.2.3.1. Настройка клиентов для использования DNS-серверов вручную

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

В Центре управления системой Сеть → Ethernet интерфейсы задать имя компьютера, указать в поле DNS-серверы DNS-сервер домена и в поле Домены поиска — домен для поиска:

Примечание

В консоли:

задать имя компьютера:

# hostnamectl set-hostname host-01.test.alt

в качестве первичного DNS должен быть указан DNS-сервер домена. Для этого необходимо создать файл /etc/net/ifaces/enp0s3/resolv.conf со следующим содержимым:
```
nameserver 192.168.0.122
```
где 192.168.0.122 — IP-адрес DNS-сервера домена.
указать службе resolvconf использовать DNS контроллера домена и домен для поиска. Для этого в файле /etc/resolvconf.conf добавить/отредактировать следующие параметры:
```
interface_order='lo lo[0-9]* lo.* enp0s3'
search_domains=test.alt
```
где enp0s3 — интерфейс, на котором доступен контроллер домена, test.alt — домен.
обновить DNS адреса:
```
# resolvconf -u
```

Примечание

В результате выполненных действий в файле /etc/resolv.conf должны появиться строки:

search test.alt
nameserver 192.168.0.122

⁠4.2.3.2. Проверка разрешения DNS

Для проверки того, что настройки DNS верны и машины могут разрешать IP-адреса и имена, можно использовать команды nslookup и host.

Прямой поиск:

# nslookup dc1.test.alt
Server:		192.168.0.122
Address:	192.168.0.122#53

Name:	dc1.test.alt
Address: 192.168.0.122

# host dc1.test.alt
dc1.test.alt has address 192.168.0.122

Обратный поиск:

# nslookup 192.168.0.122
122.0.168.192.in-addr.arpa	name = dc1.alt.test.

# host 192.168.0.122
122.0.168.192.in-addr.arpa domain name pointer dc1.alt.test.

Следует обратить внимание, что в Samba AD обратная зона не настраивается автоматически. Чтобы настроить обратную зону, см. Администрирование DNS.

AD использует записи SRV для поиска служб, таких как Kerberos и LDAP. Проверка разрешения SRV-записей:

$ nslookup
> set type=SRV
> _ldap._tcp.test.alt
Server:		192.168.0.122
Address:	192.168.0.122#53

_ldap._tcp.test.alt	service = 0 100 389 dc2.test.alt.
_ldap._tcp.test.alt	service = 0 100 389 dc1.test.alt.
> exit

или:

$ host -t SRV _ldap._tcp.test.alt
_ldap._tcp.test.alt has SRV record 0 100 389 dc1.test.alt.
_ldap._tcp.test.alt has SRV record 0 100 389 dc2.test.alt.

⁠4.3. Присоединение к домену в роли участника

⁠4.3.1. Команда system-auth

Для ввода клиентских машин в домен AD, в дистрибутивах «Альт» используется команда system-auth:

# system-auth <Действие> <Опции>

В таблице Параметры команды system-auth приведено описание параметров команды system-auth.

⁠

Таблица 4.2. Параметры команды system-auth

Параметр	Описание
Действие
`status`	Показать текущую схему аутентификацию
`list`	Вывести список доступных схем аутентификации
`write`	Установить заданные параметры аутентификации
Опция
`-d`	Включить отладку
`--winbind`	Использовать Samba Winbind для подключения системы к домену (если этот параметр не указан, будет использован SSSD)
`--gpo`	Включить групповые политики на машине
`--createcomputer=OU/SubOU`	Субконтейнер в домене (организационная единица/подразделение), куда будет помещена машина при вводе в домен
`--windows2003`	Ввести станцию в домен windows 2003
`--version`	Вывести версию программы

Примеры использования команды system-auth:

вывести текущую схему аутентификации:
```
# system-auth status
ad TEST.ALT HOST-01 TEST
```
использовать локальную аутентификацию:
```
# system-auth write local
```

использовать доменную аутентификацию (по умолчанию используется билет Kerberos):

# system-auth write ad <Домен> <Имя компьютера> <Рабочая группа> <Имя пользователя> [<Пароль>] [--windows2003] [--createcomputer="COMPUTEROU/SubCOMPUTEROU/SubSubCOMPUTEROU"] [--winbind] [--gpo]

⁠4.3.2. Подключение к домену AD с помощью SSSD

В этом разделе описывается использование демона служб безопасности системы (SSSD) для подключения системы к Active Directory (AD).

SSSD используется для доступа к пользовательскому каталогу для аутентификации и авторизации через общую структуру с кешированием пользователей, чтобы разрешить автономный вход в систему. SSSD легко настраивается; он обеспечивает интеграцию подключаемых модулей аутентификации (PAM) и службы переключения имен (NSS), базу данных для хранения локальных пользователей, а также расширенных пользовательских данных, полученных с центрального сервера.

Дополнительные ресурсы:

man realm
man sssd-ad
man sssd

⁠4.3.2.1. Ввод в домен в командной строке

Для ввода компьютера в домен необходимо выполнить команду:

# system-auth write ad test.alt host-01 test 'administrator' 'Pa$$word'
Joined 'HOST-01' to dns domain 'test.alt'

где:

test.alt — имя домена;
host-01 — имя компьютера, вводимого в домен;
test — рабочая группа;
administrator — имя пользователя, имеющего право вводить машины в домен;
Pa$$word — пароль пользователя, имеющего право вводить машины в домен.

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

⁠4.3.2.2. Ввод в домен в Центре управления системой

Для ввода компьютера в домен в Центре управления системой необходимо выбрать пункт Пользователи → Аутентификация.

В окне модуля Аутентификация следует выбрать пункт Домен Active Directory, заполнить поля (Домен, Рабочая группа, Имя компьютера), выбрать пункт SSSD (в единственном домене) и нажать кнопку Применить:

Ввод в домен в Центре управления системой

В открывшемся окне необходимо ввести имя пользователя, имеющего право вводить машины в домен, и его пароль и нажать кнопку ОК:

Пароль для учётной записи с правами подключения к домену

Примечание

Если на машине установлен пакет alterator-gpupdate, при подключении машины к домену можно включить групповые политики. Для включения групповых политки необходимо в окне ввода учётных записей пользователя с правами подключения к домену отметить пункт Включить групповые политики:

Включение групповых политик при вводе в домен

При успешном подключении к домену отобразится соответствующая информация:

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

⁠4.3.2.3. Проверка результатов присоединения

Проверка корректности присоединения:

Для проверки возможности поиска доменных пользователей отобразить сведения о пользователе AD (ivanov — пользователь в домене):
```
# getent passwd ivanov
ivanov:*:1187401105:1187400513:Иван Иванов:/home/TEST.ALT/ivanov:/bin/bash
```

Проверить возможность получения информации о домене:

# net ads info
LDAP server: 192.168.0.122
LDAP server name: dc1.test.alt
Realm: TEST.ALT
Bind Path: dc=TEST,dc=ALT
LDAP port: 389
Server time: Ср, 27 мар 2024 10:36:51 EET
KDC server: 192.168.0.122
Server time offset: 2
Last machine account password change: Ср, 20 мар 2024 11:13:27 EET

Проверить, действителен ли пароль учетной записи компьютера:
```
# net ads testjoin
Join is OK
```

Примечание

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

# samba-tool user list

Примечание

О настройке SSSD см. Настройка SSSD и Настройки SSSD в ЦУС.

⁠4.3.3. Подключение к AD с помощью Samba Winbind

В этом разделе описывается использование Samba Winbind для подключения системы к Active Directory (AD).

Samba Winbind эмулирует клиент Windows в системе Linux и взаимодействует с серверами AD.

Дополнительные ресурсы:

man realm
man winbindd

⁠4.3.3.1. Ввод в домен в командной строке

Для ввода компьютера в домен необходимо выполнить команду:

# system-auth write ad test.alt host-02 test 'administrator' 'Pa$$word' --winbind
Joined 'HOST-02' to dns domain 'test.alt'

где:

test.alt — имя домена;
host-02 — имя компьютера, вводимого в домен;
test — рабочая группа;
administrator — имя пользователя, имеющего право вводить машины в домен;
Pa$$word — пароль пользователя, имеющего право вводить машины в домен.

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

⁠4.3.3.2. Ввод в домен в Центре управления системой

В окне модуля Аутентификация следует выбрать пункт Домен Active Directory, заполнить поля (Домен, Рабочая группа, Имя компьютера), выбрать пункт Winbind (в сложных доменах) и нажать кнопку Применить:

При успешном подключении к домену отобразится соответствующая информация:

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

⁠4.3.3.3. Проверка результатов присоединения

Проверка корректности присоединения:

Для проверки возможности поиска доменных пользователей отобразить сведения о пользователе AD (ivanov — пользователь в домене):
```
# getent passwd ivanov
ivanov:*:1187401105:1187400513:Иван Иванов:/home/TEST.ALT/ivanov:/bin/bash
```

Проверить возможность получения информации о домене:

# net ads info
LDAP server: 192.168.0.122
LDAP server name: dc1.test.alt
Realm: TEST.ALT
Bind Path: dc=TEST,dc=ALT
LDAP port: 389
Server time: Ср, 27 мар 2024 10:36:51 EET
KDC server: 192.168.0.122
Server time offset: 2
Last machine account password change: Ср, 20 мар 2024 11:13:27 EET

Проверить, действителен ли пароль учетной записи компьютера:
```
# net ads testjoin
Join is OK
```

Примечание

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

# samba-tool user list

⁠4.4. Вход пользователя

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

Примечание

Определить будет ли показан список пользователей на экране приветствия/входа в систему LightDM можно с помощью control:

# control lightdm-greeter-hide-users

В команду можно передать следующие параметры:

show — показать список доступных пользователей в greeter;
hide — не перечислять пользователей в greeter.

Для регистрации в системе необходимо ввести логин учетной записи пользователя домена и нажать Enter или щелкнуть на кнопке Войти:

Ввод логина учетной записи пользователя домена

В открывшемся окне ввести пароль, соответствующий этой учетной записи и нажать кнопку Войти:

Чтобы настроить автоматическое заполнение поля Имя пользователя именем последнего пользователя, входившего в систему, в файле /etc/lightdm/lightdm-gtk-greeter.conf (группа [greeter]), необходимо указать:

enter-username = true

Примечание

В случае использования в окне логина символов верхнего регистра (например, Irina.Soboleva вместо irina.soboleva) или лишних символов (не использующихся для стандартного имяобразования в Linux) может наблюдаться некорректное поведение системы (в частности не выставляются переменные окружения XDG_RUNTIME_DIR и DBUS_SESSION_BUS_ADDRESS).

Для возможности использовать для входа привычные способы написания логина (с доменным суффиксом, точками, символами верхнего регистра) необходимо выполнить команду (должен быть установлен пакет pam-config-control):

# control pam_canonicalize_user enabled

или в файле /etc/pam.d/system-auth-common раскомментировать строку:

auth required pam_canonicalize_user.so

Модуль PAM pam_canonicalize_user.so использует введенное имя пользователя в качестве ключа для запроса базы данных паролей и заменяет имя пользователя на возвращенное значение.

⁠4.5. Отображение глобальных групп на локальные

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

роль пользователей (users);
роль пользователей с расширенными правами (powerusers);
роль локальных администраторов (localadmins).

Локальные роли users и localadmins назначаются для глобальных групп в домене.

Список назначенных ролей и привилегий:

# rolelst
domain users:users
domain admins:localadmins
localadmins:wheel,vboxadd,vboxusers
powerusers:remote,vboxadd,vboxusers
users:cdwriter,cdrom,audio,video,proc,radio,camera,floppy,xgrp,scanner,uucp,vboxusers,fuse,vboxadd
vboxadd:vboxsf
# id ivanov
uid=906201103(ivanov) gid=906200513(domain users) группы=906200513(domain users),906201107(sales),
906201114(office),100(users),80(cdwriter),22(cdrom),81(audio),475(video),19(proc),
83(radio),444(camera),71(floppy),498(xgrp),499(scanner),14(uucp),462(vboxusers),464(fuse),488(vboxadd),487(vboxsf)

Если необходимо выдать права администраторов пользователям, которые не являются администраторами домена (Domain Admins), то нужно на контроллере домена завести новую группу в AD (например, PC Admins):

# samba-tool group add 'PC Admins'
Added group PC Admins

Добавить туда необходимых пользователей (например, пользователя ivanov):

# samba-tool group addmembers 'PC Admins' ivanov
Added members to group PC Admins

Затем на машине, введённой в домен, добавить роль для данной группы:

# roleadd 'PC Admins' localadmins
# rolelst
domain users:users
domain admins:localadmins
pc admins:localadmins
localadmins:wheel,vboxadd,vboxusers
powerusers:remote,vboxadd,vboxusers
users:cdwriter,cdrom,audio,video,proc,radio,camera,floppy,xgrp,scanner,uucp,vboxusers,fuse,vboxadd
vboxadd:vboxsf

После этого пользователь, входящий в группу PC Admins, сможет получать права администратора.

⁠4.6. Отладочная информация

⁠4.6.1. Настройка уровня журналирования Samba

Дополнительные сведения см. в разделе Уровни журналирования.

⁠4.6.2. Ошибка при подключении к IP-адресу 127.0.0.1

Используя настройки по умолчанию, команда net подключается к IP-адресу 127.0.0.1. Если Samba не прослушивает петлевой интерфейс, соединение не устанавливается. Например:

# net rpc rights list -U administrator
Could not connect to server 127.0.0.1
Connection failed: NT_STATUS_CONNECTION_REFUSED

Чтобы решить эту проблему, необходимо настроить Samba для дополнительного прослушивания интерфейса loopback. Дополнительные сведения см. в разделе Настройка Samba для привязки к определённым интерфейсам.

Примечание

Чтобы временно обойти проблему, можно передать параметр -I <IP-адрес> или -S <Имя хоста> в команду net:

# net rpc rights list -U administrator -I 192.168.0.122
Password for [TEST\administrator]:
     SeMachineAccountPrivilege  Add machines to domain
      SeTakeOwnershipPrivilege  Take ownership of files or other objects
      …

⁠4.6.3. getent не показывает доменных пользователей и группы

Используя команды getent passwd и getent group нельзя увидеть доменных пользователей и группы. Этот функционал отключен по умолчанию, для того чтобы сократить нагрузку на серверы. Поэтому для проверки необходимо указать точное имя пользователя:

# getent passwd <имя_пользователя>

Примечание

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

# samba-tool user list

Если команда getent passwd <имя_пользователя> ничего не возвращает, следует попробовать выполнить команду:

# getent passwd <рабочая_группа>\<имя_пользователя>

Например:

# getent passwd "TEST\ivanov"

Если эта команда работает, а первая нет, то необходимо добавить следующую строку в файл smb.conf:

winbind use default domain = yes

⁠4.7. Удаление клиента AD

Чтобы вывести систему из домена, можно воспользоваться командой realm leave. Эта команда удалит конфигурацию домена из SSSD и локальной системы:

# realm leave test.alt

По умолчанию удаление выполняется от имени администратора (для AD — administrator). Если для присоединения к домену использовалась учётная запись другого пользователя, может потребоваться выполнить удаление от имени этого пользователя. Чтобы указать пользователя следует использовать параметр -U:

# realm leave test.alt -U <пользователь>

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

Следует обратить внимание, что когда клиент удаляется из домена, учётная запись компьютера не удаляется из каталога; удаляется только конфигурация локального клиента. Если необходимо удалить учётную запись компьютера, следует запустить команду с параметром --remove:

# realm leave --remove test.alt

Для получения дополнительной информации см. справочную страницу man realm (8).

Примечание

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

# control system-auth
local

Примечание

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

# control lightdm-greeter-hide-users show

или в файле /etc/lightdm/lightdm.conf закомментировать строку в группе [SeatDefaults]:

#greeter-hide-users=true

⁠4.8. Повторная регистрация клиента

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

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

# realm leave --remove <домен>

Возможно также понадобится удалить закешированные записи:

# sss_cache -E

После вывода машины из домена следует убедиться в корректности имени машины и восстановить файлы конфигурации /etc/samba/smb.conf, /etc/sssd/sssd.conf и /etc/krb5.conf к виду по умолчанию и повторно ввести машину в домен.

Примечание

Привести файлы /etc/samba/smb.conf и /etc/krb5.conf к виду по умолчанию можно в модуле ЦУС Аутентификация. В окне модуля Аутентификация следует установить отметку в поле Восстановить файлы конфигурации по умолчанию (smb.conf, krb5.conf, sssd.conf) и нажать кнопку Применить:

Восстановить файлы конфигурации по умолчанию

⁠4.9. Настройка аутентификации доменных пользователей на DC

Важно

На текущий момент (samba 4.19.6, gpupdate 0.10.6) данный метод не позволяет применять групповые политики на контроллере домена.

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

аутентификация доменными пользователями (в том числе по ssh);
применение групповых политик;
всё, что поддерживает обычная клиентская машина (в качестве клиента SSSD или Winbind).

Важно

В качестве клиента на контроллере домена рекомендуется использовать Winbind. Использование SSSD нежелательно.

⁠4.9.1. Winbind

⁠4.9.1.1. Установка пакетов

На контроллере домена необходимо установить пакеты task-auth-ad-winbind и gpupdate:

# apt-get install task-auth-ad-winbind gpupdate

⁠4.9.1.2. Изменение файлов конфигурации

⁠4.9.1.2.1. Настройка Kerberos (krb5.conf)

В файле /etc/krb5.conf должны быть заданы следующие параметры:

dns_lookup_realm = false
default_realm = TEST.ALT

Пример файла /etc/krb5.conf:

[logging]

[libdefaults]
 dns_lookup_kdc = true
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_realm = TEST.ALT

[realms]

[domain_realm]

⁠4.9.1.2.2. Настройка Samba (smb.conf)

В файле /etc/samba/smb.conf должны быть заданы следующие параметры:

kerberos method = dedicated keytab
dedicated keytab file = /etc/krb5.keytab

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

Пример файла /etc/samba/smb.conf:

[global]
        dns forwarder = 8.8.8.8
        netbios name = DC1
        kerberos method = dedicated keytab
        dedicated keytab file = /etc/krb5.keytab
        realm = TEST.ALT
        server role = active directory domain controller
        workgroup = TEST
        idmap_ldb:use rfc2307 = yes

        template shell = /bin/bash
        template homedir = /home/TEST.ALT/%U

        wins support = no
        winbind use default domain = yes
        winbind enum users = no
        winbind enum groups = no
        winbind refresh tickets = yes
        winbind offline logon = yes

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

[netlogon]
        path = /var/lib/samba/sysvol/test.alt/scripts
        read only = No

⁠4.9.1.2.3. Настройка NSS (nsswitch.conf)

В файле /etc/nsswitch.conf должны быть заданы следующие параметры:

passwd: files winbind systemd
shadow: tcb files winbind
group: files [SUCCESS=merge] winbind role systemd

Пример файла /etc/nsswitch.conf:

passwd:     files winbind systemd
shadow:     tcb files winbind
group:      files [SUCCESS=merge] winbind role systemd
gshadow:    files

hosts:      files myhostname dns

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

automount:  files
aliases:    files

⁠4.9.1.3. Настройка аутентификации

Необходимо переключить PAM-стек на использование для аутентификации Winbind-модуля:

# control system-auth winbind

⁠4.9.2. SSSD

Важно

На текущий момент (samba 4.19.6, sssd 2.9.4) для каталога /var/lib/samba/sysvol SID'ы домена некорректно транслируются в UNIX user id и group id.

⁠4.9.2.1. Установка пакетов

На контроллере домена должны быть установлены пакеты task-auth-ad-sssd и gpupdate:

# apt-get install task-auth-ad-sssd gpupdate

⁠4.9.2.2. Изменение файлов конфигурации

⁠4.9.2.2.1. Настройка Kerberos (krb5.conf)

В файле /etc/krb5.conf должны быть заданы следующие параметры:

includedir /etc/krb5.conf.d/
dns_lookup_realm = false
default_realm = TEST.ALT

Пример файла /etc/krb5.conf:

includedir /etc/krb5.conf.d/
[logging]

[libdefaults]
 dns_lookup_kdc = true
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_realm = TEST.ALT

[realms]

[domain_realm]

⁠4.9.2.2.2. Настройка SSSD (sssd.conf)

В файле /etc/sssd/sssd.conf должны быть заданы следующие параметры:

user = root
ad_maximum_machine_account_password_age = 0

Пример файла /etc/sssd/sssd.conf:

[sssd]
config_file_version = 2
services = nss, pam

# Managed by system facility command:
## control sssd-drop-privileges unprivileged|privileged|default
user = root

# SSSD will not start if you do not configure any domains.
domains = TEST.ALT
[nss]

[pam]
[domain/TEST.ALT]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
debug_level = 0
; cache_credentials = false
ad_gpo_ignore_unreadable = true
ad_gpo_access_control = permissive
ad_update_samba_machine_account_password = true
ad_maximum_machine_account_password_age = 0

⁠4.9.2.2.3. Настройка Samba (smb.conf)

В файле /etc/samba/smb.conf должны быть заданы следующие параметры:

idmap config * : range = 200000-2000200000
idmap config * : backend = sss

Пример файла /etc/samba/smb.conf:

[global]
        dns forwarder = 8.8.8.8
        netbios name = DC1
        realm = TEST.ALT
        server role = active directory domain controller
        workgroup = TEST
        idmap_ldb:use rfc2307 = yes

        template shell = /bin/bash
        template homedir = /home/TEST.ALT/%U

        kerberos method = system keytab
        wins support = no
        winbind use default domain = yes
        winbind enum users = no
        winbind enum groups = no
        winbind refresh tickets = yes
        winbind offline logon = yes

        idmap config * : range = 200000-2000200000
        idmap config * : backend = sss

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

[netlogon]
        path = /var/lib/samba/sysvol/test.alt/scripts
        read only = No

⁠4.9.2.2.4. Настройка NSS (nsswitch.conf)

В файле /etc/nsswitch.conf должны быть заданы следующие параметры:

passwd: files sss systemd
shadow: tcb files sss
group: files [SUCCESS=merge] sss role systemd

Пример файла /etc/nsswitch.conf:

passwd:     files sss systemd
shadow:     tcb files sss
group:      files [SUCCESS=merge] sss role systemd
gshadow:    files

hosts:      files myhostname dns

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

automount:  files
aliases:    files

⁠4.9.2.3. Настройка аутентификации

Необходимо переключить PAM-стек на использование для аутентификации sss-модулей:

# control system-auth sss

⁠4.9.3. Генерация keytab-файла

Необходимо сгенерировать системный keytab-файл для машинного аккаунта контроллера домена. Для этого следует выполнить следующую команду:

# net ads keytab create

⁠4.9.4. Службы

Необходимо отключить сервис nscd:

# systemctl disable --now nscd

Если используется схема с SSSD клиентом, необходимо запустить и включить автоматический запуск для службы sssd:

# systemctl enable --now sssd

⁠4.9.5. Настройка ролей

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

обычные пользователи домена (Domain Users) соответствуют локальной роли users:
```
# roleadd 'domain users' users
```
администраторы домена (Domain Admins) соответствуют локальной роли localadmins:
```
# roleadd 'domain admins' localadmins
```

Важно

В русскоязычных версиях MS Windows Server встроенные группы Domain Users и Domain Admins имеют русифицированные названия Пользователи домена и Администраторы домена.

⁠4.9.6. Групповые политики

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

# gpupdate-setup enable --local-policy ad-domain-controller

Важно

Работа групповых политик на контроллере домена c SSSD клиентом может быть не стабильной.

⁠4.9.7. Настройка SSH

Разрешить удалённый доступ по SSH только Администраторам домена:

# control sshd-allow-groups enabled
# control sshd-allow-groups-list remote

При необходимости можно разрешить аутентификацию по Kerberos билетам:

# control sshd-gssapi-auth enabled

Для применения настроек необходимо перезапустить сервис sshd:

# systemctl restart sshd

Примечание

Данные настройки можно применить с помощью механизма групповых политик control. Подробнее см. Групповые политики control.

⁠4.10. Настройка обновления паролей аккаунтов машин

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

Как и у любого другого пользователя, у машинного пользователя есть свой пароль, генерируемый автоматически в процессе ввода машины в домен. В отличии от обычных пользователей, у машинных аккаунтов нет ограничения на время жизни пароля, но машина имеет возможность поменять его самостоятельно. По умолчанию машины с MS Windows 2000 и старше меняют пароль раз в 30 дней. Информация о последней смене пароля хранится в атрибуте машинного аккаунта pwdlastset.

⁠4.10.1. Локальная политика смены пароля

Сменой пароля учётной записи компьютера можно управлять с помощью групповых политик. Для этого нужно отредактировать параметр политики домена по умолчанию (Default domain policy) Член домена: максимальный срок действия пароля учётной записи компьютера, который располагается в подразделе Конфигурация компьютера → Политики → Конфигурация Windows → Параметры безопасности → Локальные политики → Параметры безопасности (Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options).

Настройка максимального срока действия пароля учётной записи компьютера в RSAT

Примечание

На данный момент в ADMC (admc 0.16.3) нет возможности настроить данные параметры групповой политики. Необходимо использовать оснастку RSAT «Управление групповыми политиками» (см. Установка RSAT).

Этот параметр безопасности определяет, как часто член домена будет пытаться изменить пароль учётной записи компьютера. Значение по умолчанию: 30 дней.

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

Важно

Выше указанные параметры корректно работают на машинах с ОС MS Windows 2000 и старше.

Важно

На машинах с ОС «Альт» (sssd 2.9.4) данные параметры игнорируются.

⁠4.10.2. Включение обновления пароля

⁠4.10.2.1. ОС Windows

Для включения периодического обновления пароля учётной записи компьютера на машинах под управлением ОС Windows 2000 и старше дополнительных действий не требуется. Периодичность обновления настраивается с помощью соответствующей групповой политики.

⁠4.10.2.2. ОС «Альт»

За обновление пароля машинного аккаунта на машинах под управлением ОС «Альт» отвечают сервисы sssd и winbind.

⁠4.10.2.2.1. Winbind

Winbind, на текущий момент (samba-winbind 4.19.6), не умеет после смены пароля учётной записи компьютера обновлять системный keytab-файл (/etc/krb5.keytab). Поэтому, во избежание конфликтов с sssd, следует отключить этот функционал.

Для отключения периодического обновления пароля учётной записи компьютера, необходимо в файл /etc/samba/smb.conf в секцию [global] добавить параметр machine password timeout = 0:

[global]
machine password timeout = 0

⁠4.10.2.2.2. SSSD

sssd для обновления пароля учётной записи компьютера использует утилиту adcli. Необходимо убедиться, что пакет adcli установлен в системе:

# apt-get install adcli

Периодичностью обновления пароля учётной записи компьютера можно управлять с помощью параметра ad_maximum_machine_account_password_age (секция [domain/<Домен>]) в /etc/sssd/sssd.conf. Значение по умолчанию: 30 дней.

Для корректного функционирования обновления пароля учётной записи компьютера, sssd необходим доступ на запись в файл /etc/krb5.keytab. Для этого не достаточно привилегий пользователя _sssd, от которого обычно и запускается sssd. Необходимо запускать sssd с правами суперпользователя. Для этого следует в файле /etc/sssd/sssd.conf в секции [sssd] изменить значение параметра user на root:

[sssd]
user = root

[domain/<Домен>]
ad_update_samba_machine_account_password = true

Важно

При вводе компьютера в домен с помощью ЦУС следующие параметры прописываются в конфигурационные файлы по умолчанию:

/etc/samba/smb.conf:
```
machine password timeout = 0
```

/etc/sssd/sssd.conf:

ad_update_samba_machine_account_password = true

⁠4.10.3. Отключение обновления пароля

⁠4.10.3.1. ОС Windows

Для отключения периодического обновления пароля учётной записи компьютера на машинах под управлением ОС Windows 2000 и старше, достаточно включить параметр групповой политики Default domain policy Член домена: отключить изменение пароля учётных записей компьютера.

⁠4.10.3.2. ОС «Альт»

Для отключения периодического обновления пароля учётной записи компьютера на машинах под управлением ОС «Альт», необходимо:

в файле /etc/sssd/sssd.conf (секция [domain/<Домен>]) значение параметра ad_maximum_machine_account_password_age установить равным 0:
```
[domain/<Домен>]
ad_maximum_machine_account_password_age = 0
```
в файле /etc/samba/smb.conf (секция [global]) значение параметра machine password timeout установить равным 0:
```
[global]
machine password timeout = 0
```

⁠4.10.4. Диагностика

⁠4.10.4.1. Дата последней смены пароля

Дата последней смены пароля учётной записи компьютера хранится в базе данных домена. Запросить её можно одним из следующих способов:

на введённой в домен машине выполнить команду:

# net ads info
…
Last machine account password change: Ср, 20 мар 2024 12:36:35 EET

если машина уже потеряла доверие в домене, то выполнить эту же команду от доменного пользователя:
```
# net ads info -U <user>
```

Дата последней смены пароля учётной записи компьютера будет показана в параметре Last machine account password change.

⁠4.10.4.2. Потеря доверия между машиной и доменом

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

убедиться, что файл keytab (/etc/krb5.keytab) содержит корректную информацию:

# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/work.test.alt@TEST.ALT (aes256-cts-hmac-sha1-96)
   1 host/WORK@TEST.ALT (aes256-cts-hmac-sha1-96)
   1 host/work.test.alt@TEST.ALT (aes128-cts-hmac-sha1-96)
   1 host/WORK@TEST.ALT (aes128-cts-hmac-sha1-96)
   1 host/work.test.alt@TEST.ALT (DEPRECATED:arcfour-hmac)
   1 host/WORK@TEST.ALT (DEPRECATED:arcfour-hmac)
   1 restrictedkrbhost/work.test.alt@TEST.ALT (aes256-cts-hmac-sha1-96)
   1 restrictedkrbhost/WORK@TEST.ALT (aes256-cts-hmac-sha1-96)
   1 restrictedkrbhost/work.test.alt@TEST.ALT (aes128-cts-hmac-sha1-96)
   1 restrictedkrbhost/WORK@TEST.ALT (aes128-cts-hmac-sha1-96)
   1 restrictedkrbhost/work.test.alt@TEST.ALT (DEPRECATED:arcfour-hmac)
   1 restrictedkrbhost/WORK@TEST.ALT (DEPRECATED:arcfour-hmac)
   1 WORK$@TEST.ALT (aes256-cts-hmac-sha1-96)
   1 WORK$@TEST.ALT (aes128-cts-hmac-sha1-96)
   1 WORK$@TEST.ALT (DEPRECATED:arcfour-hmac)

попытаться получить билет Kerberos для учётной записи компьютера (в примере WORK$), используя файл keytab (/etc/krb5.keytab):
```
# kinit -k WORK\$@TEST.ALT
```

убедиться, что билет успешно получен и удалить его:

# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: WORK$@TEST.ALT

Valid starting       Expires              Service principal
21.04.2023 12:25:37  21.04.2023 22:25:37  krbtgt/TEST.ALT@TEST.ALT
    renew until 28.04.2023 12:25:37

# kdestroy -p WORK\$@TEST.ALT

Важно

Следует убедиться, что имя машины в keytab-файле (/etc/krb5.keytab) соответствует реальному имени машины (см. вывод команды hostnamectl).

⁠4.10.5. Восстановление работоспособности

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

обновить систему:

# apt-get update && apt-get dist-upgrade

удалить файл /etc/krb5.keytab;
повторно ввести машину в домен;
убедиться, что конфигурационные файлы соответствуют одному из сценариев: Включение обновления пароля или Отключение обновления пароля;
перезагрузить машину.

⁠Глава 5. Доверительные отношения (Трасты)

5.1. Настройка доверия

5.1.1. Общие сведения
5.1.2. Особенности доверительных отношений в Samba

5.2. Настройка DNS

5.2.1. Два домена Samba
5.2.2. Samba DC и Windows Server с AD

5.3. Создание доверительного отношения

5.3.1. Два домена Samba
5.3.2. Samba AD и Windows Server с AD

5.4. Управление пользователями и группами

5.4.1. Список пользователей и групп
5.4.2. Тестирование аутентификации
5.4.3. Просмотр доверия в Windows

5.5. Использование трастов на LINUX-клиентах

5.5.1. Настройка Winbind
5.5.2. Настройка SSSD

5.6. Удаление доверия

5.6.1. На стороне Samba
5.6.2. На стороне Windows Server с AD

Доверительные отношения (trusts) позволяют аутентифицироваться под пользователями не только текущего домена, но и доверенных.

⁠5.1. Настройка доверия

⁠5.1.1. Общие сведения

Доверительные отношения реализуются в рамках механизма аутентификации. Суть доверительных отношений между двумя доменами сводится к тому, что доверяющий домен (trusting domain) доверяет процесс аутентификации доверенному домену (trusted domain). Пользователь, аутентифицированный доверенным доменом, может получить доступ к ресурсам в доверяющем домене.

Отношения доверия обеспечивают доступ к ресурсам в одном или двух направлениях:

одностороннее доверие — позволяет пользователям и группам из домена A получать доступ к ресурсам в домене Б, но не наоборот. Домен A доверяет домену Б, но домен Б не доверяет домену A. При создании такого доверия нужно указать направление (входящее или исходящее);
двустороннее доверие — позволяет пользователям и группам из домена A получать доступ к ресурсам в домене Б и наоборот. Запросы проверки подлинности могут передаваться между двумя доменами в обоих направлениях. Домен А доверяет домену Б, а домен Б доверяет домену А.

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

транзитивное доверие можно использовать для расширения отношений доверия на другие домены;
нетранзитивное доверие можно использовать для запрета отношений доверия с другими доменами.

Типы доверия:

доверие леса (Forest trust) — связывает леса и все их домены (это двухсторонние или односторонние отношения доверия между разными лесами, всегда являющиеся транзитивными);
внешнее доверие (External trust) — устанавливается между двумя доменами напрямую вне леса (для установки двухстороннего доверия нужно использовать два разнонаправленных доверия, которыми надо связать все требуемые пары доменов).

⁠5.1.2. Особенности доверительных отношений в Samba

Поддерживается:

доверие леса (это доверие может быть установлено между двумя Samba-доменами или Samba-доменом и Windows-доменом);
внешние доверительные отношения (это доверие может быть установлено между двумя Samba-доменами или Samba-доменом и Windows-доменом);
добавление пользователей и групп доверенного домена в группы доверяющего домена (при этом необходимо использовать SID пользователей и групп, чтобы добавить их в свою группу, имя пользователя или имя группы использовать невозможно).

Особенности и ограничения:

не применяются правила фильтрации SID;
доверительные отношения должны быть двусторонними;
не поддерживается выборочная аутентификация (создание таких доверий возможно, но KDC и winbindd всё равно будут их игнорировать);
нельзя создать доверительные отношения между доменами в одном дереве с одним и тем же пространством имён верхнего уровня. NetBIOS имена доменов должны отличаться (домен MYDOMAIN.WIN и MYDOMAIN.NEW будут иметь одинаковое короткое имя — MYDOMAIN, это приведет к невозможности установки доверительных отношений);
в RSAT можно увидеть контейнер foreignSecurityPrincipal для всех добавленных пользователей и групп из доверенного домена. Таким образом Microsoft показывает, что пользователь или группа являются частью доверенного домена;
Winbind на клиентских машинах не распознаёт доверенные домены, что приводит к проблемам с обновлением паролей учетных записей доверенного домена после их истечения. Чтобы устранить эту проблему, необходимо в секцию [global] в файла smb.conf на Linux-клиентах, подключенных через Winbind, добавить опцию:
```
winbind scan trusted domains = yes
```
и перезапустить сервис winbind:
```
# systemctl restart winbind.service
```
при использовании групповой политики (на контроллерах в Win-домене) «Сетевая безопасность: минимальная сеансовая безопасность для серверов на базе NTLM SSP (включая безопасный RPC)» с опцией «требовать сеансовую безопасность NTLMv2» в разделе «Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности» не строится траст между Win-доменом и Samba-доменом. При включении этой политики после построения траста некорректно работают доверительные отношения между Windows-доменом и Samba-доменом. Не выполняется проверка траста (samba-tool domain trust validate) и не выполняется вход на пользователями из доверенного домена на машинах с winbind.
Примечание
После редактирования политики и ее применения в Win-домене необходимо перезапустить сервис samba.

Для управления доверием можно использовать инструмент командной строки samba-tool.

⁠

Таблица 5.1. Команды управления доверием

Команда	Описание	Примечание
domain trust create <домен>	Создать доверие домена или леса	Можно использовать следующие опции: `--type=TYPE` — тип доверия (`external`, `forest`); `--direction=DIRECTION` — направление доверия (`incoming`, `outgoing`, `both`); `--create-location=LOCATION` — где создать объект доверенного домена (`local`, `both`); `--quarantined=yes\|no` — применять к доверию специальные правила фильтрации SID (при `--type=external` по умолчанию `yes`, при `--type=forest` по умолчанию `no`); `-U USERNAME` — имя пользователя.
domain trust modify <домен>	Изменить доверие домена или леса
domain trust delete <домен>	Удалить доверие домена или леса	Можно использовать следующие опции: `--delete-location=LOCATION` — где удалить объект доверенного домена (`local`, `both`); `-U USERNAME` — имя пользователя.
domain trust list	Вывести список доверительных отношений домена
domain trust show <домен>	Показать сведения о доверенном домене
domain trust validate <домен>	Проверить доверие к домену	Можно использовать следующие опции: `--validate-location=LOCATION` — где проверить объект доверенного домена (`local`, `both`); `-U USERNAME` — имя пользователя.

⁠5.2. Настройка DNS

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

Примечание

Пересылка — это механизм, который позволяет серверу направлять запросы на разрешение доменных имён на другие DNS-серверы, если он сам не может их обработать.

Пересылка настраивается в конфигурации DNS-сервера в файле /etc/bind/options.conf:

options {
    forwarders { 8.8.8.8; };
};

При использовании доверительных отношений, системы в одном домене должны уметь находить ресурсы и аутентифицировать пользователей из другого домена. Для этого им нужно корректно определять IP-адреса ресурсов другого домена. Однако, если один DNS-сервер не знает, как разрешить запросы для другого домена, запросы просто не смогут обрабатываться. Решением является условная пересылка, которая перенаправляет запросы для второго домена на соответствующий DNS-сервер.

Условная пересылка (conditional forwarding) — метод, который позволяет направлять запросы на разные серверы в зависимости от домена.

Условная пересылка указывается в файле /etc/bind/options.conf:

zone "trust.dom" in {
    type forward;
    forwarders { 10.64.224.10; };
};

⁠5.2.1. Два домена Samba

⁠

Таблица 5.2. Исходные данные

	Имя домена	Контроллер домена	IP-адрес	ОС контроллера домена	Версия Samba
Домен Linux	`TEST.ALT`	dc1.test.alt	`192.168.0.122`	ALT Server 10.2	4.19.6
Домен Linux	`EXAMPLE.ALT`	s1.example.alt	`192.168.0.172`	ALT Server 10.2	4.19.6
Выделенный DNS-сервер			`192.168.0.150`	ALT Server 10.2

⁠5.2.1.1. Настройка переадресации DNS на DC с BIND9_DLZ

Если используется DNS бэкенд BIND9_DLZ, необходимо добавить информацию о зоне в конец файла /etc/bind/options.conf:

на контроллере домена dc1.test.alt добавить строки:
```
zone "example.alt" {
      type forward;
      forwarders { 192.168.0.172; };
};
```

на контроллере домена s1.example.alt:

zone "test.alt" {
      type forward;
      forwarders { 192.168.0.122; };
};

Перезапустить службу DNS:

# systemctl restart bind.service

Примечание

Если удалённый DNS-сервер не использует DNSSEC и включить проверку DNSSEC на удаленном DNS-сервере нельзя, можно отключить проверку DNSSEC на сервере AD. Для этого необходимо в файле /etc/bind/options.conf в секцию options добавить параметр:

dnssec-validation no;

И перезапустить службу DNS:

# systemctl restart bind.service

⁠5.2.1.2. Настройка переадресации DNS на DC с SAMBA_INTERNAL

Если используется DC с DNS бэкенд SAMBA_INTERNAL, самый простой способ заставить работать разрешение имен — настроить DNS-прокси между двумя доменами. DNS-прокси будет перенаправлять запрос между доменами и внешним DNS-серверами. В примере, в качестве DNS-прокси используется отдельный сервер (IP-адрес 192.168.0.150) с настроенным bind9.

На каждом контроллере домена:

Указать DNS-прокси, как сервер пересылки в файле /etc/samba/smb.conf (в параметре dns forwarder). Например:
```
dns forwarder = 192.168.0.150 8.8.8.8
```
Перезапустить службу samba:
```
# systemctl restart samba
```

На сервере bind9 отредактировать файл /etc/bind/options.conf:

так как SAMBA_INTERNAL не имеет функционала расширения безопасности DNS, необходимо отключить проверку DNSSEC, для этого в секцию options добавить параметр:
```
dnssec-validation no;
```

в конец файла /etc/bind/options.conf (или /etc/bind/ddns.conf) добавить информацию о зонах:

zone "example.alt" {
      type forward;
      forwarders { 192.168.0.172; };
};

zone "test.alt" {
      type forward;
      forwarders { 192.168.0.122; };
};

И перезапустить службу DNS:

# systemctl restart bind.service

⁠5.2.1.3. Проверка конфигурации DNS

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

на контроллере домена dc1.test.alt:

# host -t srv _kerberos._tcp.example.alt
_kerberos._tcp.example.alt has SRV record 0 100 88 s1.example.alt.
# host -t srv _kerberos._tcp.test.alt
_kerberos._tcp.test.alt has SRV record 0 100 88 dc1.test.alt.

на контроллере домена s1.example.alt:

# host -t srv _kerberos._tcp.example.alt
_kerberos._tcp.example.alt has SRV record 0 100 88 s1.example.alt.
# host -t srv _kerberos._tcp.test.alt
_kerberos._tcp.test.alt has SRV record 0 100 88 dc1.test.alt.

Проверить возможность получения билета Kerberos:

на контроллере домена dc1.test.alt:

# kinit administrator@EXAMPLE.ALT
Password for administrator@EXAMPLE.ALT:
# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_eFyZ8Tr
Default principal: administrator@EXAMPLE.ALT

Valid starting       Expires              Service principal
27.03.2024 14:14:36  28.03.2024 00:14:36  krbtgt/TEST.ALT@TEST.ALT
	renew until 28.03.2024 14:14:32

на контроллере домена s1.example.alt:

# kinit administrator@TEST.ALT
Password for administrator@TEST.ALT:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@TEST.ALT

Valid starting       Expires              Service principal
27.03.2024 15:17:50  28.03.2024 01:17:50  krbtgt/TEST.ALT@TEST.ALT
	renew until 28.03.2024 15:17:46

Важно

realm должен быть записан заглавными буквами.

⁠5.2.2. Samba DC и Windows Server с AD

⁠

Таблица 5.3. Исходные данные

	Имя домена	Контроллер домена	IP-адрес	ОС	Уровень работы домена	Версия Samba
Домен Linux	`TEST.ALT`	dc1.test.alt	`192.168.0.122`	ALT Server 10.2	2012_R2	4.19.6
Домен Windows	`WIN.ALT`	DC1.win.alt	`192.168.0.190`	Windows Server 2012	2012R2
Выделенный DNS-сервер			`192.168.0.150`	ALT Server 10.2

⁠5.2.2.1. Windows Server с AD

На AD сервере создать сервер условной пересылки для зоны Samba домена.

В графическом интерфейсе:

Открыть Диспетчер DNS (DNS Manager).
В разделе Серверы условной пересылки (Conditional Forwarders) добавить новый сервер пересылки, указав FQDN или IP-адрес сервера Samba:
Сохранить настройки.

В командной строке:

C:\> dnscmd 127.0.0.1 /ZoneAdd test.alt /Forwarder 192.168.0.122
DNS Server 127.0.0.1 created zone test.alt:

Command completed successfully

Или выполнить следующую команду в сеансе PowerShell для настройки пересылки DNS:

PS C:\Windows\system32> Add-DnsServerConditionalForwarderZone -Name test.alt -MasterServers 192.168.0.122 -ReplicationScope Forest

⁠5.2.2.2. Samba DC с BIND9_DLZ

Если используется DNS бэкенд BIND9_DLZ, добавить в конец файла /etc/bind/options.conf (или /etc/bind/ddns.conf) строки:

zone "win.alt" {
      type forward;
      forwarders { 192.168.0.190; };
};

И перезапустить службу DNS:

# systemctl restart bind.service

Примечание

Если удалённый DNS-сервер не использует DNSSEC и включить проверку DNSSEC на удаленном DNS-сервере нельзя, можно отключить проверку DNSSEC на сервере AD. Для этого необходимо в файл /etc/bind/options.conf в секцию options добавить параметр:

dnssec-validation no;

И перезапустить службу DNS:

# systemctl restart bind.service

⁠5.2.2.3. Samba DC с SAMBA_INTERNAL

На контроллере домена:

указать DNS-прокси, как сервер пересылки в файле /etc/samba/smb.conf (в параметре dns forwarder), например:
```
dns forwarder = 192.168.0.150 8.8.8.8
```
перезапустить службу samba:
```
# systemctl restart samba
```

На выделенном DNS-сервере:

отредактировать файл /etc/bind/options.conf:
- так как SAMBA_INTERNAL не имеет функционала расширения безопасности DNS, необходимо отключить проверку DNSSEC, для этого в секцию options добавить параметр:
  dnssec-validation no;
- в конец файла добавить информацию о зонах:
  zone "win.alt" { type forward; forwarders { 192.168.0.190; }; };
перезапустить службу DNS:
```
# systemctl restart bind.service
```

⁠5.2.2.4. Проверка конфигурации DNS

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

На Samba DC:

Запись отвечающая за работу сервисов Kerberos через UDP и LDAP через TCP:
```
# dig +short -t SRV _kerberos._udp.test.alt
0 100 88 dc1.test.alt.
# dig +short -t SRV _ldap._tcp.test.alt
0 100 389 dc1.test.alt.
```
В выводе команд должен быть отображен список всех серверов.

Наличие записей для работы сервисов AD на DNS-сервере Samba:

# dig +short -t SRV _kerberos._tcp.dc._msdcs.win.alt
0 100 88 dc1.win.alt.
# dig +short -t SRV _ldap._tcp.dc._msdcs.win.alt
0 100 389 dc1.win.alt.

Проверить возможность получения билета Kerberos:

# kinit administrator@WIN.ALT
Password for administrator@WIN.ALT:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@WIN.ALT

Valid starting       Expires              Service principal
27.04.2023 17:42:28  28.04.2023 03:42:28  krbtgt/WIN.ALT@WIN.ALT
    renew until 28.04.2023 17:42:25

Проверить наличие записей DNS-сервере AD:

Запустить утилиту nslookup.exe для поиска служебных записей:
```
C:\> nslookup.exe
> set type=SRV
```

Ввести доменное имя для служебных записей Kerberos через UDP и LDAP через TCP:

> _kerberos._udp.test.alt
_kerberos._udp.test.alt       SRV service location:
    priority                = 0
    weight                  = 100
    port                    = 88
    svr hostname            = dc1.test.alt
…
test.alt
    primary name server = dc1.test.alt
    responsible mail addr = hostmaster.test.alt
    serial = 7
    refresh = 900 (15 mins)
    retry = 600 (10 mins)
    expire = 86400 (1 days)
    default TTL = 3600 (1 hours)
> _ldap._tcp.test.alt
_ldap._tcp.test.alt       SRV service location:
    priority                = 0
    weight                  = 100
    port                    = 389
    svr hostname            = dc1.test.alt
…

⁠5.3. Создание доверительного отношения

⁠5.3.1. Два домена Samba

На стороне Samba AD для создания доверия используется команда:

# samba-tool domain trust create <домен> --type=<тип доверия>
--direction=<направление> --create-location=<место создания> -U <пользователь>

Где:

<домен> — имя удалённого домена, с которым создаётся доверие;
<тип доверия> — определяет тип доверия:
- external — используется для внешнего доверия между доменами, не находящимися в одном лесу. Рекомендуется, если для Linux-клиентов используется SSSD;
- forest — используется для создания доверия между лесами доменов, включая все их дочерние домены. Рекомендуется, если для Linux-клиентов используется Winbind;
--direction=<направление> — определяет направление доверия:
- incoming — доверие только со стороны удалённого домена к текущему;
- outgoing — доверие только от текущего домена к удалённому;
- both — двустороннее доверие;
--create-location=<место создания> — указывает место создания доверительного отношения:
- local — объект доверенного домена будет создан только в локальном домене, доверительные отношения будут зарегистрированы и настроены только со стороны текущего домена, без внесения изменений в конфигурацию удаленного домена;
- both — объект доверенного домена будет создан в обоих доменах;
-U <пользователь> — имя пользователя с правами администратора для удалённого домена.

В данном примере на контроллере домена dc1.test.alt необходимо выполнить команду:

# samba-tool domain trust create EXAMPLE.ALT  --type=forest \
--direction=both --create-location=both -U administrator@EXAMPLE.ALT

LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-1455776928-3410124986-2843404052]
RemoteDC Netbios[S1] DNS[s1.example.alt] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV,FULL_SECRET_DOMAIN_6]
Password for [administrator@EXAMPLE.ALT]:
RemoteDomain Netbios[EXAMPLE] DNS[example.alt] SID[S-1-5-21-3274802069-598906262-3677769431]
Creating remote TDO.
Remote TDO created.
Setting supported encryption types on remote TDO.
Creating local TDO.
Local TDO created
Setting supported encryption types on local TDO.
Setup local forest trust information...
Namespaces[2] TDO[example.alt]:
TLN: Status[Enabled]                  DNS[*.example.alt]
DOM: Status[Enabled]                  DNS[example.alt] Netbios[EXAMPLE] SID[S-1-5-21-3274802069-598906262-3677769431]
Setup remote forest trust information...
Namespaces[2] TDO[test.alt]:
TLN: Status[Enabled]                  DNS[*.test.alt]
DOM: Status[Enabled]                  DNS[test.alt] Netbios[TEST] SID[S-1-5-21-1455776928-3410124986-2843404052]
Validating outgoing trust...
OK: LocalValidation: DC[\\s1.example.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
Validating incoming trust...
OK: RemoteValidation: DC[\\dc1.test.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
Success

Важно

Для входа в доверенный домен через SSSD надо использовать тип связи external, а не forest.

Проверка доверия:

просмотр доверия с dc1.test.alt:

[root@dc1 ~]# samba-tool domain trust show EXAMPLE.ALT
LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-1455776928-3410124986-2843404052]
TrustedDomain:

NetbiosName:    EXAMPLE
DnsName:        example.alt
SID:            S-1-5-21-3274802069-598906262-3677769431
Type:           0x2 (UPLEVEL)
Direction:      0x3 (BOTH)
Attributes:     0x8 (FOREST_TRANSITIVE)
PosixOffset:    0x00000000 (0)
kerb_EncTypes:  0x18 (AES128_CTS_HMAC_SHA1_96,AES256_CTS_HMAC_SHA1_96)
Namespaces[2] TDO[example.alt]:
TLN: Status[Enabled]                  DNS[*.example.alt]
DOM: Status[Enabled]                  DNS[example.alt] Netbios[EXAMPLE] SID[S-1-5-21-3274802069-598906262-3677769431]

просмотр доверия с s1.example.alt:

[root@s1 ~]# samba-tool domain trust show TEST.ALT
LocalDomain Netbios[EXAMPLE] DNS[example.alt] SID[S-1-5-21-3274802069-598906262-3677769431]
TrustedDomain:

NetbiosName:    TEST
DnsName:        test.alt
SID:            S-1-5-21-1455776928-3410124986-2843404052
Type:           0x2 (UPLEVEL)
Direction:      0x3 (BOTH)
Attributes:     0x8 (FOREST_TRANSITIVE)
PosixOffset:    0x00000000 (0)
kerb_EncTypes:  0x18 (AES128_CTS_HMAC_SHA1_96,AES256_CTS_HMAC_SHA1_96)
Namespaces[2] TDO[test.alt]:
TLN: Status[Enabled]                  DNS[*.test.alt]
DOM: Status[Enabled]                  DNS[test.alt] Netbios[TEST] SID[S-1-5-21-1455776928-3410124986-2843404052]

список трастов:

[root@dc1 ~]# samba-tool domain trust list
Type[Forest]   Transitive[Yes] Direction[BOTH]     Name[example.alt]

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

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

[root@dc1 ~]# samba-tool domain trust validate EXAMPLE.ALT -Uadministrator@EXAMPLE.ALT
LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-1455776928-3410124986-2843404052]
LocalTDO Netbios[EXAMPLE] DNS[example.alt] SID[S-1-5-21-3274802069-598906262-3677769431]
OK: LocalValidation: DC[\\s1.example.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
OK: LocalRediscover: DC[\\s1.example.alt] CONNECTION[WERR_OK]
RemoteDC Netbios[S1] DNS[s1.example.alt] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV,FULL_SECRET_DOMAIN_6]
Password for [administrator@EXAMPLE.ALT]:
OK: RemoteValidation: DC[\\dc1.test.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
OK: RemoteRediscover: DC[\\dc1.test.alt] CONNECTION[WERR_OK]

⁠5.3.2. Samba AD и Windows Server с AD

Настройка на стороне Windows:

Открыть Диспетчер серверов, выбрать Средства → Active Directory — Домены и Доверие:
В открывшемся окне в контекстном меню домена выбрать пункт Свойства:
Откроется окно свойств домена. Необходимо перейти во вкладку Отношения доверия и нажать кнопку Создать отношение доверия…:
Будет запущен Мастер создания отношения доверия. Для перехода ко второму шагу следует нажать кнопку Далее:
На втором шаге создания отношения доверия необходимо ввести имя домена Samba AD (в примере TEST.ALT):
На следующем шаге следует выбрать тип доверия:
Далее выбирается направление доверия:
В открывшемся окне Стороны отношения доверия нужно выбрать, на каком из доменов применяется настройка. Если есть права администратора для обоих доменов, можно выбрать пункт Для данного и указанного домена:
Примечание
Если выбрать параметр Только для данного домена:
Необходимо задать Пароль отношения доверия (Trust Secret Key), который в дальнейшем будет использоваться при создании доверительного отношения на стороне Samba AD:
На следующем этапе мастер свяжется с удалённым доменом (если он доступен), и запросит имя и пароль пользователя с правами установки доверительных отношений в домене:
На шаге Уровень проверки подлинности исходящего доверия — Локальный лес следует выбрать Проверка подлинности в лесу:
На шаге Уровень проверки подлинности исходящего доверия — Указанный лес также следует выбрать пункт Проверка подлинности в лесу.
В окне Выбор доверия завершен мастер выдаст уведомление о том, что готов создать новое отношение доверия, и покажет краткую сводку с выбранными параметрами. Если согласиться с параметрами, то должно появиться уведомление о том, что создание доверия завершено:
После нажатия кнопки Далее появится окно Подтверждение исходящего доверия, а после него Подтверждение входящего доверия. Здесь можно оставить выбранным пункт Нет, не подтверждаю это исходящее/входящее отношение доверие, так как на стороне Samba DC доверие ещё не создавалось:
В результате будут получены двухсторонние доверительные отношения между доменами:

На стороне Samba AD для создания доверия необходимо выполнить команду:

# samba-tool domain trust create win.alt --type=forest \
--direction=both --create-location=both -Uadministrator@WIN

При появлении запроса необходимо ввести пароль администратора.

Важно

Для входа в доверенный домен через SSSD следует использовать тип связи external, а не forest.

Если все настроено верно, будет установлено доверие к домену AD:

LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-3848605173-1839566900-710408900]
RemoteDC Netbios[DC1] DNS[DC1.win.alt] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV,FULL_SECRET_DOMAIN_6,ADS_WEB_SERVICE,DS_8,__unknown_00008000__]
Password for [administrator@WIN]:
RemoteDomain Netbios[WIN] DNS[win.alt] SID[S-1-5-21-212759798-1661061060-862600140]
Creating local TDO.
Local TDO created
Setting supported encryption types on local TDO.
Setup local forest trust information...
Namespaces[2] TDO[win.alt]:
TLN: Status[Enabled]                  DNS[*.win.alt]
DOM: Status[Enabled]                  DNS[win.alt] Netbios[WIN] SID[S-1-5-21-212759798-1661061060-862600140]
Validating outgoing trust...
OK: LocalValidation: DC[\\DC1.win.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
Validating incoming trust…
OK: RemoteValidation: DC[\\dc1.test.alt] CONNECTION[WERR_OK] TRUST[WEER_OK] VERIFY_STATUS_RETURNED
Success.

В случае использования Trust Secret Key в параметре --create-location нужно заменить опцию both на local. Samba DC прежде чем создать доверительные отношения сначала запросит Trust Key (Incoming Trust Password/Outgoing Trust Password), созданный ранее при настройке в Windows:

# samba-tool domain trust create win.alt --type=forest \
--direction=both --create-location=local -Uadministrator@WIN

New Incoming Trust Password:
Retype Incoming Trust Password:
New Outgoing Trust Password:
Retype Outgoing Trust Password:
LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-3848605173-1839566900-710408900]
RemoteDC Netbios[DC1] DNS[DC1.win.alt] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,…]
Password for [administrator@WIN]:
…

Проверка доверия с dc1.test.alt:

просмотр доверия:

# samba-tool domain trust show WIN.ALT
LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-3848605173-1839566900-710408900]
TrustedDomain:

NetbiosName:    WIN
DnsName:        win.alt
SID:            S-1-5-21-212759798-1661061060-862600140
Type:           0x2 (UPLEVEL)
Direction:      0x3 (BOTH)
Attributes:     0x8 (FOREST_TRANSITIVE)
PosixOffset:    0x00000000 (0)
kerb_EncTypes:  0x18 (AES128_CTS_HMAC_SHA1_96,AES256_CTS_HMAC_SHA1_96)
Namespaces[2] TDO[win.alt]:
TLN: Status[Enabled]                  DNS[*.win.alt]
DOM: Status[Enabled]                  DNS[win.alt] Netbios[WIN] SID[S-1-5-21-212759798-1661061060-862600140]

список трастов:

# samba-tool domain trust list
Type[Forest]   Transitive[Yes] Direction[BOTH]     Name[win.alt]

# samba-tool domain trust validate win.alt -Uadministrator@WIN
LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-3848605173-1839566900-710408900]
LocalTDO Netbios[WIN] DNS[win.alt] SID[S-1-5-21-212759798-1661061060-862600140]
OK: LocalValidation: DC[\\DC1.win.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
OK: LocalRediscover: DC[\\DC1.win.alt] CONNECTION[WERR_OK]
RemoteDC Netbios[DC1] DNS[DC1.win.alt] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV,FULL_SECRET_DOMAIN_6,ADS_WEB_SERVICE,DS_8,__unknown_00008000__]
Password for [administrator@WIN]:
OK: RemoteValidation: DC[\\dc2.test.alt] CONNECTION[WERR_OK] TRUST[WERR_OK] VERIFY_STATUS_RETURNED
OK: RemoteRediscover: DC[\\dc2.test.alt] CONNECTION[WERR_OK]

⁠5.4. Управление пользователями и группами

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

Примечание

Предварительно необходимо создать несколько пользователей и групп в обоих доменах (см. Управление пользователями и группами).

⁠5.4.1. Список пользователей и групп

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

команды выполняются на контроллере домена dc1.test.alt:

# wbinfo -u --domain=EXAMPLE.ALT
# wbinfo -u --domain=TEST.ALT
TEST\administrator
TEST\guest
TEST\krbtgt
TEST\dns-dc1
TEST\ivanov

команды выполняются на контроллере домена s1.example.alt:

# wbinfo -u --domain=EXAMPLE.ALT
EXAMPLE\administrator
EXAMPLE\guest
EXAMPLE\krbtgt
EXAMPLE\dns-s1
EXAMPLE\kim
# wbinfo -u --domain=TEST.ALT

Для получения списка всех пользователей можно выполнить LDAP-запрос с помощью команды samba-tool. Пример получения списка пользователей из обоих доменов на контроллере домена dc1.test.alt:

# samba-tool user list -H ldap://s1 -Uadministrator@EXAMPLE.ALT
Password for [administrator@EXAMPLE.ALT]:
dns-s1
krbtgt
Administrator
Guest
kim
# samba-tool user list -H ldap://dc1 -Uadministrator@TEST.ALT
Password for [administrator@TEST.ALT]:
dns-dc1
krbtgt
Guest
Administrator
ivanov

Получение дополнительной информации о доменах (в примерах команды выполняются на контроллере домена dc1.test.alt):

получение списка всех доменов:
```
# wbinfo --all-domains
BUILTIN
TEST
EXAMPLE
```
вывод основного домена (домен, к которому в данный момент подключена система):
```
# wbinfo --own-domain
TEST
```
вывод списка доменов, которые находятся в состоянии доверия с текущим доменом:
```
# wbinfo --trusted-domains
BUILTIN
TEST
EXAMPLE
```
отображение текущего состояния подключения Winbind к различным доменам:
```
# wbinfo --online-status
BUILTIN : active connection
TEST : active connection
EXAMPLE : active connection
```

Получение SID пользователей и групп (в примере команды выполняются на контроллере домена dc1.test.alt):

# wbinfo -n TEST\\ivanov
S-1-5-21-1455776928-3410124986-2843404052-1105 SID_USER (1)

# wbinfo -n EXAMPLE\\kim
S-1-5-21-3274802069-598906262-3677769431-1104 SID_USER (1)

# wbinfo -n TEST\\office
S-1-5-21-1455776928-3410124986-2843404052-1107 SID_DOM_GROUP (2)

# wbinfo -n EXAMPLE\\office2
S-1-5-21-3274802069-598906262-3677769431-1107 SID_DOM_GROUP (2)

# wbinfo -i TEST\\ivanov
TEST.ALT\ivanov:*:3000022:100::/home/TEST.ALT/ivanov:/bin/false

# wbinfo -i EXAMPLE\\kim
EXAMPLE\kim:*:3000020:3000021::/home/EXAMPLE/kim:/bin/false

⁠5.4.2. Тестирование аутентификации

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

wbinfo попытается авторизовать пользователя. Первой проверкой будет аутентификация по паролю с открытым текстом. Этот тип аутентификации применяется, когда пользователь входит в систему локально (plaintext не означает, что пароль будет отправлен без шифрования, это просто название процесса входа в систему). Вторая проверка — аутентификация по паролю запрос/ответ. Этот тип аутентификации использует NTLM или Kerberos.

Проверка методов аутентификации (в примере команды выполняются на контроллере домена dc1.test.alt):

# wbinfo -a TEST\\ivanov
Enter TEST\ivanov's password:
plaintext password authentication succeeded
Enter TEST\ivanov's password:
challenge/response password authentication succeeded


# wbinfo -a EXAMPLE\\kim
Enter EXAMPLE\kim's password:
plaintext password authentication succeeded
Enter EXAMPLE\kim's password:
challenge/response password authentication succeeded

Посмотреть какие контроллеры домена отвечают за аутентификацию:

# wbinfo --ping-dc
checking the NETLOGON for domain[TEST] dc connection to "dc1.test.alt" succeeded

# wbinfo --ping-dc --domain=EXAMPLE.ALT
checking the NETLOGON for domain[EXAMPLE.ALT] dc connection to "s1.example.alt" succeeded

Назначение пользователей и групп из доверенных доменов в группу доверяющего домена:

# wbinfo -n EXAMPLE\\kim
S-1-5-21-3274802069-598906262-3677769431-1104 SID_USER (1)

# samba-tool group addmembers office S-1-5-21-3274802069-598906262-3677769431-1104
Added members to group office

# wbinfo -n EXAMPLE\\office2
S-1-5-21-3274802069-598906262-3677769431-1107 SID_DOM_GROUP (2)

# samba-tool group addmembers office S-1-5-21-3274802069-598906262-3677769431-1107
Added members to group office

# samba-tool group listmembers office
S-1-5-21-3274802069-598906262-3677769431-1104
ivanov
S-1-5-21-3274802069-598906262-3677769431-1107

⁠5.4.3. Просмотр доверия в Windows

Модуль RSAT (см. Установка RSAT) «Active Directory — домены и доверие» («Active Directory — Domain and Trusts») позволяет проверить состояние отношений доверия между доменами:

Модуль RSAT Active Directory — Домены и доверие

В модуле RSAT «Active Directory — пользователи и компьютеры» («Active Directory — Users and Computers») можно просмотреть список пользователей группы:

Модуль RSAT Active Directory — пользователи и компьютеры

⁠5.5. Использование трастов на LINUX-клиентах

Если необходимо использовать пользователей из обоих доменов (установлены двухсторонние доверительные отношения с типом связи Лес), то рабочую станцию с ОС Альт следует вводить в домен через Winbind (см. Подключение к AD с помощью Samba Winbind).

⁠5.5.1. Настройка Winbind

Важно правильно спланировать диапазоны идентификаторов (UID и GID), назначаемых пользователям и группам (см. Планирование и настройка диапазонов идентификаторов UID и GID (Winbind/IDMapping)).

На машине, введённой в домен, необходимо в файле smb.conf установить ID-маппинг для обоих доменов (backend = rid/tdb).

Пример файла smb.conf на машине введённой в домен example.alt:

[global]
        security = ads
        realm = EXAMPLE.ALT
        workgroup = EXAMPLE
        netbios name = WORK1
        template shell = /bin/bash
        kerberos method = system keytab
        wins support = no
        winbind use default domain = yes
        winbind enum users = no
        winbind enum groups = no
        template homedir = /home/EXAMPLE.ALT/%U
        winbind refresh tickets = yes
        winbind offline logon = yes
        idmap config * : range = 3000-7999
        idmap config * : backend = tdb

        idmap config EXAMPLE : backend = rid
        idmap config EXAMPLE : range = 10000-999999
        idmap config TEST : backend = rid
        idmap config TEST : range = 1000000-9999999

После перезапуска smbd и winbind можно проверить, есть ли возможность просматривать пользователей из обоих доменов:

# net rpc trustdom list -Uadministrator
Password for [EXAMPLE\administrator]:
Trusted domains list:

TEST                S-1-5-21-1455776928-3410124986-2843404052

Trusting domains list:

TEST                S-1-5-21-1455776928-3410124986-2843404052

С помощью команды winbind можно получить информацию о пользователях из обоих доменов и проверить доступность доменов:

# wbinfo -n TEST\\ivanov
S-1-5-21-1455776928-3410124986-2843404052-1105 SID_USER (1)

# wbinfo -n EXAMPLE\\kim
S-1-5-21-3274802069-598906262-3677769431-1104 SID_USER (1)

Для проверки доступности пользователей и групп из доверенных доменов можно использовать getent:

# getent group TEST\\office
TEST\office:*:1001106:

# getent group EXAMPLE\\office2
office2:*:11107:

# getent passwd TEST\\ivanov
TEST\ivanov:*:1001105:1000513::/home/EXAMPLE.ALT/ivanov:/bin/bash

# getent passwd EXAMPLE\\kim
kim:*:11125:10001:Олег Ким:/home/EXAMPLE.ALT/kim:/bin/bash

Примечание

Для авторизации в доверенном домене следует вводить учётные данные пользователя в формате DOMAIN\user:

Ввод логина учетной записи пользователя доверенного домена

Проверка входа по SSH пользователями из обоих доменов:

$ ssh TEST\\ivanov@192.168.0.126
TEST\ivanov@192.168.0.126's password:
[TEST\ivanov@work1 ~]$ exit
выход
Connection to 192.168.0.126 closed.

$ ssh EXAMPLE\\kim@192.168.0.126
EXAMPLE\kim@192.168.0.126's password:
[kim@work1 ~]$ exit
выход
Connection to 192.168.0.126 closed.

⁠5.5.2. Настройка SSSD

Особенности:

SSSD требует ручного указания настроек для каждого трастового домена в клиентской конфигурации в файле /etc/sssd/sssd.conf;
SSSD не поддерживает трасты уровня леса (Forest Trusts), что ограничивает его возможности при работе с многоуровневыми лесами доменов. Однако, для большинства стандартных трастов (External Trust) SSSD может быть применен;
по умолчанию пул UID/GID для сопоставления SID в SSSD имеет ограниченный размер. Для больших доменов с количеством пользователей более 200 тысяч этот пул необходимо расширять вручную.
При стандартной конфигурации настраивается 10000 срезов, каждый из которых может содержать до 200000 идентификаторов, начиная от 200000 и до 2000200000.
Из общего диапазона, размером 2 миллиарда под каждый домен выделяется срез ID размером 200000, каждому домену может соответствовать только один единственный срез.
Для увеличения размера среза в конфигурации SSSD используются параметры:
- ldap_idmap_range_min — нижняя (включительно) граница диапазона идентификаторов;
- ldap_idmap_range_max — верхняя (не включительно) граница диапазона идентификаторов;
- ldap_idmap_range_size — количество идентификаторов, доступных для каждого среза. Значение должно быть не меньше значения максимального RID пользователя, запланированного для использования на сервере AD.
Эти параметры позволяют адаптировать пул UID/GID под нужды домена. Однако, увеличивая размер среза, необходимо уменьшать количество срезов, что увеличивает вероятность коллизий (по умолчанию вероятность коллизии одного конкретного домена с другим составляет 1/10000).

На машине введённой в домен необходимо в файл /etc/sssd/sssd.conf добавить доверенный домен:

[domain/EXAMPLE.ALT/TEST.ALT]
use_fully_qualified_names = false

и перезапустить sssd:

# systemctl restart sssd

После перезапуска sssd можно проверить, есть ли возможность просматривать пользователей из обоих доменов:

# getent passwd ivanov
ivanov:*:1855401105:1855400513:Иван Иванов:/home/TEST.ALT/ivanov:/bin/bash

# getent passwd kim

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

# sssctl domain-list
 EXAMPLE.ALT
 TEST.ALT

# sssctl domain-status EXAMPLE.ALT
 Online status: Online

 Active servers:
 AD Global Catalog: s1.example.alt
 AD Domain Controller: s1.example.alt

 Discovered AD Global Catalog servers:
 - s1.example.alt

 Discovered AD Domain Controller servers:
 - s1.example.alt

В случае проблем с авторизацией пользователем из доверенного домена, в /etc/sssd/sssd.conf в секцию основного домена можно вписать:

krb5_validate = false

⁠5.6. Удаление доверия

⁠5.6.1. На стороне Samba

Пример удаления доверия на контроллере домена dc1.test.alt:

# samba-tool domain trust delete EXAMPLE.ALT -U administrator@EXAMPLE.ALT
LocalDomain Netbios[TEST] DNS[test.alt] SID[S-1-5-21-1455776928-3410124986-2843404052]
RemoteDC Netbios[S1] DNS[s1.example.alt] ServerType[PDC,GC,LDAP,DS,KDC,TIMESERV,CLOSEST,WRITABLE,GOOD_TIMESERV,FULL_SECRET_DOMAIN_6]
Password for [administrator@EXAMPLE.ALT]:
RemoteDomain Netbios[EXAMPLE] DNS[example.alt] SID[S-1-5-21-3274802069-598906262-3677769431]
RemoteTDO deleted.

Проверка:

# samba-tool domain trust list

⁠5.6.2. На стороне Windows Server с AD

Удаление доверия:

Открыть Диспетчер серверов, выбрать Средства → Active Directory — Домены и Доверие:
В открывшемся окне в контекстном меню домена выбрать пункт Свойства:
Откроется окно свойств домена. Необходимо перейти во вкладку Отношения доверия и нажать кнопку Создать отношение доверия…:
В группе Домены, которым доверяет этот домен (исх. отношения доверия) или группе Домены, которые доверяют этому домену (вх. отношения доверия) выбрать доверие, которое требуется удалить, а затем нажать кнопку Удалить.
В открывшемся окне выбрать где нужно удалить доверие и нажать кнопку ОК.
При выборе параметра Нет, удалить отношение доверия только в локальном домене, рекомендуется повторить эту процедуру для домена второй стороны. При выборе параметра Да, удалить отношение доверия в локальном и другом доменах, необходимо будет ввести учетную запись и пароль администратора для домена второй стороны.

⁠Глава 6. Администрирование Samba

6.1. Управление пользователями и группами

6.1.1. В ADMC
6.1.2. С помощью samba-tool

6.2. Администрирование DNS

6.2.1. DNS-записи при вводе машины в домен
6.2.2. Утилита samba-tool
6.2.3. nsupdate
6.2.4. Oснастка DNS в RSAT
6.2.5. Динамическое обновление DNS-записей
6.2.6. Обновление IP-адресов вручную
6.2.7. Известные проблемы

6.3. Администрирование сайтов и подсетей

6.3.1. Утилита samba-tool

6.4. Управление парольными политиками

6.4.1. Глобальные парольные политики
6.4.2. Объекты настроек паролей (PSO)

6.5. Резервное копирование и восстановление Samba AD DC

6.5.1. Резервное копирование и восстановление из резервной копии
6.5.2. Восстановление произвольного контроллера домена после фатального сбоя

6.6. Роли FSMO

6.6.1. Семь ролей FSMO
6.6.2. Просмотр и передача ролей FSMO

6.7. Настройка Samba для привязки к определённым интерфейсам

6.8. Создание keytab-файла

6.8.1. Назначение и формат SPN
6.8.2. Создание SPN и генерация keytab с помощью samba-tool

6.9. Настройка DHCP-сервера для обновления DNS-записей

6.9.1. Настройка DHCP-сервера
6.9.2. Настройка переключения DHCP

6.10. Аутентификация других сервисов в Samba AD

6.10.1. Настройка аутентификации Kerberos для веб-сервера Apache
6.10.2. Настройка аутентификации Kerberos для веб-сервера Nginx
6.10.3. Настройка браузеров для SSO

6.11. Distributed File System

6.11.1. Пространство DFS-имен
6.11.2. Настройка DFS на сервере Samba

6.12. Настройка SSSD

6.12.1. Журналирование SSSD
6.12.2. Настройки SSSD в ЦУС
6.12.3. Включение автономной аутентификации

6.13. Файловый сервер

6.14. Монтирование общих ресурсов samba

6.14.1. Подключение с использованием gio
6.14.2. Подключение с использованием pam_mount
6.14.3. Подключение с использованием Autofs

6.15. Журналирование в Samba

6.15.1. Настройка бэкендов
6.15.2. Настройка файлов журнала
6.15.3. Уровни журналирования
6.15.4. Настройка ведения журнала аудита
6.15.5. Интерпретация журналов аудита JSON

6.16. Усиление безопасности DC

6.16.1. Возможность анонимного получения списка пользователей, групп
6.16.2. Отключение Netbios
6.16.3. Отключение роли сервера печати
6.16.4. Отключение NTLMv1
6.16.5. Генерация дополнительных хешей паролей
6.16.6. Защита DNS-записей wpad и isatap
6.16.7. Ограничение диапазона динамических портов
6.16.8. Аудит запросов к каталогам SYSVOL и NetLogon
6.16.9. Отправка логов аудита в rsyslog

6.17. Планирование и настройка диапазонов идентификаторов UID и GID (Winbind/IDMapping)

6.17.1. Планирование диапазонов идентификаторов
6.17.2. Домен * по умолчанию
6.17.3. Использование tdb
6.17.4. Использование ad
6.17.5. Использование rid
6.17.6. Использование autorid

6.18. Установка RSAT

6.18.1. Windows Server
6.18.2. Windows 10 (1809 и более поздних версиях)
6.18.3. Windows Vista и 7

6.19. Инструменты командной строки

6.19.1. samba-tool
6.19.2. wbinfo
6.19.3. net
6.19.4. adcli
6.19.5. ldapsearch
6.19.6. sssctl
6.19.7. testparm

6.20. Конфигурационные файлы

6.20.1. smb.conf
6.20.2. krb5.conf
6.20.3. sssd.conf
6.20.4. resolv.conf
6.20.5. Bind

⁠6.1. Управление пользователями и группами

⁠6.1.1. В ADMC

Для управления пользователями и группами в «Альт Домен» можно использовать модуль удалённого управления базой данных конфигурации (ADMC). Подробнее см. Модуль удалённого управления базой данных конфигурации.

⁠6.1.2. С помощью samba-tool

Для управления пользователями и группами в «Альт Домен» можно использовать инструмент командной строки samba-tool.

Примечание

Для выполнения команды на удаленном компьютере можно использовать опцию -H или --URL=. Например:

# samba-tool user add domainuser Qwerty1 -H ldap://<DC> -Uadministrator

По умолчанию в качестве значения опции -H передается текущий узел в формате ldap://<имя узла>.

⁠

Таблица 6.1. Команды samba-tool для управления пользователями

Команда	Описание	Примечание
user add <имя пользователя> [<пароль>] [опции]	Создать нового пользователя в AD	Переданное в команде значение <имя пользователя> интерпретируется как имя учетной записи SAM (значение атрибута sAMaccountName). Оно должно быть уникальным. Некоторые опции: `--surname` — фамилия пользователя; `--given-name` — имя пользователя; `--initials` — инициалы; `--must-change-at-next-login` — пользователь должен изменить пароль при первом входе в домен; `--random-password` — сформировать пароль случайным образом; `--smartcard-required` — требовать наличие смарт-карты при входе в интерактивном режиме; `--use-username-as-cn` — включить принудительное использование имени пользователя в качестве общего имени (CN); `--userou` — имя (DN) альтернативного расположения (без domainDN), в котором будет создан пользователь вместо используемого по умолчанию CN=Users); `--company` — компания пользователя; `--department` — подразделение, к которому относится пользователь; `--description` — информация о пользователе; `--mail-address` — адрес электронной почты пользователя; `--rfc2307-from-nss` — включить копирования атрибутов пользователя Unix из диспетчера службы имен (NSS); значение параметра переопределяется в случае явного задания числового идентификатора пользователя (UID), числового идентификатора основной группы пользователя (GID), информации о пользователе (GECOS) или интерпретатора команд, который должен запускаться при входе пользователя в систему (shell); `--nis-domain` — домен службы сетевой информации (NIS) для пользователя (Unix/RFC 2307); `--unix-home` — дс пользователя (Unix/RFC 2307); `--uid` — имя пользователя (Unix/RFC 2307); `--uid-number` — уникальный числовой идентификатор пользователя (Unix/RFC 2307); `--gid-number` — числовой идентификатор основной группы пользователя (Unix/RFC 2307); `--gecos` — информация о пользователе в поле GECOS (Unix/RFC 2307); `--login-shell` — оболочка (shell), которая должна запускаться при входе в систему пользователя (Unix/RFC 2307).
user create <имя пользователя> [<пароль>] [опции]	Создать нового пользователя в AD	Команда доступна только в целях совместимости. Вместо этой команды рекомендуется использовать команду `samba-tool user add`
user delete <имя пользователя> [опции]	Удалить существующего пользователя	При удалении учетной записи также удаляются все связанные с нею разрешения, права и членства в группах.
user disable (<имя пользователя>\| --filter <фильтр>) [опции]	Отключить пользовательский аккаунт	Параметры вызова: `--filter` — LDAP-фильтр для поиска объектов в домене.
user edit <имя пользователя> [опции]	Редактировать объект пользовательского аккаунта AD	В опции `--editor=<редактор>` можно указать редактор (по умолчанию vi)
user enable (<имя пользователя>\| --filter <фильтр>) [опции]	Включить пользовательский аккаунт	Параметры вызова: `--filter` — LDAP-фильтр для поиска объектов в домене.
user list [опции]	Вывести список пользователей	По умолчанию выводятся sAMAccountNames пользователей. Можно использовать следующие опции: `--full-dn` — показать различающиеся имена пользователей (CN) вместо sAMAccountNames; `-b BASE_DN\|--base-dn=BASE_DN` — вывести пользователей с указанным базовым DN; `--hide-expired` — не выводить просроченные учётные записи пользователей; `--hide-disabled` — не выводить отключенные учётные записи пользователей.
user setprimarygroup <имя пользователя> <имя группы> [опции]	Установить основную группу для учётной записи пользователя
user getgroups <имя пользователя> [опции]	Вывести список групп, в которые входит учётная запись пользователя напрямую	Можно использовать следующие опции: `--full-dn` — показать в списке вместо имен групп SAM (sAMAccountName) их полные уникальные имена (Distinguished Name, DN).
user show <имя пользователя> [опции]	Вывести атрибуты учетной записи	В опции `--attributes=USER_ATTRS` можно указать, разделённый запятыми, список атрибутов, значения которых требуется отобразить. Для вывода скрытых атрибутов, их необходимо явно указать в параметре `--attributes`>
user move <имя пользователя> <контейнер> [опции]	Переместить учётную запись пользователя в указанную организационную единицу или контейнер	Имя пользователя указывается в команде в формате sAMAccountName. Имя организационной единицы или контейнера можно указать как полное DN, так и без компонента domainDN.
user password [опции]	Изменить пароль текущей учетной записи (пользователя, прошедшего аутентификацию)	Если пароль не передается в открытом виде в значении параметра `--newpassword`, пользователь получит запрос на ввод пароля в командной строке.
user rename <имя пользователя> [опции]	Переименовать пользователя и изменить его атрибуты	По умолчанию выводятся sAMAccountNames пользователей. Для удаления атрибута следует использовать пустое значение атрибута. Имя пользователя указывается в команде в формате sAMAccountName. Некоторые опции: `--surname` — новая фамилия; `--given-name` — новое имя; `--initials` — новые инициалы; `--force-new-cn` — новый CN (вместо использования комбинации имени, инициалов и фамилии); `--reset-cn` — установить CN на комбинацию имени, инициалов и фамилии по умолчанию; `--display-name` — новое отображаемое имя; `--mail-address` — новая электронная почта; `--samaccountname=SAMACCOUNTNAME` — новое имя для входа (sAMAccountName); `--upn` — новое основное имя пользователя.
user setexpiry (<имя пользователя>\| --filter <фильтр>) [опции]	Установить срок действия для учётной записи пользователя	По истечении заданного периода учетная запись отключается; пользователь не может получать доступ к ресурсам домена. При этом сохраняются связанные с учетной записью разрешения, права и членства. Параметры вызова: `--filter` — LDAP-фильтр для поиска объектов в домене; `--days` — продолжительность периода в днях; `--noexpiry` — период действия неограничен.
user setpassword (<имя пользователя>\| --filter <фильтр>) [опции]	Установить или сбросить пароль учетной записи пользователя	Если пароль не передается в открытом виде в значении параметра `--newpassword`, пользователь получит запрос на ввод пароля в командной строке. Параметры вызова: `--filter` — LDAP-фильтр для поиска объектов в домене; `--newpassword` — новый пароль; `--must-change-at-next-login` — пользователь должен изменить пароль при первом входе в домен; `--random-password` — сформировать пароль случайным образом; `--smartcard-required` — требовать наличие смарт-карты при входе в интерактивном режиме.
user unlock (<имя пользователя>\| --filter <фильтр>) [опции]	Разблокировать учётную запись пользователя в домене	Параметры вызова: `--filter` — LDAP-фильтр для поиска объектов в домене.
user getpassword (<имя пользователя>\| --filter <фильтр>) [опции]	Получить атрибуты пароля учётной записи пользователя	Параметры вызова: `--filter` — LDAP-фильтр для поиска объектов в домене; `--attributes` — атрибуты (через запятую), которые требуется вывести или передать скрипту, заданному в параметре `--script`. В параметре могут передаваться любые атрибуты, заданные в схеме каталога, а также следующие виртуальные атрибуты: virtualClearTextUTF16, virtualClearTextUTF8, virtualCryptSHA256, virtualCryptSHA512, virtualKerberosSalt, virtualSSHA, virtualSambaGPG, virtualDigest01..29; `--decrypt-samba-gpg` — дешифровать пароль SambaGPG (должен быть установлен пакет python3-module-gpg).
user syncpasswords [--cache-ldb-initialize] [опции]	Синхронизировать пароли всех учётных записей пользователей с помощью дополнительного сценария	Эта команда должна выполняться только на одном контроллере домена (обычно на PDC). В первый раз команда должна выполняться с параметром, обеспечивающим инициализацию кеша: `--cache-ldb-initialize`. Для корректной инициализации кеша требуется передать список атрибутов в параметре `--attributes`.

Примечание

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

# samba-tool user add --help

Примеры:

создать пользователя ivanov в подразделении KDE, пользователь должен изменить пароль при следующем входе в систему:

# samba-tool user add ivanov --given-name='Иван' \
--surname='Иванов' --mail-address='ivanov@test.alt' \
--userou='OU=KDE' --must-change-at-next-login

New Password:
Retype Password:
User 'ivanov' added successfully

создать пользователя kim со случайным паролем, с указанием удаленного LDAP-сервера, пользователь должен изменить пароль при следующем входе в систему:
```
# samba-tool user add kim --given-name='Виталий' \
--surname='Ким' --mail-address='kim@test.alt' \
--must-change-at-next-login  --random-password \
-H ldap://dc2.test.alt -U administrator

Password for [TEST\administrator]:
User 'kim' added successfully
```
установить, что срок действия пароля пользователя ivanov никогда не истекает:
```
# samba-tool user setexpiry ivanov --noexpiry

Expiry for user 'ivanov' disabled.
```
задать 20-дневный период действия (начиная с текущей даты) для учетной записи kim:
```
# samba-tool user setexpiry kim --days=20

Expiry for user 'kim' set to 20 days.
```
просмотреть список учётных записей пользователей:
```
# samba-tool user list
Guest
ivanov
Administrator
krbtgt
kim
```
отключить пользователя ivanov:
```
# samba-tool user disable ivanov
```
включить всех пользователей, почтовый ящик которых начинается на k:
```
# samba-tool user enable --filter=mail=k*
Enabled user 'mail=k*'
```

изменить пароль пользователя ivanov:

# samba-tool user setpassword ivanov

New Password:
Retype Password:
Changed password OK

переместить пользователя kim в подразделение KDE:

# samba-tool user move ivanov 'OU=KDE'

Moved user "kim" into "OU=KDE,DC=test,DC=alt"

получить информацию о пароле пользователя ivanov:

# samba-tool user getpassword ivanov \
--attributes=pwdLastSet,virtualClearTextUTF8

dn: CN=Иван Иванов,OU=TEST,DC=test,DC=alt
pwdLastSet: 133628348830281440

Got password OK

удалить пользователя ivanov:

# samba-tool user delete ivanov

Deleted user ivanov

Предупреждение

Не следует допускать одинаковых имён для пользователя и компьютера, это может привести к коллизиям (например, такого пользователя нельзя добавить в группу). Если компьютер с таким именем заведён, удалить его можно командой: pdbedit -x -m имя

Примечание

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

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

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

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

⁠

Таблица 6.2. Команды samba-tool для управления группами

Команда	Описание	Примечание
group add <имя группы> [опции]	Создать новую группу	Переданное в команде значение <имя группы> интерпретируется как имя учетной записи SAM (значение атрибута sAMaccountName). Оно должно быть уникальным. Некоторые опции: `--groupou` — имя (DN) альтернативного расположения (без domainDN), в котором будет создана группа (вместо используемого по умолчанию CN=Users); `--group-scope` — область действия, возможные значения: Domain, Global, Universal; `--group-type` — тип группы, возможные значения: Security, Distribution; `--description` — описание группы; `--mail-address` — адрес электронной почты группы; `--notes` — дополнительная информация; `--gid-number` — числовой идентификатор группы Unix/RFC 2307; `--nis-domain` — домен службы сетевой информации (NIS); `--special` — используется для создания группы безопасности с именем Protected Users.
group create <имя группы> [опции]	Создать новую группу	Доступна только в целях совместимости. Рекомендуется вместо этой команды использовать команду `samba-tool group add`
group addmembers <имя группы> (<список участников>\|--member-dn=<member-dn>) [опции]	Добавить участников в группу	Команда позволяет добавить в группу одного или нескольких участников (указанных через запятую). В качестве участника группы может выступать учетная запись пользователя, учетная запись компьютера или другая группа, существующая в домене. Опции: `--member-dn` — уникальное составное имя (DN) добавляемого в группу нового участника (значение опции `--object-types` игнорируется); `--object-types` — список типов объектов (через запятую); указанные типы используются в качестве фильтра при выполнении поиска для указанных в команде участников; возможные значения: user, group, computer, serviceaccount, contact, all; значение по умолчанию — user,group,computer; `--member-base` — базовое уникальное имя (DN) для поиска участников группы; значение по умолчанию — уникальное имя (DN) домена.
group delete <имя группы> [опции]	Удалить группу	Операция удаления является необратимой. При удалении группы также удаляются все связанные с нею разрешения и права, а также унаследованные от нее разрешения и права участников.
group edit <имя группы> [опции]	Редактировать объект группы	В опции `--editor=<редактор>` можно указать редактор (по умолчанию vi)
group addunixattrs <имя группы> <gidnumber> [опции]	Добавить атрибуты Unix/RFC 2307 для группы	Для использования этих атрибутов для сопоставления UID/GID в конфигурации (`smb.conf`) должен быть задан параметр `idmap_ldp:use rfc2307 = Yes`
group list [опции]	Вывести список групп	По умолчанию выводится список имен учетных записей SAM (sAMAccountName). Можно использовать следующие опции: `--full-dn` — выводить уникальные имена (DN) вместо sAMAccountNames; `b BASE_DN\|--base-dn=BASE_DN` — выводить в списке только группы с указанным базовым уникальным именем (DN).
group listmembers <имя группы> [опции]	Вывести список участников данной группы	По умолчанию выводятся sAMAccountNames участников. Если sAMAccountName недоступен, будет использоваться CN. Можно использовать следующие опции: `--full-dn` — показать различающиеся имена участников (CN) вместо sAMAccountNames; `--hide-expired` — не выводить членов группы с истекшим сроком действия; `--hide-disabled` — не выводить отключённых членов группы.
group move <имя группы> <контейнер> [опции]	Переместить группу в указанную организационную единицу или контейнер	Имя группы указывается в команде в формате sAMAccountName. Имя организационной единицы или контейнера можно указать как полное DN или без компонента domainDN.
group removemembers <имя группы> (<список участников>\|--member-dn=<member-dn>) [опции]	Удалить участников из группы	Команда позволяет удалить из группы одного или нескольких участников (указанных через запятую). При удалении из группы участник теряет все унаследованные от нее разрешения и права. Опции: `--member-dn` — уникальное составное имя (DN) удаляемого из группы участника (значение опции `--object-types` игнорируется); `--object-types` — список типов объектов (через запятую); указанные типы используются в качестве фильтра при выполнении поиска для указанных в команде участников; возможные значения: user, group, computer, serviceaccount, contact, all; значение по умолчанию — user,group,computer; `--member-base` — базовое уникальное имя (DN) для поиска участников группы; значение по умолчанию — уникальное имя (DN) домена.
group show <имя группы> [опции]	Вывести группу и её атрибуты	В опции `--attributes=USER_ATTRS` можно указать, разделённый запятыми, список атрибутов
group stats [опции]	Показать статистику для общих групп и членства в группах	В результате выполнения команды выводятся следующие сведения: общее количество групп; общее количество участников (без учета вложенности); среднее количество участников в группе; максимальное количество участников в группе; медианное количество участников в группе; распределение участников по группам с точки зрения количественного состава.
group rename <имя группы> [опции]	Переименовать группу и изменить её атрибуты	Для удаления атрибута следует использовать пустое значение атрибута. Имя группы указывается в команде в формате sAMAccountName. Можно использовать следующие опции: `--force-new-cn=NEW_CN` — новый CN (вместо использования sAMAccountName); `--reset-cn` — установить CN равным sAMAccountName; `--mail-address=MAIL_ADDRESS` — новая электронная почта; `--samaccountname=SAMACCOUNTNAME` — новое имя для входа (sAMAccountName).

Примечание

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

# samba-tool group add --help

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

Группы также могут использоваться для создания списков рассылки (группы рассылки). Для этого при вызове команды создания группы должна быть передана опция --group-type=Distribution.

Группы располагаются в подразделениях (OU). Область действия (scope) группы определяет место группы в дереве доменов.

Примеры:

добавить группу безопасности:

# samba-tool group add office --description='Simple group'
Added group office

добавить новую группу рассылки с указанием удалёного LDAP-сервера:

# samba-tool group add manager --group-type=Distribution \
 -H ldap://dc2.test.alt -U administrator

Added group manager

добавить новую группу в соответствии с RFC 2307 в домен NIS samdom с GID 12345:
```
# samba-tool group add mygroup --nis-domain=samdom --gid-number=12345
Added group mygroup
```

удалить группу:

# samba-tool group delete office
Deleted group office

добавить пользователя ivanov в группу «Domain Users»:
```
# samba-tool group addmembers "Domain Users" ivanov
```
добавить в группу mygroup пользователей kim,ivanov и группу manager:
```
# samba-tool group addmembers mygroup manager,kim,ivanov
```
удалить пользователя ivanov из группы «Domain Users»:
```
# samba-tool group removemembers "Domain Users" ivanov
```

переместить группу manager в подразделение OU:

# samba-tool group move manager 'OU=OU'
Moved group "manager" into "OU=OU,DC=test,DC=alt"

получить определённые атрибуты группы manager:

# samba-tool group show manager --attributes=member,objectGUID
dn: CN=test2,CN=Users,DC=test,DC=alt
objectGUID: 2f708ea2-f42c-4344-af22-bc243301c777
member: CN=Иван Иванов,OU=KDE,DC=test,DC=alt

вывести пользователей группы «Domain Users»:
```
# samba-tool group listmembers "Domain Users"
```

получить общую информацию о группах и их участниках:

# samba-tool group stats

Group membership statistics*
-------------------------------------------------
Total groups: 48
Total memberships: 32
Average members per group: 0.67
Max members: 8 (Denied RODC Password Replication Group)
Median members per group: 0.0

Members        Number of Groups
-------------------------------------------------
          0-1  42
          2-4  5
          5-9  1

* Note this does not include nested group membership

В «Альт Домен» поддерживается работа с группой безопасности «Protected Users» («Защищенные пользователи»). В данную группу должны включаться только учетные записи пользователей. После добавления в группу в отношении учетной записи начинают действовать следующие ограничения:

недоступна аутентификация по протоколу NTLM;
пользователю не выдаются и от пользователя не принимаются билеты Kerberos с использованием алгоритма шифрования RC4 (используется алгоритм AES);
максимальный период действия билета — 4 часа;
недоступно неограниченное и ограниченное делегирование Kerberos.

Примечание

Группа «Защищенные пользователи» доступна только при функциональном уровне домена Windows Server 2012 R2.

Для создания группы безопасности «Защищенные пользователи» следует создать группу «Protected Users» с указанием опции --special:

# samba-tool group add 'Protected Users' --special

⁠6.2. Администрирование DNS

Для связывания доменных имен с IP-адресами используются A-записи (для IPv4) и AAAA-записи (для IPv6), которые создаются при настройке DNS и содержат соответствующий IP-адрес узла. PTR-записи применяются для обратного разрешения, связывая IP-адреса с доменными именами в обеих версиях протокола и создаются в зоне обратного DNS.

В процессе эксплуатации IP-адреса узла могут меняться (из-за перезагрузки устройства, изменений в конфигурации сети или обновления через DHCP). В таких случаях необходимо обновить соответствующие DNS-записи, чтобы сохранить корректное разрешение имен и обеспечить работу служб аутентификации, таких как Kerberos или LDAP, для успешной проверки подлинности пользователей. Это обновление может выполняться автоматически как со стороны DHCP-сервера, так и со стороны клиента домена. DHCP-сервер может обновлять записи в DNS при изменении IP-адресов, в то время как клиент домена может обновлять записи через такие службы, как Winbind и SSSD, а также через встроенные функции операционных систем (на Windows-клиенте). Возможно также ручное обновление записей администраторами.

⁠6.2.1. DNS-записи при вводе машины в домен

При вводе машины в домен, в DNS-записи на DNS-сервере прописывается текущий IP-адрес машины.

Например, если машина с именем work.test.alt вводится в домен и имеет IP-адрес 192.168.0.55 (независимо от того, получен ли он статически или через DHCP), то на DNS-сервере будет создана (или обновлена) запись:

work.test.alt. IN A 192.168.0.55

Эта запись будет храниться в DNS-зоне прямого просмотра домена и использоваться для разрешения имени work.test.alt в IP-адрес 192.168.0.55.

PTR DNS-запись автоматически не создается, даже если существует обратная зона в базе данных AD. Для её создания необходимо на клиенте включить необходимые настройки для обновления PTR DNS-записей (то есть в дальнейшем вместо обновления запись будет зарегистрирована). В противном случае запись нужно будет создать вручную:

$ samba-tool dns add dc1.test.alt 0.168.192.in-addr.arpa 55 PTR work.test.alt -U administrator
Password for [TEST\administrator]:
Record added successfully

При этом будет создана DNS-запись:

55.0.168.192.in-addr.arpa. 3600 IN PTR work.test.alt.

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

$ host -t PTR 192.168.0.55 dc1.test.alt
Using domain server:
Name: dc1.test.alt
Address: 192.168.0.132#53
Aliases:

55.0.168.192.in-addr.arpa domain name pointer work.test.alt.

Примечание

Обратная зона создается так:

$ samba-tool dns zonecreate dc1.test.alt 0.168.192.in-addr.arpa -U administrator
Password for [TEST\administrator]:
Zone 0.168.192.in-addr.arpa created successfully

⁠6.2.2. Утилита samba-tool

Для администрирования службы доменных имен (DNS) в «Альт Домен» можно использовать подкоманду dns утилиты samba-tool.

Примечание

Для выполнения команды на удаленном компьютере можно использовать опцию -H или --URL=. Например:

$ samba-tool dns add 192.168.0.132 test.alt DC2 A 192.168.0.133 -H ldap://<DC> -Uadministrator

По умолчанию в качестве значения опции -H передается текущий узел в формате ldap://<имя узла>.

⁠6.2.2.1. Работа с DNS-записями

⁠

Таблица 6.3. Команды управления DNS-записями samba-tool

Команда	Описание	Примечание
dns add <сервер> <зона> <имя> <A\|AAAA\|PTR\|CNAME\|NS\|MX\|SRV\|TXT> <данные>	Добавить новую запись	Параметры вызова: сервер — IP-адрес или доменное имя DNS-сервера; зона — зона DNS; имя — имя DNS-записи; тип добавляемой записи с данными.
dns delete <сервер> <зона> <имя> <A\|AAAA\|PTR\|CNAME\|NS\|MX\|SRV\|TXT> <данные>	Удалить DNS-запись
dns edit <сервер> <зона> <имя> <A\|AAAA\|PTR\|CNAME\|NS\|MX\|SOA\|SRV\|TXT> <текущие данные> <новые данные>	Изменить DNS-запись	Дополнительно для изменения доступен тип записи SOA (Start of Authority), являющейся начальной записью зоны, со следующими данными (порядок пунктов в списке ниже соответствует порядку следования параметров в строке): nameserver — доменное имя DNS-сервера, на котором хранятся другие DNS-записи; email — адрес электронной почты администратора зоны (вместо @ указывается точка, например для адреса user@test.alt указывается значение user.test.alt); serial — серийный номер файла зоны, представляющий собой номер версии записи SOA; увеличивается при каждом изменении значения записи и служит сигналом другим DNS-серверам о том, что требуется обновить данные; refresh — интервал для запроса изменений; retry — интервал для повторных попыток запроса данных в случае неудачи; expire — время, в течение которого обновленные данные могут быть применены на других DNS-серверах; minimum-ttl — время хранения в кеше информации о зоне.
dns cleanup <сервер> <имя узла> [опции]	Очистить DNS-записи указанного DNS-узла	Во многих случаях данная подкоманда только устанавливает значение true в атрибуте dNSTombstoned DNS-записей. После этого при запросе таких записей информация о них возвращаться не будет, но в базе данных могут оставаться соответствующие им записи-заполнители.
dns query <сервер> <зона> <имя> <A\|AAAA\|PTR\|CNAME\|NS\|MX\|SOA\|SRV\|TXT\|ALL> [опции]	Вывести информацию о DNS-записях	Можно использовать следующие опции: `--authority` — поиск по записям полномочного DNS-сервера (значение по умолчанию); `--cache` — поиск по записям в кеше; `--glue` — поиск по корневым ссылкам DNS-сервера; `--additional` — вывод списка дополнительных записей; `--no-children` — исключение вывода дочерних записей; `--only-children` — вывод только дочерних записей.

Возможные типы записей и данные:

A <IPv4-адрес> — IPv4-адрес для связи с именем домена;
AAAA <IPv6-адрес> — IPv6-адрес для связи с именем домена;
PTR <FQDN> — полное доменное имя (FQDN) для связи с IP-адресом домена;
CNAME <FQDN> — полное доменное имя (FQDN) для создания псевдонима;
NS <FQDN> — полное доменное имя (FQDN) сервера, выполняющего роль сервера имен;
MX <FQDN> <приоритет> — полное доменное имя (FQDN) и приоритет почтового сервера;
SRV <FQDN> <порт> <приоритет> <вес> — полное доменное имя (FQDN) сервера, на котором доступна определенная служба, порт для доступа к службе, приоритет и относительный вес на случай, если существует несколько записей с одинаковым приоритетом;
TXT "'sting1' 'string2' …" — информация о домене в текстовом формате (string).

Примечание

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

$ samba-tool dns add --help

Примечание

При использовании команды samba-tool dns указание аутентифицирующей информации (имени пользователя и пароля) обязательно!

Примеры:

добавить запись типа A:

$ samba-tool dns add 192.168.0.132 test.alt \
DC2 A 192.168.0.133 -Uadministrator

Password for [TEST\administrator]:
Record added successfully

добавить запись типа PTR для обратной зоны 192.168.0.0/24:

$ samba-tool dns add dc1.test.alt 0.168.192.in-addr.arpa \
55 PTR demo.test.alt -U administrator

Password for [TEST\administrator]:
Record added successfully

удалить запись типа A:

$ samba-tool dns delete dc1.test.alt test.alt \
DC2 A 192.168.0.133 -U administrator

Password for [TEST\administrator]:
Record deleted successfully

изменить запись типа A:

$ samba-tool dns update dc1.test.alt test.alt DC2 \
A 192.168.0.133 192.168.0.149 -U administrator

Password for [TEST\administrator]:
Record updated succefully

изменить адрес электронной почты администратора в записи типа SOA:

$ samba-tool dns update dc1.test.alt test.alt @ SOA \
"dc1.test.alt admin.test.alt 63 900 600 86400 3600" \
"dc1.test.alt new.test.alt 64 900 600 86400 3600" \
-U administrator

Password for [TEST\administrator]:
Record updated succefully

вывести все DNS-записи для указанной зоны:

$ samba-tool dns query dc1.test.alt 0.168.192.in-addr.arpa \
@ ALL -U administrator

⁠6.2.2.2. Работа с DNS-зонами

⁠

Таблица 6.4. Команды samba-tool для управления зонами DNS

Команда	Описание	Примечание
dns zonecreate <сервер> <зона> [опции]	Создать зону DNS	Дополнительно с помощью параметра `--client-version` можно указать версию DNS-клиента. Возможные значения: w2k, dotnet, longhorn (по умолчанию).
dns zonedelete <сервер> <зона> [опции]	Удалить зону DNS
dns zoneinfo <сервер> <зона> [опции]	Вывести информацию о зоне DNS
dns zonelist <сервер> [опции]	Вывести список зон DNS	Можно использовать следующие опции: `--client-version` — версия DNS-клиента. Возможные значения: w2k, dotnet, longhorn (по умолчанию); `--primary` — получение списка первичных зон DNS (по умолчанию); `--secondary` — получение списка вторичных зон DNS; `--cache` — получение списка зон DNS из кеша; `--auto` — получение списка автоматически созданных зон DNS; `--reverse` — получение списка обратных зон DNS; `--ds` — получение списка зон DNS, интегрированных с доменом; `--non-ds` — получение списка зон DNS без интеграции с доменом.
dns zoneoptions <сервер> <зона> [опции]	Изменить настройки очистки от устаревших записей для зоны DNS	Можно использовать следующие опции: `--client-version` — версия DNS-клиента. Возможные значения: w2k, dotnet, longhorn (по умолчанию); `--mark-old-records-static=YYYY-MM-DD` — записи старше указанной даты становятся статическими (их временные метки становятся нулевыми); `--mark-records-static-regex=REGEXP` — записи, соответствующие заданному регулярному выражению, становятся статическими; `-n\|--dry-run` — запуск в тестовом режиме для проверки корректности заданных параметров; фактически изменения не вносятся; `--aging` — признак необходимости очистки от устаревших записей: 0 — очистка отключена (по умолчанию), 1 — очистка включена; `--norefreshinterval=[0-87600]` — интервал блокировки для зоны с включенной очисткой в часах; если параметр равен нулю, используется значение по умолчанию (168 часов, одна неделя); `--refreshinterval=[0-87600]` — интервал обновления для зоны с включенной очисткой в часах; если параметр равен нулю, используется значение по умолчанию (168 часов, одна неделя).

Примечание

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

$ samba-tool dns zoneoptions --help

Примечание

Примеры:

создать обратную зону /24:

$ samba-tool dns zonecreate 192.168.0.132 \
0.168.192.in-addr.arpa -U administrator

вывести информацию об обратной зоне DNS:

$ samba-tool dns zoneinfo dc1.test.alt \
0.168.192.in-addr.arpa -U administrator

включить очистку с большим интервалом обновления:
```
$ samba-tool dns zoneoptions dc1.test.alt \
test.alt --aging=1 --refreshinterval=306600
```

Примечание

Чтобы очистка работала, в файле smb.conf хотя бы на одном контроллере домена должен быть задан параметр dns zone scavenging = yes.

⁠6.2.2.3. Получение информации о DNS-серверах

⁠

Таблица 6.5. Команды samba-tool для получения информации о DNS-серверах

Команда	Описание	Примечание
dns serverinfo <сервер> [опции]	Вывести информацию о DNS-сервере	Дополнительно с помощью параметра `--client-version` можно указать версию DNS-клиента. Возможные значения: w2k, dotnet, longhorn (по умолчанию)
dns roothints <сервер> [<имя>] [опции]	Вывести информацию о корневых серверах DNS

Примечание

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

$ samba-tool dns roothints --help

Примеры:

вывести информацию о DNS-сервере:

$ samba-tool dns serverinfo dc1.test.alt -U administrator

вывести информацию об обратной зоне DNS:
```
$ samba-tool dns zoneinfo dc1.test.alt \
0.168.192.in-addr.arpa -U administrator
```
Данная команда возвращает структуру DNS_RPC_SERVER_INFO, содержащую информацию о состоянии и конфигурации DNS-сервера, в формате, соответствующем версии DNS-клиента.
вывести информацию о корневых серверах DNS:
```
$ samba-tool dns roothints dc1.test.alt -U administrator
```

⁠6.2.3. nsupdate

Утилита nsupdate используется для отправки запросов на обновление динамического DNS серверу имен в соответствии со стандартом RFC 2136. С ее помощью можно добавлять или удалять записи ресурсов из зоны без необходимости правки зонного файла вручную. Один запрос на обновление может содержать запросы на добавление или удаление нескольких записей ресурсов.

Синтаксис команды nsupdate:

nsupdate [-dDi] [-L level] [-l][-g | -o | -y keyname:secret | -k keyfile] [-v] [-V] [-P] [-T] [-4 | -6] [filename]

⁠

Таблица 6.6. Опции команды nsupdate

Ключ	Описание
-4	Использовать только IPv4
-6	Использовать только IPv6
-d	Включить режим отладки
-D	Включить дополнительный режим отладки
-i	Принудительно включить интерактивный режим, даже если стандартный ввод не является терминалом
-k keyfile	Позволяет указать файл, содержащий ключ аутентификации TSIG. Файлы могут быть в двух форматах: один файл, содержащий оператор ключа named.conf-format, который может быть автоматически сгенерирован ddns-confgen; или пара файлов, имена которых имеют формат K{name}.+157.+{random}.key и K{name}.+157.+{random}.private, которые могут быть сгенерированы dnssec-keygen. Параметр `-k` также может использоваться для указания ключа SIG(0), используемого для аутентификации запросов на обновление Dynamic DNS. В этом случае указанный ключ не является ключом HMAC-MD5
-l	Установить режим локального хоста. Адрес сервера будет установлен на на localhost (отключая сервер, чтобы адрес сервера не мог быть переопределен). Подключения к локальному серверу используют ключ TSIG, найденный в `/var/run/named/session.key`, который автоматически генерируется named, если какая-либо локальная первичная зона установила update-policy на local. Расположение этого файла ключа можно переопределить с помощью опции `-k`
-L level	Установить уровень отладки ведения журнала. Если 0, ведение журнала отключено
-p port	Установить порт для подключения к серверу имен. Значение по умолчанию — 53
-P	Вывести список частных типов записей ресурсов BIND, формат которых понимает nsupdate
-r udpretries	Установить количество повторных попыток UDP. Значение по умолчанию — 3. Если 0, выполняется только один запрос на обновление
-t timeout	Установить максимальное время, которое может занять запрос на обновление, прежде чем он будет прерван. Значение по умолчанию — 300 секунд. Если 0, тайм-аут отключен
-T	Вывести список стандартных типов записей ресурсов IANA, формат которых понимает nsupdate. nsupdate завершает работу после вывода списков. Параметр `-T` можно комбинировать с параметром `-P`. Другие типы можно ввести с помощью TYPEXXXXX, где XXXXX — это десятичное значение типа без начальных нулей. Rdata, если они присутствуют, анализируются с использованием формата UNKNOWN rdata (<обратная косая черта> <хэш> <пробел> <длина> <пробел> <шестнадцатеричная строка>)
-u udptimeout	Задать интервал повтора UDP. Значение по умолчанию — 3 секунды. Если равно 0, интервал вычисляется из интервала тайм-аута и количества повторов UDP
-v	Указывает, что TCP следует использовать даже для небольших запросов на обновление. По умолчанию nsupdate использует UDP для отправки запросов на обновление на сервер имен, если только они не слишком велики для того, чтобы поместиться в запрос UDP, в этом случае используется TCP. TCP может быть предпочтительнее, когда выполняется пакет запросов на обновление
-V	Вывести номер версии
-y [hmac:]keyname:secret	Задает буквальный ключ аутентификации TSIG. keyname — имя ключа, а secret — общий секрет в кодировке base64. hmac — имя алгоритма ключа; допустимые варианты: hmac-md5, hmac-sha1, hmac-sha224, hmac-sha256, hmac-sha384 или hmac-sha512. Если hmac не указан, по умолчанию используется hmac-md5 или, если MD5 отключен, hmac-sha256. Примечание Использование опции `-y` не рекомендуется, поскольку общий секрет предоставляется как аргумент командной строки в виде открытого текста.

nsupdate считывает входные данные из filename или стандартного ввода. Каждая команда предоставляется ровно в одной строке ввода. Некоторые команды предназначены для административных целей; другие — это либо инструкции по обновлению, либо проверки предварительных условий содержимого зоны. Эти проверки устанавливают условия, что некоторое имя или набор записей ресурсов (RRset) либо существует, либо отсутствует в зоне. Эти условия должны быть выполнены, чтобы весь запрос на обновление был успешным. Обновления отклоняются, если тесты на предварительные условия не пройдены.

Каждый запрос на обновление состоит из нуля или более предварительных условий и нуля или более обновлений. Это позволяет соответствующим образом аутентифицированному запросу на обновление продолжить работу, если некоторые указанные записи ресурсов либо присутствуют, либо отсутствуют в зоне. Пустая строка ввода (или команда send) приводит к отправке накопленных команд как одного запроса на обновление Dynamic DNS на сервер имен.

⁠

Таблица 6.7. Форматы команд и их значения

Команда	Описание
server servername port	Отправить все динамические запросы на обновление на сервер имен servername. Если не указано ни одного оператора сервера, nsupdate отправляет обновления на основной сервер правильной зоны. Поле MNAME записи SOA этой зоны определяет основной сервер для этой зоны. port — это номер порта на servername, куда отправляются динамические запросы на обновление. Если номер порта не указан, используется номер порта DNS по умолчанию 53. Примечание Эта команда не действует, если используется GSS-TSIG.
local address port	Отправить все динамические запросы на обновление, используя локальный адрес. Если локальный оператор не указан, `nsupdate` отправляет обновления, используя адрес и порт, выбранные системой. port также может использоваться для принудительного поступления запросов с определенного порта. Если номер порта не указан, система назначает его
zone zonename	Указывает, что все обновления должны быть сделаны в зоне zonename. Если оператор zone не указан, `nsupdate` пытается определить правильную зону для обновления на основе остальной части ввода
class classname	Указывает класс по умолчанию. Если класс не указан, класс по умолчанию — IN
ttl seconds	Указывает время жизни по умолчанию в секундах для добавляемых записей. Значение none очищает TTL по умолчанию
key hmac:keyname secret	Указывает, что все обновления должны быть подписаны TSIG с использованием пары keyname-secret. Если указан hmac, он устанавливает используемый алгоритм подписи. Значение по умолчанию — hmac-md5; если MD5 отключен, то по умолчанию используется hmac-sha256. Команда key переопределяет любой ключ, указанный в командной строке с помощью `-y` или `-k`
gsstsig	Эта команда использует GSS-TSIG для подписи обновлений. Это эквивалентно указанию `-g` в командной строке
oldgsstsig	Эта команда использует версию GSS-TSIG для Windows 2000 для подписи обновлений. Это эквивалентно указанию `-o` в командной строке
realm [realm_name]	При использовании GSS-TSIG эта команда указывает использование realm_name вместо realm по умолчанию в krb5.conf. Если realm не указан, сохраненная realm очищается
check-names [yes_or_no]	Включить или выключить обработку check-names для добавляемых записей. Check-names не влияет на предварительные условия или удаляемые записи. По умолчанию обработка check-names включена. Если обработка check-names завершается неудачей, запись не добавляется в сообщение UPDATE
prereq nxdomain domain-name	Эта команда требует, чтобы не существовало ни одной записи ресурса любого типа с именем domain-name
prereq yxdomain domain-name	Эта команда требует, чтобы существовал domain-name (как минимум одна запись ресурса любого типа)
prereq nxrrset domain-name class type	Эта команда требует, чтобы не существовало ни одной записи ресурса указанного типа, класса и domain-name. Если class не указан, предполагается IN (Интернет)
prereq yxrrset domain-name class type	Для этой команды требуется, чтобы существовала запись ресурса указанного типа, класса и доменного имени. Если class не указан, предполагается IN (Интернет)
prereq yxrrset domain-name class type data	С помощью этой команды данные из каждого набора предварительных условий этой формы, имеющих общий тип, класс и доменное имя, объединяются для формирования набора RR. Этот набор RR должен точно соответствовать набору RR, существующих в зоне с указанным типом, классом и доменным именем. Данные записываются в стандартном текстовом представлении RDATA записи ресурса
update delete domain-name ttl class type data	Удалить все записи ресурсов с именем domain-name. Если указаны type и data, удаляются только соответствующие записи ресурсов. Если class не указан, предполагается класс Internet. TTL игнорируется и допускается только для совместимости
update add domain-name ttl class type data	Добавить новую запись ресурса с указанным ttl, class и data
show	Отобразить текущее сообщение, содержащее все предварительные условия и обновления, указанные с момента последней отправки
send	Отправить текущее сообщение (эквивалентно вводу пустой строки)
answer	Отобразить ответ
debug	Включить отладку
version	Вывести номер версии
help	Вывести список команд

Примечание

Строки, начинающиеся с точки с запятой (;), являются комментариями и игнорируются.

При использовании утилиты nsupdate для динамического обновления DNS-записей в доменных средах AD, необходимо использовать механизм аутентификации GSS-TSIG, который использует Kerberos-билет для аутентификации машины в домене. Kerberos-билет используется при обновлении DNS-записей с помощью nsupdate с флагом -g.

Перед выполнением команды nsupdate -g необходимо получить Kerberos-билет для машинного аккаунта с помощью команды:

# kinit -k 'MACHINENAME$'

Примечание

Имя машинного аккаунта можно узнать, используя команду hostname -s. В команде kinit имя машинного аккаунта нужно указывать в верхнем регистре со знаком $, например:

# hostname -s
comp01
# kinit -k 'COMP01$'

В следующих примерах показано использование команды nsupdate для добавления и удаления записей ресурсов из зоны test.alt.

Удалить записи A для oldhost.test.alt и добавить запись A для newhost.test.alt с IP-адресом 192.168.0.195:
```
# nsupdate -g
> update delete oldhost.test.alt A
> update add newhost.test.alt 86400 A 192.168.0.195
> send
```
Новая запись будет имеет TTL 1 день (86400 секунд).
Указать предварительное условие перед обновлением DNS-сервера:
```
# nsupdate -g
> prereq nxdomain nickname.test.alt
> update add nickname.test.alt 86400 CNAME somehost.test.alt
> send
```
Предварительное условие позволяет серверу имен проверить, нет ли записей о ресурсах любого типа для nickname.test.alt. Если в зоне есть записи ресурсов, запрос на обновление не выполняется. Если этого имени не существует, добавляется CNAME.

⁠6.2.4. Oснастка DNS в RSAT

Оснастка DNS в RSAT позволяет администраторам Windows удаленно управлять DNS-записями через графический интерфейс. С его помощью можно добавлять, удалять и изменять DNS-записи.

Примечание

Для возможности администрирования DNS с клиента Windows должна быть установлена оснастка DNS MMC (см. Установка RSAT).

Существуют следующие известные проблемы если используется внутренний сервер DNS:

Очистка еще не реализована. Возвращается сообщение об ошибке «This function is not supported on this system».
Условные пересылки еще не реализованы. Возвращается то же сообщение об ошибке, что и выше.
Пересылку DNS можно изменить только в smb.conf, а не через оснастку MMC.
Создание статических записей. Когда создается статическая запись, она имеет временную метку и опцию «Delete this record when it becomes stale». В Windows AD статические записи имеют «статическую» временную метку и не могут быть случайно удалены.

Для подключения к своему DNS-серверу в оснастке DNS необходимо в контекстном меню DNS выбрать пункт Connect to DNS Server…:

Оснастка DNS в RSAT. Подключение к DNS-серверу

В открывшемся окне следует выбрать пункт The following computer, ввести в поле имя домена (также можно использовать IP-адрес или FQDN), установить отметку Connect to the special computer now и нажать кнопку ОК:

⁠6.2.4.1. Работа с DNS-записями

Чтобы добавить новую запись необходимо:

Перейти в зону, в которую нужно добавить новую запись.
В контекстном меню зоны выбрать тип записи:
Заполнить поля и сохранить запись, нажав кнопку Add Host:

Для обновления существующей записи необходимо:

Перейти в зону, содержащую запись, которую нужно изменить.
В контекстном меню записи выбрать пункт Properties:
Отредактировать запись и сохранить изменения, нажав кнопку Apply:

Для удаления записи необходимо:

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

⁠6.2.4.2. Работа с DNS-зонами

В качестве примера рассмотрено добавление зоны обратного просмотра:

В контекстном меню зоны обратного просмотра (Reverse Lookup Zones) выбрать пункт New Zone…:
На втором шаге мастера создания новой зоны выбрать Primary zone и установить отметку в пункте Store the zone in Active Directory:
На следующем шаге мастера указать область репликации зоны:
Указать имя зоны обратного просмотра:
Включить динамическое обновление:
Завершить работу мастера.

Примечание

Новая зона будет активна сразу, без перезапуска Samba или BIND.

Для удаления зоны следует в контекстном меню зоны выбрать пункт Delete:

⁠6.2.5. Динамическое обновление DNS-записей

Используются следующие механизмы обновления DNS-записей:

На стороне DHCP. Динамическое обновление DNS-записей часто осуществляется с помощью DHCP-серверов. В частности, такие системы как ISC DHCP и Kea DHCP могут автоматически обновлять записи на DNS-сервере при выдаче нового IP-адреса клиенту.
На стороне клиента. В доменных средах с использованием Linux-клиентов для взаимодействия с AD могут использоваться службы Winbind и SSSD для обновления DNS-записей. На Windows-клиентах обновление происходит через встроенные функции операционных систем. Кроме того, обновление записей может быть выполнено вручную администраторами.

⁠6.2.5.1. На стороне клиента

⁠6.2.5.1.1. SSSD

Включить обновление IP-адресов службой sssd можно несколькими способами:

отредактировав файл /etc/sssd/sssd.conf;
в модуле ЦУС Аутентификация;
применением control;
групповыми политиками.

⁠6.2.5.1.1.1. Настройка через файл /etc/sssd/sssd.conf

В файл конфигурации службы SSSD (/etc/sssd/sssd.conf) в секцию с параметрами домена можно добавить опции, приведенные в табл. Параметры настройки автоматического обновления DNS. Например:

[domain/TEST.ALT]
.....
#Включить обновление прямых записей (A/AAAA записей)
dyndns_update = true

#Включить обновление обратных записей (PTR записей)
dyndns_update_ptr = true
#Задать интервал обновления в секундах.
#По умолчанию — 86400 (24 часа), обновление выполняется раз в сутки.
#Если интервал равен 0, то обновление выполняется только один раз при запуске службы SSSD.
#Если интервал менее 60 секунд, то обновление выполняется раз в 60 секунд.
#Если адрес после предыдущего обновления не изменялся — обновление не выполняется.
dyndns_refresh_interval = 60

Примечание

Чтобы загрузить новые параметры конфигурации необходимо перезапустить службу SSSD:

# systemctl restart sssd

⁠

Таблица 6.8. Параметры настройки автоматического обновления DNS

Параметр	Описание	Значение по умолчанию
`dyndns_update`	Позволяет включить или отключить автоматическое обновление DNS-записей (защищенных с помощью GSS-TSIG) IP-адресом клиента через SSSD. Соответственно, администратору AD требуется только разрешить защищённые обновления для зоны DNS. Для обновления будет использован IP-адрес LDAP-соединения AD, если с помощью параметра «dyndns_iface» не указано иное.	true
`dyndns_ttl`	Значение TTL, которое применяется при обновлении DNS-записи клиента. Если `dyndns_update` имеет значение `false`, этот параметр не имеет никакого эффекта. Если администратором установлено значение TTL на стороне сервера, оно будет переопределено этим параметром.	3600 (секунд)
`dyndns_iface`	Позволяет указать интерфейс или список интерфейсов, IP-адреса которых должны использоваться для динамических обновлений DNS. Специальное значение «*» подразумевает, что следует использовать IP-адреса всех интерфейсов. Если `dyndns_update` имеет значение `false`, этот параметр не имеет никакого эффекта.	IP-адреса интерфейса, который используется для подключения LDAP AD.
`dyndns_refresh_interval`	Определяет как часто внутреннему серверу следует выполнять периодическое обновление DNS в дополнение к автоматическому обновлению, выполняемому при переходе внутреннего сервера в сетевой режим. Этот параметр применим только в том случае, если для параметра `dyndns_update` установлено значение `true`. Следует обратить внимание, что наименьшее допустимое значение составляет 60 секунд: если будет указано меньшее значение, параметр примет наименьшее допустимое значение (60 секунд).	86400 (24 часа)
`dyndns_update_ptr`	Определяет будет ли обновляться клиентская PTR-запись (защищенная с помощью GSS-TSIG) при обновлении DNS-записей клиента. Применимо, только если параметр `dyndns_update` имеет значение `true`. Следует обратить внимание, что параметр `dyndns_update_per_family` не применяется для обновлений записей PTR. Эти обновления всегда отправляются отдельно.	true
`dyndns_force_tcp`	Должна ли утилита `nsupdate` по умолчанию использовать TCP для обмена данными с сервером DNS.	false (разрешить `nsupdate` выбрать протокол)
`dyndns_auth`	Следует ли утилите `nsupdate` использовать проверку подлинности GSS-TSIG для защищённых обновлений сервера DNS. Незащищённые отправления можно отправлять, установив этот параметр в значение `none`.	GSS-TSIG
`dyndns_auth_ptr`	Следует ли утилите `nsupdate` использовать проверку подлинности GSS-TSIG для защищённых обновлений PTR сервера DNS. Незащищённые отправления можно отправлять, установив этот параметр в значение `none`.	То же, что и `dyndns_auth`
`dyndns_server`	Сервер DNS, который следует использовать для выполнения обновления DNS. В большинстве конфигураций рекомендуется не устанавливать значение для этого параметра. Установка этого параметра имеет смысл для сред, в которых сервер DNS отличается от сервера данных идентификации. Следует обратить внимание, что этот параметр используется только для резервной попытки, которая выполняется если предыдущая попытка с использованием автоматически определённых параметров завершилась неудачей.	none (разрешить `nsupdate` выбрать сервер)
`dyndns_update_per_family`	По умолчанию обновление DNS выполняется за два шага: обновление IPv4, а затем обновление IPv6. В некоторых случаях может быть желательно выполнить обновление IPv4 и IPv6 за один шаг.	true

⁠6.2.5.1.1.2. Настройка через ЦУС

Некоторые настройки автоматического обновления DNS для SSSD можно настроить в модуле ЦУС Аутентификация. Подробнее см. Настройки SSSD в ЦУС.

⁠6.2.5.1.1.3. При помощи механизма control

Список всех возможных настроек автоматического обновления DNS для SSSD с помощью control можно получить, выполнив команду:

# control | grep sssd-dyndns
sssd-dyndns-refresh-interval unknown         (disabled INTERVAL)
sssd-dyndns-ttl unknown         (disabled TTL)
sssd-dyndns-update unknown         (disabled enabled default)
sssd-dyndns-update-ptr unknown         (disabled enabled default)

⁠

Таблица 6.9. control для настройки автоматического обновления DNS для SSSD

control	Опция в файле `/etc/sssd/sssd.conf`	Описание
sssd-dyndns-refresh-interval	`dyndns_refresh_interval`	Определяет как часто серверная часть должна выполнять периодическое обновление DNS в дополнение к автоматическому обновлению, выполняемому при подключении серверной части к сети. Этот параметр применим только в том случае, если для параметра `dyndns_update` установлено значение `true`. Доступные режимы: `INTERVAL` — задать интервал `disabled` — установить значение по умолчанию (86400) `unknown`
sssd-dyndns-ttl	`dyndns_ttl`	Срок жизни, применяемый к DNS-записи клиента при ее обновлении. Если `dyndns_update` имеет значение `false`, этот параметр не имеет никакого эффекта Доступные режимы: `TTL` — задать TTL `disabled` — установить значение по умолчанию (3600) `unknown`
sssd-dyndns-update	`dyndns_update`	Позволяет включить или отключить автоматическое обновление DNS-записей (защищенных с помощью GSS-TSIG) с IP-адресом клиента через SSSD Доступные режимы: `enabled` — автоматическое обновление DNS-записи клиента через SSSD включено `disabled` — автоматическое обновление DNS-записи клиента через SSSD отключено `default` — настройка автоматического обновления DNS-записи клиента через SSSD задана по умолчанию в пакете `unknown`
sssd-dyndns-update-ptr	`dyndns_update_ptr`	Определяет будет ли обновляться клиентская PTR-запись (защищенная с помощью GSS-TSIG) при обновлении DNS-записей клиента. Применимо, только если параметр `dyndns_update` имеет значение `true`. Доступные режимы: `enabled` — автоматическое обновление DNS-записи обратной зоны через SSSD включено `disabled` — автоматическое обновление DNS-записи обратной зоны через SSSD отключено `default` — настройка автоматического обновления DNS-записи обратной зоны задана по умолчанию в пакете `unknown`

Например, чтобы SSSD автоматически обновлял на сервере DNS AD IP-адрес клиента, необходимо включить control sssd-dyndns-update:

# control sssd-dyndns-update enabled

и перезапустить службу SSSD:

# systemctl restart sssd

Проверка:

# control sssd-dyndns-update
enabled

⁠6.2.5.1.1.4. При помощи групповых политик

С помощью групповых политик в AD можно централизованно управлять настройками обновления DNS-записей на всех клиентах в сети. В настоящее время с помощью групповых политик можно сконфигурировать параметры dyndns_update и dyndns_update_ptr. Подробнее см. Групповые политики control (раздел SSSD опции).

⁠6.2.5.1.2. Samba Winbind

Samba Winbind не поддерживает возможность динамического обновления DNS-записей. Для обхода этой проблемы был разработана утилита, реализующая динамическое обновление адресов на DNS-сервере при использовании Winbind в качестве клиента домена — winbind-dnsupdate.

Для возможности работы с программой необходимо установить пакет samba-winbind-dnsupdate:

# apt-get install samba-winbind-dnsupdate

И активировать и запустить таймер, который в свою очередь запускает сервис:

# systemctl enable --now winbind-dnsupdate.timer

Основным функционалом winbind-dnsupdate является обновление IPv4 (A), IPv6 (AAAA) и соответствующих PTR DNS-записей. Для обновления DNS-записей winbind-dnsupdate использует файл /etc/resolv.conf.

⁠ Синтаксис команды winbind-dnsupdate:

winbind-dnsupdate [опции]

При запуске без параметров скрипт обновляет A запись.

⁠

Таблица 6.10. Опции команды winbind-dnsupdate

Ключ	Описание
-h, --help	Вывести справку о команде
-v, --version	Вывести версию
-a, --all	Включить обновление всех записей
-6, --update-ipv6	Включить обновление IPv6 (AAAA) записей
-d, --daemon	Отправлять логи в journald
-t, --ttl <time>	Задать TTL («время жизни», указывает, как долго настройки DNS должны храниться в кеше, прежде чем они будут автоматически обновлены)
--allow-ipv4-ptr-update	Включить обновление обратной DNS-записи IPv4 (A) PTR
--allow-ipv6-ptr-update	Включить обновление обратной DNS-записи IPv6 (AAAA) PTR

Пример запуска скрипта winbind-dnsupdate:

# winbind-dnsupdate -a
[INFO]: Hostname: comp01.test.alt.
[INFO]: Check winbind status.
[INFO]: Winbind is running. Continue.
[INFO]: Trying to get the site name.
[INFO]: Site: Default-First-Site-Name.
[INFO]: Get host credentials.
[INFO]: Retrieving host credentials successfully.
[INFO]: Trying to get a list of domain controllers in site.
[INFO]: Success.
[INFO]: Trying to find an available DNS server.
[INFO]: Checking the availability of DNS server on dc1.test.alt..
[INFO]: DNS server on dc1.test.alt. available.
[INFO]: Update IPv4.
[INFO]: Trying to get IPv4 address of a domain controller.
[INFO]: Successful. DC info:
[INFO]: Domain controller name: dc1.test.alt.
[INFO]: Domain controller IPv4: 192.168.0.132.
[INFO]: Trying parse connection interface name.
[INFO]: Successful. Intraface name: enp0s3.
[INFO]: Checking the existence of A record.
[INFO]: IPv4 record exists.
[INFO]: Checking whether the IPv4 records needs to be updated.
[INFO]: Current IPv4 address: 192.168.0.195.
[INFO]: IPv4 address in DNS server: 192.168.0.195.
[INFO]: The IPv4 address of interface enp0s3 has not been changed.
[INFO]: The update IPv4 was skipped.
[INFO]: IPv4 update was successful.
[INFO]: The update was successful.
[INFO]: Destroy host credential.

В пакете вместе со скриптом предоставляются systemd сервис и таймер. Таймер запускает systemd сервис для обновления DNS-записи через 5 минут после загрузки системы и затем каждый час. Просмотреть параметры таймера можно, выполнив команду:

# systemctl cat winbind-dnsupdate.timer
# /lib/systemd/system/winbind-dnsupdate.timer
[Unit]
Description=Update dns record Daily and on boot

[Timer]
OnBootSec=5min
OnUnitActiveSec=60min

[Install]
WantedBy=timers.target

Чтобы изменить частоту запуска systemd сервиса, необходимо отредактировать настройки таймера:

Выполнить команду:

# systemctl edit winbind-dnsupdate.timer

Добавить следующие строки после строки Anything between here and the comment below will become the new contents of the file:
```
[Timer]
OnUnitActiveSec=
OnUnitActiveSec=120min
```
OnUnitActiveSec= очистит предыдущее определение (60min), а OnUnitActiveSec=120min установит новое значение (120min).
Сохранить внесённые изменения.
Перезагрузить таймер для применения изменений:
```
# systemctl daemon-reload
```

Примечание

Команда:

# systemctl edit winbind-dnsupdate.timer

открывает текстовый редактор с конфигурацией winbind-dnsupdate.timer, куда можно внести изменения. Этот подход позволяет создавать или изменять так называемые «дополнения» (overrides) для systemd сервиса, не изменяя оригинальный файл сервиса, который находится в /usr/lib/systemd/system/. Это важно, потому что оригинальные файлы могут быть перезаписаны при обновлении пакетов.

При выполнении этой команды создаётся каталог /etc/systemd/system/winbind-dnsupdate.timer.d/, в котором, после сохранения изменений, появляется файл override.conf. В этом файле можно задать новые параметры или изменить существующие параметры сервиса.

⁠6.2.5.1.3. Windows клиент

В Windows клиенты автоматически обновляют DNS-записи, такие как A и PTR, при изменении IP-адресов или имени компьютера. Этот процесс инициируется службой DHCP-клиента, которая отправляет обновления на DNS-сервер. Обновления происходят каждые 24 часа (по умолчанию) или могут быть инициированы вручную командой ipconfig /registerdns. Для DHCP-клиентов DHCP-сервер может выполнять эти обновления от имени клиента, что снижает необходимость ручного администрирования.

⁠6.2.6. Обновление IP-адресов вручную

Для обновления IP-адресов вручную существует несколько способов:

с помощью команды samba-tool (см. Утилита samba-tool);
с помощью утилиты nsupdate (см. nsupdate);
оснастка DNS в RSAT (см. Oснастка DNS в RSAT).

⁠6.2.7. Известные проблемы

⁠6.2.7.1. Неверные права DNS-записей машины в домене

При вводе машины в домен AD вызывается утилита system-auth, которая в свою очередь использует команду net ads join. В рамках данной команды выполняется присоединение к домену с использованием Kerberos-аутентификации и не производится обновление DNS. После успешного присоединения машина регистрирует свою DNS-запись с помощью команды net ads dns register также используя Kerberos-аутентификацию.

Если машины уже введены в домен или используется старая версия alterator-auth (до версии 0.44.10-alt1), то у машин не будет прав на обновление своих DNS-записей. Это происходит потому, что во время создания DNS-записи в доменном DNS system-auth использует билет администратора, и в результате владельцем записи становится он, а не машина, что впоследствии не позволяет машине обновить свою DNS-запись.

Примечание

Имеются ввиду записи вида:

DC=host1,DC=test.alt,CN=MicrosoftDNS,DC=DomainDnsZones,DC=test,DC=alt

Исправление в пакете alterator-auth версии 0.44.10-alt1 работает только для машин, которые не были ранее введены в домен с текущим именем (то есть, если машинная учётная запись создаётся впервые). Если машина уже была добавлена в домен, но для неё используется новое имя, то будет создана новая учётная запись, и проблема с правами на обновление DNS-записей будет решена. Однако, если машина повторно вводится в домен с тем же именем, это не устранит проблему.

Примечание

При вводе машины в домен с новым именем необходимо убедиться, что очищены кеши SSSD и Winbind, а также удален старый keytab-файл.

В случае с уже введёнными в домен машинами можно воспользоваться скриптом https://github.com/altlinuxteam/samba_allow_nsupdate на контроллере домена (предварительно получив билет администратора). Этот скрипт позволяет задать необходимые права как для всех машин в домене или OU, так и для произвольного списка машин в домене. Примеры:

разрешить самостоятельное обновление для машин, находящихся в контейнере «Computers»:

# samba_allow_nsupdate --domain-dns="test.alt" --computers-base-dn="CN=Computers,DC=test,DC=alt"
Domain: test.alt
Domain DN: DC=test,DC=alt
Computers search base DN: CN=Computers,DC=test,DC=alt
Action: allow
Selected computers list:
DC1$
WS2$
WS$
WS3$
Allow self nsupdate for this computers list? (Y/n):
DC1$			S-1-5-21-3099202228-3607437695-3279060739-1000	DONE
WS2$			S-1-5-21-3099202228-3607437695-3279060739-1113	DONE
WS$			S-1-5-21-3099202228-3607437695-3279060739-1107	DONE
WS3$			S-1-5-21-3099202228-3607437695-3279060739-1127	DONE

разрешить самостоятельное обновление для произвольного списка машин в домене (в примере для WS, WS2):

# samba_allow_nsupdate --action=allow WS$ WS2$ --computers-base-dn="DC=test,DC=alt" --domain-dns="test.alt"
Domain: test.alt
Domain DN: DC=test,DC=alt
Computers search base DN: DC=test,DC=alt
Action: allow
Selected computers list:
WS$
WS2$
Allow self nsupdate for this computers list? (Y/n):
WS$			S-1-5-21-3099202228-3607437695-3279060739-1107	DONE
WS2$			S-1-5-21-3099202228-3607437695-3279060739-1113	DONE

Другие решения:

воспользоваться RSAT оснасткой DNS на Windows машине и задать необходимые права вручную;
в той же оснастке DNS для всего DNS домена дать права на запись группе «Domain Computers» (не рекомендуется);
воспользоваться инструментом samba-tool dsacl.

⁠6.3. Администрирование сайтов и подсетей

⁠6.3.1. Утилита samba-tool

Для администрирования сайтов и подсетей в «Альт Домен» можно использовать подкоманду sites утилиты samba-tool.

Примечание

Для выполнения команды на удаленном компьютере можно использовать опцию -H или --URL=. Например:

# samba-tool sites list -H ldap://<DC> -Uadministrator

По умолчанию в качестве значения опции -H передается текущий узел в формате ldap://<имя узла>.

⁠

Таблица 6.11. Команды управления сайтами samba-tool

Команда	Описание	Примечание
sites create <сайт> [опции]	Добавить новый сайт	В качестве аргумента (`сайт`) ожидается общее имя (CN) сайта. После создания сайта в него могут быть добавлены контроллеры домена, например, путём передачи имени сайта в параметре `--site=SITE` при выполнении операции присоединения (см. Присоединение к домену в роли контроллера домена).
sites list [опции]	Вывести список сайтов	Подкоманда поддерживает два формата представления информации о сайтах: без дополнительных параметров — список общих имен (CN) сайтов; с параметром `--json` — вывод подробной информации о каждом сайте в формате JSON.
sites remove <сайт> [опции]	Удалить сайт	В качестве аргумента (`сайт`) ожидается общее имя (CN) сайта.
sites subnet <подкоманда>	Подкоманды управления подсетью	См. Команды управления подсетями samba-tool
sites view <сайт> [опции]	Вывести информацию об отдельном сайте	В качестве аргумента (`сайт`) ожидается общее имя (CN) сайта. Подкоманда выводит тот же набор атрибутов сайта, что и подкоманда `samba-tool sites list --json`

⁠

Таблица 6.12. Команды управления подсетями samba-tool

Команда	Описание	Примечание
sites subnet create <подсеть> <сайт> [опции]	Создать новую подсеть	Параметры вызова: подсеть — IP-адрес и маска подсети; сайт — сайт, за которым будет закреплена подсеть.
sites subnet list <сайт> [опции]	Вывести список подсетей сайта	В качестве аргумента (`сайт`) ожидается общее имя (CN) сайта. Подкоманда поддерживает два формата представления информации о подсетях: без дополнительных параметров — список общих имен (CN) подсетей; с параметром `--json` — вывод подробной информации о каждой подсети в формате JSON.
sites subnet remove <подсеть> [опции]	Удалить подсеть	В качестве аргумента (`подсеть`) ожидается общее имя (CN) существующей подсети.
sites subnet set-site <подсеть> <сайт> [опции]	Закрепить подсеть за сайтом	Параметры вызова: подсеть — IP-адрес и маска подсети; сайт — сайт, за которым будет закреплена подсеть.
sites subnet view <подсеть> [опции]	Просмотр сведений о подсети	В качестве аргумента (`подсеть`) ожидается общее имя (CN) существующей подсети. Подкоманда выводит тот же набор атрибутов подсети, что и подкоманда `samba-tool subnet list --json`

Примечание

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

$ samba-tool sites subnet view --help

Примеры:

получить список сайтов в формате JSON:

# samba-tool sites list --json
{
"Default-First-Site-Name": {
"cn": "Default-First-Site-Name",
"distinguishedName": "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt",
"dn": "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt",
"instanceType": 4,
"name": "Default-First-Site-Name",
"objectCategory": "CN=Site,CN=Schema,CN=Configuration,DC=test,DC=alt",
"objectClass": [
    "top",
    "site"
],
"objectGUID": "4dbdb4a9-ebe9-4ff8-a047-40da60136056",
"showInAdvancedViewOnly": true,
"systemFlags": 1107296256
}
}

получить информацию о сайте:
```
# samba-tool sites view Default-First-Site-Name
```

создать сайт:

# samba-tool sites create newSite
Site newSite created !

создать подсеть:

# samba-tool sites subnet create 192.168.10.0/24 newSite
Subnet 192.168.10.0/24 created !

получить список подсетей для сайта newSite с подробной информацией в JSON:

# samba-tool sites subnet list newSite --json
{
  "192.168.10.0/24": {
    "cn": "192.168.10.0/24",
    "distinguishedName": "CN=192.168.10.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC=test,DC=alt",
    "dn": "CN=192.168.10.0/24,CN=Subnets,CN=Sites,CN=Configuration,DC=test,DC=alt",
    "instanceType": 4,
    "name": "192.168.10.0/24",
    "objectCategory": "CN=Subnet,CN=Schema,CN=Configuration,DC=test,DC=alt",
    "objectClass": [
      "top",
      "subnet"
    ],
    "objectGUID": "5ebde1f9-5369-4673-a10a-b9c10310d137",
    "showInAdvancedViewOnly": true,
    "siteObject": "CN=newSite,CN=Sites,CN=Configuration,DC=test,DC=alt",
    "systemFlags": 1073741824
  }
}

закрепить подсеть 192.168.10.0/24 за сайтом newSite:

# samba-tool sites subnet set-site 192.168.10.0/24 newSite
Subnet 192.168.10.0/24 shifted to site newSite

удалить подсеть:

# samba-tool sites subnet remove 192.168.10.0/24

⁠6.4. Управление парольными политиками

В Альт Домен настройки пароля позволяют настроить:

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

Для управления настройками паролей используется подкоманда passwordsettings утилиты samba-tool.

Управление политиками паролей домена производится на контроллере домена.

⁠6.4.1. Глобальные парольные политики

Для просмотра текущих параметров политик паролей используется команда:

# samba-tool domain passwordsettings show

Например:

# samba-tool domain passwordsettings show
Password information for domain 'DC=test,DC=alt'

Password complexity: on
Store plaintext passwords: off
Password history length: 24
Minimum password length: 7
Minimum password age (days): 1
Maximum password age (days): 42
Account lockout duration (mins): 30
Account lockout threshold (attempts): 0
Reset account lockout after (mins): 30

Команда изменения параметра политик паролей:

# samba-tool domain passwordsettings set <параметр>

Возможные параметры:

--complexity=on|off|default — должен ли пароль отвечать требованиям сложности (по умолчанию on);
--store-plaintext=on|off|default — хранить пароли используя обратимое шифрование (по умолчанию off);
--history-length=целое число|default — число хранимых предыдущих паролей пользователей (требование неповторяемости паролей) (по умолчанию 24);
--min-pwd-length=целое число|default — минимальное количество символов в пароле (по умолчанию 7);
--min-pwd-age=целое число|default — минимальный срок действия пароля (по умолчанию 1);
--max-pwd-age=целое число|default — максимальный срок действия пароля (по умолчанию 43);
--account-lockout-duration=целое число|default — интервал времени (в минутах), в течение которого возможность аутентификации для пользователя, превысившего количество попыток входа, будет заблокирована (по умолчанию 30);
--account-lockout-threshold=целое число|default — допустимое количество неудачных попыток ввода пароля перед блокировкой учетной записи (по умолчанию 0 — никогда не блокировать);
--reset-account-lockout=целое число|default — интервал времени (в минутах), по истечении которого записанное количество попыток начинается заново (по умолчанию 30).

Изменить минимальную длину пароля и количество неудачных попыток входа в систему:

# samba-tool domain passwordsettings set \
--min-pwd-length=7 --account-lockout-threshold=3

Minimum password length changed!
Account lockout threshold changed!
All changes applied successfully!

Примечание

Определить, была ли учётная запись пользователя заблокирована после нескольких неудачных попыток входа в систему можно, просмотрев параметры учётной записи. Если badPwdCount достиг своего порога и для пользователя существует параметр lockoutTime значит учётная запись была заблокирована после нескольких неудачных попыток входа в систему:

# samba-tool user show ivanov
…
badPwdCount: 3
badPasswordTime: 133560395216186060
lockoutTime: 133560395216186060
…

Чтобы разблокировать пользователя, необходимо отредактировать объект учётной записи пользователя, установив для атрибута lockoutTime значение 0:

# samba-tool user edit ivanov
Modified User 'ivanov' successfully

# samba-tool user show ivanov
…
badPasswordTime: 133560395216186060
lockoutTime: 0
…

Разблокировать пользователя также можно в модуле удалённого управления базой данных конфигурации (ADMC) (подробнее см. Модуль удалённого управления базой данных конфигурации):

Изменение значения атрибута lockoutTime в ADMC

⁠6.4.2. Объекты настроек паролей (PSO)

Объекты настроек паролей (Password Settings Object, PSO) позволяют администраторам AD переопределять параметры политики паролей домена и настраивать более точные параметры паролей для конкретных пользователей или групп пользователей. Например, для определённых пользователей можно установить требование минимальной длины пароля, ослабить ограничения сложности для других пользователей и т.д. PSO могут применяться к группам или к отдельным пользователям.

При создании объект PSO сохраняется в LDAP по пути

CN=<имя парольной политики>,CN=Password Settings Container,CN=System,DC=<domain>.

К одному и тому же пользователю может применяться множество различных PSO (напрямую или через группы). Если несколько PSO применяются к одному и тому же пользователю, в основном вступает в силу PSO с наименьшим приоритетом. Однако PSO, которые применяются непосредственно к пользователю, всегда превосходят PSO, унаследованные через членство в группе.

Если для пользователя не создано правила, будет применяться правило по умолчанию.

Примечание

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

# samba-tool domain passwordsettings pso create PwPolicyAdmins 1 --min-pwd-length=16
# samba-tool domain passwordsettings pso apply PwPolicyAdmins "domain admins"
# samba-tool domain passwordsettings pso create PwPolicyUsers 3 --min-pwd-length=8
# samba-tool domain passwordsettings pso apply PwPolicyUsers "domain admins"
# samba-tool domain passwordsettings pso create PwPolicyService 2 --min-pwd-length=24
# samba-tool domain passwordsettings pso apply PwPolicyService "domain admins"

Если объектов PSO вообще нет, производительность не снижается.

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

⁠6.4.2.1. В ADMC

Для управления объектами настроек паролей в «Альт Домен» можно использовать модуль удалённого управления базой данных конфигурации (ADMC). Подробнее см. Управление объектами парольных настроек.

⁠6.4.2.2. С помощью samba-tool

Для работы с объектами PSO используется подкоманда pso утилиты samba-tool.

Команда изменения PSO:

# samba-tool domain passwordsettings pso <подкоманда>

Доступные подкоманды:

apply — применить политику паролей PSO к пользователю или группе;
create — создать новый объект настроек пароля (PSO);
delete — удалить объект настроек пароля (PSO);
list — вывести список всех объектов настроек пароля (PSO);
set — изменить объект настроек пароля (PSO);
show — показать детали объекта настроек пароля;
show-user — отобразить настройки пароля, которые применяются к пользователю;
unapply — обновить PSO, чтобы он больше не применялся к пользователю или группе.

Для создания нового объекта PSO используется команда:

# samba-tool domain passwordsettings pso create <pso-name> <precedence> [options]

Подкоманда создает новую парольную политику с указанным именем (<pso-name>). Имя должно быть уникальным на уровне домена.

При создании политики может быть задан ее приоритет (<precedence>), который будет учитываться в том случае, если к пользователю или группе пользователей применяются несколько политик. Чем меньше значение параметра precedence, тем выше приоритет.

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

Примечание

Для создания политики требуется передать новое значение хотя бы для одного атрибута.

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

# samba-tool domain passwordsettings pso apply <pso-name> <user-or-group-name> [options]

Подкоманда обеспечивает применение атрибутов парольной политики (PSO) с указанным именем (<pso-name>) к указанному пользователю или группе пользователей (<user-or-group-name>).

Пример создания и назначения парольной политики:

Создать парольную политику:

# samba-tool domain passwordsettings pso create PwPolicyUser 1 --min-pwd-length=10
Not all password policy options have been specified.
For unspecified options, the current domain password settings will be used as the default values.
PSO successfully created: CN=PwPolicyUser,CN=Password Settings Container,CN=System,DC=test,DC=alt
Password information for PSO 'PwPolicyUser'

Precedence (lowest is best): 1
Password complexity: on
Store plaintext passwords: off
Password history length: 24
Minimum password length: 10
Minimum password age (days): 1
Maximum password age (days): 42
Account lockout duration (mins): 30
Account lockout threshold (attempts): 0
Reset account lockout after (mins): 30

Назначить созданную политику пользователю ivanov:

# samba-tool domain passwordsettings pso apply PwPolicyUser ivanov
The following PSO settings apply to user 'ivanov'.

Password information for PSO 'PwPolicyUser'

Precedence (lowest is best): 1
Password complexity: on
Store plaintext passwords: off
Password history length: 24
Minimum password length: 10
Minimum password age (days): 1
Maximum password age (days): 42
Account lockout duration (mins): 30
Account lockout threshold (attempts): 0
Reset account lockout after (mins): 30

Note: PSO applies directly to user (any group PSOs are overridden)

Чтобы увидеть, какой PSO действует для данного пользователя, используется команда настройки пароля домена samba-tool pso show-user:

# samba-tool domain passwordsettings pso show-user kim
No PSO applies to user 'kim'. The default domain settings apply.
Refer to 'samba-tool domain passwordsettings show'.

Для получения списка всех объектов PSO в домене используется команда::

# samba-tool domain passwordsettings pso list [options]

Эта подкоманда выводит список всех парольных политик (PSO), доступных в домене, в виде таблицы со столбцами Precedence и PSO name.

⁠6.5. Резервное копирование и восстановление Samba AD DC

⁠6.5.1. Резервное копирование и восстановление из резервной копии

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

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

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

Примечание

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

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

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

Online (онлайн-режим) — выполняется клонирование работающей базы данных DC. По функциональности это похоже на присоединение нового контроллера домена к сети;
Offline (автономный режим) — резервные копии Samba создаются в том виде, в котором они появляются на диске. Сюда входят метаданные репликации, которые являются локальными для этого конкретного контроллера домена и которые не включаются в резервные копии в онлайн-режиме. Такую резервную копию также можно создать, когда контроллер домена находится в автономном режиме (т.е. процесс samba фактически не запущен);
Rename (режим с переименованием) — создаётся файл резервной копии с переименованным доменом (предназначен только для временной замены).

Резервные копии можно создать, используя команду samba-tool domain backup. При этом будет создан файл резервной копии .tar.bz2, который будет содержать полную резервную копию домена (на основе данного контроллера домена). Этот файл резервной копии можно использовать для восстановления домена с помощью команды samba-tool domain backup restore.

Примечание

Следует иметь ввиду, что файл резервной копии — это резервная копия домена, а не контроллера домена. Восстановление файла резервной копии создаст новый контроллер домена с информацией о домене. Чтобы восстановить последующие контроллеры домена, необходимо присоединить данные контроллеры домена к восстановленному контроллеру домена.

⁠6.5.1.1. Создание резервной копии в онлайн/офлайн режимах

⁠6.5.1.1.1. Создание резервной копии в онлайн-режиме

В онлайн-режиме (оnline) формируется набор файлов с актуальными данными службы каталогов, не привязанными к состоянию конкретного контроллера домена.

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

Для создания резервной копии в онлайн-режиме используется команда:

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

Эту команду можно запустить как локально на контроллере домена, так и удалённо на другом узле. При удалённом запуске рекомендуется указать параметр --configfile, чтобы в резервную копию были включены правильные настройки smb.conf (т.к. локальный файл smb.conf может не существовать или его настройки могут отличаться от настроек контроллера домена).

Примечание

Перед созданием файла резервной копии рекомендуется запустить команду samba-tool dbcheck и исправить все ошибки, о которых она сообщает.

Примечание

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

Пример создания резервной копии в онлайн-режиме на контроллере домена:

# mkdir /var/samba-backup-online
# samba-tool domain backup online --targetdir=/var/samba-backup-online --server=dc1 -UAdministrator
Password for [TEST\Administrator]:
workgroup is TEST
realm is test.alt
Looking up IPv4 addresses
Looking up IPv6 addresses
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 AD has been generated at /var/samba-backup-online/tmpxqc6dwts/private/krb5.conf
Merge the contents of this file with your system krb5.conf or replace it with this one. Do not create a symlink!
…
Creating backup file /var/samba-backup-online/samba-backup-test.alt-2024-06-04T16-15-49.475857.tar.bz2...

⁠6.5.1.1.2. Создание резервной копии в автономном режиме

В автономном режиме (оffline) создается резервная копия локальных файлов контроллера домена, на котором запускается команда резервного копирования.

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

Примечание

Отличия автономного резервного копирования от онлайн-режима:

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

Для создания автономной резервной копии используется команда:

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

Примечание

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

Пример создания автономной резервной копии на контроллере домена:

# mkdir /var/samba-backup-offline
# samba-tool domain backup offline --targetdir=/var/samba-backup-offline
running backup on dirs: /var/lib/samba/private /var/lib/samba /etc/samba
Starting transaction on /var/lib/samba/private/secrets
Starting transaction on /var/lib/samba/private/sam.ldb
   backing up /var/lib/samba/private/sam.ldb

…
   adding misc file etc/lmhosts
   adding misc file etc/smb.conf
Backup succeeded.

⁠6.5.1.1.3. Восстановление домена из резервной копии

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

Остановить службу каталогов (samba) на всех контроллерах домена. Этот шаг можно пропустить если используется переименованная резервная копия.
Выполнить команду samba-tool domain backup restore, с требуемыми параметрами для восстановления базы данных домена на одном новом контроллере домена.
Запустить samba на новом контроллере домена.
Повторно добавить старые контроллеры домена в сеть, присоединив их к восстановленному контроллеру домена, например, выполнив команду:
```
samba-tool domain join <dns-realm> DC --server=<restored-dc>
```
Если используется переименованная резервная копия, также потребуется перенастроить сетевые устройства, так чтобы трафик перенаправлялся в восстановленный домен, а не в неисправный/исходный домен.

Примечание

Из файла резервной копии восстанавливается весь домен, а не конкретный контроллера домена. Шаг с командой samba-tool domain backup restore выполняется только один раз, при этом домен воссоздается на одном контроллере домена. Затем все старые контроллеры домена должны быть повторно присоединены к восстановленному контроллеру домена.

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

Команда восстановления домена из резервной копии:

# samba-tool domain backup restore --backup-file=<tar-file> \
--newservername=<DC-name> --targetdir=<new-samba-dir>

где

tar-file — файл резервной копии;
DC-name — новый контроллер домена;
new-samba-dir — каталог, куда будут восстановлены все файлы службы каталогов (smb.conf, sam.ldb и т. п.).

Следует обратить внимание, что указанный целевой каталог должен быть пустым (или не должен существовать). Не рекомендуется восстанавливать базу данных домена в место установки по умолчанию (например, в каталог /var/lib/samba). Вместо этого рекомендуется восстановить базу данных домена в другой целевой каталог, а затем, при запуске samba, использовать параметр -s (или --configfile), например:

# samba -s <targetdir>/etc/smb.conf

Указание восстановленного smb.conf гарантирует, что Samba будет использовать правильные файлы базы данных.

Восстановленный контроллер домена будет добавлен в сайт 'Default-First-Site-Name'. Если он не существует в базе данных, он будет создан. Указать альтернативный сайт для добавления восстановленного контроллера домена можно с помощью параметра --site.

Перед запуском службы каталогов на восстановленном контроллере домена следует еще раз проверить правильность восстановленных настроек smb.conf.

Пример восстановления данных из резервной копии:

# mkdir /var/lib/samba/new
# samba-tool domain backup restore
--backup-file=/home/user/samba-backup-test.alt-2024-06-04T16-15-49.475857.tar.bz2
--newservername=newdc  --targetdir=/var/lib/samba/new
Adding new DC to site 'Default-First-Site-Name'
Updating basic smb.conf settings...
…
Backup file successfully restored to /var/lib/samba/new
Please check the smb.conf settings are correct before starting samba.

⁠6.5.1.2. Переименованная резервная копия

Процедура создания резервной копии и восстановления из неё в режиме переименования:

Создание переименованной резервной копии

В режиме с переименованием (rename) формируется набор файлов с актуальными данными службы каталогов, не привязанными к состоянию конкретного контроллера домена, с переименованием домена.

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

Создание резервной копии в режиме переименования может применяться для:

запуска временного альтернативного домена на случай катастрофического отказа основного домена. На альтернативный/переименованный домен можно переключиться с минимальными усилиями. Затем можно запустить два домена одновременно, не мешая друг другу (переименованный/альтернативный домен будет предоставлять основные сетевые службы Samba, в это же время на исходных контроллерах домена можно устранять неполадки);
создания реалистичного лабораторного домена: домен переименовывается и удаляются конфиденциальные данные (на данный момент только самые важные), чтобы создать предпроизводственную среду для тестирования.

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

все DN-имена;
объект раздела домена и его NetBIOS-имя;
объекты зоны DNS, а также атрибуты dnsRoot.

Примечание

Модифицируется только клонированный домен — исходный домен вообще не затрагивается.

Объекты, которые не меняются:

userPrincipalName (UPN) по-прежнему будет использовать user@old-realm. Если при выполнении команды резервного копирования с переименованием домена использовался параметр --keep-dns-realm, пользователи могут использовать для входа в домен свои полные UPN-имена. В противном случае они могут использовать имена в формате user@new-realm (при условии, что конфигурация Kerberos корректно обрабатывает новую область);
объекты групповой политики: атрибуты объекта групповой политики (gPCFileSysPath и gPLink) вообще не обновляются, файлы в sysvol сохраняются с прежним именем области в путях (например, sysvol/test.alt/Policies). Каталог для файлов политик в sysvol по умолчанию создается с новым именем области (например, sysvol/newtest.alt/Policies).

Примечание

Обновление объектов групповой политики для обработки изменения имени домена — нетривиальный процесс. Лучший способ справиться с долгосрочным переименованием домена — вручную экспортировать файлы ГП, а затем повторно импортировать их. В краткосрочной перспективе переименованный домен сможет продолжать использовать объекты групповой политики, относящиеся к старой области.

Переименование домена выполняется в два этапа:

создание переименованной резервной копии домена: команда samba-tool domain backup rename делает клон работающей базы данных DC, в процессе клонирования переименовывает домен и создаёт файл резервной копии;
восстановление резервной копии домена: команда samba-tool domain backup restore из файла резервной копии формирует файлы, необходимые для запуска нового контроллера домена Samba.

⁠6.5.1.2.1. Создание переименованной резервной копии

Команда для создания переименованной резервной копии:

# samba-tool domain backup rename <new-domain-netbios> \
<newdomain-dns-realm> --server=<dc-to-backup> \
--targetdir=<output-dir> --no-secrets -UAdministrator

где

new-domain-netbios — новое имя NETBIOS;
newdomain-dns-realm — новая область DNS;
output-dir — каталог, куда будет записан сгенерированный файл резервной копии.

Предупреждение

Параметр --no-secrets исключает из резервной копии конфиденциальную информацию о паролях (например, такие атрибуты, как unicodePwd, lmPwdHistory и т. д.) для всех пользователей в домене. При этом, файл резервной копии по-прежнему содержит конфиденциальную информацию, такую как имена учётных записей пользователей.

В результате выполнения команды формируется файл резервной копии /var/samba-backup-rename/samba-backup-newtest.alt-<timestamp>.tar.bz2.

В случае, если команда создания резервной копии запускается на узле, который будет использоваться в качестве нового контроллера домена (он должен быть подключён к рабочему домену), рекомендуется иметь файл smb.conf, максимально соответствующий производственному контроллеру домена, и передать его команде резервного копирования (с помощью параметра --configfile=smb.conf). Это гарантирует, что резервная копия будет содержать smb.conf, точно соответствующий домену.

Пример создания переименованной резервной копии на контроллере домена:

# mkdir /var/samba-backup-rename
# samba-tool domain backup rename NEWTEST newtest.alt --server=dc1 \
--targetdir=/var/samba-backup-rename --no-secrets -UAdministrator

New realm for backed up domain: newtest.alt
New base DN for backed up domain: DC=newtest,DC=alt
New domain NetBIOS name: NEWTEST
Password for [TEST\Administrator]:
Provisioning the new (renamed) domain...
…

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

⁠6.5.1.2.2. Восстановление данных из резервной копии

Файл резервной копии /var/samba-backup-rename/samba-backup-newtest.alt-<timestamp>.tar.bz2 может использоваться для восстановления клонированной и переименованной базы данных на диске. В восстановленном домене будет только один новый контроллер домена с именем, указанными с помощью опции --newservername. В последующем к нему могут быть присоединены другие контроллеры домена. Для указания нового каталога для размещения всех файлов службы каталогов (smb.conf, sam.ldb и т. п.) может использоваться опция --targetdir.

Команда восстановления домена из резервной копии:

# samba-tool domain backup restore --backup-file=<tar-file> \
--newservername=<DC-name> --targetdir=<new-samba-dir>

где

tar-file — файл резервной копии;
DC-name — новый контроллер домена;
new-samba-dir — каталог, куда будут восстановлены все файлы службы каталогов (smb.conf, sam.ldb и т. п.).

Пример восстановления домена из переименованной резервной копии:

# mkdir /var/lib/samba/newtest
# samba-tool domain backup restore --targetdir=/var/lib/samba/newtest \
--newservername=NEWDC1 --backup-file=/home/user/samba-backup-newtest.alt.alt-2024-04-17T20-09-56.883910.tar.bz2

Примечание

Целевой каталог должен быть пустым (или не должен существовать). Не рекомендуется восстанавливать базу данных домена в место установки по умолчанию (например, в каталог /var/lib/samba/). Однако можно указать подкаталог (например, /var/lib/samba/newtest/).

Примечание

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

⁠6.5.1.2.3. Сброс пароля

Во время резервного копирования/восстановления пароль для учётной записи администратора сбрасывается на случайно сгенерированный пароль. Для его изменения можно просто обновить базу данных на локальном диске, выполнив команду:

# samba-tool user setpassword Administrator \
--newpassword=<пароль> -H /var/lib/samba/newtest/private/sam.ldb

Для тестирования аутентификации пользователей можно либо добавить дополнительные «тестовые» учётные записи пользователей/машин, либо «командовать» некоторыми учётными записями, скопированными из рабочего домена. Для учётных записей, скопированных из рабочего домена, не будут установлены пароли, поэтому на этом этапе также можно сбросить пароли для выбранных учётных записей. Или можно сделать это позже, когда служба каталогов действительно запустится на новом контроллере домена.

⁠6.5.1.2.4. Запуск Samba

Перед запуском службы каталогов на новом контроллере домена, рекомендуется проверить корректность настроек в восстановленном файле smb.conf (например, /var/lib/samba/newtest/etc/smb.conf) и в файле /etc/krb5.conf, и при необходимости вручную внести в них изменения.

При запуске службы каталогов необходимо указать восстановленный smb.conf (это гарантирует, что Samba загрузит правильные файлы базы данных для нового домена). Например:

# samba -s /var/lib/samba/newtest/etc/smb.conf

При первом запуске службы каталогов могут быть зарегистрированы ошибки DNS. Это связано с тем, что samba_dnsupdate запускается автоматически и добавляет записи DNS для нового домена.

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

# ldbsearch -H ldap://NEWDC1 -UAdministrator

⁠6.5.1.2.5. Обновление подсетей сайта

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

⁠6.5.1.3. Рекомендуемая стратегия

Восстановление файла резервной копии имеет несколько неудобств:

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

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

выполнить восстановление из файла резервной копии на временный контроллер домена и запустить службу каталогов;
повторно по одному присоединить существующие контроллеры домена к временному контроллеру домена (во время присоединения можно повторно использовать одно и то же имя сервера и место установки по умолчанию);
после присоединения всех существующих контроллеров домена к восстановленному домену, можно удалить временный контроллер домена (например, с помощью команды samba-tool domain demote).

В этом случае новая сеть контроллеров домена будет полностью повторять существующую.

Примечание

Пример разворачивания домена (SAMBA_INTERNAL) из резервной копии на ВМ:

Подготовить узел:

установить пакет task-samba-dc (или task-samba-dc-mitkrb5):
```
# apt-get install task-samba-dc
```

остановить конфликтующие службы:

# for service in smb nmb krb5kdc slapd bind; do systemctl disable $service; systemctl stop $service; done

очистить базы и конфигурацию Samba:

# rm -f /etc/samba/smb.conf
# rm -rf /var/lib/samba/*
# rm -rf /var/cache/samba

Скопировать файл резервной копии на ВМ и выполнить восстановление домена из файла резервной копии:

# samba-tool domain backup restore --backup-file=/home/user/samba-backup-test.alt-2024-04-17T20-09-56.883910.tar.bz2 --newservername=newdc --targetdir=/var/lib/samba
Adding new DC to site 'Default-First-Site-Name'
Updating basic smb.conf settings...
…
Backup file successfully restored to /var/lib/samba
Please check the smb.conf settings are correct before starting samba.

Скопировать файл smb.conf из каталога /var/lib/samba/etc/ в /etc/samba/:
```
# cp /var/lib/samba/etc/smb.conf /etc/samba/
```
Запустить службу каталогов:
```
# systemctl enable --now samba
```
Заменить файл /etc/krb5.conf файлом из каталога /var/lib/samba/private/:
```
# cp /var/lib/samba/private/krb5.conf /etc/krb5.conf
```

Проверить работоспособность домена (см. Проверка работоспособности домена):

# samba-tool domain info 127.0.0.1
Forest           : test.alt
Domain           : test.alt
Netbios domain   : TEST
DC name          : newdc.test.alt
DC netbios name  : NEWDC
Server site      : Default-First-Site-Name
Client site      : Default-First-Site-Name

# smbclient -L localhost -Uadministrator
Password for [TEST\administrator]:

Sharename       Type      Comment
---------       ----      -------
sysvol          Disk
netlogon        Disk
share           Disk      Commonplace
Free            Disk
IPC$            IPC       IPC Service (Samba 4.19.6)
SMB1 disabled -- no workgroup available

# host -t SRV _kerberos._udp.test.alt.
_kerberos._udp.test.alt has SRV record 0 100 88 newdc.test.alt.

⁠6.5.1.4. Отладочная информация

Если команды резервного копирования или восстановления завершится с ошибкой, то они могут оставить после себя временный каталог (указанный в параметре --targetdir). Это может помочь понять, почему произошел сбой. Необходимо удалить этот каталог перед повторным запуском команды восстановления.

Создание резервной копии:

резервное копирование следует запускать от имени пользователя root. Резервное копирование в онлайн-режиме может быть успешным и для пользователя без полномочий root, но при попытке восстановить данные из такой резервной копии могут возникнуть проблемы;
для резервных копий, выполненных в онлайн-режиме или в режиме переименования, следует проверить правильность используемых учётных данных и сведений о сервере, например:
```
# ldbsearch -H ldap://<server> -UAdministrator
```
чтобы узнать больше информации о причине сбоя можно увеличить уровень журналирования. Например, добавить в команду параметр --debug=3;
работа команд, для выполнения резервного копирования резервного копирования в онлайн-режиме или в режиме переименования, очень похожа на присоединение к контроллеру домена. Если известно, что присоединение к контроллеру домена в вашей сети не удается, то эти команды также вероятно не будут работать. Сообщения «Committing SAM database» и «Cloned domain <domain>», говорят о том, что часть резервного копирования, подобная присоединению, скорее всего, выполнена успешно;
инструменты резервного копирования не работают напрямую с контроллером домена Windows (в основном простое резервное копирование файлов sysvol не удается из-за блокировки службы DFSR). Если используется смешанный домен контроллера домена, следует создать резервную копию контроллера домена Samba, а не контроллера домена Windows. Если используется домен Windows, можно на время резервного копирования на контроллере домена остановить службу DFSR «Репликация DFS».

Восстановление из резервной копии:

команду восстановления необходимо запускать от имени пользователя root;

имя, указанное в параметре --newservername, не должно существовать в исходном домене. В противном случае будет получена ошибка:

Adding CN=NEWDC,OU=Domain Controllers,DC=test,DC=alt
ERROR(ldb): uncaught exception - Entry CN=NEWDC,OU=Domain Controllers,DC=test,DC=alt already exists
  File "/usr/lib64/samba-dc/python3.9/samba/netcmd/__init__.py", line 186, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib64/samba-dc/python3.9/samba/netcmd/domain_backup.py", line 562, in run
    ctx.join_add_objects(specified_sid=dom_sid(str(sid)))
  File "/usr/lib64/samba-dc/python3.9/samba/join.py", line 674, in join_add_objects
    ctx.samdb.add(rec, controls=controls)

если команда резервного копирования выполнялась локально на контроллере домена, то файл резервной копии должен содержать файл smb.conf контроллера домена. Однако smb.conf в файле резервной копии может содержать конфигурацию «интерфейсов», которая не соответствует IP-адресам на контроллере домена, на котором разворачиваются данные из резервной копии. Избежать этой проблемы можно, указав аргумент --host-ip во время восстановления (это имеет значение только на переименованных резервных копий).

⁠6.5.2. Восстановление произвольного контроллера домена после фатального сбоя

Служба каталогов использует единую распределенную базу данных, которая хранит сведения обо всех сетевых ресурсах домена. Каждый контроллер домена работает с локальной копией этой базы данных. Синхронизацию изменений между такими локальными копиями обеспечивает механизм репликации. При выполнении на существующем контроллере домена команды samba-tool domain join DC локальная копия базы данных полностью перезаписывается актуальной копией распределенной базы данных (происходит процесс «повторного ввода» контроллера в домен).

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

Алгоритм восстановления контроллера домена под тем же именем, если в результате каких либо технических проблем он пришел в неработоспособное состояние:

Вывести контроллер домена из эксплуатации, путём удаления всей информации о нём. Для этого на любом работающем контроллере домена выполнить команду:
```
# samba-tool domain demote --remove-other-dead-server=dc2 -UAdministrator
```
где dc2 — имя (hostname) не функционирующего контроллера домена.
На узле, который будет заменой вышедшего из строя контроллера домена, выполнить следующие действия:
- в файле /etc/krb5.conf указать опции default_realm = TEST.ALT и dns_lookup_realm = false;
- остановить все зависимые службы:
  # for service in samba smb nmb krb5kdc slapd bind; do systemctl disable $service; systemctl stop $service; done
- очистить всю конфигурацию Samba:
  # rm -f /etc/samba/smb.conf # rm -rf /var/lib/samba # rm -rf /var/cache/samba # mkdir -p /var/lib/samba/sysvol
- ввести узел в домен как дополнительный контроллер домена:
  # samba-tool domain join test.alt DC --dns-backend=SAMBA_INTERNAL -Uadministrator --realm=test.alt
- запустить samba и обновить dns:
  # systemctl enable --now samba # samba_dnsupdate --use-samba-tool --verbose

Важно

На других контроллерах домена в выводе команды samba-tool drs showrepl некоторое время будет присутствовать сообщение WERR_GEN_FAILURE в секции неисправного КД:

…
DC=DomainDnsZones,DC=test,DC=alt
  Default-First-Site-Name\DC2 via RPC
    DSA object GUID: b78f2c9d-5c62-4497-a5e1-4fc85aedf1cb
    Last attempt @ Wed Apr 24 07:51:24 2024 MSK failed, result 31 (WERR_GEN_FAILURE)
    28 consecutive failure(s).
    Last success @ NTTIME(0)

DC=ForestDnsZones,DC=test,DC=alt
  Default-First-Site-Name\DC2 via RPC
    DSA object GUID: b78f2c9d-5c62-4497-a5e1-4fc85aedf1cb
    Last attempt @ Wed Apr 24 07:51:24 2024 MSK failed, result 31 (WERR_GEN_FAILURE)
    28 consecutive failure(s).
    Last success @ NTTIME(0)
…

Это нормально, и через некоторое время после полной репликации оно исчезнет. Репликация может занять до нескольких часов.

⁠6.6. Роли FSMO

FSMO, или Flexible single-master operations (операции с одним исполнителем) — это операции, выполняемые контроллерами домена AD, которые требуют обязательной уникальности сервера для каждой операции. В зависимости от типа операции уникальность FSMO подразумевается в пределах одного домена или леса доменов. Различные типы FSMO могут выполняться как на одном, так и на нескольких контроллерах домена. Выполнение FSMO сервером называют ролью сервера, а сами сервера — хозяевами операций.

Active Directory — это центральный репозиторий, в котором хранятся все объекты и соответствующие им атрибуты. Это иерархическая база данных с поддержкой нескольких источников. Большинство операций в AD можно выполнять на любом контроллере домена. Служба репликации AD скопирует изменения на остальные контроллеры домена, обеспечив идентичность базы AD на всех контроллерах одного домена. Один из способов разрешения конфликтов заключается в том, что сохраняются изменения, внесенные последними. Изменения, внесенные остальными контроллерами домена, игнорируются.

Однако существует несколько операций (например, изменение схемы AD), при которых конфликты недопустимы. В AD некоторые обновления выполняются на одном специальном контроллере домена, а затем реплицируются на все остальные. AD использует роли, назначенные контроллерам домена, для этих специальных задач. Так как роль не привязана к одному контроллеру домена, она называется ролью FSMO.

В настоящее время существует семь ролей FSMO с разными областями действия:

Эмулятор PDC/PDC Emulator (один на домен);
Хозяин RID/RID Master (один на домен);
Хозяин схемы/Schema Master (один на лес);
Хозяин именования доменов/Domain Naming Master (один на лес);
Хозяин инфраструктуры/Infrastructure Master (один на домен);
Хозяин зоны DNS домена/Domain DNS Zone Master role (один на домен);
Хозяин зоны DNS леса/Forest DNS Zone Master role (один на лес).

⁠6.6.1. Семь ролей FSMO

Ниже описаны роли FSMO, их функции и требования к доступности. Эти сведения позволяют определить последствия, когда контроллер домена, владеющий этой ролью, находится в автономном режиме.

⁠6.6.1.1. Эмулятор PDC

Владелец роли эмулятора PDC отвечает за следующие задачи в домене:

является сервером точного времени для клиентов в домене. Для аутентификации Kerberos необходима точная синхронизация времени. Эмулятор PDC корневого домена в лесу является по умолчанию сервером точного времени для эмуляторов PDC в дочерних доменах;
изменения паролей, внесенные другими контроллерами домена в домене, реплицируются преимущественно в эмулятор PDC. В случае недоступности эмулятора PDC информация об изменении пароля всё равно распространится по домену, просто произойдет это несколько медленнее;
выполняет все функции, предоставляемые PDC в стиле NT4;
обрабатывает блокировки учетных записей. Сбои аутентификации на любом контроллере домена в домене, вызванные неправильным паролем, перенаправляются в эмулятор PDC до того, как сообщение о сбое из-за неправильного пароля будет передано пользователю. При успешной аутентификации учётной записи сразу после неудачной попытки, о ней уведомляется эмулятор PDC и сбрасывает счетчик неудачных попыток в ноль;
консоль управления групповыми политиками по умолчанию соединяется с эмулятором PDC, и изменения политик происходят на нем же. Если эмулятор PDC недоступен, то будет нужно указать редактору, к какому контроллеру домена подключиться;
в больших средах контроллер домена, которому принадлежит роль эмулятора PDC, может иметь высокую загрузку ЦП из-за сквозной аутентификации, смены пароля и синхронизации времени.

На каждый домен приходится один эмулятор PDC.

Этот контроллер домена должен, по возможности, быть доступен всегда, потому что для Kerberos требуется точное время на всех машинах в домене. Если клиенты настроены на использование другого источника времени и в сети нет клиентов до Windows 2000, временное отсутствие может быть менее критичным.

Для поиска эмулятора PDC можно использовать команду host:

# host -t SRV _ldap._tcp.pdc._msdcs.<домен>

Например:

# host -t SRV _ldap._tcp.pdc._msdcs.test.alt
_ldap._tcp.pdc._msdcs.test.alt has SRV record 0 100 389 dc1.test.alt.

⁠6.6.1.2. Хозяин RID

Владелец роли FSMO хозяина RID отвечает за обработку запросов пула RID от всех DC в домене. Он также отвечает за перемещение объектов в другой домен и удаление их из домена.

Все объекты безопасности, например, учётные записи и группы пользователей/компьютеров имеют уникальный идентификатор безопасности (SID). SID объектов содержит идентификатор безопасности (SID) домена, одинаковый для всех объектов в домене, и относительный идентификатор (RID), уникальный для каждого идентификатора безопасности субъекта безопасности, созданного в домене.

Каждому контроллеру домена в домене выделяется пул относительных идентификаторов RID, которые разрешено назначать созданным субъектам безопасности. По умолчанию это диапазон из 500 уникальных RID для всего домена, назначаемых хозяином RID каждому контроллеру домена. Если объект безопасности создается на контроллере домена, то RID берется из этого пула, что гарантирует его уникальность в домене. Если выделенный пул RID контроллера домена оказывается ниже порогового значения (ниже 50 %), контроллер домена выполняет запрос дополнительных идентификаторов RID к хозяину RID в домене. Хозяин RID в домене отвечает на запрос, извлекая идентификаторы RID из невыделенного пула RID домена и назначая их пулу запрашивающего контроллера домена.

На каждый домен приходится один хозяин RID.

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

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

⁠6.6.1.3. Хозяин схемы

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

Схема каталога (контекст именования схемы) или LDAP://cn=schema,cn=configuration,dc=<домен> существует на всех контроллерах домена. Обновления выполняются только на хозяине схемы. После завершения обновления схема реплицируется из хозяина схемы во все остальные контроллеры домена каталога.

В каждом лесу есть один хозяин схемы.

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

⁠6.6.1.4. Хозяин именования доменов

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

Информация об именах доменов хранится в разделе «Контекст именования конфигурации» в CN=Partitions,CN=Configuration,DC=<домен>. Этот раздел существует на всех контроллерах домена, но обновляется только на хозяине именования доменов.

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

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

⁠6.6.1.5. Хозяин инфраструктуры

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

На каждый домен приходится один хозяин инфраструктуры.

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

⁠6.6.1.6. Хозяин зоны DNS домена

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

На каждый домен приходится один хозяин зоны DNS домена.

⁠6.6.1.7. Хозяин зоны DNS леса

Контроллер домена, которому принадлежит роль хозяина зоны DNS леса, отвечает за координацию добавления или удаления записей всего леса на DNS-серверах, на которых размещена зона DNS верхнего уровня. Эти записи содержат имена серверов глобального каталога (GC).

На каждый домен приходится один хозяин зоны DNS леса.

⁠6.6.2. Просмотр и передача ролей FSMO

По возможности следует передавать роли FSMO штатным образом и не использовать принудительную передачу (захват роли). Для штатной передачи роли требуется, чтобы контроллер домена, которому в данный момент принадлежит роль, работал и был подключен к сети. В этом случае при передаче роли старый контроллер домена узнает, что он больше не владеет ролью.

Если контроллер домена сломан (например, из-за аппаратного дефекта) и больше никогда не будет возвращён в сеть, можно использовать принудительную передачу (захватить роль на оставшемся контроллере домена). Если старый контроллер домена будет снова подключён к сети, это вызовет конфликты и приведет к неконсистентному AD (т.к. старый контроллер домена не заметит изменения и по-прежнему будет считать себя владельцем роли).

Роли FSMO можно передавать с помощью инструмента командной строки samba-tool или в модуле удалённого управления базой данных конфигурации (ADMC) (подробнее см. Модуль удалённого управления базой данных конфигурации).

⁠6.6.2.1. ADMC

Для просмотра текущего владельца роли необходимо выбрать пункт меню Файл → Мастера Операций. В открывшемся окне в списке слева следует выбрать роль и в поле Текущий мастер будет показан владелец роли:

Список возможных ролей:

DNS домена — хозяин зоны DNS домена;
DNS леса — хозяин зоны DNS леса;
PDC эмуляция — эмулятор PDC;
Схема — хозяин схемы;
Имена домена — хозяин именования доменов;
Инфраструктура — хозяин инфраструктуры;
RID распределение — хозяин RID.

Для штатной передачи роли необходимо выполнить следующие действия:

В окне Параметры подключения — ADMC (Файл → Параметры подключения) выбрать контроллер домена, который должен стать новым владельцем роли, и нажать кнопку ОК:
В окне Мастера Операций — ADMC (Файл → Мастера Операций) выбрать роль (при этом в поле Текущий мастер будет показан текущий владелец роли, а в поле Изменить на — контроллер домена, который должен стать новым владельцем роли) и нажать кнопку Изменить:
Владелец роли будет изменён:

⁠6.6.2.2. Инструмент samba-tool

⁠6.6.2.2.1. Просмотр текущих владельцев

Операция просмотра списка владельцев ролей FSMO доступна всем пользователям.

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

# samba-tool fsmo show
SchemaMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
InfrastructureMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
RidAllocationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
DomainNamingMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
DomainDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
ForestDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt

⁠6.6.2.2.2. Передача роли

Операция передачи роли FSMO доступна пользователям со следующими полномочиями:

передача ролей уровня леса — администраторы леса (члены группы Enterprise Admins);
передача ролей уровня домена — администраторы домена (члены группы Domain Admins);
передача роли владельца схемы каталога — администраторы схемы (члены группы Schema Admins).

Для штатной передачи роли необходимо на контроллере домена, который должен стать новым владельцем роли, выполнить команду:

# samba-tool fsmo transfer --role=<роль>

Список возможных ролей:

rid — хозяин RID (RidAllocationMasterRole);
pdc — эмулятор PDC (PdcEmulationMasterRole);
infrastructure — хозяин инфраструктуры (InfrastructureMasterRole);
schema — хозяин схемы (SchemaMasterRole);
naming — хозяин именования доменов (DomainNamingMasterRole);
domaindns — хозяин зоны DNS домена (DomainDnsZonesMasterRole);
forestdns — хозяин зоны DNS домена (ForestDnsZonesMasterRole);
all — все роли.

Пример штатной передачи роли (команда выполняется на DC2):

# samba-tool fsmo transfer --role=infrastructure
FSMO transfer of 'infrastructure' role successful

Проверка:

# samba-tool fsmo show
SchemaMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
InfrastructureMasterRole owner: CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
RidAllocationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
PdcEmulationMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
DomainNamingMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
DomainDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt
ForestDnsZonesMasterRole owner: CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=alt

⁠6.6.2.2.3. Захват роли FSMO

Операция захвата роли FSMO доступна пользователям со следующими полномочиями:

захват ролей уровня леса — администраторы леса (члены группы Enterprise Admins);
захват ролей уровня домена — администраторы домена (члены группы Domain Admins);
захват роли владельца схемы каталога — администраторы схемы (члены группы Schema Admins).

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

# samba-tool fsmo seize --role=<роль>

Список возможных ролей:

rid — хозяин RID (RidAllocationMasterRole);
pdc — эмулятор PDC (PdcEmulationMasterRole);
infrastructure — хозяин инфраструктуры (InfrastructureMasterRole);
schema — хозяин схемы (SchemaMasterRole);
naming — хозяин именования доменов (DomainNamingMasterRole);
domaindns — хозяин зоны DNS домена (DomainDnsZonesMasterRole);
forestdns — хозяин зоны DNS домена (ForestDnsZonesMasterRole);
all — все роли.

Важно

Если роль была передана принудительно, старый контроллер домена больше никогда не должен подключаться к сети!

Примечание

При передаче ролей domaindns и forestdns необходимо предоставить аутентификацию.

Примечание

В ранних версиях samba-tool была ошибка, не позволявшая захватить роль naming:

# samba-tool fsmo seize --role=naming
ERROR (ldb): uncaught exception — Failed FSMO transfer: WERR_BADFILE

В этом случае необходимо использовать «ещё более принудительную передачу»:

# samba-tool fsmo seize --force --role=naming

⁠6.7. Настройка Samba для привязки к определённым интерфейсам

Если на сервере настроено несколько сетевых интерфейсов, можно настроить Samba для привязки только к определенным интерфейсам.

Например, для того чтобы привязать все службы Samba к устройству enp0s3 и loopback (lo) необходимо добавить следующие параметры в раздел [global] файла smb.conf:

bind interfaces only = yes
interfaces = lo enp0s3

и перезапустить службу Samba:

# systemctl restart samba.service

В параметре interfaces вместо имён интерфейсов можно указывать IP-адреса.

Примечание

Некоторые утилиты подключаются к петлевому IP-адресу, если имя хоста не указано. Поэтому всегда нужно указывать Samba прослушивать петлевые (lo) устройства.

⁠6.8. Создание keytab-файла

⁠6.8.1. Назначение и формат SPN

SPN (Service Principal Name) — уникальный идентификатор экземпляра сервиса. SPN используется аутентификацией Kerberos для сопоставления экземпляра сервиса с учетной записью сервиса (service logon account). Это позволяет клиентским приложением аутентифицироваться в роли сервиса даже не зная имени пользователя.

До того как аутентификация Kerberos сможет использовать SPN для аутентификации сервиса, SPN должен быть привязан к учётной записи, которая будет использоваться для входа. К учётной записи может быть привязано несколько SPN. SPN может быть привязан только к одной учетной записи. Если учетная запись, привязанная к SPN, изменяется, то необходимо заново выполнить привязку.

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

SPN состоит из двух обязательных элементов и двух дополнительных элементов:

<service class>/<host>:<port>/<service name>

Элементы SPN:

service class (обязательный элемент) — строка, указывающая на класс, к которому относится сервис (например: HTTP, www, ldap и т. п.);
host (обязательный элемент) — имя компьютера, на котором работает сервис; это может быть полное доменное имя (FQDN) или NetBIOS-имя;
port — номер порта; может использоваться в том случае, если несколько экземпляров сервиса одного класса работают на одном узле; не требуется указывать, если экземпляр сервиса один и работает на стандартном для своего класса порту;
service name — имя реплицируемого сервиса, которое позволяет идентифицировать предоставляемые сервисом данные или обслуживаемый сервисом домен; в качестве имени могут использоваться DN-имя или objectGUID объекта службы каталогов, DNS-имя домена (если сервис реализует определенную службу на уровне всего домена), DNS-имя записи SRV или MX.

Примечание

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

для файлового сервера могут использоваться следующие SPN (их можно добавить столько, сколько нужно):
- HOST/fileserver.test.alt
- HOST/fileserver
- HOST/fileserver@TEST.ALT
- CIFS/fileserver.test.alt
для веб-сервера (подробнее см. Настройка аутентификации для веб-сервера):
- HTTP/web.test.alt
для прокси-сервера:
- HTTP/proxy.test.alt
на практике можно сопоставить SPN с IP-адресом, но это не рекомендуется:
- HOST/192168.0.129@TEST.ALT

Keytab-файл — это файл содержащий пары Kerberos принципалов и их ключей (полученных с использованием Kerberos пароля). Эти файлы используются для аутентификации в системах, использующих Kerberos, без ввода пароля. Если пароль принципала изменится, то keytab-файл необходимо будет сгенерировать заново.

Важно

Каждый кто имеет разрешения на чтения keytab-файла может воспользоваться любыми ключами в нем. Чтобы предотвратить нежелательное использование, необходимо ограничивать права доступа при создании keytab-файла.

⁠6.8.2. Создание SPN и генерация keytab с помощью samba-tool

Добавить имена SPN для пользователя можно с помощью команды samba-tool spn add:

# samba-tool spn add host/fdqn@KerberosRealm <sAMAccount name>

После добавления SPN можно сгенерировать keytab, выполнив команду:

# samba-tool domain exportkeytab <имя>.keytab --principal=[<sAMAccount name> | <SPN>]

В результате выполнения этой команды будет создан keytab-файл <имя>.keytab, содержащий UPN или SPN, в зависимости от того, что было указано в параметре --principal.

Получить дополнительную информацию можно на справочной странице samba-tool (8) (man samba-tool).

Примечание

В команде нужно использовать или <sAMAccount name> или <SPN>, но не оба параметра сразу.

Пример:

привязать к пользователю SPN:
```
# samba-tool spn add HTTP/test.alt webauth
```

создать keytab:

# samba-tool domain exportkeytab /tmp/web.keytab --principal=HTTP/test.alt
Export one principal to /tmp/keytab

проверка:

# klist -ke /tmp/web.keytab
Keytab name: FILE:/tmp/web.keytab
KVNO Principal
---- ------------------------------------------------------------------------
   2 HTTP/test.alt@TEST.ALT (DEPRECATED:arcfour-hmac)

Можно также проверить авторизацию в домене по имени SPN с помощью keytab-файла. Для этого на контроллере домена получить билет Kerberos:

# kinit administrator@TEST.ALT
Password for administrator@TEST.ALT:

И выполнить команду:

# kinit -5 -V -k -t /tmp/web.keytab HTTP/test.alt
Using default cache: /tmp/krb5cc_0
Using principal: HTTP/test.alt@TEST.ALT
Using keytab: /tmp/web.keytab
Authenticated to Kerberos v5

Примечание

Если при проверке авторизации возникает ошибка:

kinit: Client not found in Kerberos database while getting initial credentials

Необходимо в ADMC изменить для пользователя webauth значение параметра userPrincipalName на значение servicePrincipalName + REALM (в данном примере нужно поменять webauth на HTTP/test.alt@TEST.ALT):

ADMC. Изменение параметра userPrincipalName

И заново экспортировать keytab-файл.

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

# samba-tool spn list <user> [options]

В качестве аргумента передается имя учетной записи SAM (значение атрибута sAMaccountName).

Команда удаления идентификатора SPN, привязанного к учетной записи пользователя:

# samba-tool spn delete <name> <user> [options]

В качестве аргументов передаются значение SPN (name) и имя учетной записи SAM (значение атрибута sAMaccountName).

⁠6.9. Настройка DHCP-сервера для обновления DNS-записей

В этом разделе описана настройка DHCP-сервера для автоматического обновления DNS-записей Samba в домене.

Предварительные условия:

DHCP-сервер устанавливается на одном из контроллеров домена;
созданы все необходимые обратные зоны;
если используется Bind9, Bind9_dlz должен быть установлен и должен работать на контроллере домена Samba AD, на котором выполняется данная настройка.

Описание имеющейся сети:

Realm: TEST.ALT
Подсеть: 192.168.0.0
Маска сети: 255.255.255.0
Широковещательный адрес: 192.168.0.255
Шлюз по умолчанию: 192.168.0.1
Имя домена: test.alt
DNS-сервера: 192.168.0.122, 192.168.0.123
Netbios-сервера: 192.168.0.122, 192.168.0.123
Ntp-сервера: 192.168.0.122, 192.168.0.123
Диапазон арендуемых IP-адресов: 192.168.0.150 192.168.0.200

⁠6.9.1. Настройка DHCP-сервера

Все действия, указанные ниже, выполняются на узле dc1.test.alt (192.168.0.122), если не указано иное.

Создать пользователя (в примере dhcpduser), от имени которого будут производится обновления DNS-записей:

# samba-tool user create dhcpduser \
  --description="Пользователь для обновления TSIG-GSSAPI DNS через DHCP-сервер" \
  --random-password
User 'dhcpduser' added successfully

Установить срок действия пароля (бессрочный) для созданного пользователя и добавить его в группу DnsAdmins:

# samba-tool user setexpiry dhcpduser --noexpiry
Expiry for user 'dhcpduser' disabled.
# samba-tool group addmembers DnsAdmins dhcpduser
Added members to group DnsAdmins

Экспортировать файл keytab, чтобы пользователь мог аутентифицироваться через Kerberos:

# samba-tool domain exportkeytab --principal=dhcpduser@TEST.ALT /etc/dhcp/dhcpduser.keytab
Export one principal to /etc/dhcp/dhcpduser.keytab
# chown dhcpd:dhcp /etc/dhcp/dhcpduser.keytab
# chmod 400 /etc/dhcp/dhcpduser.keytab

Примечание

Параметр dhcpd:dhcp указывает пользователя и группу, от имени которых работает DHCP-сервер.

Создать скрипт, который будет выполнять обновления (файл /usr/local/bin/dhcp-dyndns.sh):

#!/bin/bash
#
# This script is for secure DDNS updates on Samba,
# it can also add the 'macAddress' to the Computers object.
#
# Version: 0.9.6
#

##########################################################################
#                                                                        #
#    You can optionally add the 'macAddress' to the Computers object.    #
#    Add 'dhcpduser' to the 'Domain Admins' group if used                #
#    Change the next line to 'yes' to make this happen                   #
Add_macAddress='no'
#                                                                        #
##########################################################################

keytab=/etc/dhcp/dhcpduser.keytab

usage()
{
  cat >>-EOF
  USAGE:
    $(basename "$0") add ip-address dhcid|mac-address hostname
    $(basename "$0") delete ip-address dhcid|mac-address
  EOF
}

_KERBEROS()
{
  # get current time as a number
  test=$(date +%d'-'%m'-'%y' '%H':'%M':'%S)
  # Note: there have been problems with this
  # check that 'date' returns something like

  # Check for valid kerberos ticket
  #logger "${test} [dyndns] : Running check for valid kerberos ticket"
  klist -c "${KRB5CCNAME}" -s
  ret="$?"
  if [ $ret -ne 0 ]
  then
    logger "${test} [dyndns] : Getting new ticket, old one has expired"
    kinit -F -k -t $keytab "${SETPRINCIPAL}"
    ret="$?"
    if [ $ret -ne 0 ]
    then
      logger "${test} [dyndns] : dhcpd kinit for dynamic DNS failed"
      exit 1
    fi
  fi
}

rev_zone_info()
{
  local RevZone="$1"
  local IP="$2"
  local rzoneip
  rzoneip="${RevZone%.in-addr.arpa}"
  local rzonenum
  rzonenum=$(echo "$rzoneip" |  tr '.' '\n')
  declare -a words
  for n in $rzonenum
  do
    words+=("$n")
  done
  local numwords="${#words[@]}"

  unset ZoneIP
  unset RZIP
  unset IP2add

  case "$numwords" in
    1)
      # single ip rev zone '192'
      ZoneIP=$(echo "${IP}" | awk -F '.' '{print $1}')
      RZIP="${rzoneip}"
      IP2add=$(echo "${IP}" | awk -F '.' '{print $4"."$3"."$2}')
      ;;
    2)
      # double ip rev zone '168.192'
      ZoneIP=$(echo "${IP}" | awk -F '.' '{print $1"."$2}')
      RZIP=$(echo "${rzoneip}" | awk -F '.' '{print $2"."$1}')
      IP2add=$(echo "${IP}" | awk -F '.' '{print $4"."$3}')
      ;;
    3)
      # triple ip rev zone '0.168.192'
      ZoneIP=$(echo "${IP}" | awk -F '.' '{print $1"."$2"."$3}')
      RZIP=$(echo "${rzoneip}" | awk -F '.' '{print $3"."$2"."$1}')
      IP2add=$(echo "${IP}" | awk -F '.' '{print $4}')
      ;;
    *)
      # should never happen
      exit 1
      ;;
  esac
}

BINDIR=$(samba -b | grep 'BINDIR' | grep -v 'SBINDIR' | awk '{print $NF}')
[[ -z $BINDIR ]] && printf "Cannot find the 'samba' binary, is it installed ?\\nOr is your path set correctly ?\\n"
WBINFO="$BINDIR/wbinfo"

SAMBATOOL=$(command -v samba-tool)
[[ -z $SAMBATOOL ]] && printf "Cannot find the 'samba-tool' binary, is it installed ?\\nOr is your path set correctly ?\\n"

MINVER=$($SAMBATOOL -V | grep -o '[0-9]*' | tr '\n' ' ' | awk '{print $2}')
if [ "$MINVER" -gt '14' ]
then
  KTYPE="--use-kerberos=required"
else
  KTYPE="-k yes"
fi

# DHCP Server hostname
Server=$(hostname -s)

# DNS domain
domain=$(hostname -d)
if [ -z "${domain}" ]
then
  logger "Cannot obtain domain name, is DNS set up correctly?"
  logger "Cannot continue... Exiting."
  exit 1
fi

# Samba realm
REALM="${domain^^}"

# krbcc ticket cache
export KRB5CCNAME="/tmp/dhcp-dyndns.cc"

# Kerberos principal
SETPRINCIPAL="dhcpduser@${REALM}"
# Kerberos keytab as above
# krbcc ticket cache : /tmp/dhcp-dyndns.cc
TESTUSER="$($WBINFO -u | grep 'dhcpduser')"
if [ -z "${TESTUSER}" ]
then
  logger "No AD dhcp user exists, need to create it first.. exiting."
  logger "you can do this by typing the following commands"
  logger "kinit Administrator@${REALM}"
  logger "$SAMBATOOL user create dhcpduser --random-password --description='Unprivileged user for DNS updates via DHCP server'"
  logger "$SAMBATOOL user setexpiry dhcpduser --noexpiry"
  logger "$SAMBATOOL group addmembers DnsAdmins dhcpduser"
  exit 1
fi

# Check for Kerberos keytab
if [ ! -f "$keytab" ]
then
  logger "Required keytab $keytab not found, it needs to be created."
  logger "Use the following commands as root"
  logger "$SAMBATOOL domain exportkeytab --principal=${SETPRINCIPAL} $keytab"
  logger "chown XXXX:XXXX $keytab"
  logger "Replace 'XXXX:XXXX' with the user & group that dhcpd runs as on your distro"
  logger "chmod 400 $keytab"
  exit 1
fi

# Variables supplied by dhcpd.conf
action="$1"
ip="$2"
DHCID="$3"
name="${4%%.*}"

# Exit if no ip address
if [ -z "${ip}" ]
then
  usage
  exit 1
fi

# Exit if no computer name supplied, unless the action is 'delete'
if [ -z "${name}" ]
then
  if [ "${action}" = "delete" ]
  then
    name=$(host -t PTR "${ip}" | awk '{print $NF}' | awk -F '.' '{print $1}')
  else
    usage
    exit 1
  fi
fi

# exit if name contains a space
case ${name} in
  *\ * )
    logger "Invalid hostname '${name}' ...Exiting"
    exit
    ;;
esac

# if you want computers with a hostname that starts with 'dhcp' in AD
# comment the following block of code.
if [[ $name == dhcp* ]]
then
  logger "not updating DNS record in AD, invalid name"
  exit 0
fi

## update ##
case "${action}" in
  add)
    _KERBEROS
    count=0
    # does host have an existing 'A' record ?
    mapfile -t A_REC < <($SAMBATOOL dns query "${Server}" "${domain}" "${name}" A "$KTYPE" 2>/dev/null | grep 'A:' | awk '{print $2}')
    if [ "${#A_REC[@]}" -eq 0 ]
    then
      # no A record to delete
      result1=0
      $SAMBATOOL dns add "${Server}" "${domain}" "${name}" A "${ip}" "$KTYPE"
      result2="$?"
    elif [ "${#A_REC[@]}" -gt 1 ]
    then
      for i in "${A_REC[@]}"
      do
        $SAMBATOOL dns delete "${Server}" "${domain}" "${name}" A "${i}" "$KTYPE"
      done
      # all A records deleted
      result1=0
      $SAMBATOOL dns add "${Server}" "${domain}" "${name}" A "${ip}" "$KTYPE"
      result2="$?"
    elif [ "${#A_REC[@]}" -eq 1 ]
    then
      # turn array into a variable
      VAR_A_REC="${A_REC[*]}"
      if [ "$VAR_A_REC" = "${ip}" ]
      then
        # Correct A record exists, do nothing
        logger "Correct 'A' record exists, not updating."
        result1=0
        result2=0
        count=$((count+1))
      elif [ "$VAR_A_REC" != "${ip}" ]
      then
        # Wrong A record exists
        logger "'A' record changed, updating record."
        $SAMBATOOL dns delete "${Server}" "${domain}" "${name}" A "${VAR_A_REC}" "$KTYPE"
        result1="$?"
        $SAMBATOOL dns add "${Server}" "${domain}" "${name}" A "${ip}" "$KTYPE"
        result2="$?"
      fi
    fi

    # get existing reverse zones (if any)
    ReverseZones=$($SAMBATOOL dns zonelist "${Server}" "$KTYPE" --reverse | grep 'pszZoneName' | awk '{print $NF}')
    if [ -z "$ReverseZones" ]; then
      logger "No reverse zone found, not updating"
      result3='0'
      result4='0'
      count=$((count+1))
    else
      for revzone in $ReverseZones
      do
        rev_zone_info "$revzone" "${ip}"
        if [[ ${ip} = $ZoneIP* ]] && [ "$ZoneIP" = "$RZIP" ]
        then
          # does host have an existing 'PTR' record ?
          PTR_REC=$($SAMBATOOL dns query "${Server}" "${revzone}" "${IP2add}" PTR "$KTYPE" 2>/dev/null | grep 'PTR:' | awk '{print $2}' | awk -F '.' '{print $1}')
          if [[ -z $PTR_REC ]]
          then
            # no PTR record to delete
            result3=0
            $SAMBATOOL dns add "${Server}" "${revzone}" "${IP2add}" PTR "${name}"."${domain}" "$KTYPE"
            result4="$?"
            break
          elif [ "$PTR_REC" = "${name}" ]
          then
            # Correct PTR record exists, do nothing
            logger "Correct 'PTR' record exists, not updating."
            result3=0
            result4=0
            count=$((count+1))
            break
          elif [ "$PTR_REC" != "${name}" ]
          then
            # Wrong PTR record exists
            # points to wrong host
            logger "'PTR' record changed, updating record."
            $SAMBATOOL dns delete "${Server}" "${revzone}" "${IP2add}" PTR "${PTR_REC}"."${domain}" "$KTYPE"
            result3="$?"
            $SAMBATOOL dns add "${Server}" "${revzone}" "${IP2add}" PTR "${name}"."${domain}" "$KTYPE"
            result4="$?"
            break
          fi
        else
          continue
        fi
      done
    fi
    ;;
  delete)
    _KERBEROS

    count=0
    $SAMBATOOL dns delete "${Server}" "${domain}" "${name}" A "${ip}" "$KTYPE"
    result1="$?"
    # get existing reverse zones (if any)
    ReverseZones=$($SAMBATOOL dns zonelist "${Server}" --reverse "$KTYPE" | grep 'pszZoneName' | awk '{print $NF}')
    if [ -z "$ReverseZones" ]
    then
      logger "No reverse zone found, not updating"
      result2='0'
      count=$((count+1))
    else
      for revzone in $ReverseZones
      do
        rev_zone_info "$revzone" "${ip}"
        if [[ ${ip} = $ZoneIP* ]] && [ "$ZoneIP" = "$RZIP" ]
        then
          host -t PTR "${ip}" > /dev/null 2>&1
          ret="$?"
          if [ $ret -eq 0 ]
          then
            $SAMBATOOL dns delete "${Server}" "${revzone}" "${IP2add}" PTR "${name}"."${domain}" "$KTYPE"
            result2="$?"
          else
            result2='0'
            count=$((count+1))
          fi
          break
        else
          continue
        fi
      done
    fi
    result3='0'
    result4='0'
    ;;
	*)
    logger "Invalid action specified"
    exit 103
  ;;
esac

result="${result1}:${result2}:${result3}:${result4}"

if [ "$count" -eq 0 ]
then
  if [ "${result}" != "0:0:0:0" ]
  then
    logger "DHCP-DNS $action failed: ${result}"
    exit 1
  else
    logger "DHCP-DNS $action succeeded"
  fi
fi

if [ "$Add_macAddress" != 'no' ]
then
  if [ -n "$DHCID" ]
  then
    Computer_Object=$(ldbsearch "$KTYPE" -H ldap://"$Server" "(&(objectclass=computer)(objectclass=ieee802Device)(cn=$name))" | grep -v '#' | grep -v 'ref:')
    if [ -z "$Computer_Object" ]
    then
      # Computer object not found with the 'ieee802Device' objectclass, does the computer actually exist, it should.
      Computer_Object=$(ldbsearch "$KTYPE" -H ldap://"$Server" "(&(objectclass=computer)(cn=$name))" | grep -v '#' | grep -v 'ref:')
      if [ -z "$Computer_Object" ]
      then
        logger "Computer '$name' not found. Exiting."
        exit 68
      else
        DN=$(echo "$Computer_Object" | grep 'dn:')
        objldif="$DN
changetype: modify
add: objectclass
objectclass: ieee802Device"

        attrldif="$DN
changetype: modify
add: macAddress
macAddress: $DHCID"

        # add the ldif
        echo "$objldif" | ldbmodify "$KTYPE" -H ldap://"$Server"
        ret="$?"
        if [ $ret -ne 0 ]
        then
          logger "Error modifying Computer objectclass $name in AD."
          exit "${ret}"
        fi
        sleep 2
        echo "$attrldif" | ldbmodify "$KTYPE" -H ldap://"$Server"
        ret="$?"
        if [ "$ret" -ne 0 ]; then
          logger "Error modifying Computer attribute $name in AD."
          exit "${ret}"
        fi
        unset objldif
        unset attrldif
        logger "Successfully modified Computer $name in AD"
      fi
  else
    DN=$(echo "$Computer_Object" | grep 'dn:')
    attrldif="$DN
changetype: modify
replace: macAddress
macAddress: $DHCID"

    echo "$attrldif" | ldbmodify "$KTYPE" -H ldap://"$Server"
    ret="$?"
    if [ "$ret" -ne 0 ]
    then
      logger "Error modifying Computer attribute $name in AD."
      exit "${ret}"
    fi
      unset attrldif
      logger "Successfully modified Computer $name in AD"
    fi
  fi
fi

exit 0

Примечание

Если нужно сохранять MAC-адреса узлов в AD, следует заменить строку:

Add_macAddress='no'

на:

Add_macAddress='yes'

Следует обратить внимание, что необходимо предоставить права администратора домена пользователю обновления DNS.

Установить права для скрипта:

# chmod 755 /usr/local/bin/dhcp-dyndns.sh

Создать резервную копию исходного файла конфигурации:

# cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.orig

Внести изменения в файл конфигурации /etc/dhcp/dhcpd.conf:

authoritative;
ddns-update-style none;

subnet 192.168.0.0 netmask 255.255.255.0 {
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.0.255;
        option time-offset 0;
        option routers 192.168.0.1;
        option domain-name-servers 192.168.0.122, 192.168.0.123;
        option ntp-servers 192.168.0.122, 192.168.0.123;
        option domain-name "test.alt";
        default-lease-time 3600;
        pool {
             max-lease-time 1800; #30 минут
             range 192.168.0.150 192.168.0.200;
             }
}

on commit {
set noname = concat("dhcp-", binary-to-ascii(10, 8, "-", leased-address));
set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
set ClientDHCID = concat (
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,1,1))),2), ":",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,2,1))),2), ":",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,3,1))),2), ":",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,4,1))),2), ":",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,5,1))),2), ":",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,6,1))),2)
);
set ClientName = pick-first-value(option host-name, config-option host-name, client-name, noname);
log(concat("Commit: IP: ", ClientIP, " DHCID: ", ClientDHCID, " Name: ", ClientName));
execute("/usr/local/bin/dhcp-dyndns.sh", "add", ClientIP, ClientDHCID, ClientName);
}

on release {
set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
set ClientDHCID = concat (
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,1,1))),2), ":",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,2,1))),2), ":",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,3,1))),2), ":",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,4,1))),2), ":",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,5,1))),2), ":",
suffix (concat ("0", binary-to-ascii (16, 8, "", substring(hardware,6,1))),2)
);
log(concat("Release: IP: ", ClientIP));
execute("/usr/local/bin/dhcp-dyndns.sh", "delete", ClientIP, ClientDHCID);
}

on expiry {
set ClientIP = binary-to-ascii(10, 8, ".", leased-address);
# cannot get a ClientMac here, apparently this only works when actually receiving a packet
log(concat("Expired: IP: ", ClientIP));
# cannot get a ClientName here, for some reason that always fails
# however the dhcp update script will obtain the short hostname.
execute("/usr/local/bin/dhcp-dyndns.sh", "delete", ClientIP, "", "0");
}

Отключить chroot для DHCP-сервера:

# control dhcpd-chroot disabled

Перезапустить DHCP-сервер:

# systemctl restart dhcpd

Теперь если на клиенте изменить сетевую конфигурацию со статического IP-адреса, на получение IP-адреса от DHCP-сервера, в журнале на сервере можно будет увидеть следующее:

dhcpd[7817]: DHCPDISCOVER from 08:00:27:99:a6:1f via enp0s3
dhcpd[7817]: DHCPOFFER on 192.168.0.150 to 08:00:27:99:a6:1f (host-199) via enp0s3
dhcpd[7817]: Commit: IP: 192.168.0.150 DHCID: 08:00:27:99:a6:1f Name: host-199
dhcpd[7817]: execute_statement argv[0] = /usr/local/bin/dhcp-dyndns.sh
dhcpd[7817]: execute_statement argv[1] = add
dhcpd[7817]: execute_statement argv[2] = 192.168.0.150
dhcpd[7817]: execute_statement argv[3] = 08:00:27:99:a6:1f
dhcpd[7817]: execute_statement argv[4] = host-199
dhcpd[8228]: 17-07-24 08:55:31 [dyndns] : Getting new ticket, old one has expired
dhcpd[8236]: 'A' record changed, updating record.
dhcpd[8237]: Record deleted successfully
dhcpd[8240]: Record added successfully
dhcpd[8268]: Record added successfully
dhcpd[8271]: DHCP-DNS add succeeded
dhcpd[7817]: DHCPREQUEST for 192.168.0.125 (192.168.0.122) from 08:00:27:99:a6:1f (host-199) via enp0s3
dhcpd[7817]: DHCPACK on 192.168.0.150 to 08:00:27:99:a6:1f (host-199) via enp0s3

Клиента можно найти как в прямой, так и в обратной зонах:

# host host-199
host-199.test.alt has address 192.168.0.150
host-199.test.alt has IPv6 address fd47:d11e:43c1:0:a00:27ff:fe99:a61f
# host 192.168.0.150
150.0.168.192.in-addr.arpa domain name pointer host-199.test.alt.

⁠6.9.2. Настройка переключения DHCP

Для обеспечения отказоустойчивости, следует на втором контроллере домена также поднять DHCP-сервер.

Связь между двумя DHCP-серверами осуществляется через интерфейс прикладного программирования управления объектами (OMAPI). Этот API контролирует работу протокола переключения DHCP. Этот API будет настроен на следующих шагах.

На ведущем (master) DHCP-сервере необходимо сгенерировать случайный ключ OMAPI:

# tsig-keygen -a hmac-md5 omapi_key
key "omapi_key" {
    algorithm hmac-md5;
    secret "KKkAspinSr/nXYXhAv7CTQ==";
};

Как на ведущем, так и на ведомом устройстве должен быть настроен специальный раздел, путём добавления следующих строк в файл /etc/dhcp/dhcpd.conf:

omapi-port 7911;
omapi-key omapi_key;
key "omapi_key" {
    algorithm hmac-md5;
    secret "Секретный_ключ";
};

«Секретный_ключ» следует заменить на ключ, полученный на предыдущем шаге.

Для настройки аварийного переключения на первом сервере в файл /etc/dhcp/dhcpd.conf перед разделом subnet следует добавить строки:

omapi-port 7911;
omapi-key omapi_key;
key "omapi_key" {
    algorithm hmac-md5;
    secret "KKkAspinSr/nXYXhAv7CTQ==";
};

failover peer "dhcp-failover" {
  primary;
  address dc1.test.alt; # Полное DNS-имя основного DHCP-сервера
  port 847;
  peer address dc2.test.alt; # Полное DNS-имя имя резервного DHCP-сервера
  peer port 647;
  max-response-delay 60;
  max-unacked-updates 10;
  mclt 3600;
  split 128;
  load balance max seconds 3;
}

И добавить ссылку на подсеть/пул, которые будут выполнять аварийное переключение в раздел pool:

pool {
    failover peer "dhcp-failover"; # Add for failover
    max-lease-time 1800; #30 минут
    range 192.168.0.150 192.168.0.200;
    }

На втором DC выполнить следующие действия:

Скопировать скрипт и keytab-файл с первого DC на второй:
```
# scp dc1:/usr/local/bin/dhcp-dyndns.sh /usr/local/bin/
# scp dc1:/etc/dhcp/dhcpduser.keytab /etc/dhcp/
# chown dhcpd:dhcp /etc/dhcp/dhcpduser.keytab
```
Примечание
Для возможности копирования файлов должно быть настроено беспарольное взаимодействие между rootами контроллеров домена (см. Настройка беспарольного доступа по ssh).
Создать резервную копию исходного файла конфигурации DHCP-сервера и скопировать файл конфигурации с первого сервера:
```
# cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.orig
# scp dc1:/etc/dhcp/dhcpd.conf /etc/dhcp/
```

В файле /etc/dhcp/dhcpd.conf внести изменения в раздел «failover peer "dhcp-failover"»:

failover peer "dhcp-failover" {
  secondary;
  address dc2.test.alt; # Полное DNS-имя имя резервного DHCP-сервера
  port 647;
  peer address dc1.test.alt; # Полное DNS-имя основного DHCP-сервера
  peer port 847;
  max-response-delay 60;
  max-unacked-updates 10;
  load balance max seconds 3;
}

Отключить chroot для DHCP-сервера:
```
# control dhcpd-chroot disabled
```

Примечание

Параметр split должен быть установлен только на ведущем DHCP-сервере. Этот параметр управляет балансировкой нагрузки двух серверов. Параметр может принимать значения от 0 до 255. Если установлено значение «255», основной сервер, если он не отключен (по какой-либо причине), будет отвечать на все запросы DHCP. Если установить значение «128», то оба DHCP-сервера будут использоваться одинаково. Подробности смотрите на man-странице dhcpd.conf.

Далее следует перезапустить оба DHCP-сервера:

# systemctl restart dhcpd

В системном журнале на обоих серверах должны появиться записи вида:

dhcpd[7879]: failover peer dhcp-failover: peer moves from recover-done to normal
dhcpd[7879]: failover peer dhcp-failover: Both servers normal

Если OMAPI работает правильно, можно проверить переход на другой ресурс, остановив основной сервер.

⁠6.10. Аутентификация других сервисов в Samba AD

В данном разделе показано, как обеспечить прозрачную авторизацию пользователей домена на веб-сайте. В качестве веб-сервера используется отдельный сервер (web.test.alt, IP-адрес 192.168.0.150), введенный в домен.

Примечание

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

Для работы требуется наличие прямой и обратной записей DNS для веб-сервера.

Если в качестве веб-сервера используется не DC, следует добавить А-запись для веб-сервера:

$  samba-tool dns add dc1.test.alt test.alt web A 192.168.0.150 -Uadministrator
Password for [TEST\administrator]:
Record added successfully

где dc1.test.alt — имя контроллера домена.

Добавить зону обратного просмотра для подсети 192.168.0.0/24, в которой располагается веб-сервер:

$ samba-tool dns zonecreate dc1.test.alt 0.168.192.in-addr.arpa -Uadministrator
Password for [TEST\administrator]:
Zone 0.168.192.in-addr.arpa created successfully

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

Обратная зона работает напрямую без перезапуска Samba или BIND.

Добавить зону обратного просмотра для веб-сервера:

$ samba-tool dns add dc1.test.alt 0.168.192.in-addr.arpa 150 PTR web.test.alt

⁠6.10.1. Настройка аутентификации Kerberos для веб-сервера Apache

В этом разделе показано, как обеспечить прозрачную авторизацию пользователей домена на веб-сайте, размещенном на веб-сервере Apache2.

⁠6.10.1.1. Создание keytab-файла

Нужно настроить SPN (имена участников-служб) для имени сервера, на которое разрешается любой веб-сайт (подробнее см. Создание keytab-файла). Если виртуальный хостинг не используется, веб-адрес и имя машины будут одинаковыми. Для создания SPN на контроллере домена выполнить команды:

# samba-tool user add --random-password webauth
# samba-tool user setexpiry webauth --noexpiry
# samba-tool spn add HTTP/web.test.alt webauth

Создать Kerberos keytab-файл для Apache2:

# samba-tool domain exportkeytab /tmp/httpd.keytab --principal=HTTP/web.test.alt@TEST.ALT
Export one principal to /tmp/httpd.keytab

Перенести полученный файл keytab на веб-сервер в каталог /etc/httpd2/conf/, установить права на него, так чтобы Apache мог читать, но не изменять keytab-файл:

# chown apache2:apache2 /etc/httpd2/conf/httpd.keytab
# chmod 0440 /etc/httpd2/conf/httpd.keytab

⁠6.10.1.2. Настройка Apache2

На веб-сервере установить пакет apache2-mod_auth_gssapi и включить необходимые модули:

# apt-get install apache2-mod_auth_gssapi
# a2enmod auth_gssapi
# a2enmod authn_core
# a2enmod authz_user
# service httpd2 condreload

Добавить в конфигурацию Apache строки:

<Location "/login.html">
        AuthType GSSAPI
        AuthName "GSSAPI Login"
        #GssapiBasicAuth On
        GssapiCredStore keytab:/etc/httpd2/conf/httpd.keytab
        GssapiAllowedMech krb5
        Require valid-user
</Location>

Перезапустить Apache:

# systemctl restart httpd2

⁠6.10.1.3. Проверка аутентификации

Тестовый сайт должен быть доступен по адресу http://<полное_доменное_имя_веб-сервера>.

На рабочей станции, введённой в домен, получить билет Kerberos:

$ kinit ivanov
Password for ivanov@TEST.ALT:
$ klist
Ticket cache: KEYRING:persistent:500:krb_ccache_5VitJSL
Default principal: ivanov@TEST.ALT

Valid starting       Expires              Service principal
28.04.2023 15:54:41  29.04.2023 01:54:41  krbtgt/TEST.ALT@TEST.ALT
    renew until 05.05.2023 15:54:38

Попытаться прочитать содержимое сайта, используя аутентификацию Kerberos:

$ curl --negotiate -u : http://web.test.alt/login.html
<html><body><h1>It works!</h1></body></html>

Получено содержимое страницы.

Удалить билеты Kerberos:

$ kdestroy
$ klist

Попытаться прочитать содержимое сайта, используя аутентификацию Kerberos:

$ curl --negotiate -u : http://web.test.alt/login.html
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Authentication required!</title>
</head>

<body>
<h1>Authentication required!</h1>
…
<h2>Error 401</h2>
<address>
  <a href="/">web.test.alt</a><br />
  <span>Apache/2.4.57 (Unix) mod_auth_gssapi/1.6.3 OpenSSL/1.1.1u</span>
</address>
</body>
</html>

Содержимое страницы не доступно.

⁠6.10.2. Настройка аутентификации Kerberos для веб-сервера Nginx

В этом разделе показано, как обеспечить прозрачную авторизацию пользователей домена на веб-сайте, размещенном на веб-сервере Nginx.

⁠6.10.2.1. Создание keytab-файла

Подробнее см. Создание keytab-файла.

Нужно настроить SPN (имена участников-служб) для имени сервера, на которое разрешается любой веб-сайт (таким образом, фактическое имя сервера, на которое указывает CNAME, является полным). Если виртуальный хостинг не используется, веб-адрес и имя машины будут одинаковыми. Для этого на контроллере домена:

# samba-tool user add --random-password nginxauth
# samba-tool user setexpiry nginxauth --noexpiry
# samba-tool spn add HTTP/web.test.alt nginxauth

Создать Kerberos keytab-файл для Nginx:

# samba-tool domain exportkeytab /tmp/nginx.keytab --principal=HTTP/web.test.alt@TEST.ALT
Export one principal to /tmp/nginx.keytab

⁠6.10.2.2. Настройка Nginx

Для работы прозрачной доменной аутентификации (SSO) в Nginx необходимо установить пакеты nginx и nginx-spnego:

# apt-get install nginx nginx-spnego

Модуль SPNEGO для Nginx — это программный компонент для возможности прохождения аутентификации (Single Sign-On или SSO) через сервер LDAP.

Включить модуль http_auth_spnego:

# ln -s /etc/nginx/modules-available.d/http_auth_spnego.conf /etc/nginx/modules-enabled.d/

Перенести полученный на контроллере домене файл keytab на веб-сервер в каталог /etc/nginx. Установить права на файл keytab:

# chmod 644 /etc/nginx/nginx.keytab

Nginx должен иметь права на чтение keytab-файла, но не на его изменение.

Настроить аутентификацию в секции server файла конфигурации сайта:

server {
    …
    location /
    {
        root /var/www/html;
        auth_gss on;
        auth_gss_realm TEST.ALT; #имя Kerberos области
        auth_gss_keytab /etc/nginx/nginx.keytab; #путь к keytab-файлу
        auth_gss_service_name HTTP/web.test.alt; #имя используемого SPN
        auth_gss_allow_basic_fallback off;
    }
}

Описание опций:

auth_gss — включение/отключение аутентификации;
auth_gss_keytab — абсолютный путь к файлу keytab, содержащему учётные данные службы;
auth_gss_realm — имя области Kerberos;
auth_gss_service_name — имя субъекта-службы, используемое при получении учетных данных;
auth_gss_allow_basic_fallback — включить/отключить базовую аутентификацию. При включённой базовой аутентификации (по умолчанию), если SSO не проходит (машина не в домене) разрешает обычный ввод логина и пароля. Если используется SPNEGO без SSL, рекомендуется отключить базовую аутентификацию, так как в этом случае пароль будет отправлен в виде открытого текста.

Перезапустить nginx:

# systemctl restart nginx

Если нужно авторизовать только определенный набор пользователей, можно использовать параметр auth_gss_authorized_principal. Можно указывать несколько записей, по одной на строку:

auth_gss_authorized_principal <username>@<realm>
auth_gss_authorized_principal <username2>@<realm>

Список пользователей также можно указать с помощью шаблона регулярного выражения в параметре auth_gss_authorized_principal_regex. Этот параметр можно использовать вместе с параметром auth_gss_authorized_principal:

auth_gss_authorized_principal <username>@<realm>
auth_gss_authorized_principal_regex ^(<username>)/(<group>)@<realm>$

⁠6.10.2.3. Проверка аутентификации

Тестовый сайт должен быть доступен по адресу http://<полное_доменное_имя_веб-сервера>.

На рабочей станции, введённой в домен, получить билет Kerberos:

$ kinit ivanov
Password for ivanov@TEST.ALT:
$ klist
Ticket cache: KEYRING:persistent:500:krb_ccache_5VitJSL
Default principal: ivanov@TEST.ALT

Valid starting       Expires              Service principal
28.04.2023 15:54:41  29.04.2023 01:54:41  krbtgt/TEST.ALT@TEST.ALT
    renew until 05.05.2023 15:54:38

Попытаться прочитать содержимое сайта, используя аутентификацию Kerberos:

$ curl --negotiate -u : http://web.test.alt
<html><body><h1>It works!</h1></body></html>

Получено содержимое страницы.

Удалить билеты Kerberos:

$ kdestroy
$ klist

Попытаться прочитать содержимое сайта, используя аутентификацию Kerberos:

$ curl --negotiate -u : http://web.test.alt
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.22.1</center>
</body>
</html>

Содержимое страницы не доступно.

⁠6.10.3. Настройка браузеров для SSO

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

Для работы SSO в браузерах необходимо произвести некоторые настройки.

⁠6.10.3.1. Настройка Mozilla Firefox

Порядок действий:

В адресной строке ввести about:config, чтобы отобразить список текущих параметров конфигурации (необходимо будет нажать кнопку Принять риск и продолжить).
В поле Фильтр ввести negotiate, чтобы ограничить список параметров.
Выбрать параметр network.negotiate-auth.trusted-uris.
Указать в этом параметре имя Kerberos области (realm), включая предшествующую точку (.). Если нужно добавить несколько доменов, их необходимо указать через запятую.

В ряде случаев может потребоваться отредактировать еще несколько параметров:

параметр network.automatic-ntlm-auth.trusted-uris выставить в Kerberos realm: .test.alt;
параметр network.negotiate-auth.delegation-uris выставить в Kerberos realm: .test.alt;
параметр network.automatic-ntlm-auth.allow-non-fqdn выставить в: true;
параметр network.negotiate-auth.allow-non-fqdn выставить в: true;

Вместо выставления этих параметров можно создать файл /usr/lib64/firefox/browser/defaults/preferences/prefs.js со следующим содержимым:

pref("network.negotiate-auth.trusted-uris",".test.alt");
pref("network.automatic-ntlm-auth.trusted-uris",".test.alt");
pref("network.automatic-ntlm-auth.allow-non-fqdn","true");
pref("network.negotiate-auth.allow-non-fqdn","true");
pref("network.negotiate-auth.delegation-uris",".test.alt");

Эти параметры могут быть распространены через групповые политики для Firefox:

параметр network.negotiate-auth.trusted-uris — политика SPNEGO;
параметр network.automatic-ntlm-auth.trusted-uris — политика NTLM;
параметр network.negotiate-auth.delegation-uris — политика Делегированная авторизация;
параметр network.automatic-ntlm-auth.allow-non-fqdn — политика Разрешить неполное доменное имя (Non FQDN);
параметр network.negotiate-auth.allow-non-fqdn — политика Разрешить неполное доменное имя (Non FQDN);

Подробнее см. Групповые политики для Firefox

⁠6.10.3.2. Настройка Chromium

В файл /etc/chromium/policies/managed/policies.json добавить строки:

{
    "AuthServerAllowlist": "*.test.alt",
    "AuthNegotiateDelegateAllowlist": "*.test.alt"
}

где .test.alt — имя Kerberos области (realm).

Для применения настроек необходимо перезапустить браузер. Результат применения параметров политики для Chromium можно проверить, указав в адресной строке URL: chrome://policy.

Эти параметры могут быть распространены через групповые политики для Chromium: Список разрешенных серверов для аутентификации (Разрешить аутентификацию на серверах из списка) и Список разрешенных серверов для делегирования прав по протоколу Kerberos (Разрешить делегирование прав по протоколу Kerberos на серверах). Подробнее см. Групповые политики для Chromium

Примечание

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

$ chromium-browser --auth-server-whitelist="*.test.alt"

⁠6.10.3.3. Настройка «Яндекс.Браузера»

В файл /etc/opt/yandex/browser/policies/managed/policies.json добавить строки:

{
    "AuthServerAllowlist": "*.test.alt",
    "AuthNegotiateDelegateAllowlist": "*.test.alt"
}

Где .test.alt — имя Kerberos области (realm).

Для применения настроек необходимо перезапустить браузер. Результат применения параметров политики для «Яндекс.Браузера» можно проверить, указав в адресной строке URL: browser://policy.

Эти параметры могут быть распространены через групповые политики для «Яндекс.Браузера»: политики Разрешить аутентификацию на серверах из списка и Разрешить делегирование прав по протоколу Kerberos на серверах. Подробнее см. Групповые политики для «Яндекс.Браузера».

⁠6.11. Distributed File System

Распределенная файловая система (Distributed File System, DFS) — серверная технология Microsoft, предназначенная для упрощения доступа к общим файловым ресурсам, распределенным по сети. С помощью DFS можно объединять в единую логическую структуру файловые ресурсы, физически находящиеся на различных серверах, а также производить между ними репликацию. Функционал DFS образуют две составляющих: пространство DFS-имен — DFS-N (DFS-Namespace) и механизм репликации — DFS-R (DFS-Replication).

Samba поддерживает DFS-N, но пока не поддерживает DFS-R.

⁠6.11.1. Пространство DFS-имен

Пространство DFS-имен — это единый виртуальный каталог, содержащий ссылки на общие каталоги, расположенные на разных файловых серверах. Пространство имен состоит из корня (root), ссылок (folders) и целевых объектов (folder targets). Пространство имен DFS может быть двух типов: автономное (Stand-alone) и доменное (Domain-based).

Автономный вариант работает на одном сервере и приводит к тому, что имена DFS содержат имя этого сервера, они выглядят как общие ресурсы, предоставляемые этим сервером (можно создать распределенную файловую систему не используя доменные службы AD).

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

Корень пространства имен (Namespace root) — это базовая точка, от которой начинается отсчёт пространства имён. В зависимости от типа корень доступен по адресу \\ServerName\RootName (Stand-alone) или \\DomainName\RootName (Domain-based).

Сервер пространства имен (Namespace server) — физический сервер, на котором содержится пространство имён DFS.

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

Целевой объект (Folder targets) — ссылка на общий файловый ресурс, находящийся на определенном файловом сервере. Одна ссылка может указывать как на один, так и на несколько целевых объектов.

⁠6.11.2. Настройка DFS на сервере Samba

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

Сервер Samba можно сделать сервером DFS, задав логический параметр host msdfs в файле /etc/samba/smb.conf. Корень DFS назначается с помощью логического параметра root msdfs. Если для этого параметра установлено значение yes, Samba будет воспринимать открытый для общего доступа ресурс как корневой DFS. Ссылки DFS, указываемые в открытом для доступа каталоге, имеют вид: msdfs:serverA\shareA,serverB\shareB и т.д. Корневой каталог DFS в Samba содержит ссылки DFS в виде символических ссылок,

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

создать каталог, в котором будут настроены ссылки DFS на другие серверы в сети (в примере /media/dfsroot):
```
# mkdir /media/dfsroot
```
в файл /etc/samba/smb.conf в секцию [global] добавить параметр:
```
host msdfs = yes
```
и добавить секцию [dfs], с указанием корня:
```
[dfs]
        path = /media/dfsroot
        msdfs root = yes
```
в каталоге /media/dfsroot настроить ссылки DFS на общие ресурсы в сети:
```
# cd /media/dfsroot
# ln -s msdfs:dc1.test.alt\\free linka
# ln -s msdfs:web.test.alt\\tests linkb
```
Перезапустить samba:
```
# systemctl restart samba
```

дерево DFS теперь доступно по адресу //test.alt/dfs/. При доступе к ссылкам linka или linkb (которые отображаются для клиента как каталоги) пользователи напрямую переходят к соответствующим общим ресурсам в сети. Проверка:

$ smbclient //test.alt/dfs/linka -U 'ivanov'
Password for [TEST\ivanov]:
Try "help" to get a list of possible commands.
smb: \> ls
  .                                   D        0  Mon May 22 10:13:28 2023
  ..                                  D        0  Mon May 22 10:13:06 2023
  dc.txt                              N        5  Mon May 22 15:57:14 2023

        48254668 blocks of size 1024. 40859796 blocks available
smb: \> exit

Примечание

Для доступа к ресурсам DFS по имени домена с использованием аутентификации Kerberos необходимо добавить к имени сервера псевдоним — имя домена. Это можно сделать, выполнив на контроллере домена команду:

# samba-tool spn add cifs/cifs/<имя_домена> <имя_сервера>$

Например:

# samba-tool spn add cifs/test.alt dc1$

Подключиться к данному пространству можно, набрав в адресной строке следующий адрес: smb://<имя_домена>/<имя_пространства_имен>:

⁠6.12. Настройка SSSD

⁠6.12.1. Журналирование SSSD

⁠6.12.1.1. Файлы журналов SSSD

Каждая служба SSSD записывает логи в свой собственный файл журнала в каталоге /var/log/sssd/. Например, для машины в домене AD test.alt, файлы журналов SSSD могут выглядеть следующим образом:

# ls -l /var/log/sssd/
итого 1660
-rw------- 1 _sssd _sssd       0 мая 18 12:55 gpo_child.log
-rw------- 1 _sssd _sssd       0 мая 18 12:55 krb5_child.log
-rw------- 1 _sssd _sssd       0 мая 18 12:54 ldap_child.log
-rw------- 1 root  root      261 июн 19 10:10 sssd_ifp.log
-rw------- 1 root  root     3955 июн 19 09:34 sssd.log
-rw------- 1 _sssd _sssd 1677605 июн 19 11:18 sssd_nss.log
-rw------- 1 _sssd _sssd    1134 июн 19 09:34 sssd_pac.log
-rw------- 1 _sssd _sssd    3067 июн 19 09:34 sssd_pam.log
-rw------- 1 _sssd _sssd       0 мая 18 12:54 sssd_TEST.ALT.log

krb5_child.log: Файл журнала для недолговечного вспомогательного процесса, участвующего в аутентификации Kerberos.
ldap_child.log: Файл журнала для недолговечного вспомогательного процесса, участвующего в получении билета Kerberos для связи с сервером LDAP.
sssd_<domain.name>.log: Для каждого раздела [domain] в файле sssd.conf служба SSSD записывает информацию о взаимодействии с LDAP-сервером в отдельный файл журнала.
sssd.log: Файл журнала для мониторинга SSSD и связи его с ответчиком и внутренними процессами.
sssd_ifp.log: Файл журнала для ответчика InfoPipe, который предоставляет общедоступный интерфейс D-Bus, доступный через системную шину.
sssd_nss.log: Файл журнала для ответчика Name Services Switch (NSS), который извлекает информацию о пользователях и группах.
sssd_pac.log: Файл журнала для ответчика Microsoft Privilege Attribute Certificate (PAC), который собирает PAC из билетов AD Kerberos и извлекает информацию о пользователях AD из PAC, что позволяет избежать её запроса непосредственно из AD.
sssd_pam.log: Файл журнала для ответчика Pluggable Authentication Module (PAM).
sssd_ssh.log: Файл журнала для процесса ответчика SSH.

⁠6.12.1.2. Уровни журналирования SSSD

⁠

Таблица 6.13. Уровни журналирования SSSD

Уровень	Описание
0, 0x0010	Фатальные ошибки. Ошибки, которые не позволяют запустить службу SSSD или вызывает завершение работы сервиса
1, 0x0020	Критические ошибки. Ошибки, которые не завершают работу службы SSSD, но как минимум одна из основных функций не работает должным образом
2, 0x0040	Серьёзные ошибки. Ошибки, сообщающие о том, что определенный запрос или операция завершились неудачно. Это уровень журналирования по умолчанию
3, 0x0080	Незначительные ошибки. Ошибки, которые могут стать причиной ошибок второго уровня (ошибок при выполнении действий)
4, 0x0100	Настройки конфигурации
5, 0x0200	Данные функций
6, 0x0400	Сообщения трассировки для функций действий
7, 0x1000	Сообщения трассировки для функций внутреннего управления
8, 0x2000	Содержимое переменных внутренних функций
9, 0x4000	Информация трассировки крайне низкого уровня
9, 0x20000	Быстродействие и статистические данные. Из-за способа обработки запросов на внутреннем уровне, записанное в журнал время выполнения запроса может быть больше, чем оно было на самом деле
10, 0x10000	Информация трассировки libldb ещё более низкого уровня. Практически никогда не требуется

Установка уровня журнала также включает все уровни ниже него. Например, установка уровня журнала на 6 также включает уровни с 0 по 5.

Чтобы вести журнал для необходимых уровней журналирования, указанных в представлении битовых масок, следует просто сложить их номера. Например, чтобы вести журнал для фатальных, критических, серьёзных ошибок и для данных функций, следует использовать значение 0x0270.

⁠6.12.1.3. Настройка уровня журналирования для SSSD в файле `sssd.conf`

Чтобы включить подробное журналирование, сохраняющееся при перезапуске службы SSSD, следует добавить опцию debug_level=<целое_число> в каждую секцию файла /etc/sssd/sssd.conf. Где значение <целое_число> — число от 0 до 10. Уровни до 3 регистрируют крупные сбои, а уровни начиная с 8 и выше предоставляют большое количество подробных сообщений журнала. Уровень 6 является хорошей отправной точкой для отладки проблем

Пример настройки уровня журналирования в файле /etc/sssd/sssd.conf:

[sssd]
debug_level = 6
config_file_version = 2
services = nss, pam

[domain/TEST.ALT]
debug_level = 6
id_provider = ad
…

[nss]
debug_level = 6

[pam]
debug_level = 6

Чтобы загрузить новые параметры конфигурации необходимо перезапустить службу SSSD:

# systemctl restart sssd

⁠6.12.1.4. Настройка уровня журналирования для SSSD с помощью команды sssctl

Изменить уровень журналирования службы SSSD можно с помощью команды sssctl debug-level <целое_число>. Где значение <целое_число> — число от 0 до 10. Уровни до 3 регистрируют крупные сбои, а уровни начиная с 8 и выше предоставляют большое количество подробных сообщений журнала. Уровень 6 является хорошей отправной точкой для отладки проблем.

Просмотр текущего уровня журналирования:

# sssctl debug-level
sssd                      0x0070
nss                       0x0070
pam                       0x0070
pac                       0x0070
domain/TEST.ALT           0x0070

Установка нового уровня журналирования:

# sssctl debug-level 6
# sssctl debug-level
sssd                      0x07f0
nss                       0x07f0
pam                       0x07f0
pac                       0x07f0
domain/TEST.ALT           0x07f0

Примечание

Уровень журналирования, заданный с помощью команды sssctl debug-level будет действовать до перезапуска службы sssd.

⁠6.12.2. Настройки SSSD в ЦУС

Некоторые параметры SSSD можно установить в модуле ЦУС Аутентификация. В окне модуля Аутентификация следует нажать кнопку Настройка SSSD… откроется окно настроек SSSD:

⁠

Таблица 6.14. Настройки SSSD в Alterator

Настройка	Опция в файле `/etc/sssd/sssd.conf`	Описание
Правила применения групповых политик	`ad_gpo_access_control`	Определяет в каком режиме будет осуществляться контроль доступа в SSSD основанный на групповых политиках Active Directory (GPO) Доступные режимы: `enforced` (принудительный режим) — правила управления доступом в SSSD, основанные на GPO, выполняются, ведётся логирование `permissived` (разрешающий режим) — правила управления доступом в SSSD, основанные на GPO, не выполняются, ведётся только логирование. Такой режим необходим администратору, чтобы оценить, как срабатывают новые правила `disabled` (отключить) — правила управления доступом в SSSD, основанные на GPO, не логируются и не выполняются `default` (по умолчанию) — настройка контроля доступом в SSSD, основанная на GPO, сброшена на значение по умолчанию в пакете
Игнорировать, если групповые политики не читаются	`ad_gpo_ignore_unreadable`	Определяет будут ли проигнорированы правила управления доступом в SSSD основанные на групповых политиках, если недоступен какой-либо шаблон (GPT) объекта групповой политики (GPO) Доступные режимы: `enabled` (включить) — игнорировать правила управления доступом через групповые политики, если шаблоны групповых политик не доступны для SSSD `disabled` (отключить) — запретить доступ пользователям SSSD AD, которым назначены групповые политики, если шаблоны групповых политик не доступны `default` (по умолчанию) — настройка игнорирования политик, при недоступности шаблонов групповых политик сброшена на значение по умолчанию в пакете
Кешировать учётные данные	`cache-credentials`	Определяет, будут ли учётные данные удалённых пользователей сохраняться в локальном кеше SSSD Доступные режимы: `enabled` (включить) — сохранение в локальном кеше SSSD учётных данных пользователей включено `disabled` (отключить) — сохранение в локальном кеше SSSD учётных данных пользователей отключено `default` (по умолчанию) — настройка сохранения в локальном кеше SSSD учётных данных пользователей сброшена на значение по умолчанию в пакете
Привилегии запуска SSSD	`sssd-drop-privileges`	Позволяет сбросить права службы SSSD, чтобы избежать работы от имени суперпользователя (root) Доступные режимы: `privileged` (привилегированный) — служба SSSD запущена от имени привилегированного суперпользователя (root) `unprivileged` (непривилегированный) — служба SSSD запущена от имени непривилегированного пользователя (_sssd) `default` (по умолчанию) — режим привилегий службы SSSD задан по умолчанию в пакете
Интервал обновления записей DNS	`dyndns_refresh_interval`	Определяет как часто серверная часть должна выполнять периодическое обновление DNS в дополнение к автоматическому обновлению, выполняемому при подключении серверной части к сети. Этот параметр применим только в том случае, если для параметра `dyndns_update` установлено значение `true`. Доступные режимы: `enabled` (включить) — задать интервал `disabled` (отключить) — установить значение по умолчанию (86400) `unknown`
TTL для клиентской записи DNS	`dyndns_ttl`	Срок жизни, применяемый к DNS-записи клиента при ее обновлении. Если `dyndns_update` имеет значение `false`, этот параметр не имеет никакого эффекта Доступные режимы: `enabled` (включить) — задать TTL `disabled` (отключить) — установить значение по умолчанию (3600) `unknown`
Обновлять IP-адрес машины в DNS	`dyndns_update`	Позволяет включить или отключить автоматическое обновление DNS-записей (защищенных с помощью GSS-TSIG) с IP-адресом клиента через SSSD Доступные режимы: `enabled` (включить) — автоматическое обновление DNS-записи клиента через SSSD включено `disabled` (отключить) — автоматическое обновление DNS-записи клиента через SSSD отключено `default` (по умолчанию) — настройка автоматического обновления DNS-записи клиента через SSSD задана по умолчанию в пакете `unknown`
Обновлять PTR-запись машины в DNS-записей	`dyndns_update_ptr`	Определяет будет ли обновляться клиентская PTR-запись (защищенная с помощью GSS-TSIG) при обновлении DNS-записей клиента. Применимо, только если параметр `dyndns_update` имеет значение `true`. Доступные режимы: `enabled` (включить) — автоматическое обновление DNS-записи обратной зоны через SSSD включено `disabled` (отключить) — автоматическое обновление DNS-записи обратной зоны через SSSD отключено `default` (по умолчанию) — настройка автоматического обновления DNS-записи обратной зоны задана по умолчанию в пакете `unknown`

⁠6.12.3. Включение автономной аутентификации

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

Чтобы пользователи могли пройти аутентификацию, даже когда провайдер идентификации недоступен, можно включить кеширование учетных данных, установив параметр cache_credentials в значение true в разделе домена (в файле /etc/sssd/sssd.conf).

Дополнительно можно использовать параметр offline_credentials_expiration в разделе [pam], чтобы установить ограничение по времени (в днях), в течении которого пользователи смогут аутентифицироваться в автономном режиме с момента последнего успешного входа.

Пример настройки возможности автономной аутентификации пользователей в течение 5 дней с момента последнего успешного входа:

[pam]
offline_credentials_expiration = 5
[domain/TEST.ALT]
cache_credentials = true

Для включения/отключения кеширования учетных данных можно использовать control sssd-cache-credentials. Например:

просмотреть текущее значение:
```
# control sssd-cache-credentials
default
```
включить кеширование учетных данных:
```
# control sssd-cache-credentials enabled
default
```
отключить кеширование учетных данных:
```
# control sssd-cache-credentials disabled
default
```

Примечание

⁠6.13. Файловый сервер

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

⁠6.14. Монтирование общих ресурсов samba

Рассматриваемые ниже способы позволяют подключать файловые ресурсы (file shares) для доменного пользователя без повторного ввода пароля (SSO, Single Sign-On).

⁠6.14.1. Подключение с использованием gio

Примечание

Способ актуален для дистрибутивов, использующих gio (например, Simply Linux, Альт Рабочая станция).

Недостаток подключения общих ресурсов с использованием gio — необходимо открыть ресурс в файловом менеджере (Caja, Pcmanfm). Однако можно открывать любые ресурсы на любых серверах, входящие в домен Active Directory.

Процедура монтирования общих ресурсов с использованием gio:

установить необходимые пакеты:
```
# apt-get install fuse-gvfs gvfs-backend-smb libgio
```
включить пользователя в группу fuse:
```
# gpasswd -a <пользователь> fuse
```
разрешить для всех доступ к fuse:
```
# control fusermount public
```
войти под доменным пользователем;
открыть ресурс в файловом менеджере (например, по адресу smb://server/sysvol). Ресурс будет смонтирован по пути /var/run/<uid_пользователя>/gvfs или /var/run/user/<uid_пользователя>/gvfs/smb-share:server=сервер,share=ресурс;
другой вариант (полезно для скриптов в автозапуске):
```
gio mount smb://server/sysvol/
```

Примечание

Если необходимо открывать что-то с ресурса в WINE, в winecfg следует добавить диск с путём /var/run/uid_пользователя/gvfs.

⁠6.14.2. Подключение с использованием pam_mount

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

Процедура монтирования общих ресурсов с использованием pam_mount:

установить пакеты pam_mount и cifs-utils:
```
# apt-get install pam_mount cifs-utils
```
Важно
Для того чтобы файловые ресурсы, подключенные с помощью pam_mount, корректно отключались при завершении сеанса, следует установить пакет systemd-settings-enable-kill-user-processes и перезагрузить систему:
```
# apt-get install systemd-settings-enable-kill-user-processes
```
прописать pam_mount в схему аутентификации по умолчанию. Для этого в конец файла /etc/pam.d/system-auth добавить строки:
```
session         [success=1 default=ignore] pam_succeed_if.so  service = systemd-user quiet
session         optional        pam_mount.so disable_interactive
```
установить правило монтирования ресурса в файле /etc/security/pam_mount.conf.xml (перед тегом <cifsmount>):
```
<volume uid="10000-2000200000" fstype="cifs" server="dc1.test.alt" path="sysvol" mountpoint="~/share"
options="sec=krb5i,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775" />
```
где
- uid="10000-2000200000" — диапазон присваиваемых для доменных пользователей UID (подходит для Winbind и для SSSD);
- server="dc1.test.alt" — имя сервера с ресурсом;
- path="sysvol" — имя файлового ресурса;
- mountpoint="~/share" — путь монтирования в домашней папке пользователя.
Опционально можно добавить:
- sgrp="group_name" — имя группы, при членстве пользователя в которой, папка будет примонтирована.

Параметр sec=krb5i более безопасный, но требует больше вычислительных ресурсов. Вместо него можно указать sec=krb5.

Предупреждение

В параметре server необходимо указывать настоящее имя сервера, а не имя домена.

Предупреждение

По умолчанию для монтирования используется smb версии 1.0, если он отключен, то необходимо указать в параметрах версию 2 или 3:

<volume uid="10000-2000200000" fstype="cifs" server="dc1.test.alt" path="sysvol" mountpoint="~/share"
options="sec=krb5i,vers=2.0,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775" />

Для проверки можно попробовать смонтировать ресурс в сессии:

mount.cifs //dc1.test.alt/sysvol /mnt/  -o vers=2.0,user=ivanov

Доступность ресурса можно также проверить с помощью команды smbclient, например:

smbclient -L dc1.test.alt -U ivanov -m SMB2

⁠6.14.3. Подключение с использованием Autofs

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

Принцип работы:

задаётся каталог, в котором будет происходить подключение, например, /mnt/auto/;
при необходимости обратиться к сетевой файловой системе, следует обратиться к каталогу с именем этой ФС в этом каталоге, например, /mnt/auto/server/share/;
при обращении будет произведена попытка смонтировать соответствующий сетевой ресурс;
при отсутствии обращения, после заданного таймаута, сетевой ресурс будет отмонтирован.

AutoFS использует для конфигурирования шаблоны /etc/auto*. Основной шаблон называется auto.master, он может указывать на один или несколько других шаблонов для конкретных типов носителей. Пример содержимого файла /etc/auto.master:

# Format of this file:
# mountpoint map options
# For details of the format look at autofs(8).
/mnt/auto       /etc/auto.tab   -t 5
/mnt/net        /etc/auto.avahi -t 120

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

Примечание

Параметр -t (--timeout) устанавливает количество секунд, после истечения которых каталоги будут размонтированы. Значение 0 отключает таймаут. Значения параметра по умолчанию задаются в файле /etc/autofs.conf.

Базовый каталог будет создан, если он не существует. Он станет точкой монтирования, отображающей в себе динамически подключаемые носители, что означает, что существующее содержимое базового каталога будет недоступно пока autofs работает.

Пример настройки автоматического подключения сетевых файловых ресурсов Windows (Samba) при входе пользователя:

Добавить в /etc/auto.master строку:
```
/mnt/samba /etc/auto.smb -t 120
```
Здесь /mnt/samba — каталог, в котором будут подключаться сетевые файловые системы, /etc/auto.smb — стандартный скрипт, входящий в состав пакета autofs, 120 — таймаут подключения при отсутствии обращения.
Включить и запустить сервис autofs:
```
# systemctl enable --now autofs
```
Для автоматического подключения ресурсов достаточно обратиться к ресурсу по имени хоста, например:
```
$ ls /mnt/samba/<имя_хоста>
```
или в диспетчере файлов:

Пример настройки автоматического подключения сетевых файловых ресурсов Windows (Samba) при входе пользователя в систему для дистрибутивов с KDE (Альт Рабочая станция К, Альт Образование):

Установить пакет kde5-autofs-shares:
```
# apt-get install kde5-autofs-shares
```
Добавить в /etc/auto.master строку:
```
/mnt/samba /etc/auto.smb -t 120
```
Здесь /mnt/samba — каталог, в котором будут подключаться сетевые файловые системы, /etc/auto.smb — скрипт, входящий в состав пакета autofs, 120 — таймаут подключения при отсутствии обращения.
Включить и запустить сервис autofs:
```
# systemctl enable --now autofs
```
В диспетчере файлов Dolphin по адресу smb://test.alt (Сеть → Общие папки Samba) найти нужный ресурс Windows (Samba).
В контекстном меню подключаемого ресурса выбрать пункт Подключение:

Данный ресурс будет подключаться автоматически при входе в систему:
Примечание
Список ресурсов для подключения хранится в файле ~/.autofs.shares.

Важно

Данный способ работает только для ресурсов с гостевым доступом или ресурсов с авторизацией Kerberos.

⁠6.15. Журналирование в Samba

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

Файлы журналов службы Samba по умолчанию находятся в каталоге /var/log/samba/.

⁠6.15.1. Настройка бэкендов

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

Установить бэкенд для Samba можно, используя параметр log file, который задается в разделе [global] файла /etc/samba/smb.conf. Параметр представляет собой список бэкэндов, разделенных пробелом, в формате:

logging = backend1[:option][@loglevel] backendN[:option][@loglevel]

Где:

backend — один из доступных бэкендов:
- syslog — запись в системный журнал;
- file — запись в файл, указанный в параметре log file, либо в стандартные файлы журналов Samba в каталоге /var/log/samba/;
- systemd — запись в журнал systemd;
- lttng — трассировка с использованием инструментов фреймворка LTTng;
- gpfs – аудит файлов в кластерной файловой системе GPFS;
- ringbuf — запись в кольцевой буфер (ring buffer). Для задания размера буфера поддерживается необязательный аргумент size в формате:
  logging = ringbuf:size=NBYTES
  (значение по умолчанию — 1 МБ).
  Данный вариант логирования может быть полезен при анализе ошибок, которые связаны с временными эффектами и не могут быть воспроизведены при записи логов в файлы с указанием высоких уровней отладки;
[:option] — дополнительные опции, специфичные для указанного бэкенда;
[@loglevel] — уровень журналирования. Если для бэкенда данный параметр не установлен, в бэкенд отправляются все сообщения. Параметр log level определяет общие уровни журнала, а указанные здесь уровни определяют, что отправляется на отдельные бэкенды.

Примечание

Если параметр logging задан, то его значение переопределяет значения параметров syslog и syslog only.

По умолчанию параметр logging не задан.

Пример задания параметра logging:

logging = syslog@1 file

⁠6.15.2. Настройка файлов журнала

Параметр log file в разделе [global] файла /etc/samba/smb.conf позволяет переопределить файл журнала Samba.

Параметр log file использует стандартные подстановки, что позволят иметь отдельные файлы журналов для различных сущностей и объектов, обслуживаемых Samba.

Примеры подстановок:

%m — NetBIOS-имя клиентской машины. Этот параметр недоступен, когда Samba прослушивает порт 445, поскольку клиенты больше не отправляют эту информацию. Для возможности использования этой подстановки следует установить в разделе [global] параметр:
```
smbports = 139
```
%M — интернет-имя клиентской машины;
%I — IP-адрес клиентской машины;
%i — локальный IP-адрес, с которым установил соединение клиент;
%T — текущие дата и время;
%U — имя пользователя сессии.

Примечание

Получить полный список подстановок можно в разделе VARIABLE SUBSTITUTIONS на справочной странице smb.conf(5) (man smb.conf).

Например, для создания отдельного файла журнала для каждого подключенного узла с именем в формате <NetBIOS_name>.log в каталоге /var/log/samba/ следует задать параметр следующим образом:

log file = /var/log/samba/%m.log

Параметр max log size в разделе [global] файла /etc/samba/smb.conf определяет максимальный размер файла журнала. Значение параметра задается в килобайтах. Samba периодически проверяет размер файла журнала и, если он превышен, переименовывает файл, добавляя расширение .old и создает новый файл.

Указание значения 0 для параметра max log size означает отсутствие ограничений. Значение по умолчанию 5000.

Пример устнавки ограничения максимального размера файла журнала в 1 МБ:

max log size = 1000

Примечание

В процессе ротации Samba перезаписывает архивированный ранее файл.

⁠6.15.3. Уровни журналирования

Установить уровень журналирования для Samba можно, используя параметр log level файла /etc/samba/smb.conf. Для разных классов отладки можно указывать разные уровни журналирования и отдельные файлы журналов.

Уровень журналирования задается в виде целого числа в диапазоне от 0 до 10, где 0 соответствует отключению вывода отладочной информации, а 10 — обеспечивает вывод полной отладочной информации об ошибках и проблемах, которые могут возникать в процессе работы Samba. Оптимальным для получения отладочной информации является уровень 3. Уровни выше 3 предназначены преимущественно для выявления внутренних ошибок Samba. Их использование может привести к существенному снижению производительности сервера.

В таблице Классы отладки приведено описание доступных классов отладки.

⁠

Таблица 6.15. Классы отладки

Класс отладки	Описание
all	Включает все сообщения отладки и подходит для общего мониторинга системы
tdb	Отвечает за отладку работы с TDB (Trivial Database). TDB — это простая встраиваемая база данных, используемая Samba для хранения различных данных, таких как сессии, аутентификационные данные, метаданные файлов и другие внутренние структуры
printdrivers	Используется для отладки драйверов печати. Этот класс полезен для отладки и анализа работы с принтерами, включая загрузку, установку и настройку драйверов
lanman	Предназначен для отладки протоколов LAN Manager, что может быть полезно при работе с устаревшими системами или приложениями
smb	Предназначен для регистрации вызовов по протоколу SMB
rpc_parse	Включает информацию об обработке RPC-сообщений. Может использоваться при анализе репликации
rpc_srv	Включает информацию о регистрации конечных точек RPC
rpc_cli	Предназначен для регистрации информации, связанной с работой RPC-клиента (Remote Procedure Call). Используется для отладки взаимодействия между клиентом и сервером в контексте RPC-вызовов, которые используются для выполнения различных операций в Samba, таких как управление доменными службами, доступ к общим ресурсам и другие действия, связанные с протоколами SMB/CIFS
passdb	Предназначен для регистрации доступа к хранилищу данных паролей
sam	Предназначен для регистрации событий, связанных с управлением учетными записями пользователей и групп в AD (SAM — Security Accounts Manager)
auth	Предназначен для регистрации событий аутентификации пользователей. Включает процессы проверки учетных данных (логин/пароль), использование Kerberos, NTLM и других механизмов аутентификации
winbind	Предназначен для регистрации сообщений при присоединении клиентов к Samba для проведения различных операций. Позволяет анализировать работу сервиса Winbind
vfs	Предназначен для журналирования проблем с правами доступа и некорректным поведением бэкенда, абстрагируемого VFS
idmap	Предназначен для регистрации событий установки соответствия между SID и группами в Linux (Identity Mapping)
quota	Предназначен для регистрации информации, связанной с управлением квотами (quotas) на файловых системах. Квоты используются для ограничения объема дискового пространства, которое может использовать пользователь или группа
acls	Предназначен для регистрации событий проверки и изменения прав доступа на основе списков управления доступом (Access Control Lists)
locking	Предназначен для регистрации событий блокировок файлов базы данных каталога и конкретных записей при одновременном доступе к ним разных клиентов
msdfs	Предназначен для регистрации событий, связанных с поддержкой DFS (Distributed File System) в Samba. DFS позволяет объединять несколько общих ресурсов в одну виртуальную иерархию
dmapi	Предназначен для регистрации событий, связанных с использованием DMAPI (Data Management API) в Samba
registry	Предназначен для регистрации взаимодействия с данными реестра Windows, которые используются в службе каталогов
scavenger	Предназначен для регистрации событий «сборки мусора» (garbage collection) в Samba. Этот процесс используется для очистки устаревших или неиспользуемых данных, таких как открытые файлы, сессии, аутентификации и другие ресурсы, которые больше не нужны
dns	Предназначен для регистрации запросов на поиск и изменение записей DNS
ldb	Предназначен для регистрации подключений к базе данных LDAP
tevent	Предназначен для регистрации сообщений библиотеки управления памятью talloc
auth_audit, auth_json_audit	Предназначены для регистрации событий аутентификации и авторизации учетных записей (успешных и неуспешных попытках входа в систему, изменениях паролей и изменениях статусов учетных записей). Могут использоваться, например, для отслеживания попыток несанкционированного входа
kerberos	Предназначен для регистрации событий взаимодействия по протоколу Kerberos
drs_repl	Предназначен для регистрации событий входящей и исходящей репликации на контроллере домена
smb2	Предназначен для регистрации вызовов по протоколу SMB (SMB2 и SMB3)
smb2_credits	Предназначен для регистрации запросов передачи данных по протоколу SMB. Записи содержат информацию о количестве переданных запросов и количестве запросов, которые осталось выполнить для завершения передачи файлов
dsdb_audit, dsdb_json_audit	Предназначены для регистрации изменений в базе данных контроллера домена Samba (sam.ldb) (изменения пользователей, групп, разрешений, структуры каталога и т. д.)
dsdb_password_audit, dsdb_password_json_audit	Предназначены для регистрации событий изменения и сброса паролей
dsdb_transaction_audit, dsdb_transaction_json_audit	Предназначены для регистрации транзакций (фиксация, откат) в базе данных каталога. Могут использоваться для контроля целостности данных
dsdb_group_audit, dsdb_group_json_audit	Предназначены для регистрации изменений в составе групп

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

catia
dfs_samba4
extd_audit
fileid
fruit
full_audit
media_harmony
preopen
recycle
shadow_copy
unityed_media
virusfilter

Чтобы настроить ведение журналов для определенных классов так, чтобы они писались в другой файл, а не в общий файл журнала, можно добавить @PATH к классу.

Получить дополнительную информацию и список классов отладки можно на справочной странице smb.conf(5) (man smb.conf).

⁠6.15.3.1. Установка уровня журналирования в файле `smb.conf`

Примеры использования параметра log level для настройки уровня журналирования:

установить уровень журнала 3 для всех классов отладки:
```
log level = 3
```
установить общий уровень журнала 3, а для классов passdb и auth — 5:
```
log level = 3 passdb:5 auth:5
```
установить общий уровень журнала 3, а для класса winbind — 1 и писать логи в файл /var/log/winbind.log:
```
log level = 3 winbind:1@/var/log/winbind.log
```

⁠6.15.3.2. Установка уровня журналирования при выполнении команд

Команды Samba используют уровень журналирования, установленный в параметре log level в файле /etc/samba/smb.conf. Для всех команд Samba это значение можно переопределить, используя следующую опцию:

-d DEBUGLEVEL, --debuglevel=DEBUGLEVEL

Например:

$ net usershare add Share2 /tmp/share2 -d 5
# samba-tool group add testgroup12 -d dsdb_audit:3

⁠6.15.4. Настройка ведения журнала аудита

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

Ведение журнала аудита является локальной настройкой, эту функцию необходимо включить на каждом сервере Samba. События регистрируются только на том сервере Samba, на котором произошло событие. Чтобы хранить все журналы на централизованном сервере, следует настроить централизованный сервер системных журналов, настроить Samba для регистрации в syslog и настроить syslog для отправки журналов на централизованный сервер.

Для мониторинга файлов журналов и выполнения определенных действий на основе результатов их анализа могут использоваться дополнительные утилиты.

Примечание

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

Журнал аудита Samba поддерживает стандартный формат и формат JSON. Можно включить каждый формат по отдельности или оба вместе, используя разные классы отладки журнала (например, auth_audit для ведения записи в стандартном формате и auth_json_audit для ведения записи в формате JSON).

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

⁠6.15.4.1. Регистрация событий аутентификации и авторизации

Samba поддерживает протоколирование успешных и неуспешных событий аутентификации, а также успешных событий авторизации.

Примечание

Аутентификация

Аутентификация происходит, когда Samba проверяет комбинацию имени пользователя и пароля.

Авторизация

Авторизация происходит при запуске сеанса.

Следующие примеры показывают, в каких случаях Samba регистрирует события аутентификации и авторизации:

При входе пользователя в домен центр распространения ключей Kerberos (KDC), работающий на DC, фиксирует событие аутентификации. Если в домене работают несколько контроллеров, запрос аутентификации регистрируется только на контроллере, который обслуживает данный запрос.
При подключении к общему ресурсу на участнике домена:
- участник домена регистрирует событие авторизации;
- при использовании аутентификации Kerberos центр распространения ключей (KDC) на контроллере домена Samba фиксирует событие аутентификации. В случае использования аутентификации Kerberos за нее отвечает KDC. Поэтому Samba на участнике домена AD не может регистрировать такое событие аутентификации;
  при использовании аутентификации через NT LAN Manager (NTLM) участник домена регистрирует событие аутентификации.

Примечание

При использовании NTLM всегда регистрируется пара событий — событие аутентификации и событие авторизации. Однако при использовании Kerberos регистрируется только одно событие на контроллере домена в момент выдачи билета TGT (Ticket Granting Ticket). После этого каждый раз при получении доступа к какой-либо службе регистрируется событие авторизации.

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

auth_audit — регистрация в стандартном формате;
auth_json_audit — регистрация в формате JSON.

Для классов auth_audit и auth_json_audit доступны следующие уровни журналирования (каждый последующий уровень включает все предшествующие ему):

2 — неуспешные события аутентификации;
3 — успешные события аутентификации;
4 — успешные события авторизации;
5 — успешные анонимные события аутентификации и авторизации.

Пример включения ведения журнала аудита аутентификации (установить уровень журнала по умолчанию — 1, включить регистрацию неудачных и успешных запросов аутентификации — 3):

Установить в секции [global] файла /etc/samba/smb.conf:
```
log level = 1 auth_audit:3 auth_json_audit:3
```
Перезапустить службу Samba.

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

[2024/05/29 14:32:52.509247,  2] ../../auth/auth_log.c:858(log_authentication_event_human_readable)
Auth: [Kerberos KDC,ENC-TS Pre-authentication] user [(null)]\[ivanov\\@TEST@TEST.ALT] at [Wed, 29 May 2024 14:32:52.509236 EET] with [aes256-cts-hmac-sha1-96] status [NT_STATUS_WRONG_PASSWORD] workstation [(null)] remote host [ipv4:192.168.0.135:51947] mapped to [TEST]\[ivanov]. local host [NULL]

[2024/05/29 14:39:06.426556,  3] ../../auth/auth_log.c:858(log_authentication_event_human_readable)
Auth: [Kerberos KDC,ENC-TS Pre-authentication] user [(null)]\[ivanov\\@TEST@TEST.ALT] at [Wed, 29 May 2024 14:39:06.426540 EET] with [aes256-cts-hmac-sha1-96] status [NT_STATUS_OK] workstation [(null)] remote host [ipv4:192.168.0.135:55134] became [TEST]\[ivanov] [S-1-5-21-578923263-1107570656-1287136478-1103]. local host [NULL]

Пример записей о неуспешной и успешной попытках аутентификации пользователя с использованием формата JSON:

{"timestamp": "2024-05-29T14:32:52.509393+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 3}, "eventId": 4625, "logonId": "5bd240f7cc4de1b5", "logonType": 3, "status": "NT_STATUS_WRONG_PASSWORD", "localAddress": null, "remoteAddress": "ipv4:192.168.0.135:51947", "serviceDescription": "Kerberos KDC", "authDescription": "ENC-TS Pre-authentication", "clientDomain": null, "clientAccount": "ivanov\\@TEST@TEST.ALT", "workstation": null, "becameAccount": "ivanov", "becameDomain": "TEST", "becameSid": "S-1-5-21-578923263-1107570656-1287136478-1103", "mappedAccount": "ivanov", "mappedDomain": "TEST", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "aes256-cts-hmac-sha1-96", "clientPolicyAccessCheck": null, "serverPolicyAccessCheck": null, "duration": 3129}}

{"timestamp": "2024-05-29T14:39:06.426725+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 3}, "eventId": 4624, "logonId": "11424f6685e647f9", "logonType": 3, "status": "NT_STATUS_OK", "localAddress": null, "remoteAddress": "ipv4:192.168.0.135:55134", "serviceDescription": "Kerberos KDC", "authDescription": "ENC-TS Pre-authentication", "clientDomain": null, "clientAccount": "ivanov\\@TEST@TEST.ALT", "workstation": null, "becameAccount": "ivanov", "becameDomain": "TEST", "becameSid": "S-1-5-21-578923263-1107570656-1287136478-1103", "mappedAccount": "ivanov", "mappedDomain": "TEST", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "aes256-cts-hmac-sha1-96", "clientPolicyAccessCheck": null, "serverPolicyAccessCheck": null, "duration": 5421}}

⁠6.15.4.2. Регистрация изменений в базе данных

Для регистрации изменений в базе данных контроллера домена Samba (sam.ldb) используются следующие классы отладки:

dsdb_audit — регистрация в стандартном формате;
dsdb_json_audit — регистрация в формате JSON.

Для регистрации изменений в составе групп используются следующие классы отладки:

dsdb_group_audit — регистрация в стандартном формате;
dsdb_group_json_audit — регистрация в формате JSON.

Для классов dsdb_audit, dsdb_json_audit, dsdb_group_audit и dsdb_group_json_audit доступны следующие уровни журналирования:

5 — внесение изменений в базу данных;
5 — регистрация изменений, полученных через механизм репликации с другого контроллера домена.

События изменения и сброса паролей регистрируются в рамках следующих классов отладки:

dsdb_password_audit — регистрация в стандартном формате;
dsdb_password_json_audit — регистрация в формате JSON.

Примечание

Каждое изменение пароля также регистрируется как событие аутентификации через классы отладки auth_audit и auth_audit_json.

Для классов dsdb_password_audit и dsdb_password_json_audit доступны следующие уровни журналирования:

5 — успешные события изменения и сброса пароля.

Для регистрации неуспешных транзакций, завершающихся откатом, и событий подготовки фиксации данных (prepare commit) используются следующие классы отладки:

dsdb_transaction_audit — регистрация в стандартном формате;
dsdb_transaction_json_audit — регистрация в формате JSON.

Для классов dsdb_transaction_audit и dsdb_transaction_json_audit доступны следующие уровни журналирования:

5 — неуспешная транзакция (откат);
10 — успешная транзакция (фиксация).

В Samba возможны откаты транзакций. Они редко отражают что-либо помимо неуспешного завершения отдельной операции (например, в результате попытки создания записи, которая конфликтует с существующими). Записи о транзакции формируются и фиксируются в системных журналах до ее завершения. Такое журналирование информации о транзакциях позволяет выявлять операции с паролями и операции по внесению изменении в sam.ldb, которые закончились откатом и фактически не были выполнены.

Пример включения ведения журнала аудита базы данных DC AD (установить уровень журнала по умолчанию — 1, включить ведение журнала изменений базы данных в формате JSON):

Установить в секции [global] файла /etc/samba/smb.conf:

log level = 1 dsdb_json_audit:5 dsdb_password_json_audit:5 dsdb_group_json_audit:5 dsdb_transaction_json_audit:5

Перезапустить службу Samba.

⁠6.15.5. Интерпретация журналов аудита JSON

Если включено ведение журнала аудита в формате JSON, сведения о различных событиях регистрируются в формате JSON. Каждое событие описывается определенным набором атрибутов, соответствующим его типу. Внешний слой атрибутов состоит из трёх элементов: метки времени, типа события и объекта данных (в примере добавлены переносы на новую строку и отступы; реальные записи всегда форматируются в виде одной строки):

{
"timestamp": 2024-05-29T14:32:52.509393+0200,
"type": одно из значений "Authentication", "Authorization", "dsdbChange",
        "dsdbTransaction", "passwordChange", "replicatedUpdate",
        "groupChange",
type: { data }
}

Примечание

Некоторые атрибуты могут присутствовать в записях, даже если они неприменимы. Например, если NETLOGON не используется (согласно serviceDescription), для параметра netlogonComputer будет установлено значение «null», для параметра netlogonNegotiateFlags будет установлено значение «0x00000000», другие параметры, оносящиеся к NETLOGON, будут иметь аналогичные пустые значения.

⁠6.15.5.1. Общие атрибуты

В таблице Общие атрибуты приведен набор атрибутов, которые присутсвуют при регистрации любого события.

⁠

Таблица 6.16. Общие атрибуты

Атрибут	Значение
`version`	Номер версии формата JSON. Состоит из двух частей: «major» — увеличивается, если поля меняют значение «minor» — увеличивается, если добавляется новое поле Изменения в перечне возможных значений обычно не приводят к изменению версии. Это распространяется на все данные, предоставляемые клиентами. Также это относится, например, к атрибуту `passwordType`, набор поддерживаемых форматов которого может меняться с течением времени без изменения версии в JSON.

Атрибут

Значение

version

Номер версии формата JSON. Состоит из двух частей:

«major» — увеличивается, если поля меняют значение
«minor» — увеличивается, если добавляется новое поле

Изменения в перечне возможных значений обычно не приводят к изменению версии. Это распространяется на все данные, предоставляемые клиентами. Также это относится, например, к атрибуту passwordType, набор поддерживаемых форматов которого может меняться с течением времени без изменения версии в JSON.

⁠6.15.5.2. Атрибуты событий аутентификации (Authentication)

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

⁠

Таблица 6.17. Атрибуты событий аутентификации

Атрибут	Значение
`authDescription`	Тип аутентификации: «simple bind/TLS», «simple bind» — простая привязка LDAP с каналом TLS или без него «guest» — анонимный запрос SMB1 «bare-NTLM» — запрос SMB, использующий протокол NT1 «plaintext» — запрос SMB, в виде обычного текста «interactive» — аналог физического входа на конкретной рабочей станции «network» — проверка подлинности запроса/ответа по сети «Unknown Auth Description», «Unknown Pre-authentication» — события KDC «ServerAuthenticate» — запрос/ответ компьютера при входе в систему с использованием NETLOGON «LDAP Modify» — смена пароля (не событие аутентификации, но регистрируется здесь, чтобы администратор не пропустил его)
`becameAccount`	Имя учетной записи, под которой выполнен вход (может не совпадать со значением, предоставленным клиентом)
`becameDomain`	Имя домена, в который произведён вход
`becameSid`	Идентификатор безопасности (SID) аутентифицированной учетной записи
`clientAccount`	Имя учётной записи, предоставленное клиентом
`clientDomain`	Имя домена, предоставленное клиентом
`duration`	Время (в микросекундах), в течение которого выполнялась аутентификация
`eventId`	Идентификатор события Windows, указывающий в общих чертах, что произошло
`localAddress`	Адрес сервера и используемый порт
`logonId`	Случайный 64-битный идентификатор, помогающий отслеживать события входа в систему на разных этапах
`logonType`	Тип входа в Windows. Для Samba один из: 2 — интерактивный, то есть вход выполняется на текущем компьютере 3 — сетевой, то есть вход выполняется по сети 8 — сетевой с использованием нехешированных паролей, то есть вход выполняется по сети, при этом пароль передается в пакет подтверждения подлинности в нехешированной форме (NetworkCleartext)
`mappedAccount`	Имя учетной записи клиента, преобразованное в имя учетной записи AD
`mappedDomain`	Имя домена клиента, преобразованное в доменное имя AD
`netlogonComputer`	Имя компьютера, заявленное при аутентификации через NETLOGON RPC
`netlogonNegotiateFlags`	Флаги NETLOGON, согласуемые в процессе взаимодействия клиента и сервера
`netlogonSecureChannelType`	Тип безопасного канала, используемого для входа по протоколу NETLOGON
`netlogonTrustAccount`	Учетная запись, используемая для аутентификации по протоколу NETLOGON
`netlogonTrustAccountSid`	Идентификатор безопасности (SID) учётной записи, используемый для аутентификации по протоколу NETLOGON
`passwordType`	Алгоритм/протокол пароля (например, «HMAC-SHA256», «NTLMv2», «arcfour-hmac-md5»)
`remoteAddress`	Заявленный адрес (и порт) удаленного клиента
`serviceDescription`	Тип службы (например, «LDAP», «SMB2», «NETLOGON», «Kerberos KDC»)
`status`	Сообщение NT STATUS. Для успешной аутентификации это будет «NT_STATUS_OK». Неудачная аутентификация может иметь значение «NT_STATUS_OK», если аутентификация не удалась после регистрации этого сообщения, но обычно имеет код ошибки. Некоторые типы сообщений при неудачной аутентификации: NT_STATUS_ACCESS_DENIED — доступ запрещен по неустановленным причинам, (наиболее вероятная причинаvнеправильные учетные данные) NT_STATUS_WRONG_PASSWORD — неверный пароль NT_STATUS_NO_SUCH_USER — пользователь не существует NT_STATUS_NO_SUCH_DOMAIN — домен не существует NT_STATUS_ACCOUNT_RESTRICTION — учетная запись защищена или иным образом ограничена NT_STATUS_DOWNGRADE_DETECTED — клиент, возможно, предпринимает какие-либо действия для использования некорректных способов аутентификации NT_STATUS_INVALID_SERVER_STATE — сервер, возможно, используется не по назначению NT_STATUS_INVALID_INFO_CLASS — сервер, возможно, используется не по назначению NT_STATUS_INVALID_PARAMETER — клиент получил некорректные данные NT_STATUS_NETWORK_CREDENTIAL_CONFLICT — в процессе входа произошли изменения (возможно, имеет место гонка в рамках изменения учетных данных, либо при согласовании данных шифрования возникла ошибка) NT_STATUS_NOT_IMPLEMENTED — тип аутентификации не реализован в Samba NT_STATUS_NOT_SUPPORTED — тип аутентификации, либо способ его использования со стороны клиента не поддерживается Samba NT_STATUS_INVALID_SYSTEM_SERVICE — выбранная служба аутентификации недоступна NT_STATUS_INTERNAL_ERROR — сервер не может завершить выполнение аутентификации по причине внутренней ошибки NT_STATUS_NO_MEMORY — сервер не может завершить аутентификацию по причине нехватки памяти
`version`	См. описание в таблице Общие атрибуты Текущая версия: {"major": 1, "minor": 3}
`workstation`	Заявленное имя клиентской рабочей станции

Пример записи об успешной попытке аутентификации:

{"timestamp": "2024-05-29T14:39:06.426725+0200", "type": "Authentication",
"Authentication": {"version": {"major": 1, "minor": 3}, "eventId": 4624, "logonId": "11424f6685e647f9",
"logonType": 3, "status": "NT_STATUS_OK", "localAddress": null, "remoteAddress": "ipv4:192.168.0.135:55134",
"serviceDescription": "Kerberos KDC", "authDescription": "ENC-TS Pre-authentication",
"clientDomain": null, "clientAccount": "ivanov\\@TEST@TEST.ALT", "workstation": null,
"becameAccount": "ivanov", "becameDomain": "TEST", "becameSid": "S-1-5-21-578923263-1107570656-1287136478-1103",
"mappedAccount": "ivanov", "mappedDomain": "TEST", "netlogonComputer": null, "netlogonTrustAccount": null,
"netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null,
"passwordType": "aes256-cts-hmac-sha1-96", "clientPolicyAccessCheck": null, "serverPolicyAccessCheck": null, "duration": 5421}}

⁠6.15.5.3. Атрибуты событий авторизации (Authorization)

В таблице Успешные события авторизации приведен набор атрибутов, который используется для регистрации успешных событий авторизации.

⁠

Таблица 6.18. Успешные события авторизации

Атрибут	Значение
`account`	Имя авторизуемой учетной записи
`accountFlags`	Битовое поле атрибутов учетной записи
`authType`	Строка, описывающая тип авторизации (например, «krb5», «NTLMSSP», «simple bind»)
`domain`	Имя домена
`localAddress`	Адрес сервера и используемый порт
`logonServer`	Сервер, на котором выполнена аутентификация
`remoteAddress`	Видимый адрес клиента
`serviceDescription`	Тип службы (например, «LDAP», «SMB2», «DCE/RPC»)
`sessionId`	Уникальный идентификатор сессии (GUID)
`sid`	Идентификатор безопасности (SID) авторизуемой учетной записи
`transportProtection`	Тип защиты, используемой в канале (например, «SMB», «TLS», «SEAL», «NONE»)
`version`	См. описание в таблице Общие атрибуты Текущая версия: {"major": 1, "minor": 2}

Пример записи об успешной попытке авторизации:

{"timestamp": "2024-05-29T15:32:39.282334+0200", "type": "Authorization",
"Authorization": {"version": {"major": 1, "minor": 2}, "localAddress": "ipv4:127.0.0.1:389",
"remoteAddress": "ipv4:127.0.0.1:43350", "serviceDescription": "LDAP",
"authType": "simple bind", "domain": "NT AUTHORITY", "account": "ANONYMOUS LOGON",
"sid": "S-1-5-7", "sessionId": "5accdd86-4c6e-4bd2-8ab1-7e95f641ecf2",
"logonServer": "DC1", "transportProtection": "NONE", "accountFlags": "0x00000010",
"clientPolicyAccessCheck": null, "serverPolicyAccessCheck": null}}

⁠6.15.5.4. Атрибуты событий, связанных с изменениями в базе данных (dsdbChange)

События dsdbChange регистрируются, когда клиент вызывает существенные изменения в базе данных AD (известной как DSDB внутри Samba). Некоторые конкретные изменения, а именно изменения пароля, группы и изменения репликации, регистрируются отдельно как события «passwordChange», «groupChange» и «replicationUpdate».

В таблице События dsdbChange приведен набор атрибутов, который используется для регистрации событий, связанных с внесением значимых изменений в базу данных службы каталогов.

⁠

Таблица 6.19. События dsdbChange

Атрибут	Значение
`attributes`	Список изменяемых атрибутов
`dn`	Уникальное составное имя (DN) изменяемого объекта
`operation`	Операция LDAP, соответствующая выполняемому действию по изменению данных: «Modify» «Add» «Delete»
`performedAsSystem`	Признак системного или пользовательского действия: «true» — действие выполняется Samba с использованием системной учетной записи «false» — действие выполняется от имени пользователя
`remoteAddress`	Удаленный адрес пользователя, инициировавшего операцию
`sessionId`	Уникальный идентификатор (GUID) сессии аутентификации
`status`	Строка, указывающая на успешное завершение действия или невозможность его выполнения по той или иной причине; выводимая информация соответствует кодам ответа LDAP, которые фиксируются в атрибуте `statusCode`. Примеры значений: «Success» «Operations error» «Protocol error» «Time limit exceeded» «Size limit exceeded» «Unsupported critical extension» «No such attribute» «Undefined attribute type» «Constraint violation» «Attribute or value exists» «Invalid attribute syntax» «No such object» «Alias problem» «Invalid DN syntax» «Insufficient access rights» «Unwilling to perform» «Naming violation» «Object class violation» «Not allowed on non-leaf» «Not allowed on RDN» «Entry already exists»
Числовой код, соответствующий статусу в атрибуте `status`	В общем случае в качестве значения атрибута приводится код ответа LDAP в соответствии с RFC 4511
`transactionId`	Уникальный идентификатор (GUID) транзакции, в рамках которой выполняется операция (если операция является частью транзакции)
`userSid`	Идентификатор безопасности (SID) пользователя, инициировавшего операцию
`version`	См. описание в таблице Общие атрибуты Текущая версия: {"major": 1, "minor": 2}

Значение поля attributes может рассматриваться в качестве аналога описания изменения в формате LDIF.

Например, следующий JSON:

"dsdbChange": {
"operation": "Modify",
"dn": "@SAMBA_DSDB",
"attributes": {
"backupDate": {"actions": [
{"action": "add",
    "values": [
    {"value": "2024-05-29T15:32:39.282334+0200"}
    ]
  }
 ]
}}}

описывает изменение, выполненное этим LDIF:

dn: @SAMBA_DSDB
changetype: modify
add: backupDate
backupDate:  2024-05-29T15:32:39.282334+0200

Для секретных атрибутов вместо каких-либо значений указывается тег redacted: true.

Если значение очень длинное (> 1024 байт), оно будет усечено с добавлением «…» и флагом truncated: true, например:

"values": [
    {truncated: true,
                "value": "It was the best of times, it was the worst of times, it was the age…"
    }
]

Пример записи о внесении изменений в базу данных AD:

{"timestamp": "2024-05-29T09:52:14.813697+0200", "type": "dsdbChange",
"dsdbChange": {"version": {"major": 1, "minor": 0}, "statusCode": 0,
"status": "Success", "operation": "Modify",
"remoteAddress": "ipv6:fd47:d11e:43c1:0:a00:27ff:fe9d:4de0:38500", "performedAsSystem": false,
"userSid": "S-1-5-21-578923263-1107570656-1287136478-500",
"dn": "CN=Марков Кирилл,CN=Users,DC=test,DC=alt", "transactionId": "ce759566-8bf9-46ce-95a1-0d632232a220",
"sessionId": "48c760f6-6cdc-4fba-b16d-1689f2cfad33",
"attributes": {"unicodePwd": {"actions": [{"action": "replace", "redacted": true}]}}}}

⁠6.15.5.5. Атрибуты событий, связанных с транзакциями (dsdbTransaction)

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

Каждая транзакция имеет идентифицирующий GUID; другие операции DSDB, являющиеся частью транзакции, будут включать этот GUID в атрибут transactionId.

В таблице Атрибуты событий, связанных с транзакциями приведен набор атрибутов, связанных с транзакциями (dsdbTransaction).

⁠

Таблица 6.20. Атрибуты событий, связанных с транзакциями

Атрибут	Значение
`action`	Текущий этап транзакции: «begin» «commit» «rollback»
`duration`	Продолжительность транзакции в микросекундах (до момента записи этого поля)
`transactionId`	Уникальный идентификатор (GUID) транзакции
`version`	См. описание в таблице Общие атрибуты Текущая версия: {"major": 1, "minor": 0}

Пример регистрации событий, связанных с транзакциями:

{"timestamp": "2024-05-29T20:41:36.895027+0200", "type": "dsdbTransaction",
"dsdbTransaction": {"version": {"major": 1, "minor": 0}, "action": "commit",
"transactionId": "a89149be-5c19-42c2-bf08-94ddc5b0eb78", "duration": 8819}}

{"timestamp": "2024-05-29T20:41:37.691707+0200", "type": "dsdbTransaction",
"dsdbTransaction": {"version": {"major": 1, "minor": 0}, "action": "commit",
"transactionId": "92a8db3a-94d4-4ac5-b929-b1e4344b12e3", "duration": 5697}}

⁠6.15.5.6. Атрибуты событий, связанных с изменением пароля (passwordChange)

PasswordChange — это особый вид dsdbChange.

В таблице Атрибуты событий, связанных с изменением пароля приведен набор атрибутов, который используется для регистрации событий, связанных с изменением пароля (passwordChange).

⁠

Таблица 6.21. Атрибуты событий, связанных с изменением пароля

Атрибут	Значение
`action`	Тип операции: «Change» — смена пароля «Reset» — сброс пароля
`dn`	Уникальное составное имя (DN) пользователя, пароль которого изменяется или сбрасывается
`eventId`	Идентификатор события Windows: 4723 соответствует событию смены пароля (Change) 4724 соответствует событию сброса пароля (Reset)
`remoteAddress`	Удаленный адрес пользователя, выполняющего операцию
`sessionId`	Идентификатор сессии DSDB
`status`	Текст ошибки
`statusCode`	Код ошибки
`transactionId`	Уникальный идентификатор (GUID) транзакции, в рамках которой выполняется операция (если операция является частью транзакции)
`userSid`	Идентификатор безопасности (SID) пользователя, инициировавшего операцию
`version`	См. описание в таблице Общие атрибуты Текущая версия: {"major": 1, "minor": 1}

Пример регистрации события сброса пароля пользователя:

{"timestamp": "2024-05-29T15:28:18.876663+0200", "type": "passwordChange",
"passwordChange": {"version": {"major": 1, "minor": 1}, "eventId": 4724,
"statusCode": 0, "status": "Success", "remoteAddress": "ipv6:fd47:d11e:43c1:0:a00:27ff:fe9d:4de0:35534",
"userSid": "S-1-5-21-578923263-1107570656-1287136478-500",
"dn": "CN=Орлов Игорь,CN=Users,DC=test,DC=alt", "action": "Reset",
"transactionId": "d7456cd1-6f32-4575-b530-dc22a34bdc6a", "sessionId": "ce6866f6-43ea-4665-a896-0d10bd3194e1"}}

⁠6.15.5.7. Атрибуты событий, связанных с изменением группы (groupChange)

Событие groupChange указывает на изменение DSDB, которое добавляет или удаляет пользователя из группы.

В таблице Атрибуты событий, связанных с изменением группы приведен набор атрибутов, который используется для регистрации событий, связанных с изменением группы (groupChange).

⁠

Таблица 6.22. Атрибуты событий, связанных с изменением группы

Атрибут	Значение
`action`	Тип операции: «Removed» — удаление пользователя из группы «Added» — добавление пользователя в группу «PrimaryGroup» — смена основной группы
`eventId`	Идентификатор события Windows: 4728 пользователь добавлен в глобальную группу безопасности 4729 пользователь удален из глобальной группы безопасности 4732 пользователь добавлен в локальную группу безопасности 4733 пользователь удален из локальной группы безопасности 4746 пользователь добавлен в локальную группу 4747 пользователь удален из локальной группы 4751 пользователь добавлен в глобальную группу 4752 пользователь удален из глобальной группы 4756 пользователь добавлен в универсальную группу безопасности 4757 пользователь удален из универсальной группы безопасности 4761 пользователь добавлен в универсальную группу 4762 пользователь удален из универсальной группы
`group`	Уникальное составное имя (DN) группы
`remoteAddress`	Удаленный адрес пользователя, выполняющего операцию
`sessionId`	Идентификатор сессии DSDB
`status`	Текст ошибки
Числовой код, соответствующий статусу в атрибуте `status`	В общем случае в качестве значения атрибута приводится код ответа LDAP в соответствии с RFC 4511
`transactionId`	Уникальный идентификатор (GUID) транзакции, в рамках которой выполняется операция (если операция является частью транзакции)
`user`	Уникальное составное имя (DN) пользователя, членство в группе которого изменяется в рамках операции
`userSid`	Идентификатор безопасности (SID) пользователя, инициировавшего операцию
`version`	См. описание в таблице Общие атрибуты Текущая версия: {"major": 1, "minor": 1}

Пример регистрации события добавления пользователя в группу:

{"timestamp": "2024-05-29T15:20:19.634972+0200", "type": "groupChange",
"groupChange": {"version": {"major": 1, "minor": 1}, "eventId": 4728,
"statusCode": 0, "status": "Success", "action": "Added",
"remoteAddress": "ipv6:fd47:d11e:43c1:0:a00:27ff:fe9d:4de0:59778",
"userSid": "S-1-5-21-578923263-1107570656-1287136478-500",
"group": "CN=testgroup,CN=Users,DC=test,DC=alt", "transactionId": "28372270-093c-4bca-af45-ae3e93b71eda",
"sessionId": "9518687d-8ad1-4c2c-810c-8cc18c2943f7", "user": "CN=Марков Кирилл,CN=Users,DC=test,DC=alt"}}

⁠6.16. Усиление безопасности DC

⁠6.16.1. Возможность анонимного получения списка пользователей, групп

Samba наследует поведение домена NT4, которое больше не требуется в режиме AD. Например, следующая команда возвращает всех пользователей домена:

# rpcclient -U "" -c enumdomusers dc1.test.alt

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

[global]
restrict anonymous = 2

Может также потребоваться работа с полем dSHeuristics:

# samba-tool forest directory_service dsheuristics 0000000

⁠6.16.2. Отключение Netbios

Если конфигурация DNS выполнена правильно, старые протоколы NetBIOS, которые больше не нужны, могут быть отключены. Для этого следует внести изменения в секцию global файла /etc/samba/smb.conf:

[global]
disable netbios = yes
smb ports = 445

⁠6.16.3. Отключение роли сервера печати

Контроллер домена не следует настраивать с ролью сервера печати. Сервер Samba, настроенный как файловый сервер, лучше подходит для этой функции.

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

[global]
printcap name = /dev/null
load printers = no
disable spoolss = yes
printing = bsd

⁠6.16.4. Отключение NTLMv1

Протокол аутентификации NTLMv1 появился в начале 1990-х годов и был быстро заменен на NTLMv2 из-за недостатков безопасности. Он больше не полезен в современных сетях, за исключением случаев использования MS-CHAP-v2, который является протоколом по умолчанию для аутентификации 802.1x на рабочих станциях Windows (например, аутентификация Radius для подключений Wi-Fi). В случае MS-CHAP-v2 использование NTLMv1 можно до некоторой степени допустить, поскольку он инкапсулирован в другой, более надежный протокол.

В Samba есть возможность глобально отключить NTLMv1, если он не используется для аутентификации MS-CHAP-v2. Рекомендуется добавить следующий параметр в секцию global файла /etc/samba/smb.conf:

[global]
ntlm auth = mschapv2-and-ntlmv2-only

⁠6.16.5. Генерация дополнительных хешей паролей

Чтобы разрешить передачу хешей в другую базу аутентификации, можно попросить Samba AD генерировать дополнительные хеши, когда пользователь меняет свой пароль. Для этого следует добавить в секцию global файла /etc/samba/smb.conf строку:

[global]
password hash userPassword schemes = CryptSHA256 CryptSHA512

⁠6.16.6. Защита DNS-записей wpad и isatap

Серверы Windows AD имеют глобальный черный список запросов DNS с двумя записями:

wpad
isatap

В разделе реестра GlobalQueryBlockList перечислены эти две записи DNS, для предотвращения создания таких записей и перенаправления сетевого трафика неавторизованным объектом, действующим в локальной сети. Протокол автоматического обнаружения веб-прокси (WPAD) по умолчанию настроен в браузерах WPAD, в частности в браузерах Internet Explorer.

Даже если конфигурации wpad и isatap не используются, всё равно важно создать эти две записи, чтобы предотвратить их использование обходным путем, поскольку в Samba AD нет способа заблокировать создание записей, так как это можно сделать в Microsoft AD.

Создание записей wpad и isatap в Samba AD:

# samba-tool dns add `hostname -s` `hostname -d` wpad A 127.0.0.1 -P
# samba-tool dns add `hostname -s` `hostname -d` isatap A 127.0.0.1 -P

⁠6.16.7. Ограничение диапазона динамических портов

По умолчанию AD использует очень широкий динамический диапазон для вызовов MS-RPC. Рекомендуется ограничить этот диапазон. Для этого следует добавить в секцию global файла /etc/samba/smb.conf строку:

[global]
rpc server dynamic port range = 50000-55000

Примечание

Если используется фаервол, то его нужно будет перенастроить.

⁠6.16.8. Аудит запросов к каталогам SYSVOL и NetLogon

Для возможности аудита запросов к каталогам SYSVOL и NetLogon следует добавить в файл /etc/samba/smb.conf строки:

[global]
...
full_audit:failure = none
full_audit:success = pwrite write renameat
full_audit:prefix = IP=%I|USER=%u|MACHINE=%m|VOLUME=%S
full_audit:facility = local7
full_audit:priority = NOTICE
...
[sysvol]
...
vfs objects = dfs_samba4, acl_xattr, full_audit
...
[netlogon]
...
vfs objects = dfs_samba4, acl_xattr, full_audit

⁠6.16.9. Отправка логов аудита в rsyslog

⁠6.16.9.1. Настройка rsyslog

Установить пакет rsyslog-classic:

# apt-get install rsyslog-classic

На стороне отправителя сообщений (клиента) cоздать файл /etc/rsyslog.d/all.conf, в котором прописать протокол (@@ — TCP, @ — UDP) и адрес доставки сообщений:

*.* @@192.168.0.111:514

На стороне приёмника сообщений (сервера) в файле /etc/rsyslog.d/00_common.conf раскомментировать строки:

#для udp
module(load="imudp")
input(type="imudp" port="514")
#для tcp
module(load="imtcp")
input(type="imtcp" port="514")

и создать свой шаблон для логов /etc/rsyslog.d/myrules.conf:

$template remote-incoming-logs,"/var/log/%HOSTNAME/%PROGRAMNAME.log"
*.* ?remote-incoming-logs

⁠6.16.9.2. rsyslog на том же хосте

В секцию global файла /etc/samba/smb.conf добавить строку:

[global]
log level = 1 auth_json_audit:3@/var/log/samba/samba_audit.log

Создать файл /etc/rsyslog.d/send_samba.conf:

module(load="imfile" PollingInterval="10") #needs to be done just once
input(type="imfile"
     File="/var/log/samba/samba_audit.log"
     Tag="samba_auth"
     Severity="info"
     Facility="auth")
if ($syslogtag == "samba_auth") then {
   action(type="omfwd" target="dc1.test.alt" port="514" protocol="tcp"
          action.resumeRetryCount="100"
          queue.type="linkedList" queue.size="10000")
}

⁠6.16.9.3. rsyslog на вышестоящем хосте

В секцию global файла /etc/samba/smb.conf добавить строку:

[global]
log level = 1 auth_json_audit:3@/var/log/samba/samba_audit.log

Создать файл /etc/rsyslog.d/recv_samba.conf:

$ModLoad imtcp
$InputTCPServerRun 514
if ($syslogtag == "samba_auth")  then /var/log/samba/audit_auth.log

⁠6.17. Планирование и настройка диапазонов идентификаторов UID и GID (Winbind/IDMapping)

Домены Windows различают пользователей и группы по уникальным идентификаторам безопасности (SID). Однако в Linux для каждого пользователя и группы требуются уникальные идентификаторы UID и GID. Служба winbindd отвечает за предоставление информации о пользователях и группах домена.

Чтобы служба winbindd могла предоставлять уникальные идентификаторы для пользователей и групп в Linux, необходимо на клиенте домена настроить сопоставление идентификаторов в файле smb.conf для:

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

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

tdb — в доменах * по умолчанию;
ad — в AD доменах;
rid — в AD доменах;
autorid — в AD доменах и доменах * по умолчанию.

⁠6.17.1. Планирование диапазонов идентификаторов

Независимо от того, хранятся ли UID и GID Linux в AD (если в AD включены расширения схемы RFC2307) или настроена их автоматическая генерация, для каждой конфигурации домена требуется уникальный диапазон идентификаторов. Этот диапазон не должен пересекаться с диапазонами других доменов.

Примечание

При пересечении диапазонов идентификаторов работа системы не будет корректной.

Пример непересекающихся диапазонов сопоставления идентификаторов для доменов по умолчанию (*), AD-DOM и TRUST-DOM:

[global]
...
idmap config * : backend = tdb
idmap config * : range = 10000-999999

idmap config AD-DOM:backend = rid
idmap config AD-DOM:range = 2000000-2999999

idmap config TRUST-DOM:backend = rid
idmap config TRUST-DOM:range = 4000000-4999999

Примечание

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

Важно

Максимальное значение uid/gid:

2^31 - 1 = 2147483647

При планировании диапазонов необходимо также учитывать, что в Linux есть специальные UID, которые нельзя использовать:

0 — root (суперпользователь);
65534 — nobody UID (UID «переполнения» или аналогичный) используется в системах Linux для обозначения пользователя, который не имеет прав доступа к системным ресурсам;
65535, он же «16-разрядный (uid_t) -1uid_t». До того, как ядро Linux 2.4 было 16-разрядным, и программы скомпилированные для этого, следовательно, предполагали, что (uid_t)-1 равно 65535. Таким образом, этот UID непригоден для использования.

⁠6.17.2. Домен * по умолчанию

В доменной среде должна быть добавлена одна конфигурация сопоставления идентификаторов для каждого из следующих параметров:

домен, членом которого является клиент, на котором производится настройка;
каждый доверенный домен.

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

локальные пользователи и группы;
встроенные учетные записи и группы, такие как BUILTIN\Administrators.

Бэкенд домена по умолчанию должен быть доступен для записи, чтобы назначенные идентификаторы постоянно сохранялись.

Для домена по умолчанию можно использовать один из следующих бэкендов:

tdb

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

Например, в разделе [global] в файле smb.conf можно задать:

idmap config * : backend = tdb
idmap config * : range = 10000-999999

Для получения более подробной информации см. Использование tdb

autorid

При использовании бэкенда autorid при настройке домена * по умолчанию необязательно добавлять дополнительные конфигурации сопоставления идентификаторов для доменов.

Например, в разделе [global] в файле smb.conf можно задать:

idmap config * : backend = autorid
idmap config * : range = 10000-999999

Для получения более подробной информации см. Использование autorid

⁠6.17.3. Использование tdb

Служба winbindd по умолчанию использует доступный для записи бэкенд tdb для хранения таблиц сопоставления идентификаторов безопасности (SID), UID и GID. Это относится к локальным и встроенным пользователям и группам.

Этот бэкенд следует использовать только для домена * по умолчанию.

⁠6.17.4. Использование ad

Можно настроить пользователя Samba AD на использование бэкенда ad.

Бэкенд ad реализует API, доступный только для чтения, для чтения информации об учетной записи и группе из AD. Это обеспечивает следующие преимущества:

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

Примечание

Бэкенд ad не поддерживает домены AD с односторонними доверительными отношениями. Если настраивается участник домена в AD с односторонними доверительными отношениями, следует вместо этого использовать одну из следующих серверных частей сопоставления идентификаторов: tdb, rid или autorid.

⁠

Таблица 6.23. Атрибуты из AD, которые считывает бэкенд ad

Имя атрибута AD	Тип объекта	Сопоставление
sAMAccountName	Пользователь и группа	Имя пользователя или группы в зависимости от объекта
uidNumber	Пользователь	Идентификатор пользователя (UID)
gidNumber	Группа	Идентификатор группы (GID)
loginShell	Пользователь	Путь к командной строке пользователя

Предварительные требования:

и пользователи, и группы должны иметь уникальные идентификаторы, заданные в AD. Идентификаторы должны находиться в диапазоне, настроенном в файле smb.conf. Объекты, идентификаторы которых находятся за пределами диапазона, не будут доступны на клиенте;
у пользователей и групп должны быть заданы все необходимые атрибуты в AD;
настроено сопоставление идентификаторов в файле smb.conf.

Пример:

idmap config * : backend = tdb
idmap config * : range = 3000-7999

idmap config TEST : backend = ad
idmap config TEST : range = 10000-999999
idmap config TEST : schema_mode = rfc2307

Чтобы разрешить клиенту домена считывать командную строку входа в систему и путь к домашнему каталогу пользователей из соответствующего атрибута AD, необходимо установить:

idmap config DOMAIN : unix_nss_info = yes

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

template shell = /bin/bash
template homedir = /home/%U

⁠6.17.5. Использование rid

Можно настроить клиента домена для использования бэкенда rid.

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

S-1-5-21-XXXXXXXXXX-YYYYYYYYYY-ZZZZZZZZZZ-RID

Где:

S-1-5-21 — префикс SID, общая часть для идентификаторов безопасности Windows;
XXXXXXXXXX-YYYYYYYYYY-ZZZZZZZZZZ — уникальная часть домена;
RID — число, уникальное для каждой учетной записи в домене (например, пользователя или группы).

Для настройки idmap rid в Samba, RID берётся из последней части SID и используется для определения UID/GID на основе заранее заданного диапазона.

Если задаётся конфигурацию idmap rid, например:

idmap config DOMAIN : backend = rid
idmap config DOMAIN : range = 10000-999999

Samba берёт RID из SID и добавляет его к началу диапазона range. Например, для пользователя с SID S-1-5-21-XXXXXXXXXX-YYYYYYYYYY-ZZZZZZZZZZ-1000, UID будет вычислен как 10000 + 1000 = 11000.

Бэкенд rid реализует доступный только для чтения API для вычисления информации об учетной записи и группе на основе алгоритмической схемы сопоставления для доменов. При настройке необходимо задать наименьшее и наибольшее значения идентификаторов в параметре idmap config DOMAIN : range. Samba не будет сопоставлять пользователей или группы с более низким или более высоким RID, чем указано в этом параметре.

Примечание

Для бэкенда rid нельзя назначать новые идентификаторы, например, для BUILTIN групп. Поэтому не следует использовать этот бэкенд для домена * по умолчанию.

Важно

Необходимо планировать интервал с запасом, в соответствии с прогнозированием увеличения количества объектов, так как максимальное значение RID равно 2147483647.

Пример:

idmap config * : backend = tdb
idmap config * : range = 10000-999999

idmap config DOMAIN : backend = rid
idmap config DOMAIN : range = 2000000-2999999

Примечание

Пользователи и группы, чьи идентификаторы не входят в диапазон, игнорируются.

⁠6.17.6. Использование autorid

Бэкенд autorid работает аналогично бэкенду для сопоставления идентификаторов rid, но может автоматически назначать идентификаторы для разных доменов. Это позволяет использовать autorid в следующих ситуациях:

только для домена * по умолчанию;
для домена * по умолчанию и дополнительных доменов, без необходимости создавать конфигурации сопоставления идентификаторов для каждого из дополнительных доменов (любые домены, кроме основного). Они могут быть доверенными доменами в инфраструктуре AD. Для таких доменов можно не указывать подробную конфигурацию в smb.conf.
только для определенных доменов (те домены, для которых вручную заданы конкретные параметры сопоставления идентификаторов).

Пример:

idmap config * : backend = autorid
idmap config * : range = 100000-9999999

Примечание

По умолчанию значение rangesize равно 100000.

При необходимости можно задать другой размер диапазона:

idmap config * : rangesize = 200000

Примечание

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

Клиент присваивает это количество непрерывных идентификаторов каждому объекту домена до тех пор, пока не будут взяты все идентификаторы из диапазона, заданного в параметре idmap config * : range.

Примечание

Диапазон (range) должен быть кратен размеру диапазона (rangesize).

⁠6.18. Установка RSAT

Для администрирования AD из Windows можно использовать средства удаленного администрирования сервера Microsoft (RSAT).

⁠6.18.1. Windows Server

В ОС Windows Server средства удаленного администрирования сервера Microsoft (RSAT) включены по умолчанию.

Установка:

Запустить Диспетчер серверов.
На Windows Server 2012, 2012 R2, и 2016:
- выбрать Управление → Добавить роли и компоненты:
- в открывшемся окне Мастер добавления ролей и компонентов выбрать пункт Установка ролей или компонентов:
- выбрать хост, на котором будут установлены компоненты:
- на шаге Выбор компонентов для установки нажать кнопку Далее.
На Windows Server 2008 и 2008 R2 в дереве навигации выбрать Компоненты и нажать Добавить компоненты.
Выбрать компоненты для установки (см. Рекомендуемые компоненты для администрирования Samba AD):

⁠

Таблица 6.24. Рекомендуемые компоненты для администрирования Samba AD

Компонент	Описание
Group Policy Management	Предоставляет оснастки для групповой политики: средство управления (GPMC), редактор управления (gpedit) и начальный редактор GPO
AD DS Snap-Ins and Command-Line Tools	Предоставляет оснастку «Пользователи и компьютеры Active Directory» (ADUC) и «Сайты и службы Active Directory» (ADSS)
Server for NIS	Добавляет вкладку Атрибуты UNIX в свойства объектов ADUC. Позволяет настраивать атрибуты RFC2307. Эта функция не поддерживается в Windows Server 2016
Active Directory Module for Windows PowerShell	Включает командлеты Active Directory (AD) PowerShell
DNS Server tools	Оснастка MMC DNS для удаленного управления DNS

⁠6.18.2. Windows 10 (1809 и более поздних версиях)

В Windows 10 1809 и более поздних версиях RSAT устанавливается в качестве дополнительной функции. Для установки компьютер должен иметь доступ в Интернет.

Установка:

Перейти в раздел Settings → Apps → Optional Features → View features (Параметры Windows → Приложения → Дополнительные возможности → Добавить компонент):
Выбрать нужные компоненты RSAT (см. Рекомендуемые компоненты для администрирования Samba AD) и нажать кнопку Next:
Нажать кнопку Install.

⁠

Таблица 6.25. Рекомендуемые компоненты для администрирования Samba AD

Компонент	Описание
RSAT: Group Policy Management Tools	Включают консоль управления групповыми политиками (gpmc.msc), редактор управления групповыми политиками (gpme.msc) и редактор GPO инициализирующей программы групповой политики (gpedit.msc)
RSAT: Active Directory Domain Services and Lightweight Directory Services Tools	Предоставляет оснастку «Пользователи и компьютеры Active Directory» (ADUC) и «Сайты и службы Active Directory» (ADSS)
RSAT: DNS Server Tools	Включает оснастку «Диспетчер DNS» для удаленного управления DNS и программу командной строки `dnscmd.exe`
RSAT: Remote Desktop Services Tool	Добавляет вкладку Профиль служб удаленных рабочих столов в свойства объекта пользователя ADUC и устанавливает оснастку MMC «Удаленные рабочие столы» для администрирования RDP-сервера (tsmmc.msc).

⁠6.18.3. Windows Vista и 7

До версии Windows 10 1809 пакет удаленного администрирования серверов RSAT устанавливается в виде MSU обновления, которое нужно скачать с серверов Microsoft.

Установка:

Перейти в Панель управления → Программы → Включение или отключение компонентов Windows:
Включить компоненты (см. Рекомендуемые компоненты для администрирования Samba AD):
Нажать кнопку ОК.

⁠

Таблица 6.26. Рекомендуемые компоненты для администрирования Samba AD

Компонент	Описание
Group Policy Management Tools (Средства управления групповыми политиками)	Включает консоль управления групповыми политиками (gpmc.msc), редактор управления групповыми политиками (gpme.msc) и редактор GPO инициализирующей программы групповой политики (gpedit.msc)
AD DS Tools (Оснастки и программы командной строки доменных служб Active Directory)	Предоставляет оснастку «Пользователи и компьютеры Active Directory» (ADUC) и «Сайты и службы Active Directory» (ADSS)
Server for NIS Tools (Средства сервера для NIS)	Добавляет вкладку Атрибуты UNIX (UNIX Attributes) в свойства объектов ADUC. Позволяет настраивать атрибуты RFC2307. Включает программу командной строки `ypclear.exe`
Active Directory Module for Windows PowerShell (Модуль Active Directory для Windows PowerShell)	Обеспечивает централизованную среду для управления службами каталогов
DNS Server tools (Средства серверов DNS)	Включает оснастку «Диспетчер DNS» для удаленного управления DNS и программу командной строки `dnscmd.exe`
Remote Desktop Services Tool (Средства служб удалённых рабочих столов)	Добавляет вкладку Профиль служб удаленных рабочих столов в свойства объекта пользователя ADUC и устанавливает оснастку MMC «Удаленные рабочие столы» для администрирования RDP-сервера (tsmmc.msc).

⁠6.19. Инструменты командной строки

⁠

Таблица 6.27. Основные инструменты командной строки

Утилита	Описание
samba-tool	Основная утилита управления Samba
wbinfo	Позволяет получить информацию от демона winbindd
net	Инструмент администрирования Samba и удаленных серверов CIFS
adcli	Инструмент для выполнения действий в домене Active Directory
ldapsearch	Утилита для поиска информации в LDAP
testparm	Проверка корректности содержимого основного файла конфигурации Samba — `/etc/samba/smb.conf`

⁠6.19.1. samba-tool

Для управления Samba AD DC в состав пакета Samba входит инструмент командной строки samba-tool.

⁠

Таблица 6.28. Основные команды samba-tool

Команда	Описание
computer	Управление учетными записями компьютеров
contact	Управление контактами
dbcheck	Проверка локальной базы данных AD на наличие ошибок
delegation	Управление делегированием
dns	Управление параметрами доменной службы DNS
domain	Управление параметрами домена
drs	Управление службой репликации каталогов (Directory Replication Services, DRS)
dsacl	Управление списками контроля доступа DS
forest	Управление конфигурацией леса
fsmo	Управление ролями (Flexible Single Master Operations, FSMO)
gpo	Управление групповыми политиками
group	Управление группами
ldapcmp	Сравнение двух баз данных ldap
ntacl	Управление списками контроля доступа ACL
processes	Вывод списка процессов
ou	Управление организационными подразделениями (OU)
rodc	Управление контроллером домена (Read-Only Domain Controller, RODC)
schema	Управление и запрос схемы
sites	Управление сайтами
spn	Управление службой принципалов (Service Principal Name, SPN)
testparm	Проверка конфигурационного файла на корректность синтаксиса
time	Получение показаний текущего времени сервера
user	Управление пользователями
visualize	Графическое представление состояния сети Samba

Получить дополнительную информацию можно на справочной странице samba-tool(8) (man samba-tool).

Пример получения дополнительной информации о подкоманде:

$ samba-tool fsmo --help

Примеры:

вывести список групповых политик:

# samba-tool gpo listall
GPO          : {31B2F340-016D-11D2-945F-00C04FB984F9}
display name : Default Domain Policy
path         : \\test.alt\sysvol\test.alt\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
dn           : CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=test,DC=alt
version      : 0
flags        : NONE

GPO          : {FE6268E4-FDEB-4DCA-94E8-BB1170C66F45}
display name : scripts
path         : \\test.alt\sysvol\test.alt\Policies\{FE6268E4-FDEB-4DCA-94E8-BB1170C66F45}
dn           : CN={FE6268E4-FDEB-4DCA-94E8-BB1170C66F45},CN=Policies,CN=System,DC=test,DC=alt
version      : 65536
flags        : NONE

GPO          : {6AC1786C-016F-11D2-945F-00C04FB984F9}
display name : Default Domain Controllers Policy
path         : \\test.alt\sysvol\test.alt\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}
dn           : CN={6AC1786C-016F-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=test,DC=alt
version      : 0
flags        : NONE

GPO          : {44F1A3E9-BD0D-44D7-AC1D-CEEF2817C573}
display name : Общие каталоги
path         : \\test.alt\sysvol\test.alt\Policies\{44F1A3E9-BD0D-44D7-AC1D-CEEF2817C573}
dn           : CN={44F1A3E9-BD0D-44D7-AC1D-CEEF2817C573},CN=Policies,CN=System,DC=test,DC=alt
version      : 0
flags        : NONE

вывести все связанные контейнеры для объекта групповой политики:

# samba-tool gpo listcontainers {44F1A3E9-BD0D-44D7-AC1D-CEEF2817C573}
Container(s) using GPO {44F1A3E9-BD0D-44D7-AC1D-CEEF2817C573}
    DN: OU=OU,DC=test,DC=alt
    DN: OU=KDE,DC=test,DC=alt

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

# samba-tool gpo getlink OU=OU,DC=test,DC=alt
GPO(s) linked to DN OU=OU,DC=test,DC=alt
    GPO     : {96D5897A-CEFB-4A1B-90AF-5D83707130C4}
    Name    : Файлы
    Options : NONE

    GPO     : {A12547D7-2FFA-4E37-9382-D6767489E3DF}
    Name    : kde
    Options : NONE

    GPO     : {75E65DF7-56A7-48E1-A393-F5FFAA1010FD}
    Name    : Control_ping
    Options : NONE

    GPO     : {FE6268E4-FDEB-4DCA-94E8-BB1170C66F45}
    Name    : scripts
    Options : NONE

    GPO     : {44F1A3E9-BD0D-44D7-AC1D-CEEF2817C573}
    Name    : Общие каталоги
    Options : NONE

    GPO     : {0CCFA74C-57F5-42B5-98E2-007D4A59C4C4}
    Name    : firefox
    Options : NONE

    GPO     : {2CF4EB19-343E-448A-BBBC-A9EC2F7C22E9}
    Name    : Установка пакетов
    Options : NONE

⁠6.19.2. wbinfo

Команда wbinfo создает запросы и возвращает информацию к (от) демона winbindd(8).

⁠

Таблица 6.29. Параметры команды wbinfo

Параметр	Описание	Пример
-a\|--authenticate username%password	Попытаться аутентифицировать пользователя через winbindd(8). Проверяет два метода аутентификации: plaintext password (применяется при входе пользователя в систему локально), challenge/response password (использует NTLM или Kerberos).	$ `wbinfo -a TEST\\ivanov` Enter TEST\ivanov's password: plaintext password authentication succeeded Enter TEST\ivanov's password: challenge/response password authentication succeeded
--allocate-gid	Получить новый GID из idmap
--allocate-uid	Получить новый UID из idmap
--all-domains	Вывести список всех доменов (доверенных и собственный)	$ `wbinfo --all-domains` BUILTIN TEST EXAMPLE
-c\|--change-secret	Изменить пароль доверительной учетной записи. Может использоваться вместе с доменом для изменения паролей учетных записей междоменного доверия.
--ccache-save <имя_пользователя>%<пароль>	Сохранить имя пользователя и пароль для ccache
--change-user-password <имя_пользователя>	Изменить пароль пользователя (будет запрошен старый и новый пароль)	# `wbinfo --change-user-password ivanov` Enter ivanov's old password: Enter ivanov's new password: Password change for user ivanov succeeded
--dc-info <домен>	Вывести текущий контроллер домена для домена	$ `wbinfo --dc-info TEST` dc1.test.alt (192.168.0.122)
--domain <домен>	Определяет домен, в котором будут выполняться любые указанные операции
-D\|--domain-info <домен>	Показать информацию об указанном домене	$ `wbinfo -D TEST` Name : TEST Alt_Name : test.alt SID : S-1-5-21-578923263-1107570656-1287136478 Active Directory : Yes Native : Yes Primary : Yes
--dsgetdcname <домен>	Найти DC для домена	$ `wbinfo --dsgetdcname TEST` \\dc1.test.alt \\192.168.0.122 1 d75c7b83-9472-4646-adb2-52b3d6968eb6 test.alt test.alt 0xe00013fd Default-First-Site-Name Default-First-Site-Name
--gid-info <gid>	Получить информацию о группе по gid	$ `wbinfo --gid-info 10000` domain admins:*:10000:
--group-info <группа>	Получить информацию о группе по имени группы	$ `wbinfo --group-info "TEST\\domain admins"` domain admins:*:10000:
-g\|--domain-groups	Вывести список доменных групп	$ `wbinfo -g` … TEST\domain admins TEST\domain users TEST\domain guests TEST\domain computers …
--get-auth-user	Эта функция была перенесена в утилиту `net` (см. `net help getauthuser`)
--getdcname <домен>	Вывести имя контроллера домена для указанного домена	$ `wbinfo --getdcname TEST` DC1
-G\|--gid-to-sid <gid>	Преобразовать идентификатор группы UNIX в SID Windows NT. Если указанный gid не относится к диапазону gid idmap, операция завершится ошибкой.	$ `wbinfo -G 10000` S-1-5-21-578923263-1107570656-1287136478-512
-i\|--user-info <имя_пользователя>	Вывести информацию о пользователе	$ `wbinfo -i TEST\\ivanov` ivanov:*:10000:10001:Иван Иванов:/home/TEST.ALT/ivanov:/bin/bash
-I\|--WINS-by-ip ip	Вывести NetBIOS-имя, связанное с IP-адресом	$ `wbinfo -I 192.168.0.135` 192.168.0.135 WORK135
-K\|--krb5auth <имя_пользователя>%<пароль>	Попытаться аутентифицировать пользователя через Kerberos	$ `wbinfo -K TEST\\ivanov` Enter TEST\ivanov's password: plaintext kerberos password authentication for [TEST\ivanov] succeeded (requesting cctype: FILE)
--krb5ccname KRB5CCNAME	Запросить определенный тип кеша учетных данных Kerberos, используемый для аутентификации
--lanman	Использовать криптографию Lanman для аутентификации пользователей
--logoff	Выйти из системы
--logoff-uid UID	Определяет идентификатор пользователя, используемый во время запроса на выход из системы
--logoff-user <имя_пользователя>	Определяет имя пользователя, используемое во время запроса на выход из системы
--lookup-sids SID1,SID2...	Поиск SID	$ `wbinfo --lookup-sids S-1-5-21-578923263-1107570656-1287136478-512` S-1-5-21-578923263-1107570656-1287136478-512 -> <none>\Domain Admins 2
-m\|--trusted-domains	Вывести список доверенных доменов	$ `wbinfo --trusted-domains` BUILTIN TEST EXAMPLE
-n\|--name-to-sid <имя>	Вывести SID, связанный с указанным именем. Если домен не указан, используется домен, указанный в параметре `workgroup` `smb.conf`	$ `wbinfo -n TEST\\ivanov` S-1-5-21-578923263-1107570656-1287136478-1103 SID_USER (1)
-N\|--WINS-by-name <name>	Вывести IP-адрес, связанный с именем NetBIOS, указанным в параметре name	$ `wbinfo -N WORK135` 192.168.0.135 WORK135
--ntlmv1	Использовать криптографию NTLMv1 для аутентификации пользователей
--ntlmv2	Использовать криптографию NTLMv2 для аутентификации пользователей
--online-status <домен>	Показать, поддерживает ли winbind в настоящее время активное соединение или нет. Если домен не указан, будет выведен статус текущего домена	$ `wbinfo --online-status` BUILTIN : active connection TEST : active connection
--own-domain	Вывести собственный домен	$ `wbinfo --own-domain` TEST
--pam-logon <имя_пользователя>%<пароль>	Попытаться аутентифицировать пользователя так же, как это сделал бы pam_winbind	$ `wbinfo --pam-logon ivanov` Enter ivanov's password: plaintext password authentication succeeded
-p\|--ping	Проверяет запущен ли winbindd(8)	$ `wbinfo -p` Ping to winbindd succeeded
-P\|--ping-dc	Проверить безопасное соединение с контроллером домена	$ `wbinfo -P` checking the NETLOGON for domain[TEST] dc connection to "dc1.test.alt" succeeded
-r\|--user-groups <имя_пользователя>	Получить список идентификаторов групп, к которым принадлежит пользователь. Доступно только при наличии пользователя на контроллере домена	$ `wbinfo -r ivanov` 10001 10003
-R\|--lookup-rids rid1, rid2, rid3..	Преобразовать RID в имена
--remove-gid-mapping GID,SID	Удалить существующее сопоставление GID и SID из базы данных
--remove-uid-mapping UID,SID	Удалить существующее сопоставление UID и SID из базы данных
-s\|--sid-to-name sid	Преобразовать SID в имя	$ `wbinfo -s S-1-5-21-578923263-1107570656-1287136478-1103` TEST\ivanov 1
--separator	Вывести активный разделитель winbind	$ `wbinfo --separator` \
--sequence	Команда устарела, вместо неё следует использовать параметр `--online-status`
--set-auth-user <имя_пользователя>%<пароль>	Эта функция была перенесена в утилиту `net` (см. `net help setauthuser`)
--set-gid-mapping GID,SID	Создать сопоставление GID и SID в базе данных
--set-uid-mapping UID,SID	Создать сопоставление UID и SID в базе данных
-S\|--sid-to-uid sid	Преобразовать SID в идентификатор пользователя	$ `wbinfo -S S-1-5-21-578923263-1107570656-1287136478-1103` 10000
--sid-aliases sid	Получить псевдонимы SID для заданного SID
--sid-to-fullname sid	Преобразовать SID в полное имя пользователя (ДОМЕН\имя пользователя)	$ `wbinfo --sid-to-fullname S-1-5-21-578923263-1107570656-1287136478-1103` TEST\Иван Иванов 1
--sids-to-unix-ids sid1,sid2,sid3...	Преобразовать SID в Unix ID	$ `wbinfo --sids-to-unix-ids S-1-5-21-578923263-1107570656-1287136478-1103` S-1-5-21-578923263-1107570656-1287136478-1103 -> uid 10000
-t\|--check-secret	Проверить, что доверительная учетная запись рабочей станции, созданная при добавлении сервера Samba в домен Windows NT, работает. Может использоваться вместе с доменом для проверки учетных записей междоменного доверия
-u\|--domain-users	Вывести список доменных пользователей	$ `wbinfo -u` administrator krbtgt ivanov guest
--uid-info uid	Получить информацию о пользователе по идентификатору	$ `wbinfo --uid-info 10000` ivanov:*:10000:10001:Иван Иванов:/home/TEST.ALT/ivanov:/bin/bash
--usage	Вывести краткую справку о программе
--user-domgroups sid	Вывести группы пользователей домена	$ `wbinfo --user-domgroups S-1-5-21-578923263-1107570656-1287136478-1103` S-1-5-21-578923263-1107570656-1287136478-1103 S-1-5-21-578923263-1107570656-1287136478-513
--user-sidinfo sid	Получить информацию о пользователе по sid	$ `wbinfo --user-sidinfo S-1-5-21-578923263-1107570656-1287136478-1103` ivanov:*:10000:10001:Иван Иванов:/home/TEST.ALT/ivanov:/bin/bash
--user-sids sid	Получить SID групп пользователя	$ `wbinfo --user-sids S-1-5-21-578923263-1107570656-1287136478-1103` S-1-5-21-578923263-1107570656-1287136478-1103 S-1-5-21-578923263-1107570656-1287136478-513 S-1-5-32-545
-U\|--uid-to-sid uid	Преобразовать идентификатор пользователя UNIX в SID	$ `wbinfo -U 10000` S-1-5-21-578923263-1107570656-1287136478-1103
-Y\|--sid-to-gid sid	Преобразовать SID в идентификатор группы UNIX	$ `wbinfo -Y S-1-5-21-578923263-1107570656-1287136478-513` 10001

⁠6.19.3. net

net — инструмент администрирования Samba и удаленных серверов CIFS. Синтаксис:

net <протокол> <функция> <дополнительные_параметры> <параметры_цели>

где <протокол> — протокол, используемый при выполнении команды. Возможные значения: ads (Active Directory), rap (Win9x/NT3) или rpc (WindowsNT4/2000/2003/2008/2012). Если протокол не указан, net пытается определить его автоматически.

⁠

Таблица 6.30. Основные команды net ads

Команда	Описание
info	Вывод информации о домене
join	Присоединение машины к домену
testjoin	Проверка, действителен ли пароль учетной записи компьютера
leave	Удалить локальную машину из домена AD
status	Вывод информации об учетной записи компьютера
user	Список/изменение пользователей
group	Список/изменение групп
dns	Выполнить динамическое обновление DNS
password	Изменить пароль пользователей
changetrustpw	Изменить пароль доверительной учетной записи
printer	Список/изменение записей принтера
search	Выполнить поиск LDAP с использованием фильтра
dn	Выполнить поиск LDAP по DN
sid	Выполнить поиск LDAP по SID
workgroup	Показать имя рабочей группы
lookup	Найти контроллер домена AD с помощью поиска CLDAP
keytab	Управление локальным файлом keytab
spnset	Управление именами участников-служб (SPN)
gpo	Управление объектами групповой политики
kerberos	Управление keytab Kerberos
enctypes	Список/изменение enctypes

Получить дополнительную информацию можно на справочной странице net(8) (man net).

Пример получения дополнительной информации о подкоманде:

# net time --help

Получение информации о домене:

# net ads info
LDAP server: 192.168.0.122
LDAP server name: dc1.test.alt
Realm: TEST.ALT
Bind Path: dc=TEST,dc=ALT
LDAP port: 389
Server time: Ср, 27 мар 2024 10:36:51 EET
KDC server: 192.168.0.122
Server time offset: 2
Last machine account password change: Ср, 20 мар 2024 11:13:27 EET

Получение информации об учетной записи компьютера:

# net ads status -U administrator

⁠6.19.4. adcli

adcli — инструмент для выполнения действий в домене Active Directory.

⁠

Таблица 6.31. Основные команды adcli

Команда	Описание
info домен	Вывести информацию о домене
join домен	Присоединить данную машину к домену (создает учетную запись компьютера в домене и настраивает keytab для этой машины. Не настраивает службу аутентификации, например, sssd)
update	Обновляет пароль учетной записи компьютера на контроллере домена для локальной машины, записывает новые ключи в keytab и удаляет старые ключи
testjoin	Проверить, действителен ли пароль учетной записи компьютера
create-user [--domain=домен] пользователь	Создать учетную запись пользователя
delete-user [--domain=домен] пользователь	Удалить учетную запись пользователя
passwd-user [--domain=домен] пользователь	Установить (повторно) пароль пользователя
create-group [--domain=домен] группа	Создать группу
delete-group [--domain=домен] группа	Удалить группу
add-member [--domain=домен] группа пользователь или компьютер…	Добавить пользователей в группу
remove-member [--domain=домен] группа пользователь…	Удалить пользователей из группы
preset-computer [--domain=домен] компьютер…	Предустановить учетные записи компьютеров (предварительно создает одну или несколько учетных записей компьютеров в домене, чтобы позже компьютеры могли использовать их при присоединении к домену. При этом, машины могут присоединяться с помощью одноразового пароля или автоматически без пароля)
reset-computer [--domain=домен] компьютер	Сбросить учетную запись компьютера (если соответствующая машина присоединена к домену, её членство будет нарушено)
delete-computer [--domain=домен] компьютер	Удалить учетную запись компьютера
show-computer [--domain=домен] компьютер	Показать атрибуты учетной записи компьютера, хранящиеся в AD
create-msa [--domain=домен]	Создать управляемую учетную запись службы (MSA) в заданном домене AD (это бывает нужно, если компьютер не должен присоединяться к домену Active Directory, но к нему необходим LDAP доступ)

Получить дополнительную информацию можно на справочной странице adcli(8) (man adcli).

Пример получения дополнительной информации о подкоманде:

# adcli testjoin --help

Получение информации о домене:

# adcli info test.alt
[domain]
domain-name = test.alt
domain-short = TEST
domain-forest = test.alt
domain-controller = dc1.test.alt
domain-controller-site = Default-First-Site-Name
domain-controller-flags = pdc gc ldap ds kdc timeserv closest writable good-timeserv full-secret
domain-controller-usable = yes
domain-controllers = dc1.test.alt dc2.test.alt
[computer]
computer-site = Default-First-Site-Name

Показать атрибуты учетной записи компьютера:

# adcli show-computer -D test.alt win2012
Password for Administrator@TEST.ALT:
sAMAccountName:
 WIN2012$
userPrincipalName:
 - not set -
msDS-KeyVersionNumber:
 1
msDS-supportedEncryptionTypes:
 28
dNSHostName:
 win2012.test.alt
servicePrincipalName:
 HOST/win2012.test.alt
 RestrictedKrbHost/win2012.test.alt
 HOST/WIN2012
 RestrictedKrbHost/WIN2012
 Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/win2012.test.alt
operatingSystem:
 Windows Server 2012 R2 Standard
operatingSystemVersion:
 6.3 (9600)
operatingSystemServicePack:
 - not set -
pwdLastSet:
 133294743593838200
userAccountControl:
 4096
description:
 - not set -

Создать группу testldap в подразделении OU:

# adcli create-group -D test.alt -O OU=OU,dc=test,dc=alt testldap
Password for Administrator@TEST.ALT:

⁠6.19.5. ldapsearch

ldapsearch — утилита для поиска информации в LDAP. Синтаксис:

ldapsearch <параметры> <фильтр> <атрибуты>

ldapsearch открывает соединение с сервером LDAP, подключается к нему и выполняет поиск с помощью фильтра.

Если утилита ldapsearch найдет одну или несколько записей, то значения указанных атрибутов этих записей будут переданы в стандартный поток вывода. Если в этом списке указан знак *, возвращаются все пользовательские атрибуты. Если в этом списке указан знак +, возвращаются все операционные атрибуты. Если атрибуты не указаны, то возвращаются все пользовательские атрибуты.

Результаты поиска отображаются в виде расширенной версии LDIF. Формат вывода контролируется с помощью параметра -L.

⁠

Таблица 6.32. Параметры команды ldapsearch

Параметр	Описание
Параметры поиска
-a {never\|always\|search\|find}	Задает способ преобразования псевдонимов. Может принимать значения: never (по умолчанию), always, search или find, указывающие, соответственно, что псевдонимы не преобразуются, преобразуются всегда, преобразуются при поиске, либо преобразуются только при определении базового объекта для поиска
-A	Получить только атрибуты (без значений)
-b basedn	Позволяет переопределить заданную по умолчанию начальную точку поиска
-c	Режим продолжения операции (не останавливать поиск при ошибках)
-E [!]ext[=extparam]	Указывает расширения поиска. Знак '!' обозначает критичность расширения. Общие расширения: [!]domainScope (диапазон домена) !dontUseCopy [!]mv=<filter> (RFC 3876 фильтр совпавших значений) [!]pr=<size>[/prompt\|noprompt] (RFC 2696 постраничный вывод результатов/запрос вывода) [!]sss=[-]<attr[:OID]>[/[-]<attr[:OID]>...] (RFC 2891 сортировка на стороне сервера) [!]subentries[=true\|false] (RFC 3672 подзаписи) [!]sync=ro[/<cookie>] (RFC 4533 LDAP Sync refreshOnly) [!]sync=rp[/<cookie>][/<slimit>] (LDAP Sync refreshAndPersist) [!]vlv=<before>/<after>(/<offset>/<count>\|:<value>) (ldapv3-vlv-09 вид виртуального списка) [!]deref=derefAttr:attr[,...][;derefAttr:attr[,...][;...]] [!]<oid>[=:<b64value>] (общий контроль; нет обработки ответа)
-f file	Считать серию строк из файла `file` и выполнить по одному поиску LDAP для каждой строки. В этом случае заданный в командной строке фильтр `filter` интерпретируется как шаблон, в котором первое и только первое вхождение `%s` заменяется строкой из файла `file`. Любые другие вхождения символа % в шаблоне будут рассматриваться как ошибка. Если требуется, чтобы в поисковом фильтре присутствовал символ %, он должен быть закодирован как \25 (смотрите RFC 4515). Если в качестве значения `file` указан символ «-», то строки считываются со стандартного ввода.
-F prefix	URL-префикс для временных файлов (по умолчанию: file://path, где `path` либо `/tmp/.private/<user>`, либо значение, указанное в параметре `-T`)
-l limit	Ограничение на время поиска (в секундах). Значение 0 (ноль) или none означает, что ограничений нет. Значение max означает максимальное допустимое протоколом значение (целое число)
-L[LL]	Управление выводом результатов поиска в формате обмена данными LDAP (LDAP Data Interchange Format): `-L` — вывести ответы в формате LDIFv1, `-LL` — отключить вывод комментариев, `-LLL` — отключить вывод версии LDIF.
-M[M]	Включить элемент управления Manage DSA IT. `-MM` делает этот элемент управления критичным.
-P {2\|3}	Версия протокола LDAP (по умолчанию 3)
-s {base\|one\|sub\|children}	Задает область поиска. Может принимать одно из следующих значений: base, one, sub (по умолчанию) или children, что означает поиск только по базовому объекту, на одном уровне, по всему поддереву и по дочерним записям соответственно
-S attr	Отсортировать возвращаемые записи по атрибуту `attr`. По умолчанию возвращаемые записи не сортируются. Если в качестве `attr` задана строка нулевой длины (""), записи сортируются по компонентам их уникального имени Distinguished Name. По умолчанию `ldapsearch` выводит записи по мере их получения. При использовании параметра `-S` все данные сначала получаются, потом сортируются, потом выводятся.
-t[t]	При указании одного `-t` полученные непечатаемые значения записываются в набор временных файлов (полезно при работе со значениями, содержащими несимвольные данные, такими как jpegPhoto или audio). При указании второго `-t` все полученные значения записываются в файлы.
-T path	Временные файлы записываются в указанный в `path` каталог (по умолчанию `/tmp/.private/<user>`)
-u	Включить в вывод форму удобного для пользователя имени (User Friendly Name, UFN) уникального имени (Distinguished Name, DN)
-z limit	Ограничить количество возвращаемых в результате поиска записей значением `limit`. Значение 0 (ноль) или none означает, что ограничений нет. Значение max означает максимальное допустимое протоколом значение (целое число).
Общие параметры
-d debuglevel	Установить уровень отладки LDAP
-D binddn	Использовать указанное в `binddn` уникальное имя Distinguished Name при подсоединении к каталогу LDAP. При SASL-подсоединениях сервер будет игнорировать это значение.
-e [!]ext[=extparam]	Указывает общие расширения. Знак '!' обозначает критичность расширения. Общие расширения: [!]assert=<filter> (RFC 4528; фильтр RFC 4515) [!]authzid=<authzid> (RFC 4370; "dn:<dn>" или "u:<user>") [!]chaining[=<resolveBehavior>[/<continuationBehavior>]] [!]manageDSAit (RFC 3296) [!]noop ppolicy [!]postread[=<attrs>] (RFC 4527; разделённый запятыми список атрибутов) [!]preread[=<attrs>] (RFC 4527; разделённый запятыми список атрибутов) [!]relax [!]sessiontracking abandon, cancel, ignore (сигнал SIGINT посылает abandon/cancel, либо в ответ на него посылается ignore; если расширение помечено как критичное, сигнал SIGINT не принимается; ненастоящие элементы управления
-h host	Сервер LDAP
-H URI	Указывает URI (возможно, несколько), ссылающийся на LDAP-сервер (серверы). В URI допускаются поля: протокол/хост/порт.
-I	Использовать интерактивный режим SASL.
-n	Демонстрируется, что будет сделано, но реальный поиск не выполняется. Используется для отладки совместно с параметром `-v`
-N	Не использовать обратное разрешение DNS для получения канонического имени хоста SASL.
-O props	Параметры безопасности SASL
-o opt[=optparam]	Указывает опции общего назначения. Возможные опции: nettimeout=<timeout> (в секундах, либо «none» или «max») ldif-wrap=<width> (в символах, либо «no» для предотвращения переноса строк)
-p порт	Порт, на котором сервер LDAP принимает запросы. Номер порта по умолчанию — 389. Если номер порта не задан, и указан параметр `-Z`, то применяется номер порта LDAP SSL по умолчанию, равный 636.
-Q	Использовать тихий режим SASL. Запросы не выводятся никогда.
-R realm	Задаёт realm аутентификационного идентификатора для SASL. Форма realm зависит от того, какой механизм аутентификации в действительности используется.
-U authcid	Идентификатор аутентификации SASL. Форма идентификатора зависит от того, какой механизм аутентификации в действительности используется.
-v	Запустить в подробном режиме (диагностические сообщения посылаются в стандартный вывод)
-V[V]	Вывести информацию о версии. При указании `-VV`, после вывода информации о версии осуществляется выход. При указании `-V`, после вывода информации о версии выполняется поиск согласно заданным критериям.
-w passwd	Использовать указанное значение `passwd` в качестве пароля для простой аутентификации.
-W	Запрашивать ввод пароля для простой аутентификации (используется для того, чтобы не указывать пароль в командной строке).
-x	Использовать простую аутентификацию
-X authzid	Идентификатор авторизации SASL ("dn:<dn>" или "u:<user>")
-y file	Считать пароль из файла `file`. В качестве пароля используется всё содержимое файла. Поэтому файл не должен содержать символа переноса строки.
-Y mech	Задаёт механизм SASL, который будет использоваться для аутентификации. Если параметр не указан, программа выберет лучший из известных серверу механизмов.
-Z[Z]	Запустить запрос TLS (`-ZZ` для запроса успешного ответа)

⁠6.19.5.1. Фильтр

Фильтр должен быть указан в строковом формате фильтров LDAP (см. RFC 4515). Если фильтр не указан, используется фильтр по умолчанию (objectClass=*).

Синтаксис LDAP-фильтра имеет вид:

<Атрибут><оператор сравнения><значение>

Вместо имени атрибута можно использовать его идентификатор (Attribute-Id). Тело фильтра должно быть заключено в скобки.

⁠

Таблица 6.33. Примеры LDAP-фильтров

Запрос	LDAP фильтр
Все пользователи:	(sAMAccountType=805306368)
Отключенные (Disabled) пользователи:	(&(sAMAccountType=805306368)(useraccountcontrol:1.2.840.113556.1.4.803:=2))
Заблокированные (Locked) пользователи:	(&(sAMAccountType=805306368)(badPwdCount>=4))
Пользователи, у которых в настройках указано «Пароль никогда не истекает»	(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=65536))
Пользователи которые не меняли пароль с 5 мая 2023 года (см. https://www.epochconverter.com/ldap для преобразования даты во временную метку Windows)	(&(objectCategory=person)(pwdLastSet<=133278047990000000))
Пользователи с незаполненным полем mail	(&(objectCategory=group)(!(mail=*)))
Пользователи, которые должны сменить пароль при следующем входе в систему	(&(sAMAccountType=805306368)(pwdLastSet=0))
Пользователи с ограниченным сроком действия учетной записи	(&(sAMAccountType=805306368)(accountExpires>=1)(accountExpires<=9223372036854775806))
Пользователи, созданные за определенный период (формат даты: YYYY MM DD HH mm ss.s Z)	(&(sAMAccountType=805306368)(whenCreated>=20230401000000.0Z<=20230701000000.0Z))
Все компьютеры	(objectCategory=computer)
Все контроллеры домена	(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=8192))
Контроллеры домена, доступные только для чтения	(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=67108864))
Группы, в которых нет пользователей	(&(objectCategory=group)(!(member=*)))
Группы, с ключевым словом admin в имени	(&(objectCategory=group)(samaccountname=admin))
Все группы безопасности (Security)	(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648))
Все члены группы Sales (без учёта вложенности)	(memberOf=CN=Sales,CN=Users,DC=test,DC=alt)
Все члены группы Sales (с учётом вложенности)	(memberOf:1.2.840.113556.1.4.1941:=CN=Sales,CN=Users,DC=test,DC=alt)
Все группы, в которые входит пользователь testldap	(&(objectCategory=group)(member=CN=testldap,CN=Users,DC=test,DC=alt)))
Все подразделения (OU)	(objectCategory=organizationalUnit)
Все объекты групповой политики	(objectCategory=groupPolicyContainer)
Все отношения доверия	(objectClass=trustedDomain)
Объекты связанные с ролями FSMO	(fsMORoleOwner=*)
PDC Emulator	(&(objectClass=domainDNS)(fSMORoleOwner=*))
RID Master	(&(objectClass=rIDManager)(fSMORoleOwner=*))
Объект AD с определенным SID	(objectSID=S-1-5-21-1723588197-2340999690-1379671080-1105)

⁠6.19.5.2. Формат вывода

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

Отличительное имя (DN)
имя_атрибута: значение
имя_атрибута: значение
имя_атрибута: значение
…

Записи разделяются пустыми строками.

Если задан параметр -t вместо реальных значений атрибутов будут выводиться URI временных файлов, в которые эти значения помещаются. Если задан параметр -A будут выводиться только имена атрибутов.

Примечание

Значение атрибута записывается в 7-битной кодировке ASCII и отделяется от его имени символом «:». Значения, не подходящие под эту кодировку, записываются в кодировке base64 и отделяются от имени атрибута символами «::»:

имя_атрибута:: base64_значение_атрибута

Например:

dn:: Q0490JfQsNC50YbQtdCy0LAg0J7Qu9GM0LPQsCxDTj1Vc2VycyxEQz10ZXN0LERDPWFsdA==
cn:: 0JfQsNC50YbQtdCy0LAg0J7Qu9GM0LPQsA==

…
$  echo "0JfQsNC50YbQtdCy0LAg0J7Qu9GM0LPQsA==" | base64 -d 
Зайцева Ольга

Чтобы отобразить строки в кодировке base64 можно использовать следующую команду:

$ ldapsearch -LLL -D testldap@test.alt -x -W | perl -MMIME::Base64 -MEncode=decode -n -00 -e 's/\n
+//g;s/(?<=:: )(\S+)/decode("UTF-8",decode_base64($1))/eg;print'

⁠6.19.5.3. Примеры

Вывести всех пользователей, фамилия которых начинается с буквы «К»:

$ ldapsearch -LLL -H ldap://192.168.0.122:389 \
-D testldap@test.alt -b "dc=test,dc=alt" \
-x -W "(&(sAMAccountName=*)(sn=К*))" cn sn

где:

-H ldap://192.168.0.122:389 — сервер LDAP;
-D testldap@test.alt — пользователь с правом чтения в каталоге LDAP;
-b "dc=test,dc=alt" — контейнер AD, в котором будет выполняться поиск;
-x — использовать простую аутентификацию;
-W — спросить пароль;
"(&(sAMAccountName=*)(sn=К*))" — выражение, по которому будут отфильтрованы результаты;
cn sn — поля, которые необходимо вывести.

Параметры по умолчанию можно задать в файле /etc/openldap/ldap.conf, например:

BASE    dc=test,dc=alt
URI     ldap://dc1.test.alt

Команда с использованием базы поиска и URI по умолчанию:

$ ldapsearch -LLL -D testldap@test.alt \
-x -W "(&(sAMAccountName=*)(sn=К*))" cn sn

Вывести фамилию и электронную почту всех пользователей, из подразделения OU, у которых непустое поле mail:

$ ldapsearch -LLL -H ldap://192.168.0.122:389 \
-D testldap@test.alt -b "ou=OU,dc=test,dc=alt" -s one \
-x -W "(&(sAMAccountName=*)(mail=К*))" sn mail

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

Считать последовательность строк из файла new.filter и выполнить функцию поиска LDAP для каждой строки:

$ ldapsearch -H ldap://192.168.0.122:389 \ -D testldap@test.alt -b "dc=test,dc=alt" -x -W -f new.filter "(samaccountname=%s)" cn

Содержимое файла new.filter:

z*
ivanov
k*
*k

Команда выполняет поиск по поддереву для каждого фильтра, начиная с samaccountname=z*. Когда этот поиск завершается, начинается поиск для фильтра cn=ivanov и т.д. Пример вывода вышеуказанной команды с параметром -n:

 LDAPv3
# base <dc=test,dc=alt> with scope subtree
# filter pattern: (samaccountname=%s)
# requesting: dn
#

#
# filter: (samaccountname=z*)
#

#
# filter: (samaccountname=ivanov)
#

#
# filter: (samaccountname=k*)
#

#
# filter: (samaccountname=*k)
#

⁠6.19.6. sssctl

sssctl — это инструмент командной строки, который предоставляет унифицированный способ получения информации о состоянии Security System Services Daemon (SSSD).

Утилиту sssctl можно использовать для сбора следующей информации:

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

С помощью утилиты sssctl можно:

управлять кешем SSSD;
управлять журналами;
проверить конфигурационные файлы.

⁠

Таблица 6.34. Основные команды sssctl

Команда	Описание
Статус SSSD
domain-list	Вывести список доступных доменов
domain-status домен	Вывести информацию о домене
user-checks пользователь	Вывести информацию о пользователе и проверить аутентификацию
access-report домен	Создать отчёт о правилах управления доступом, которые применяются к клиентскому компьютеру (работает только для домена FreeIPA)
Информация о кешированном содержимом
user-show пользователь	Информация о кеше пользователя
group-show группа	Информация о кеше группы
netgroup-show группа	Информация о кеше сетевой группы
Инструменты для работы с локальными данными
client-data-backup	Резервное копирование локальных данных
client-data-restore	Восстановление локальных данных из резервной копии
cache-remove	Резервное копирование локальных данных и удаление кешированного содержимого
cache-upgrade	Выполнить обновление кеша
cache-expire	Сделать недействительными кешированные объекты
cache-index действие	Управление индексами кеша
Инструменты для управления журналированием
logs-remove	Удалить существующие файлы журналов SSSD
logs-fetch файл	Архивировать файлы журналов SSSD в tarball
debug-level [уровень]	Изменить или вывести уровень журналирования SSSD
analyze	Анализ зарегистрированных данных
Инструменты для проверки файлов конфигурации
config-check	Выполнить статический анализ конфигурации SSSD
Инструменты, связанные с сертификатом
cert-show сертификат	Вывести информацию о сертификате
cert-map сертификат	Показать пользователей, привязанных к сертификату

Получить дополнительную информацию можно на справочной странице sssctl(8) (man sssctl).

Пример получения дополнительной информации о подкоманде:

# sssctl user-show --usage

или:

# sssctl user-show --help

Получение информации о домене:

# sssctl domain-status TEST.ALT
Online status: Online

Active servers:
AD Global Catalog: dc1.test.alt
AD Domain Controller: dc1.test.alt

Discovered AD Global Catalog servers:
- dc1.test.alt

Discovered AD Domain Controller servers:
- dc1.test.alt

Показать информацию о кеше пользователя:

# sssctl user-show kim
Name: kim
Cache entry creation date: 03/27/24 20:57:31
Cache entry last update time: 06/03/24 16:49:12
Cache entry expiration time: 06/03/24 18:19:12
Initgroups expiration time: 06/03/24 18:19:12
Cached in InfoPipe: N

Показать данные авторизации пользователя:

# sssctl user-checks kim
user: kim
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: kim
 - user id: 1939201105
 - group id: 1939200513
 - gecos: Олег Ким
 - home directory: /home/TEST.ALT/kim
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: kim
 - uidNumber: 1939201105
 - gidNumber: 1939200513
 - gecos: Олег Ким
 - homeDirectory: not set
 - loginShell: not set

testing pam_acct_mgmt

pam_acct_mgmt: Success

PAM Environment:
 - no env -

⁠6.19.7. testparm

С помощью команды testparm можно проверить содержимое файла конфигурации /etc/samba/smb.conf.

Пример проверки настройки Samba:

$ testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed

Server role: ROLE_ACTIVE_DIRECTORY_DC

Press enter to see a dump of your service definitions

# Global parameters
[global]
    dns forwarder = 8.8.8.8
    ldap server require strong auth = No
    passdb backend = samba_dsdb
    realm = TEST.ALT
    server role = active directory domain controller
    workgroup = TEST
    rpc_server:tcpip = no
    rpc_daemon:spoolssd = embedded
    rpc_server:spoolss = embedded
    rpc_server:winreg = embedded
    rpc_server:ntsvcs = embedded
    rpc_server:eventlog = embedded
    rpc_server:srvsvc = embedded
    rpc_server:svcctl = embedded
    rpc_server:default = external
    winbindd:use external pipes = true
    idmap_ldb:use rfc2307 = yes
    idmap config * : backend = tdb
    map archive = No
    vfs objects = dfs_samba4 acl_xattr

[dfs]
    msdfs root = Yes
    path = /media/dfsroot

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

[netlogon]
    path = /var/lib/samba/sysvol/test.alt/scripts
    read only = No

[free]
    guest ok = Yes
    path = /mnt/win/free
    read only = N

⁠6.20. Конфигурационные файлы

⁠6.20.1. smb.conf

/etc/samba/smb.conf — файл конфигурации Samba.

⁠6.20.2. krb5.conf

/etc/krb5.conf — файл конфигурации Kerberos.

⁠6.20.3. sssd.conf

/etc/sssd/sssd.conf — файл конфигурации SSSD.

Для работы с Active Directory в SSSD имеется специальный AD-провайдер sssd-ad.

Минимальный конфигурационный файл (/etc/sssd/sssd.conf) для sssd-ad:

[sssd]
config_file_version = 2
services = nss, pam

# Managed by system facility command:
## control sssd-drop-privileges unprivileged|privileged|default
user = _sssd

# SSSD will not start if you do not configure any domains.

domains = TEST.ALT
[nss]

[pam]
[domain/TEST.ALT]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
debug_level = 0
;cache_credentials = true
ad_gpo_ignore_unreadable = true
ad_gpo_access_control = permissive
ad_update_samba_machine_account_password = true

Получить подробную информацию можно на справочной странице sssd.conf(5) (man sssd.conf).

⁠6.20.4. resolv.conf

/etc/resolv.conf — файл конфигурации ресолвера (механизма преобразования имен хостов в адреса IP).

Файл конфигурации ресолвера (resolver) содержит информацию, которая считывается функциями разрешения имён при первом их вызове процессом. Файл разработан в удобочитаемом формате, и содержит список ключевых слов со значениями, которые предоставляют различного рода информацию для функций разрешения имён. Файл настройки считается надёжным источником информации DNS (например, информация об AD-бите DNSSEC будет возвращаться в неизменном виде из этого источника).

Если этот файл не существует, то будет опрашиваться только служба имён на локальной машине; доменное имя определяется из имени узла, а список поиска будет содержать это доменное имя.

Обычно в файле /etc/resolv.conf указан как минимум 1 сервер имен, на который будут перенаправляться все DNS запросы:

# Generated by resolvconf
# Do not edit manually, use
# /etc/net/ifaces/<interface>/resolv.conf instead.
nameserver 192.168.197.241

Важно

Файл /etc/resolv.conf не должен редактироваться. Его автоматически генерирует resolvconf. Редактировать можно файл /etc/net/ifaces/<interface>/resolv.conf

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

nameserver IP-адрес сервера имён

Интернет-адрес сервера имён, на который надо переправлять все запросы, либо адрес IPv4 (в точечной нотации), либо адрес IPv6 в нотации с двоеточием (и, возможно, с точками) в соответствии с RFC 2373. Может быть указано до MAXNS (в настоящее время 3) серверов имён, ключевое слово должно быть указано для каждого сервера. Если указано несколько серверов, библиотека распознавателя запрашивает их в указанном порядке. Если в файле нет строк nameserver, по умолчанию используется сервер имён на локальном компьютере. Используемый алгоритм заключается в том, чтобы попробовать обратиться к первому указанному серверу имён, и, если время ожидания запроса истекло, попробовать обратиться к следующему серверу, и т.д. пока не будет исчерпан список серверов, а затем повторять попытки, пока не будет сделано максимальное количество повторных попыток.

options

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

options параметр …

где параметр может иметь следующие значения:

attempts:n: Задаёт количество попыток, которое преобразователь предпримет, отправляя запрос на свои серверы имён, прежде чем закончить работу и вернуть ошибку. По умолчанию используется RES_DFLRETRY (в настоящее время равно 2). Значение этого параметра скрыто ограничено числом 5.
debug: Устанавливает RES_DEBUG в _res.options (эффективно, только если glibc был собран с поддержкой отладки; см. resolver(3)).
edns0 (начиная с glibc 2.6): Задаёт значение RES_USE_EDNSO в _res.options. Включает поддержку расширений DNS, описанных в RFC 2671.
inet6: Задаёт значение RES_USE_INET6 в _res.options. Это приводит к выполнению запроса AAAA перед запросом A внутри функции gethostbyname(3), и отображению ответов IPv4 в «туннелированной форме» IPv6, если записи AAAA не были найдены, но существует набор записей A. Начиная с glibc 2.25, эта опция устарела; приложения должны использовать getaddrinfo(3), а не gethostbyname(3).
ip6-bytestring (с glibc 2.3.4 до glibc 2.24): Задаёт значение RES_USE_BSTRING в _res.options. Это приводит к поиску обратной записи IPv6, с использованием формата значимых битов, описанного в RFC 2673; если этот параметр не установлен (по умолчанию), то используется формат полубайта. Эта опция была удалена в glibc 2.25, так как она полагалась на несовместимое с предыдущими версиями расширение DNS.
ip6-dotint/no-ip6-dotint (с glibc 2.3.4 до glibc 2.24): Устанавливает/сбрасывает значение RES_NOIP6DOTINT в _res.options. Если указан сброс (ip6-dotint), то выполняется поиск обратной записи IPv6 в зоне ip6.int; если задана установка (no-ip6-dotint), то по умолчанию выполняется поиск обратной записи IPv6 в зоне ip6.arpa. Эти параметры доступны в версиях glibc до 2.24, где по умолчанию используется no-ip6-dotint. Поскольку ip6-dotint перестала поддерживаться, эти опции были удалены в glibc 2.25.
ndots:n: Задаёт минимальное количество точек, которые должны обязательно присутствовать в имени, переданном функции res_query(3) (см. resolver(3)), прежде чем будет сделан первоначальный абсолютный запрос. По умолчанию n равно 1, поэтому если в имени есть точки, сначала имя пытаются разрешить как абсолютное, прежде чем добавлять к нему элементы из списка поиска. Значение этой опции скрыто ограничено числом 15.
no-check-names: Задаёт значение RES_NOCHECKNAME в _res.options, что приводит к отключению в современном BIND проверки в поступающих именах узлов и почтовых именах недопустимых символов, таких как символы подчёркивания (_), не-ASCII или управляющие символы.
no-reload (начиная с glibc 2.16): Задаёт значение RES_NORELOAD в _res.options. Эта опция отключает автоматическую перезагрузку измененного файла конфигурации.
no-tld-query (начиная с glibc 2.14): Задаёт значение RES_NOTLDQUERY в _res.options. Этот параметр указывает res_nsearch() не пытаться разрешить неполное имя, как если бы оно было доменом верхнего уровня. Данный параметр может привести к проблемам, если в качестве TLD указано «localhost», а не localhost в одном или более элементах списка поиска. Данный параметр не действует, если не установлен RES_DEFNAMES или RES_DNSRCH.
rotate: Задаёт значение RES_ROTATE в _res.options, что приводит к циклическому выбору указанных серверов имён. Без этой опции распознаватель всегда будет запрашивать первый сервер имён в списке и использовать последующий сервер имён только в случае сбоя первого. Эта опция позволяет распределить нагрузку между разными серверами имён.
single-request-reopen (начиная с glibc 2.9): Задаёт RES_SNGLKUPREOP в _res.options. Для разрешения имён используется единый сокет для запросов A и AAAA. Некоторое оборудование ошибочно возвращает только один ответ. Когда это происходит, клиент продолжает ждать второго ответа.
Указание этого параметра изменяет это поведение так, что если два запроса с одного порта не обрабатываются правильно, то сокет будет закрыт и открыт новый перед посылкой второго запроса.
single-request (начиная с glibc 2.10): Задаёт значение RES_SNGLKUP в _res.options. По умолчанию, glibc начиная с версии 2.9 выполняет поиск по IPv4 и IPv6 параллельно.
Некоторые приложения DNS-серверов не могут обработать такие запросы должным образом и делают паузу между ответами на запрос. Этот параметр отключает данное поведение, что заставляет glibc делать запросы IPv6 и IPv4 последовательно (за счет некоторого замедления процесса разрешения имени).
timeout:n: Задаёт промежуток времени, который функции определения имён будут ждать ответа от удалённого сервера имён перед тем как повторить запрос другому серверу имён. Это время может не совпадать с общим временем, затраченным на любой вызов API-интерфейса преобразователя, и нет гарантии, что один вызов API-интерфейса преобразователя соответствует одному тайм-ауту. Измеряется в секундах, значение по умолчанию — RES_TIMEOUT (в настоящее время равно 5). Значение этой опции скрыто ограничено числом 30.
trust-ad (начиная с glibc 2.31): Задаёт значение RES_TRUSTAD в _res.options. Этот параметр управляет поведением бита AD распознавателя-заглушки. Если проверяющий преобразователь устанавливает в ответе бит AD, это означает, что данные в ответе были проверены в соответствии с протоколом DNSSEC. Чтобы полагаться на бит AD, локальная система должна доверять как распознавателю, проверяющему DNSSEC, так и сетевому пути к нему, поэтому требуется явное согласие. Если активна опция trust-ad, тупиковый распознаватель устанавливает бит AD в исходящих DNS-запросах (чтобы включить поддержку бита AD) и сохраняет бит AD в ответах. Без этой опции бит AD в запросах не устанавливается и всегда удаляется из ответов, прежде чем они будут возвращены приложению. Это означает, что приложения могут доверять биту AD в ответах, если параметр trust-ad установлен правильно.
В glibc версии 2.30 и более ранних AD не устанавливается автоматически в запросах и без изменений передается приложениям в ответах.
use-vc (начиная с glibc 2.14): Задаёт значение RES_USEVC в _res.options. Данный параметр включает принудительное использование TCP для запросов DNS.

search список поиска

По умолчанию список поиска содержит одну запись — имя локального домена. Он определяется по локальному имени хоста, возвращаемому функцией gethostname(2); локальным доменным именем считается всё, что следует после первого знака «.». Если имя хоста не содержит «.», предполагается, что корневой домен является именем локального домена.

Это поведение можно изменить, перечислив имена доменов, в которых нужно вести поиск, после ключевого слова search через пробел или символ табуляции. При разрешении запросов имён, в которых меньше точек чем указано в ndots (по умолчанию 1), будет использован каждый компонент пути поиска пока не будет найдено соответствующее имя. Для сред с несколькими субдоменами см. параметры ndots:n, чтобы избежать атак типа «человек посередине» и ненужного трафика для корневых DNS-серверов. Обратите внимание, что этот процесс может быть медленным и будет генерировать много сетевого трафика, если серверы для перечисленных доменов не являются локальными, и что время ожидания запросов истечет, если сервер для одного из доменов недоступен.

При наличии нескольких директив search используется только список поиска из последнего экземпляра.

Список поиска может содержать не более шести доменов и не может быть длиннее 256 символов. В glibc 2.25и более ранних версиях список поиска мог содержать не более шести доменов и не мог быть длиннее 256 символов. Начиная с glibc 2.26 список поиска не ограничен.

Директива domain — это устаревшее название директивы search, которая обрабатывает только одну запись в списке поиска.

sortlist

Позволяет сортировать адреса, возвращаемых функцией gethostbyname(3). Список сортировки задается в виде пар IP-адрес/сетевая маска. Маску сети указывать не обязательно, по умолчанию используется естественная маска сети. IP-адрес и маска сети разделяются косой чертой. В списке можно указывать до 10 пар. Пример:

sortlist 130.155.160.0/255.255.240.0 130.155.0.0

Ключевое слово search системного файла resolv.conf можно переопределить для каждого процесса, задав для переменной среды LOCALDOMAIN список доменов поиска, разделенных пробелами.

Ключевое слово options системного файла resolv.conf можно переопределить для каждого процесса, задав для переменной среды RES_OPTIONS список параметров преобразователя, разделенных пробелами.

Любые изменения, внесенные вручную в файл конфигурации /etc/resolv.conf, обязательно будут перезаписаны при изменениях в сети или перезагрузке системы.

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

Строки, начинающиеся с точки с запятой (;) или решетки (#), считаются комментариями.

Resolvconf – это платформа для обновления системной информации о серверах DNS. Он настраивается как посредник между программами, которые предоставляют эту информацию и программами, которые используют эту информацию.

Обновить файл /etc/resolv.conf, чтобы внести изменения в DNS:

# resolvconf -u

Пример файла /etc/resolv.conf:

search test.alt example.test
nameserver 192.168.0.122
nameserver 8.8.8.8

Запись search позволяет использовать в качестве адреса только xocт-имя для компьютеров в домене test.alt. Например, чтобы обратиться системе work.test.alt, пользователь должен ввести в качестве адреса только хост-имя, work. Когда преобразователь пытается разрешить доменное имя, например, work, он сначала формирует полное доменное имя, используя имя домена test.alt, в work.test.alt и выполняет DNS-запрос, используя это полное доменное имя. Если это не удается, то преобразователь пробует следующий в очереди домен и запрашивает IP-адрес work.example.test.

При этом, когда преобразователь пытается разрешить доменное имя work.ru, он сначала запросит work.ru как абсолютное доменное имя. Если DNS не сможет разрешить его, то только тогда преобразователь объединит его с поисковым доменом, чтобы сформировать work.ru.test.alt, и повторит запрос.

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

⁠6.20.5. Bind

Основные файлы настройки DNS:

/etc/named.conf — основной файл конфигурации, содержит в себе ссылки на остальные конфигурационные файлы;
/etc/bind/options.conf — файл для глобальных настроек службы;
/etc/bind/rndc.conf — получить информацию DNS об удаленном сервере;
/etc/bind/local.conf — файл для настроек зоны DNS;
/var/lib/samba/bind-dns/named.conf — инструмент для динамического обновления записей DNS.

Конфигурационный файл BIND 9 состоит из разделов, операторов и комментариев. Правила синтаксиса файла named.conf:

список IP должен быть разделен символом «;», можно указывать подсеть в формате 192.168.0.1/24 или 192.168.0.1/255.255.255.0, (для исключения IP-адреса перед ним нужно поставить знак !);
строки начинающиеся с символа «#», «//» и заключенные в «/*» и «*/» считаются комментариями;
в файлах описания зон символ @ является переменной, хранящей имя зоны, указанной в конфигурационном файле named.conf или в директиве @ $ORIGIN текущего описания зоны;
каждая завершенная строка параметров должна завершаться символом «;».

В таблице Разделы конфигурационного файла bind приведены некоторые разделы файла конфигурации.

⁠

Таблица 6.35. Разделы конфигурационного файла bind

Раздел	Описание
`acl`	Позволяет задать именованный список сетей. Формат раздела: acl имя_сети {ip; ip; ip; };
`controls`	Объявляет каналы управления, которые будут использоваться утилитой rndc
`dnssec-policy`	Описывает ключ DNSSEC и политику подписи для зон
`key`	Указывает ключевую информацию для использования при аутентификации и авторизации с использованием TSIG
`:any:key-store`	Описывает хранилище ключей DNSSEC
`logging`	Указывает, какую информацию регистрирует сервер и куда отправляются сообщения журнала
`options`	Задает глобальные параметры конфигурационного файла, управляющие всеми зонами
`parental-agents`	Определяет именованный список серверов для включения в списки родительских агентов основной и дополнительной зон
`primaries`	Определяет именованный список серверов для включения в основные и дополнительные зоны или списки уведомлений
`server`	Устанавливает определенные параметры конфигурации для каждого сервера
`tls`	Указывает информацию о конфигурации для соединения TLS
`http`	Указывает информацию о конфигурации для HTTP-соединения
`trust-anchors`	Определяет якоря доверия DNSSEC: при использовании с ключевым словом Initial-key или Initial-ds якоря доверия поддерживаются в актуальном состоянии с помощью обслуживания якоря доверия RFC 5011; при использовании со static-key или static-ds ключи являются постоянными.
`zone`	Определяет описание зон(ы)

В таблице Основные параметры конфигурационного файла bind описаны некоторые параметры файла /etc/bind/options.conf. Для получения более подробной информации следует обратиться к man странице named.conf(5).

⁠

Таблица 6.36. Основные параметры конфигурационного файла bind

Опция	Описание
`directory`	Указывает каталог расположения таблиц зон
`listen-on`	Определяет адреса IPv4, на которых сервер прослушивает DNS-запросы
`listen-on-v6`	Определяет адреса IPv6, на которых сервер прослушивает DNS-запросы
`allow-query`	IP-адреса и подсети, от которых будут обрабатываться запросы. Если параметр не задан, сервер отвечает на все запросы
`allow-transfer`	Устанавливает возможность передачи зон для slave-серверов
`allow-query-cache`	IP-адреса и подсети, которые могут получить доступ к кешу этого сервера
`allow-recursion`	IP-адреса и подсети, от которых будут обрабатываться рекурсивные запросы (для остальных будут выполняться итеративные запросы). Если параметр не задан, сервер выполняет рекурсивные запросы для всех сетей
`pid-file`	Указывает путь к файлу, в который сервер записывает идентификатор процесса
`tkey-gssapi-keytab`	Устанавливает файл таблицы ключей KRB5, который будет использоваться для обновлений GSS-TSIG. Это файл таблицы ключей KRB5, который можно использовать для обновлений GSS-TSIG. Если этот параметр установлен, а `tkey-gssapi-credential` не установлен, обновления разрешены с любым ключом, соответствующим участнику в указанной вкладке ключей
`minimal-responses`	Контролирует, добавляет ли сервер записи в разделы полномочий и дополнительных данных. При значении yes сервер добавляет записи в авторитетные и дополнительные разделы только тогда, когда такие записи требуются протоколом DNS (например, при возврате делегирования или отрицательных ответах). Это обеспечивает лучшую производительность сервера, но может привести к увеличению количества клиентских запросов
`max-cache-ttl`	Указывает максимальное время (в секундах), в течение которого сервер кеширует обычные (положительные) ответы. Максимальный срок кеша по умолчанию — 04800 (одна неделя)
`forward`	Позволяет указать каким образом сервер обрабатывает запрос клиента. При значении first DNS-сервер будет пытаться разрешать имена с помощью DNS-серверов, указанных в параметре forwarders. Если разрешить имя с помощью данных серверов не удалось, то попытаться разрешить имя самостоятельно. Если указать значение none, сервер не будет пытаться разрешить имя самостоятельно
`forwarders`	DNS-сервер, на который будут перенаправляться запросы клиентов
`dnssec-validation`	Включает проверку DNSSEC в именованных файлах. Если установлены значения auto (по умолчанию) и yes, проверка DNSSEC включена. Если установлено значение no, проверка DNSSEC отключена
`type`	Указывает тип зоны, описываемой в текущем разделе. Тип зоны может принимать следующие значения: forward — указывает зону переадресации, которая переадресовывает запросы, пришедшие в эту зону; hint — указывает вспомогательную зону (данный тип содержит информацию о корневых серверах, к которым сервер будет обращаться в случае невозможности найти ответ в кеше); master — указывает работать в качестве мастер сервера для текущей зоны; slave — указывает работать в качестве подчиненного сервера для текущей зоны.

⁠Глава 7. Решение проблем

7.1. Диагностика

7.1.1. Инструмент диагностики состояния контроллера домена
7.1.2. Инструмент диагностики клиента домена
7.1.3. ALT Diagnostic Tool

⁠7.1. Диагностика

⁠7.1.1. Инструмент диагностики состояния контроллера домена

diag-domain-controller — инструмент диагностики состояния контроллера домена.

diag-domain-controller содержит набор проверок и тестов, по результатам которых можно определить корректность настроек компьютера для работы в качестве контроллера домена. diag-domain-controller имеет модульную структуру. Модули можно вызывать общим списком или отдельно.

Установка:

# apt-get install diag-domain-controller

Синтаксис:

diag-domain-controller [options] [<diagnostic-task>]

где diagnostic-task — название функции из списка тестов. Если не указывать название функции, будут запущены все тесты.

Возможные опции:

-l, --list — вывести список тестов;
-V, --version — вывести версию и выйти;
-h, --help — показать справку и выйти.

Возможные состояния тестов:

DONE — успешное выполнение модуля;
WARN — предупреждение для некритических тестов в модуле;
FAIL — неудачное выполнение теста.

В таблице Тесты diag-domain-controller приведены тесты, доступные в diag-domain-controller в настоящее время.

⁠

Таблица 7.1. Тесты diag-domain-controller

Тест	Описание
is_domain_info_available	Проверка доступности просмотра общей информации о домене
is_hostname_correct	Проверка правильного написания доменного имени узла
is_not_empty_sysvol	Проверяет, содержит ли файлы каталог sysvol
is_samba_package_installed	Проверяет, установлен ли в системе пакет Samba (samba-dc или samba-dc-mitkrb5)
is_samba_service_running	Проверяет, запущена ли служба Samba
are_there_errors_in_samba_databases	Проверяет наличие ошибок в базах Samba
is_ntp_service_running	Проверяет, включена ли синхронизация времени

Примеры (команды запускаются на контроллере домена):

вывести список тестов:

$ diag-domain-controller -l
is_domain_info_available
is_hostname_correct
is_not_empty_sysvol
is_samba_package_installed
is_samba_service_running
are_there_errors_in_samba_databases
is_ntp_service_running

запустить тест is_domain_info_available:

$ diag-domain-controller is_domain_info_available
is_domain_info_available
[DONE]: is_domain_info_available

запустить все тесты:

$ diag-domain-controller
[DONE]: is_domain_info_available
[DONE]: is_hostname_correct
[DONE]: is_not_empty_sysvol
[DONE]: is_samba_package_installed
[DONE]: is_samba_service_running
[FAIL]: are_there_errors_in_samba_databases
[WARN]: is_ntp_service_running

⁠7.1.2. Инструмент диагностики клиента домена

diag-domain-client — инструмент диагностики состояния клиента домена.

diag-domain-client содержит набор проверок и тестов, по результатам которых можно определить корректность настроек компьютера для работы в домене, а также убедиться, что доступны все необходимые ресурсы домена. diag-domain-client имеет модульную структуру. Модули можно вызывать общим списком или отдельно.

Утилита позволяет записать результат в log-файл. Процесс диагностики зависит от того, находится ли компьютер в домене или нет. Выполнение некоторых проверок требует полномочий суперпользователя. Для корректной работы необходимо получить Kerberos-билет доменного пользователя.

Установка:

# apt-get install diag-domain-client

Синтаксис:

diag-domain-client [options] [<test-function-name>]

где test-function-name — название функции из списка тестов. Если не указывать название функции, будут запущены все тесты.

Возможные опции:

-h, --help — показать справку и выйти;
-V, --version — вывести версию и выйти;
-v, --verbose — подробный вывод;
-w[FILE], --logfile[=FILE] — записать подробный вывод в файл по указанному пути. Если файл не указан, вывод будет записан в файл ./diag-domain-client.log. В случае если файл уже существует, то запись производится в файл с постфиксом (например, diag-domain-client.log.1, diag-domain-client.log.2 и т.д.);
-f, --force — принудительная запись в существующий файл;
-l, --list — вывести список тестов.

Возможные состояния тестов:

DONE — успешное выполнение модуля;
SKIP — пропуск проверки, если проверка выполняется без полномочий суперпользователя;
WARN — предупреждение для некритических тестов в модуле;
FAIL — неудачное выполнение теста.

Если компьютер введен в домен, утилита diag-domain-client выдаёт FAIL для тех проверок, когда несоответствие проверяемого элемента приводит к неработоспособности машины в домене. При выполнении программы не суперпользователем некоторые проверки могут быть пропущены (SKIP) или находиться в состоянии WARN. В случае успешного выполнения отображается статус DONE.

В таблице Тесты и проверки diag-domain-client приведены тесты и проверки, доступные в diag-domain-client в настоящее время.

⁠

Таблица 7.2. Тесты и проверки diag-domain-client

Тест/Проверка	Описание
check_hostnamectl	Отображает полную информацию о узле и соответствующие настройки: имя, значок, система, версия ядра, архитектура, информация о виртуализации (при наличии)
test_hostname	Проверяет, является ли имя компьютера полностью определенным именем домена (FQDN)
check_system_auth	Отображает метод аутентификации пользователей, используемый в подсистеме PAM (sss, winbind — компьютер введен в домен, local — не введен). Выводит содержимое файла `/etc/pam.d/system-auth`
is_samba_package_installed	Проверяет, установлен ли в системе пакет Samba (samba-dc или samba-dc-mitkrb5)
test_domain_system_auth	Проверяет, подходит ли метод аутентификации для работы машины в домене (допустимые значения: sss, winbind)
check_system_policy	Отображает, какие политики применяются в процессе PAM-аутентификации: local — никакие, gpupdate — локальные и доменные
test_gpupdate_system_policy	Проверяет, настроено ли применение групповых политик в системе
check_krb5_conf_exists	Проверяет наличие, отображает права доступа и содержимое файла конфигурации `krb5.conf`
check_krb5_conf_ccache	Отображает текущий способ кеширования Kerberos-билетов — keyring, file, dir
test_keyring_krb5_conf_ccache	Проверяет настроенный способ кеширования Kerberos-билетов (для keyring)
check_krb5_conf_kdc_lookup	Проверяет включен ли поиск Kerberos-имени домена через DNS. Допустимыми значениями для «dns_lookup_kdc» в `/etc/krb5.conf` являются — true/yes
check_krb5_keytab_exists	Проверяет наличие, права доступа и дату последнего изменения файла `/etc/krb5.conf`. В этом файле хранятся принципалы и хеши пароля доменной учётной записи компьютера
check_keytab_credential_list	Отображает содержимое файла `/etc/krb5.conf` (файл с учётными данными машинного пользователя). В этом файле хранятся принципалы и хеши пароля доменной учётной записи компьютера. Требуется запуск от root, иначе SKIP
check_resolv_conf	Проверяет наличие и выводит содержимое файла конфигурации разрешения имен `resolv.conf`
compare_resolv_conf_with_default_realm	Сравнивает домен для поиска (поле search в `/etc/resolv.conf`) с доменом по умолчанию, указанным для Kerberos
check_smb_conf	Проверяет наличие и выводит содержимое файла настроек конфигурации Samba
compare_smb_realm_with_krb5_default_realm	Сравнивает домен, указанный в файле конфигурации Samba, с доменом по умолчанию, указанным для Kerberos
test_smb_realm	Проверяет корректное заполнение информации о домене в конфигурационных файлах Samba и Kerberos
test_domainname	Сверяет доменное имя из `/etc/hostname` с именем домена в составе FQDN-имени узла
check_time_synchronization	Отображает настройку синхронизации времени с сервером; выводит подробную информацию — часовой пояс, временную зону и т.д. Необходимо для корректной работы с сертификатами, электронной подписью, билетами Kerberos
test_time_synchronization	Проверяет, включена ли синхронизация времени
check_nameservers	Проверяет доступность всех контроллеров домена по имени (`host <domain FQDN>`) и IP-адресу (работает ли `resolv.conf`)
check_domain_controllers	Проверяет доступность всех контроллеров домена в домене (из srv-записей). Отображает версии контроллеров домена (из LDAP)
check_kerberos_and_ldap_srv_records	Проверяет наличие srv-записей вида _kerberos._udp.<domain FQDN> и _ldap._tcp.<domain FQDN> для домена. Требуется для корректной работы машины в домене. Без записей Kerberos, sssd и winbind не смогут найти контроллеры домена
compare_netbios_name	Сравнивает короткое имя машины из `/etc/hostname` с NetBios-именем машины в `smb.conf`
check_common_packages	Проверяет наличие установленных основных пакетов и их версий (alterator-auth, libnss-role, libkrb5 и libsmbclient)
check_group_policy_packages	Проверяет наличие установленных основных пакетов и их версий для управления групповыми политиками (local-policy и gpupdate)
check_sssd_ad_packages	Проверяет наличие установленного мета-пакета и его версии для аутентификации c помощью sssd (task-auth-ad-sssd)
check_sssd_winbind_packages	Проверяет наличие установленного мета-пакета и его версии для аутентификации c помощью winbind (task-auth-ad-winbind)

Примеры:

вывести список тестов:

$ diag-domain-client -l
check_hostnamectl
test_hostname
check_system_auth
test_domain_system_auth
check_system_policy
test_gpupdate_system_policy
check_krb5_conf_exists
check_krb5_conf_ccache
test_keyring_krb5_conf_ccache
check_krb5_conf_kdc_lookup
check_krb5_keytab_exists
check_keytab_credential_list
check_resolv_conf
compare_resolv_conf_with_default_realm
check_smb_conf
compare_smb_realm_with_krb5_default_realm
test_smb_realm
test_domainname
check_time_synchronization
test_time_synchronization
check_nameservers
check_domain_controllers
check_kerberos_and_ldap_srv_records
compare_netbios_name
check_common_packages
check_group_policy_packages
check_sssd_ad_packages
check_sssd_winbind_packages

запустить тест check_smb_conf:

$ diag-domain-client check_smb_conf
is_domain_info_available
[DONE]: is_domain_info_available

запустить тест check_krb5_conf_kdc_lookup с подробным выводом информации:

$ diag-domain-client check_krb5_conf_kdc_lookup -v
===============================================================================
| Samba environment diagnostic tool |
-------------------------------------------------------------------------------
Version: 0.2.8
Date: Ср 09 окт 2024 12:54:51 EET
-------------------------------------------------------------------------------
System information
Kernel: 5.10.212-std-def-alt1
Branch: p10
===============================================================================

===============================================================================
| check_krb5_conf_kdc_lookup |
-------------------------------------------------------------------------------

/etc/krb5.conf: dns_lookup_kdc is enabled

-------------------------------------------------------------------------------
Check DNS lookup kerberos KDC status: [DONE]
===============================================================================

запустить все тесты:

$ diag-domain-client
Check hostname persistance: [DONE]
Test hostname is FQDN (not short): [DONE]
System authentication method: [DONE]
Domain system authentication enabled: [DONE]
System policy method: [DONE]
System group policy enabled: [DONE]
Check Kerberos configuration exists: [DONE]
Kerberos credential cache status: [DONE]
Using keyring as kerberos credential cache: [DONE]
Check DNS lookup kerberos KDC status: [DONE]
Check machine crendetial cache is exists: [DONE]
Check machine credentials list in keytab: [SKIP]
Check nameserver resolver configuration: [DONE]
Compare krb5 realm and first search domain: [DONE]
Check Samba configuration: [DONE]
Compare samba and krb5 realms: [DONE]
Check Samba domain realm: [DONE]
Check hostname FQDN domainname: [DONE]
Check time synchronization: [DONE]
Time synchronization enabled: [WARN]
Check nameservers availability: [WARN]
Check domain controllers list: [FAIL]
Check Kerberos and LDAP SRV-records: [DONE]
Compare NetBIOS name and hostname: [DONE]
Check common packages: [DONE]
Check group policy packages: [DONE]
Check SSSD AD packages: [DONE]
Check SSSD Winbind packages: [WARN]

записать вывод теста check_krb5_conf_kdc_lookup в файл /tmp/diag-domain-client.log:

$ diag-domain-client check_krb5_conf_kdc_lookup -w/tmp/diag-domain-client.log
Check DNS lookup kerberos KDC status: [DONE]

просмотреть содержимое файла /tmp/diag-domain-client.log:

$ cat /tmp/diag-domain-client.log
===============================================================================
| Samba environment diagnostic tool |
-------------------------------------------------------------------------------
Version: 0.2.8
Date: Ср 09 окт 2024 12:54:24 EET
-------------------------------------------------------------------------------
System information
Kernel: 5.10.212-std-def-alt1
Branch: p10
===============================================================================

===============================================================================
| check_krb5_conf_kdc_lookup |
-------------------------------------------------------------------------------

/etc/krb5.conf: dns_lookup_kdc is enabled

-------------------------------------------------------------------------------
Check DNS lookup kerberos KDC status: [DONE]
===============================================================================

⁠7.1.3. ALT Diagnostic Tool

ALT Diagnostic Tool (ADT) — приложение для диагностики ОС с графическим и терминальным интерфейсом.

Утилита ADT позволяет:

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

Программа ADT предназначена для:

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

Запуск инструментов диагностики регулируется системным администратором, позволяя создавать отчеты пользователям, не передавая им административные полномочия.

⁠7.1.3.1. Установка

Для работы с ADT необходимо установить:

ADT (пакет adt);
диагностические инструменты (например, пакеты diag-domain-client, diag-domain-controller).

Установка ADT:

# apt-get install adt

Установка инструментов диагностики состояния клиента домена и состояния контроллера домена:

# apt-get install diag-domain-client diag-domain-controller

⁠7.1.3.2. Работа с ADT

Запустить и добавить в автозагрузку службу alterator-manager:

# systemctl enable --now alterator-manager.service

Запустить ADT можно:

из командной строки:
```
$ adt
```
в рабочей среде Mate: Меню → Системные → ADT;
в рабочей среде KDE5: Меню запуска приложений → Настройки → ADT.

Внешний вид программы ADT без установленных инструментов диагностики:

Интерфейс ADT без установленных инструментов диагностики

Внешний вид программы ADT с инструментами диагностики:

Интерфейс ADT с установленными инструментами диагностики

Для выбора набора тестов следует дважды щелкнуть мышью по его названию, либо выделить набор и нажать кнопку Выбрать инструмент. Откроется окно с набором тестов инструмента:

ADT. Набор тестов для диагностики клиента домена

В области управления инструментом диагностики доступны опции: Отчет, Запустить все тесты, Назад. Напротив каждого теста находятся кнопки Запустить и Журнал.

Нажатие на кнопку Запустить все тесты запускает весь набор тестов выбранного инструмента:

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

Нажатие на кнопку Журнал выводит отчет теста от утилиты инструмента диагностики (если инструмент поддерживает такую возможность):

Для поиска конкретного теста среди доступных можно воспользоваться строкой Фильтр:

Для сохранения полного отчёта инструмента в файл (если инструмент поддерживает такую возможность) следует нажать кнопку Отчет на панели инструментов:

Примечание

Для возможности генерирования файла с отчетом, инструмент диагностики должен поддерживать опции -r, --report.

⁠7.1.3.3. Руководство администратора

⁠7.1.3.3.1. Компоненты

Alterator-manager — модульный сервис, предназначенный для конфигурации посредством D-Bus. Весь функционал реализуется в виде модулей, а интерфейсы описываются в конфигурационных файлах «alterator entry».

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

Системная шина — создаётся при старте демона D-Bus. Предназначена для взаимодействия между различными системными службами, а также взаимодействие пользовательских приложений с этими службами;
Сессионная шина — создаётся для каждого пользователя во время авторизации как отдельный экземпляр. Предназначена для взаимодействия между пользовательскими приложениями в рамках одной сессии.

На шинах D-Bus регистрируются службы, предоставляющие определенные функции. Они могут быть как частью операционной системы, так и сторонними приложениями.

Для каждой службы заводятся объекты, представляющие собой абстракции реальных ресурсов или служб.

У каждого объекта есть один или несколько интерфейсов, которые определяют, какие действия можно совершить с объектом. Интерфейсы описывают методы (функции), которые можно вызвать, свойства, которые можно запросить или изменить, и сигналы, которые объект может отправлять.

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

Интерфейсы объектов. У каждого объекта есть один или несколько интерфейсов, которые определяют, какие действия можно совершить с объектом. Интерфейсы описывают методы (функции), которые можно вызвать, свойства, которые можно запросить или изменить, и сигналы, которые объект может отправлять.

Каждая служба поддерживающая D-Bus представлена в виде объектов на этих шинах. А взаимодействие между ними осуществляется посредством интерфейсов и методов этих объектов.

На системной шине методы запускаются с правами root и имеют высокие привилегии. На сессионной шине методы запускаются с правами пользователя и не имеют доступа к системным ресурсам, которые требуют высоких привилегий. С точки зрения alterator-manager диагностический инструмент является объектом на D-Bus, описанном в двух файлах «alterator entry»:

.backend — описывает интерфейс диагностического инструмента, обеспечивающий взаимодействие с D-Bus. В нем же описываются методы интерфейса: info, run, list, report;
.diagnostictool — описывает отображение диагностического инструмента в ADT. Содержит информацию о тестах, доступных в рамках описываемого диагностического инструмента.

alterator-module-executor — модуль альтератора для обработки файлов .backend и запуска исполняемых файлов.

⁠7.1.3.3.2. Алгоритм работы

Алгоритм работы ALT Diagnostic Tool:

Systemd служба alterator-manager во время запуска создает на шине D-Bus службу с именем «ru.basealt.alterator».
Systemd служба alterator-module-executor собирает информацию из файлов .backend обо всех установленных диагностических инструментах и создает объекты на системной и сессионных (в зависимости от расположения backend-файлов) шинах D-Bus с именами вида «ru.basealt.alterator.<имя инструмента>».
ADT формирует список диагностических инструментов, обращаясь к D-Bus и получая информацию обо всех объектах сервиса «ru.basealt.alterator», имеющих интерфейс «ru.basealt.alterator.diag1».
Для каждого диагностического инструмента ADT вызывает на D-Bus метод List, чтобы получить список всех возможных тестов.
ADT запускает через D-Bus метод Run, передав ему в качестве параметра имя теста.
По коду возврата ADT получает информацию об успешном/неуспешном прохождении теста, а из данных, полученных из stderr и stdout формирует журнал выполнения теста.

Блок-схема взаимодействия компонентов:

⁠7.1.3.3.3. Разработка инструмента диагностики

⁠7.1.3.3.3.1. Формат файлов инструмента диагностики

Минимальный набор файлов для инструмента диагностики в ADT:

исполняемый файл;
файлы .backend и .diagnostictool (или .diag), описывающие сущности Alterator Entry.

Примечание

Оба варианта .diagnostictool и .diag считаются верными.

⁠7.1.3.3.3.2. Требования к исполняемому файлу

Исполняемый файл может быть как бинарным, так и текстовым (написанным на интерпретируемом языке). Файл должен поддерживать запуск в следующем виде:

/путь_к_исполняемому_файлу {param}

где {param} — означает имя теста, который необходимо выполнить.

При успешном завершении теста исполняемый файл должен завершиться с кодом возврата 0. При неуспешном завершении теста — с кодом возврата отличным от 0.

Лог выполнения нужно выводить в стандартный вывод.

Необходима также поддержка следующих ключей:

-l или --list — вывод списка тестов. Список необходимо выводить в стандартный вывод. Имя каждого теста должно быть с новой строки;
-r или report — сгенерировать файл с отчетом. Файл с отчетом может представлять собой как текстовые данные, так и бинарные (например, архив). Его содержимое необходимо направить в стандартный вывод. ADT получит этот вывод и сохранит в файл с именем вида «имя_инструмента_дата» и суффиксом, указанным в файле .diagnostictool.

Исполняемый файл рекомендуется разместить в каталоге согласно стандарту FHS (Filesystem Hierarchy Standard).

⁠7.1.3.3.3.3. Рекомендации к файлам .backend и .diagnostictool

Для описания файлов .backend и .diagnostictool следует воспользоваться спецификацией Alterator Entry

Файлы .backend и .diagnostictool являются текстовыми и содержат описание в виде секций. Синтаксис файлов:

[имя секции1]
Поле1 = значение
Поле2 = значение
ПолеN = значение
[имя секции2]
Поле1 = значение
Поле2 = значение
ПолеN = значение
[имя секцииN]
Поле1 = значение
Поле2 = значение
ПолеN = значение

При этом следует учитывать:

все поля чувствительны к регистру и должны начинаться с заглавной буквы;
перед и после знака «=» пробелы;
значения полей указываются без кавычек;
значения могут содержать пробелы;
сли строка начинается с символа «#», то она считается комментарием и при чтении информации из файла игнорируется.

Имя каталога должно соответствовать суффиксу в имени файла:

./backends для файла .backend;
./diagnostictools для файла .diagnostictool (или .diag).

⁠7.1.3.3.3.3.1. Файл .diagnostictool

Файл .diagnostictool имеет имя вида <имя диагностического инструмента>.diagnostictool.

Если разрабатываемый диагностический инструмент предполагается распространять, то файлы сущностей необходимо разместить в каталоге /usr/share/alterator/diagnostictools/. В противном случае, рекомендуется использовать каталог /etc/alterator/diagnostictools/.

Файл .diagnostictool содержит информацию для GUI Он включает секцию [Alterator Entry] и секции, описывающие варианты тестирования.

Секция [Alterator Entry]:

[Alterator Entry]
- Name — идентификатор инструмента (имя без пробелов);
- Type — всегда Diagnostictool;
- DisplayName — имя инструмента;
- DisplayName[локаль] — имя инструмента, выводящееся в GUI, если используется интерфейс с использованием указанной в скобках локали;
- Comment — описание инструмента;
- Comment[локаль] — описание, выводящиеся в GUI, если используется интерфейс с использованием указанной в скобках локали;
- Icon — имя файла с иконкой;
- ReportSuffix — суффикс файла с отчетом. Этот файл будет создаваться при вызове метода Report.
Секции, описывающие варианты тестирования:
- [Название секции соответствует названию теста]
- DisplayName — идентификатор теста (имя без пробелов);
- DisplayName[локаль] — имя теста, выводящееся в GUI, если используется интерфейс с использованием указанной в скобках локали;
- Comment — описание теста;
- Comment[локаль] — описание теста, выводящееся в GUI, если используется интерфейс с использованием указанной в скобках локали.

⁠7.1.3.3.3.3.2. Файл .backend

Файл .backend имеет имя вида <имя диагностического инструмента>.ru.basealt.alterator.backend.

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

/usr/share/alterator/backends/system — если объект необходимо создать на системной шине;
/usr/share/alterator/backends/user — если объект необходимо создать на сессионной шине;

В противном случае, рекомендуется использовать каталог:

/etc/alterator/backends/system/ — если объект необходимо создать на системной шине;
/etc/alterator/backends/user/ — если объект необходимо создать на сессионной шине;

Секция [Alterator Entry] описывает информацию об объекте и содержит следующие поля:

[Alterator Entry]
- Type — содержит тип метода. Всегда имеет значение Backend;
- Module — всегда executor;
- Name — идентификатор инструмента (имя без пробелов);
- Interface — идентификатор интерфейса. Имеет значение ru.basealt.alterator.diag1. Можно сократить до diag1;
- thread_limit — указывает максимальное число потоков при одновременном выполнении нескольких методов.

Секция Info описывает метод Info и содержит следующие поля:

[Info]
- execute — в качестве параметра необходимо передать команду, выводящую содержимое файла .diagnostictool (cat <путь к файлу>);
- stdout_bytes — всегда enabled;
- thread_limit — всегда 3;
- action_id — содержит идентификатор метода. Всегда имеет значение Info.

Секция Run описывает метод Run и содержит следующие поля:

[Run]
- execute — содержит строку для запуска тестов вида <путь к исполняемому файлу> {param};
- stdout_signal_name — всегда diag1_stdout_signal. ADT ожидает сигнал с таким именем;
- stderr_signal_name — всегда diag1_stderr_signal. ADT ожидает сигнал с таким именем;
- action_id — содержит идентификатор метода. Всегда имеет значение Run.

Секция List описывает метод List и содержит следующие поля:

[List]
- execute — содержит команду для вывода списка всех возможных тестов в виде <путь к исполняемому файлу> -l;
- stdout_strings — всегда enabled;
- action_id — содержит идентификатор метода. Всегда имеет значение List.

Секция Report содержит следующие поля:

[Report]
- execute — содержит команду для создания отчета в виде <путь к исполняемому файлу> -R;
- stdout_bytes — всегда enabled;
- action_id — содержит идентификатор метода. Всегда имеет значение Report.

⁠7.1.3.3.4. Пример инструмента диагностики

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

Пример состоит из трех файлов:

исполняемый файл: /usr/bin/diag-example;
файл .backend: /usr/share/alterator/backends/diag-example.backend;
файл .diag, описывающий тесты: /usr/share/alterator/diagnostictools/diag-example.diag.

⁠7.1.3.3.4.1. Исполняемый файл

Содержимое исполняемого файла /usr/bin/diag-example:

#!/bin/bash
#
# Copyright (c) 2024 Evgeny Sinelnikov <sin@altlinux.org>
#
# Example diagnostic tool
#
# SPDX-License-Identifier: GPL-2.0-or-later
#

set -euo pipefail

. shell-getopt

PROG="${0##*/}"
PROG_VERSION='0.0.1'

cmd="run"
global_retval=0

print_version()
{
cat <<EOF
$PROG version $PROG_VERSION
Written by Evgeny Sinelnikov <sin@altlinux.org>

Copyright (C) 2024 Evgeny Sinelnikov <sin@altlinux.org>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
EOF
exit
}

show_usage()
{
cat <<EOF
$PROG - example diagnostic tool.

Usage: $PROG [options] [<diagnostic-task>]

Options:
-l, --list                list of diagnostic tasks;
-V, --version             print program version and exit;
-h, --help                show this text and exit.

Report bugs to https://bugzilla.altlinux.org/

EOF
exit
}

TEMP=$(getopt -n "$PROG" -o "l,V,h" -l "list,version,help" -- "$@") || show_usage
eval set -- "$TEMP"

while :; do
case "$1" in
    --) shift; break
        ;;
    -l|--list) cmd="list";
        ;;
    -V|--version) print_version
        ;;
    -h|--help) show_usage
        ;;
    *) fatal "Unrecognized option: $1"
        ;;
esac
shift
done

task_list="$*"

task_show()
{
local func="$1"

echo "$func"
}

task_run()
{
local retval=126
local func="$1"

if test -n "$task_list"; then
    echo "$task_list" | tr ' ' '\n' | grep -q "^$func\$" ||
        return 0
fi

$func && retval=0 || retval="$?"
test $retval = 0 || global_retval=1

return $retval
}

task()
{
local task="$1"

case "$cmd" in
    list) task_show "$task"
        ;;
    run) task_run "$task" && echo "[DONE]: $task" || echo "[FAIL]: $task"
        ;;
    *) fatal "Unrecognized command: $cmd"
        ;;
esac
}

is_gigabyte()
{
/usr/sbin/dmidecode -s baseboard-manufacturer | grep -q "^Gigabyte Technology"
}

is_std_def_kernel_running()
{
uname -r | grep -q '^[[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+-std-def-'
}

task is_gigabyte
task is_std_def_kernel_running

exit "$global_retval"

⁠7.1.3.3.4.2. Файл .backend

Содержимое файла /usr/share/alterator/backends/diag-example.backend:

[Alterator Entry]
Type = Backend
Module = executor
Name = diag_example
Interface = diag1

[Info]
execute = cat /usr/share/alterator/diagnostictools/diag-example.diag
stdout_bytes = enabled
stdout_byte_limit = 200000
action_id = Info

[Run]
execute = diag-example {param}
stdout_signal_name = diag_example_stdout_signal
stderr_signal_name = diag_example_stderr_signal
thread_limit = 1
action_id = Run

[List]
execute = diag-example -l
stdout_strings = enabled
stdout_strings_limit = 200000
action_id = List

⁠7.1.3.3.4.3. Файл .diag, описывающий тесты

Содержимое файла /usr/share/alterator/diagnostictools/diag-example.diag:

[Alterator Entry]
Type = diag
Name = Example
DisplayName = Diagnostic tool example
DisplayName[ru] = Пример инструмента диагностики
Comment = Diagnostic tool comment
Comment[ru] = Комментарий к диагностическому инструменту
Icon = system-run

[is_gigabyte]
DisplayName = Is motherboard manufacturer — Gigabyte?
DisplayName[ru] = Производитель материнской платы — Gigabyte?

⁠7.1.3.3.4.4. Отображение диагностического инструмента в интерфейсе ADT

Примечание

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

# systemctl restart alterator-manager.service

Пример отображения диагностического инструмента в интерфейсе ADT

⁠7.1.3.4. Ошибки и нестандартные случаи

Если диагностический инструмент не отображается, необходимо проверить объект alterator-manager с именем ru.basealt.alterator на системной шине D-Bus:

Примечание

Для этого можно использовать утилиту D-Feet (пакет d-feet):

⁠Глава 8. Примечания

8.1. Настройка беспарольного доступа по ssh
8.2. Центр управления системой

⁠8.1. Настройка беспарольного доступа по ssh

Генерация SSH-ключа (на DC1):

# ssh-keygen -t ed25519

На вопрос о файле для сохранения ключа нажать Enter (по умолчанию). На вопрос о пароле к ключу также нажать Enter (не указывать пароль).

Скопировать публичную часть SSH-ключа на второй контроллер домена (DC2) для пользователя user:

# ssh-copy-id -i ~/.ssh/id_ed25519.pub user@dc2.test.alt

Скопировать публичную часть SSH-ключа на второй контроллер домена (DC2) для администратора. Для этого подключаемся к DC2 и под root копируем публичную часть ключа:

# ssh user@dc2.test.alt
[user@dc2 ~]$ su -
Password:
[root@dc2 ~]# cat /home/user/.ssh/authorized_keys >>.ssh/authorized_keys
[root@dc2 ~]# exit
выход
[user@dc2 ~]$ exit
выход
Connection to dc2 closed.

Теперь есть возможность удалённо выполнять команды на DC2 с привилегиями администратора.

⁠8.2. Центр управления системой

Центр управления системой (ЦУС, альтератор) представляет собой удобный интерфейс для выполнения наиболее востребованных административных задач: добавление и удаление пользователей, настройка сетевых подключений, просмотр информации о состоянии системы и т.п.

ЦУС состоит из независимых диалогов-модулей. Каждый модуль отвечает за настройку определённой функции или свойства системы.

Запустить ЦУС в графической среде можно следующими способами:

в графической среде MATE: Система → Администрирование → Центр управления системой;
в графической среде XFCE, KDE: Меню запуска приложений → Настройки → Центр управления системой;
из командной строки: командой acc.

Запуск ЦУС требует административных прав, и если запустить его от обычного пользователя, он запросит пароль администратора системы (root):

ЦУС имеет также веб-ориентированный интерфейс, позволяющий управлять сервером с любого компьютера сети.

Для запуска веб-ориентированного интерфейса, должен быть установлен пакет alterator-fbi:

# apt-get install alterator-fbi

И запущены сервисы ahttpd и alteratord:

# systemctl enable --now ahttpd
# systemctl enable --now alteratord

Работа с ЦУС может происходить из любого веб-браузера. Для начала работы необходимо перейти по адресу https://ip-адрес:8080/.

При запуске центра управления системой необходимо ввести в соответствующие поля имя пользователя (root) и пароль пользователя:

После этого будут доступны все возможности ЦУС на той машине, к которой было произведено подключение через веб-интерфейс.

Веб-интерфейс центра управления системой

Установленные пакеты, которые относятся к ЦУС, можно посмотреть, выполнив команду:

$ rpm -qa | grep alterator*

Прочие пакеты для ЦУС можно найти, выполнив команду:

$ apt-cache search alterator*

Модули можно дополнительно загружать и удалять как обычные программы:

# apt-get install alterator-net-openvpn
# apt-get remove alterator-net-openvpn