Модуль 2. Развертывание ALD Pro

Введение

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

При установке продукта мы затрагиваем много вопросов по администрированию Astra Linux, которые уже рассматривали в первой части курса, но мы постарались привести в этом модуле небольшие емкие пояснения, чтобы он мог служить кратким руководством (Quick Start Guide) для тех системных администраторов, кому доведется знакомиться с учебным курсом, начиная именно с этого модуля, как точки входа.

Подготовка виртуальной среды для прохождения этого курса

Описания тестового стенда

В рамках курса мы установим пару контроллеров домена и несколько подсистем, в том числе рабочих станций. Все виртуальные машины будут работать в одной натированной сети 10.0.1.0/24, см. рис. 162.

рис. 162 Схема тестового стенда ALD Pro

В качестве доменного имени возьмем значение ald.mycompany.lan в соответствии с рекомендациями из предыдущего модуля, см. Рекомендации по именованию домена.

Для упрощения развертывания тестового стенда в ходе установки первого контроллера мы сделаем копию виртуальной машины и будем использовать ее в качестве шаблона для установки остальных подсистем и рабочих станций, поэтому на всех хостах у нас будет операционная система с максимальным уровнем защищенности «Смоленск» и динамическими дисками на 50 ГБ, хотя для клиентов ALD Pro уровень защищенности не имеет значения.

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

Минимальные требования для тестовой среды

Тестовый стенд будет работать без реальной нагрузки, поэтому мы можем существенно снизить минимальные требования к производительности виртуальных машин, но при планировании ресурсов реальной инфраструктуры ориентируйтесь, пожалуйста, на рекомендации, которые были изложены ранее, см. Модуль 1. Система ALD Pro и ее компоненты, раздел Минимальные требования к инфраструктуре для развертывания ALD Pro.

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

Компонент системы	Ядер CPU	RAM	SSD	Кол-во
Контроллер домена	2	4 ГБ	50 ГБ	2 шт.
Подсистема «Репозиторий ПО»	1	2 ГБ	50 ГБ	1 шт.
Подсистема «Общий доступ к файлам»	1	2 ГБ	50 ГБ	1 шт.
Подсистема «Служба печати»	1	2 ГБ	50 ГБ	1 шт.
Подсистема «Мониторинг»	1	2 ГБ	50 ГБ	1 шт.
Подсистема «Аудит»	1	2 ГБ	50 ГБ	1 шт.
Клиентские машины	1	2 ГБ	50 ГБ	2 шт.

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

• CPU: 8 ядер.

• RAM: 16 ГБ.

• SSD: 150 ГБ (желательно, чтобы диск был SSD, т.к. производительность работы контроллеров домена сильно зависит от скорости дисковой подсистемы).

Для установки продукта версии ALD Pro 3.0.0 будем использовать операционную систему ALSE 1.7.7 UU2 с ядром 6.1-generic и уровнем защищенности «Смоленск». Для получения подробной информации о совместимости см. табл. 15 Матрица совместимости ALD Pro.

табл. 15 Матрица совместимости ALD Pro

Назначение системы	Версия ОС ALSE	Ядро ОС ALSE	Уровень защищенности ALSE	Альтернативные ОС
ALD Pro 3.0.0
Контроллеры домена и подсистемы	1.7.6 UU2, 1.7.7 UU2	5.15-generic, 6.1-generic	Смоленск	Нет
Серверы и рабочие станции	1.7.6, 1.7.6 UU1, 1.7.6 UU2, 1.7.7, 1.7.7 UU1, 1.7.7 UU2, 1.8.1, 1.8.1 UU1, 1.8.1 UU2, 1.8.3	5.4-generic, 5.10-generic, 5.15-generic, 6.1-generic	Любой	РЕД ОС 7.3.5, РЕД ОС 8, Альт Рабочая станция 10.4, Альт СП Рабочая станция 10
ALD Pro 2.5.0
Контроллеры домена и подсистемы	1.7.6 UU2	5.15-generic, 6.1-generic	Смоленск	Нет
Серверы и рабочие станции	1.7.3, 1.7.4, 1.7.5, 1.7.5 UU1, 1.7.6, 1.7.6 UU1, 1.7.6 UU2, 1.8.1, 1.8.1 UU1, 1.8.1 UU2	5.4-generic, 5.10-generic, 5.15-generic, 6.1-generic	Любой	Нет
ALD Pro 2.4.1
Контроллеры домена и подсистемы	1.7.5, 1.7.5 UU1, 1.7.6, 1.7.6 UU1, 1.7.6 UU2	5.15-generic, 6.1-generic	Смоленск	Нет
Серверы и рабочие станции	1.7.1, 1.7.2, 1.7.3, 1.7.4, 1.7.5, 1.7.5 UU1, 1.7.6, 1.7.6 UU1, 1.7.6 UU2, 1.8.1, 1.8.1 UU1	5.4-generic, 5.10-generic, 5.15-generic, 6.1-generic	Любой	Нет
ALD Pro 2.4.0
Контроллеры домена и подсистемы	1.7.5, 1.7.5 UU1, 1.7.6, 1.7.6 UU1, 1.7.6 UU2	5.15-generic, 6.1-generic	Смоленск	Нет
Серверы и рабочие станции	1.7.1, 1.7.2, 1.7.3, 1.7.4, 1.7.5, 1.7.5 UU1, 1.7.6, 1.7.6 UU1, 1.7.6 UU2, 1.8.1	5.4-generic, 5.10-generic, 5.15-generic, 6.1-generic	Любой	Нет

Настройка натированной сети

Взаимодействие между хостами в домене осуществляется через компьютерную сеть TCP/IP по протоколам KRB5, DNS, LDAP(S), RPC, HTTP(S), NTP, SMB и многим другим. В рамках курса мы будем устанавливать все виртуальные машины в одной общей натированной сети VirtualBox, для создания которой нужно выполнить следующие действия:

• Открыть менеджер сети из меню Файл ‣ Инструменты.

• Перейти на вкладку Сеть NAT и нажать кнопку Создать.

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

  • Имя сети: Сеть - Стенд ALD Pro.

  • CIDR сети (диапазон адресов): 10.0.1.0/24.

  • Поддержка DHCP: выключить, т.к. IP-адреса на хостах стенда будем настраивать вручную, см. рис. 163.

рис. 163 Создание сети NAT

В натированной сети средствами VirtualBox будет создан шлюз, через который виртуальные машины смогут выходить в Интернет. Адресом шлюза будет первый IP-адрес сети 10.0.1.1.

Примечание

Учитывая, что все хосты будут находиться в одной сети, они смогут взаимодействовать друг с другом без каких-либо ограничений, но в реальной жизни компьютерную сеть предприятия обычно нарезают на множество сегментов, взаимодействие между которыми ограничивают правилами межсетевого экрана для повышения безопасности в соответствии с концепцией нулевого доверия (Zero Trust). Чтобы правильно настроить сетевое оборудование, ознакомьтесь с разделом Правила межсетевого экрана.

Развертывание первого контроллера домена

Подготовка виртуальной машины

Создание виртуальной машины

В окне VirtualBox Manager выполните команду Машина ‣ Создать и укажите следующие параметры:

• Имя: dc-1.ald.company.lan - Стенд ALD Pro.

• Папка машины: по умолчанию.

• Тип: Linux.

• Версия: Other Linux (64-bit).

• Объем памяти: 4096 МБ.

• Жесткий диск: Создать новый виртуальный жесткий диск.

• Тип файла: VDI (VirtualBox Disk Image).

• Формат хранения: Динамический виртуальный жесткий диск.

• Путь: по умолчанию.

• Размер: 50 ГБ.

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

• На вкладке Система ‣ Процессор укажите 4 ЦП для ускорения установки ОС, далее можно уменьшить этот параметр до 2 ЦП.

• На вкладке Система ‣ Ускорение укажите интерфейс паравиртуализации KVM.

• На вкладке Носители для компакт-диска укажите установочный файл ALSE 1.7.7 UU2.

• На вкладке Сеть выберите тип подключения Сеть NAT и имя Сеть - Стенд ALD Pro, см. рис. 164.

рис. 164 Настройки сети VM

Примечание

Для установки операционной системы необходимо будет загрузить образ диска ALSE 1.7.7 UU2 из официального репозитория.

Мы не рекомендуем загружать ISO-образ через торрент-сети или сайты в Интернете, т.к. такие файлы могут быть изменены злоумышленниками и содержать вредоносное программное обеспечение. Для обеспечения безопасности используйте только официальный источник dl.astralinux.ru или ссылку из личного кабинет Астра.

Установка операционной системы

Загрузите виртуальную машину и установите операционную систему с графическим окружением и максимальным уровнем защищенности «Смоленск»:

• Именем компьютера оставьте astra по умолчанию.

• Локальным администратором укажите пользователя localadmin.

• В качестве пароля локального администратора установите значение Pa$$w0rd.

• Настройку сети пропустите.

• При разметке диска выберите пункт Авто – использовать весь диск и настроить LVM (потребуется в будущем при обновлении ОС до версии ALSE 1.8+) и схему разметки Все файлы в одном разделе.

• Версию ядра оставьте 6.1-generic по умолчанию. Не используйте варианты hardened (с усиленной самозащитой) и lowlatency (с увеличенной до 1000 Гц частотой переключения задач), которые доступны для версии 5.15, но не поддерживаются продуктом ALD Pro.

• Из пакетов программ по умолчанию можно исключить, например, Средства работы с графикой, но обязательно оставьте Офисные приложения, так как в дальнейшем нам потребуется LibreOffice для просмотра CSV-файлов в табличном виде. Добавьте также пакет Средство удаленного подключения SSH, если вы хотите подключаться к компьютеру удаленно.

• При выборе дополнительных параметров укажите уровень защищенности Смоленск и оставьте включенными флажки Мандатный контроль целостности и Мандатное управление доступа. В тестовых средах для удобства работы можно отключить флажок Запрос пароля для команды sudo.

• При настройке GRUB используйте тот же пароль Pa$$w0rd.

Для получения дополнительной информации об установке системы см. Модуль 2. Установка ОС Astra Linux.

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

cat /etc/astra/build_version
sudo astra-modeswitch getname

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

localadmin@astra:~$ cat /etc/astra/build_version
1.7.7.9

localadmin@astra:~$ sudo astra-modeswitch getname
maximum(smolensk)

Кратко о работе утилиты sudo

Утилита sudo похожа на команду Run as... из Windows и позволяет запускать команды из-под пользователя с повышенными привилегиями.

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

В тестовых средах вы можете отключить запрос пароля для команды sudo, увеличить время timestamp_timeout в файле /etc/sudoers или запустить новую оболочку от имени суперпользователя командой sudo -i:

localadmin@astra:~$ sudo -i
[sudo] пароль для localadmin:
root@astra:~#

После выполнения команды sudo -i вы увидите, что имя пользователя сменилось на root, а строка приглашения заканчивается символом решетки # — это означает, что теперь вы можете запускать команды от имени root без использования утилиты sudo.

Чтобы выйти из привилегированной сессии, достаточно выполнить команду exit:

root@astra:~# exit
выход
localadmin@astra:~$

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

Для получения дополнительной информации о работе утилиты sudo см. Модуль 10. Система аутентификации PAM и управление правами SUDO.

Временная настройка сетевого интерфейса

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

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

• В контекстном меню апплета выберите пункт Параметры соединений.

• В окне сетевых соединений двойным кликом по строке Проводное соединение 1 откройте настройки этого подключения.

• На вкладке Параметры IPv4 укажите следующие настройки:

  • IP-адрес: 10.0.1.10.

  • Маска: 24 или 255.255.255.0.

  • Шлюз: 10.0.1.1.

  • Сервер DNS: 77.88.8.8.

рис. 165 Настройка сетевого интерфейса с помощью апплета Network Manager

Чтобы изменения вступили в силу, выключите и включите обратно поддержку сети в контекстном меню апплета NetworkManager.

рис. 166 Включение/отключение поддержки сети

Чтобы убедиться в работе сетевого стека, выполните следующие команды:

ip a show dev eth0
ping dl.astralinux.ru -c 4

рис. 167 Проверка работы сети

Для получения дополнительной информации по управлению сетевыми интерфейсами см. Модуль 20. Сеть и стек TCP/IP, управление сетевыми интерфейсами.

Настройка репозиториев операционной системы

Файлы программ для Linux объединяются в пакеты, а пакеты объединяются в репозитории, которые могут распространяться как в виде ISO-образов на диске, так и размещаться на веб-серверах в локальной сети или Интернет. Мы будем использовать два репозитория base и extended, поэтому напомним их назначение:

• base – это базовый репозиторий, который объединяет репозитории main и update, а также содержит пакеты со средствами разработки, которые потребуются нам, например, для установки гостевых дополнений (gcc и linux-headers).

• extended – содержит дополнительное программное обеспечение, которое может функционировать в среде Astra Linux.

Примечание

Следует принимать во внимание, что пакеты из репозиториев base и extended собираются из исходных кодов и для них устраняются известные уязвимости, но действие сертификатов соответствия на эти репозитории не распространяется, поэтому в продуктивной среде рекомендуется использовать только репозитории main и update.

С пакетами из репозиториев работает менеджер apt, поэтому основным файлом для хранения списка доступных репозиториев является /etc/apt/sources.list, а дополнительные списки могут находиться в файлах *.list из директории /etc/apt/sources.list.d/.

Вы можете редактировать файл /etc/apt/sources.list напрямую или запустить редактор с помощью следующей команды, чтобы воспользоваться дополнительными проверками при сохранении изменений:

sudo apt edit-sources

Для операционной системы ALSE 1.7.7 UU2 (1.7.7.9) установите следующее содержимое файла /etc/apt/sources.list:

deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-base/ 1.7_x86-64 main contrib non-free
deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-extended/ 1.7_x86-64 main contrib non-free

В source-листах каждая строка указывает параметры подключаемого репозитория в следующем формате:

deb <путь_к_каталогу_репозитория> <код_дистрибутива> <компонент1> <компонентN>

Где:

• deb — указывает на то, что репозиторий соответствует репозиторию бинарных файлов с предварительно скомпилированными пакетами. Для репозиториев с исходными кодами используют «deb-src».

• uri — задает адрес репозитория. У сетевых репозиториев адрес начинается с http(s)://, адреса локальных копий репозиториев начинаются с file:/, а при добавлении репозитория с диска командой apt-cdrom add в файле появится строка cdrom:[]/.

• код дистрибутива — дополняет uri, уточняя необходимый релиз продукта. В одном репозитории могут находиться пакеты сразу для нескольких релизов.

• компонент — это группа пакетов, объединенная по условиям использования:

  • non-free — группа содержит пакеты, которые не соответствуют принципам свободного ПО, имеют патенты или другие юридические ограничения;

  • contrib — группа содержит пакеты, которые сами по себе соответствуют принципам свободного ПО, но зависят от пакетов из группы non-free (т. е. не могут без них работать);

  • main — группа содержит пакеты свободного ПО, которые не зависят от пакетов из групп contrib и non-free.

Информацию о пакетах репозитория менеджер apt возьмет из файлов Release или InRelease, адреса которых формируются по шаблону <uri>/dists/<код дистрибутива>/<Release или InRelease>.

Как вы помните, в адресе uri разработчики Astra Linux предлагают использовать ветку stable, которая соответствует последней версии операционной системы, но для работы с ALD Pro нужно обязательно переключиться на ветку frozen конкретной версии, чтобы гарантировать полную совместимость пакетов. Информация о поддержке продуктом ALD Pro очередных обновлений операционной системы Astra Linux и возможности обновления публикуется в release notes по продукту.

Дополнительная информация о настройке репозиториев

При использовании операционной системы Astra Linux нежелательно устанавливать программное обеспечение из репозиториев предыдущих версий, поэтому у каждой версии ОС, включая срочные обновления UU, есть своя собственная ветка frozen:

• Если вы установили Astra Linux SE 1.7.6 (1.7.6.11) и хотите зафиксировать эту версию, то содержимое файла должно быть следующим:

deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.6/repository-base/ 1.7_x86-64 main contrib non-free
deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.6/repository-extended/ 1.7_x86-64 main contrib non-free

• Если вы установили Astra Linux SE 1.7.6 UU1 (1.7.6.14) и хотите зафиксировать эту версию, то содержимое файла должно быть следующим:

deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.6/uu/1/repository-base/ 1.7_x86-64 main contrib non-free
deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.6/uu/1/repository-extended/ 1.7_x86-64 main contrib non-free

• Если вы установили Astra Linux SE 1.7.6 UU2 (1.7.6.15) и хотите зафиксировать эту версию, то содержимое файла должно быть следующим:

deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.6/uu/2/repository-base/ 1.7_x86-64 main contrib non-free
deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.6/uu/2/repository-extended/ 1.7_x86-64 main contrib non-free

После изменения состава репозиториев следует обновить индекс доступных пакетов с помощью команды sudo apt update. Эта команда извлекает список пакетов и зависимостей, но еще не обновляет само программное обеспечение. Вот результат ее выполнения:

localadmin@astra:~$ sudo apt update
Пол:1 https://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-base 1.7_x86-64 InRelease [5 306 B]
Пол:2 https://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-extended 1.7_x86-64 InRelease [9 772 B]
Пол:3 https://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-base 1.7_x86-64/main amd64 Packages [4 535 kB]
Пол:4 https://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-base 1.7_x86-64/contrib amd64 Packages [2 223 B]
Пол:5 https://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-base 1.7_x86-64/non-free amd64 Packages [71,5 kB]
Пол:6 https://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-extended 1.7_x86-64/main amd64 Packages [1 906 kB]
Пол:7 https://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-extended 1.7_x86-64/contrib amd64 Packages [8 340 B]
Пол:8 https://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-extended 1.7_x86-64/non-free amd64 Packages [66,7 kB]
Получено 6 605 kB за 1с (6 266 kB/s)
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Может быть обновлён 1 пакет. Запустите «apt list --upgradable» для показа.

Если обратить внимание на последнюю строку в выводе предыдущей команды, то вы увидите, что может быть обновлён 1 пакет, который можно посмотреть с помощью команды sudo apt list --upgradable:

localadmin@astra:~$ sudo apt list --upgradable
Вывод списка… Готово
astra-version/stable 8.1.46+v1.7.7.ext1.6 amd64 [может быть обновлён с: 8.1.46+v1.7.7.9]
N: Есть 1 дополнительная версия. Используйте «-a» для просмотра.

Если бы у нас был подключен только репозиторий base, то все пакеты имели бы последние версии и ничего обновлять не требовалось бы, но так как мы подключили еще репозиторий extended, то менеджер APT предлагает нам обновить пакет astra-version из расширенного репозитория. Установка этого пакета не приведет к каким-либо существенным изменениям в системе, просто появится man-справка на саму утилиту astra-version и еще несколько вспомогательных файлов.

Для установки обновлений в Debian и Ubuntu обычно предлагают команду sudo apt upgrade, но для системы Astra Linux использовать ее категорически запрещается, т.к. эта команда не удаляет устаревшие пакеты, даже если это требуется для обновления приложений, что может нарушить работу операционной системы. Поэтому вместо команды upgrade следует использовать команду dist-upgrade в стратегии --force-confold, т.е. при обновлении пакетов менеджер apt должен сохранять содержимое старых конфигурационных файлов, если они были изменены из скриптов установки или вручную:

sudo apt dist-upgrade -y -o Dpkg::Options::=--force-confold

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

localadmin@astra:~$ sudo apt dist-upgrade -y -o Dpkg::Options::=--force-confold
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Расчёт обновлений… Готово
Следующий пакет устанавливался автоматически и больше не требуется:
libopts25
Для его удаления используйте «sudo apt autoremove».
Следующие пакеты будут обновлены:
astra-version
Обновлено 1 пакетов, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
Необходимо скачать 8 376 B архивов.
После данной операции объём занятого дискового пространства возрастёт на 0 B.
Пол:1 https://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-extended 1.7_x86-64/main amd64 astra-version amd64 8.1.46+v1.7.7.ext1.6 [8 376 B]
Получено 8 376 B за 0с (54,4 kB/s)
(Чтение базы данных … на данный момент установлено 266737 файлов и каталогов.)
Подготовка к распаковке …/astra-version_8.1.46+v1.7.7.ext1.6_amd64.deb …
Распаковывается astra-version (8.1.46+v1.7.7.ext1.6) на замену (8.1.46+v1.7.7.9) …
Настраивается пакет astra-version (8.1.46+v1.7.7.ext1.6) …
Обрабатываются триггеры для man-db (2.8.5-2+deb10u1) …
Обрабатываются триггеры для xserver-xorg-core (2:21.1.7-1ubuntu4astra.se45) …
update exec ids due to /usr/bin changed
setfattr: /usr/bin/fly-dm: No such attribute

Чтобы упростить обновление операционной системы, разработчики Astra Linux создали специальную утилиту astra-update, которая под капотом запускает обновление с использованием правильной стратегии и отключает во время обновления функции безопасности, поэтому вместо dist-upgrade вы можете запустить эту команду со следующими ключами:

sudo astra-update -A -r -T

Где:

• Ключ -A – указывает, что обновления нужно устанавливать полностью автоматически -I, включая -e и отключая -d функции безопасности по мере необходимости.

• Ключ -r – указывает, что установка обновлений должна быть ограничена списком репозиториев из файла /etc/apt/sources.list.

• Ключ -T – указывает, что выполнять проверку технологического диска не требуется, т.к. подключенные репозитории содержат все необходимые пакеты.

Примечание

Кстати, продукт ALD Pro для обновления пакетов использует стратегию --force-confnew, то есть пакетный менеджер должен переопределять содержимое конфигурационных файлов, даже если они были изменены из скриптов установки или вручную, поэтому для корректного обновления продукта обратитесь к соответствующему разделу руководства администратора.

Для получения дополнительной информации по работе с пакетами и репозиториями программного обеспечения см. Модуль 15. Управление ПО в Astra Linux.

Установка гостевых дополнений

Для возможности переноса команд в виртуальную машину через буфер обмена нам потребуется установить гостевые дополнения (guest additions). Подключите и примонтируйте диск с гостевыми дополнениями, выбрав меню Устройства ‣ Подключить образ диска Дополнений гостевой ОС:

рис. 168 Подключение диска с гостевыми дополнениями

Примечание

Диск с гостевыми дополнениями можно скачать по ссылке с официального сайта.

Установите VBoxLinuxAdditions следующими командами:

sudo apt install gcc make linux-headers-6.1
sudo sh /media/cdrom0/VBoxLinuxAdditions.run

Осталось в настройках машины включить двунаправленный буфер обмена и после перезагрузки системы вы сможете с помощью горячего сочетания клавиш Shift + Ins переносить в окно терминала вашей виртуальной машины текст конфигурационных файлов и команды через общий буфер обмена.

рис. 169 Включение двунаправленного буфера обмена

Клонирование шаблона виртуальной машины

Чтобы упростить в дальнейшем развертывание остальных подсистем и рабочих станций, сделаем копию виртуальной машины сразу после установки гостевых дополнений. Перед выполнением клонирования рекомендуется завершить работу операционной системы из меню Пуск ‣ Завершение работы ‣ Выключение или командой poweroff утилиты systemctl:

systemctl poweroff

Запустите мастер клонирования командой Машина ‣ Клонировать из окна VirtualBox. При выполнении клонирования укажите следующие параметры:

• Имя: Шаблон - Стенд ALD Pro.

• Путь: Оставьте по умолчанию.

• Тип клонирования: Полное клонирование.

• Цель клонирования: Состояние машины.

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

рис. 170 Клонирование шаблона виртуальной машины

Настройка сетевого интерфейса для постоянной работы

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

Операционная система была установлена с графическим интерфейсом Fly, поэтому в качестве менеджера сетевых подключений по умолчанию предлагается использовать службу NetworkManager, которая отлично подходит для управления сетевыми настройками на рабочих станциях пользователей, т.к. позволяет автоматически переключаться на доступные Wi-Fi сети и устанавливать VPN-соединения, но на серверах ее использование считается излишним. Отключить службу можно следующими командами:

sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager
sudo systemctl mask NetworkManager
systemctl status NetworkManager

После выполнения последней команды status в терминале отобразится информация о том, что служба NetworkManager остановлена (inactive), и запустить ее не получится, т.к. она замаскирована (masked):

...
localadmin@astra:~@ systemctl status NetworkManager
 o NetworkManager.service
   Loaded: masked (Reason: Unit NetworkManager.service is masked.)
   Active: inactive (dead) since Mon 2025-08-15 11:49:50 MSK; 1s ago
 Main PID: 509 (code=exited, status=0/SUCCESS)
      CPU: 264ms

Отключение апплета NetworkManager

После выключения службы Network Manager значок апплета в трее начнет вводить вас в заблуждение, что у компьютера нет подключения к сети. Вы можете завершить работу аплета и удалить пакет network-manager следующими командами:

sudo kill $(pidof nm-applet)
sudo apt remove network-manager

Старое название службы до версии ALSE 1.7.4

В AstraLinux Special Edition до версии 1.7.4 служба называлась network-manager в нижнем регистре через дефис, поэтому для отключения службы нужно было выполнять следующие команды:

sudo systemctl stop network-manager
sudo systemctl disable network-manager
sudo systemctl mask network-manager
systemctl status network-manager

Теперь сетевые настройки нужно задавать вручную в файлах /etc/network/interfaces и /etc/resolv.conf. Файл interfaces определяет настройки сетевых интерфейсов для утилит ifup и ifdown, которые используются службой networking. Файл resolv.conf определяет настройки для разрешения DNS-имен.

Для настройки сетевого интерфейса вы можете открыть файл /etc/network/interfaces напрямую:

sudo nano /etc/network/interfaces

Содержимое файла после редактирования должно стать следующим (новые строки отмечены цветом):

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# Настройка eth0
auto eth0
iface eth0 inet static
  address 10.0.1.11
  netmask 255.255.255.0
  gateway 10.0.1.1

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

• auto eth0 — строка, начинающаяся со слова auto, указывает интерфейс, который будет подниматься автоматически при вызове команды ifup -a. Посмотреть список доступных интерфейсов можно командой ip a, первый сетевой интерфейс обычно имеет идентификатор eth0.

• iface eth0 inet static — строка со словом iface начинает группу строк, отвечающих за настройку указанного интерфейса. Следующее слово inet/inet6 указывает, какой протокол будет использоваться: IPv4 или IPv6 соответственно. Параметр static или dhcp указывает на способ назначения настроек: вручную или динамически.

  На контроллерах домена настоятельно рекомендуется использовать статичные IP-адреса, потому что контроллер выступает не только в роли LDAP-сервера и центра распространения Kerberos-ключей, но и как DNS-сервер. Если же вам все-таки потребуется перенести контроллер в другую подсеть, то нужно будет поменять A-запись в прямой зоне, PTR-запись в обратной зоне, указать новый IP-адрес на всех компьютерах, где он был задан вручную, в том числе в настройках DHCP-сервера, а затем перезагрузить все хосты, которым этот IP-адрес был выдан в качестве DNS по протоколу DHCP.

• address, netmask, gateway — задают IP-адрес, маску и шлюз по умолчанию для интерфейса, который указан в строке iface (при условии, что для него выбран способ назначения настроек static).

Примечание

В некоторых инструкциях в файле interfaces задают такие параметры, как dns-nameservers и dns-search, но они имеют силу только в том случае, если в системе работает служба resolvconf, которая переносит эти настройки в файл /etc/resolv.conf соответствующим образом. В системе Astra Linux служба resolvconf по умолчанию не устанавливается, поэтому указанные настройки не имеют смысла.

Чтобы применить новые настройки, достаточно перезапустить службу networking командой systemctl restart networking. Может потребоваться также очистить старое соединение командой ip addr flush dev <имя устройства>:

sudo ip addr flush dev eth0
sudo systemctl restart networking

Проверить работу сети можно с помощью утилиты ping:

localadmin@astra:~$ ping 77.88.8.8 -c 4
PING 77.88.8.8 (77.88.8.8) 56(84) bytes of data.
64 bytes from 77.88.8.8: icmp_seq=1 ttl=54 time=91.3 ms
64 bytes from 77.88.8.8: icmp_seq=2 ttl=54 time=91.6 ms
. . .

Для возможности обращения компьютера к публичным репозиториям по DNS-именам следует настроить файл /etc/resolv.conf, который используется функциями библиотеки glibc (host, ping), утилитами из пакета dnsutils (nslookup, dig) и другими сетевыми приложениями, в том числе службой sssd. В нашем случае файл уже был настроен ранее службой NetworkManager до ее удаления с сервера, поэтому содержимое файла должно быть следующим:

localadmin@astra:~$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 77.88.8.8

Вы можете удалить комментарий от NetworkManager и указать любой другой сервер по своему усмотрению. Корректность настройки файла /etc/resolv.conf можно проверить с помощью той же утилиты ping, обращаясь к серверу по имени:

localadmin@astra:~$ ping dl.astralinux.ru -c 4
PING dl.astralinux.ru (51.250.6.116) 56(84) bytes of data.
64 bytes from 51.250.6.116 (51.250.6.116): icmp_seq=1 ttl=52 time=31.9 ms
64 bytes from 51.250.6.116 (51.250.6.116): icmp_seq=2 ttl=52 time=27.2 ms
. . .

Примечание

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

Напомним еще раз, что для получения дополнительной информации по управлению сетевыми интерфейсами см. Модуль 20. Сеть и стек TCP/IP, управление сетевыми интерфейсами.

Настройка репозиториев продукта ALD Pro

Ранее мы уже настроили репозитории для операционной системы ALSE 1.7.7 UU2 (1.7.7.9), поэтому содержимое файла /etc/apt/sources.list должно быть следующим:

deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-base/ 1.7_x86-64 main contrib non-free
deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-extended/ 1.7_x86-64 main contrib non-free

Из основного репозитория операционной системы продукт ALD Pro берет целый ряд системных компонентов, таких как FreeIPA, 389 Directory Server, SSSD и другие, но для установки программного комплекса потребуется настроить так же и собственный репозиторий продукта.

В рамках настоящего курса мы предлагаем устанавливать крайний релиз ALD Pro 3.0 или версию ALD Pro 2.4, для которой определен длительный период поддержки (Long-Term Support, LTS), что сильно уменьшает накладные расходы команд эксплуатации на своевременную установку обновлений безопасности.

Дополнительная информация о версионировании ALD Pro

Нумерация релизов ALD Pro ведется в формате «X.Y.Z», который по правилам семантического версионирования соответствует следующим требованиям:

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

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

  Выпуск оперативных обновлений, начиная с релиза 2.0, гарантируется на срок не менее 36 месяцев с даты выхода очередного обновления.

• Z — срочные оперативные обновления (патчи, включенные в продукт) — вносят исправления, связанные с устранением критичных дефектов и угроз информационной безопасности без нарушения обратной совместимости. Установка срочных оперативных обновлений выполняется типовым образом и не требует значительных временных затрат со стороны команды, отвечающей за эксплуатацию системы в продуктивной среде.

  Выпуск срочных оперативных обновлений, начиная с релиза 2.4.0, осуществляется только в рамках оперативных обновлений с длительным сроком поддержки (Long-Term Support, LTS) и гарантируется на срок не менее 6 месяцев с даты выхода следующего LTS-релиза. Первым LTS-релизом стала версия 2.4, следующий LTS-релиз запланирован на версию 3.2, выход которой ожидается в конце 2025 года.

Чтобы подключить репозиторий ALD Pro нужно открыть еще несуществующий файл /etc/apt/sources.list.d/aldpro.list на редактирование командой:

sudo nano /etc/apt/sources.list.d/aldpro.list

И сохранить в нем следующую строку:

deb https://dl.astralinux.ru/aldpro/frozen/01/3.0.0/ 1.7_x86-64 main base

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

sudo apt update

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

Серверная часть:

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

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

• Пакеты операционной системы и продукта можно обновлять как вместе, так и по отдельности. Обновление операционной системы существенно влияет на функциональные возможности продукта, т.к. ключевые компоненты FreeIPA и 389 Directory Server поставляются через базовый репозиторий операционной системы.

• Схема LDAP-каталога будет изменена во всем домене уже после обновления операционной системы или продукта на первом контроллере домена. Вместе с тем, функциональные возможности нового API будут доступны только при обращении клиентов к обновленным контроллерам и подсистемам.

Клиентская часть:

• Установку клиентской части можно выполнять на любой компьютер без оглядки на другое используемое программное обеспечение. Конфликт зависимостей пакетов минимален.

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

• Если домен находится в процессе обновления, клиент (начиная с версии 2.4.0) загрузит актуальную версию скриптов policy manager из LDAP-каталога и только в части API будет ограничен функциональными возможностями того контроллера домена, который его обслуживает.

Дополнительная информация по приоритетам пакетов

Разработчики Astra Linux предупреждают, что установка пакетов из сторонних репозиториев (включая репозитории Debian) небезопасно и может привести к нарушению работы системы, поэтому, подключая такие репозитории, системные администраторы принимают ответственность полностью на себя. Вместе с тем, для уменьшения вероятности замещения компонентов, реализующих сертифицированные функции безопасности ОС, пакетами из сторонних репозиториев, в Astra Linux устанавливается повышенный приоритет 900 для собственных пакетов:

localadmin@astra:~$ cat /etc/apt/preferences.d/smolensk
Package: *
Pin: release n=1.7_x86-64
Pin-Priority: 900

Изначально продукт ALD Pro использовал идентификатор релиза generic, поэтому нужно было создавать дополнительный файл для настройки приоритетов собственных пакетов, но с версии 2.2.0 мы перешли на такой же идентификатор 1.7_x86-64, как у операционной системы, что позволяет использовать для пакетов ALD Pro такой же приоритет, как у пакетов операционной системы, поэтому никаких дополнительных файлов создавать больше не требуется.

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

Имя хоста должно быть задано в формате полного имени FQDN (от англ. Fully Qualified Domain Name), например, dc-1.ald.company.lan. Такой подход принят в Red Hat, и он наследуется при использовании службы каталога ALD Pro на базе FreeIPA.

Для изменения имени хоста в Astra Linux мы рекомендуем использовать утилиту hostnamectl, так как после прямого редактирования файла /etc/hostname изменения вступают в силу не сразу, а только после перезагрузки системы.

sudo hostnamectl set-hostname dc-1.ald.company.lan

Для того, чтобы сервер всегда мог преобразовать свое имя dc-1.ald.company.lan в IP-адрес 10.0.1.11, даже при недоступности DNS-сервиса, в файл /etc/hosts нужно добавить строку, связывающую IP-адрес с именем хоста. Вы можете указать не только полное имя, но и короткое dc-1, однако первым по списку обязательно должно идти полное имя, т. к. первое значение считается каноническим именем и будет возвращаться командой hostname -f, что требуется для корректной работы скриптов автоматизации.

Обратите внимание, что в файле не должно быть строки, связывающей имя хоста с адресом 127.0.0.1, т. к. в соответствии с настройками /etc/gai.conf адреса локальной петли имеют более высокий приоритет, а нам крайне важно, чтобы имя хоста разрешалось в IP-адрес локальной сети, а не loopback, потому что какие-то из служб в будущем могут прослушивать сетевые порты только на этом адресе.

С учетом указанных замечаний, содержимое файла /etc/hosts должно быть следующим:

127.0.0.1 localhost.localdomain localhost
10.0.1.11 dc-1.ald.company.lan dc-1

Примечание

Обратите внимание, что имя хоста нужно настроить до установки пакетов продукта, т.к. служба Rabbit MQ по завершению установки возьмет текущее имя хоста в качестве имени кластера и последующее повышение роли сервера будет завершаться ошибкой из-за несовпадения имен. В этом случае вы можете, конечно, переустановить пакет rabbitmq-server и повторить установку контроллера домена, но лучше все-таки выдержать правильную последовательность действий.

Установка пакетов контроллера домена

Теперь система готова к установке серверной части ALD Pro. Выполните следующую команду:

sudo DEBIAN_FRONTEND=noninteractive \
  apt-get install -y -q aldpro-mp aldpro-gc aldpro-syncer

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

• DEBIAN_FRONTEND — переменная окружения, которая позволяет изменить режим взаимодействия с пользователем при установке пакетов менеджером APT. Многие приложения на стадии установки уточняют необходимые настройки для последующей работы, что станет помехой для автоматического развертывания. Переключение менеджера пакетов в режим noninteractive позволяет избежать уведомлений от пактов Kerberos, OpenDNSSec и PAM.

• \ — позволяет перенести текст длинной команды на следующую строку, чтобы исключить появление горизонтальной прокрутки в веб-версии и неправильных переносов при экспорте в PDF-формат.

• -y — параметр позволяет автоматически ответить «Да» на все возможные вопросы в ходе установки.

• -q — параметр позволяет скрыть сообщения о прогрессе установки, делая журнал более читаемым.

• Устанавливаемые deb-пакеты:

  • aldpro-mp — пакет портала управления (management portal), который позволяет через зависимости установить все остальные пакеты, необходимые для работы основных функций контроллера домена ALD Pro.

  • aldpro-gc — пакет модуля глобального каталога, который необходим, если планируется использовать двусторонние доверительные отношения с лесом доменов Microsoft Active Directory. Глобальный каталог прослушивает порт 3268/TCP и позволяет обрабатывать запросы от стандартных оснасток Microsoft Windows на поиск пользователей и групп из домена ALD Pro при назначении прав доступа в домене MS AD.

  • aldpro-syncer — пакет модуля синхронизации, который необходим, если планируется использовать расширенные функции интеграции с доменом Microsoft Active Directory. Он позволяет получить один и тот же состав пользователей, групп и подразделений в двух доменах, синхронизируя все основные атрибуты объектов, включая пароли пользователей. Это дает возможность предоставить пользователям доступ по логину/паролю к любым информационным системам, вне зависимости от того, через контроллер какого домена информационная система проверяет аутентичность пользователей.

Сразу после установки пакетов контроллера домена рекомендуется удалить локатор библиотеки libkrb5 от службы winbind, который может приводить к значительным задержкам в работе Kerberos-аутентификации на контроллере домена. Сделать это можно следующей командой:

sudo rm /usr/lib/x86_64-linux-gnu/krb5/plugins/libkrb5/winbind_krb5_locator.so

Прежде чем продолжить, проверьте журнал пакетного менеджера /var/log/apt/term.log на предмет ошибок. Если установка прошла корректно, то следующая команда не должна показать никаких строк:

sudo grep 'error:' /var/log/apt/term.log

Повышение роли сервера до контроллера домена

Теперь все готово для продвижения контроллера (англ. domain controller promotion) или, как обычно говорят, для повышения роли сервера до контроллера домена. В ходе этой процедуры выполняется настройка всех компонентов, чтобы сервер начал выполнять функции контроллера домена. В домене MS AD повышение роли сервера выполняется с помощью мастера настройки доменных служб или средства командной строки Adprep.exe, а в домене ALD Pro для этого предназначена утилита aldpro-server-install:

sudo aldpro-server-install --host dc-1 --domain ald.company.lan \
  --ip 10.0.1.11 --setup_gc --setup_syncer --no-reboot

Комментарии по использованным ключам:

• Параметр -n (--host) — короткое имя хоста без указания полного имени домена, например, dc-1. Значение должно быть указано в нижнем регистре.

• Параметр -d (--domain) — полное имя домена, например, ald.company.lan.

• Параметр --ip — IP-адрес контроллера домена, например, 10.0.1.11. Значение требуется указывать явно, так как на сервере может быть несколько сетевых интерфейсов.

• Ключ --setup_gc — указывает, что нужно настроить установленный ранее модуль глобального каталога.

• Ключ --setup_syncer — указывает, что нужно настроить установленный ранее модуль синхронизации.

• Ключ --no-reboot — отменяет перезагрузку после завершения процедуры настройки. Выполнение скрипта занимает некоторое время, поэтому мы рекомендуем выполнить перезагрузку вручную после ознакомления с результатами его работы в терминале.

Стандартное описание всех параметров скрипта вы можете получить с помощью ключа -h или --help.

Утилита поддерживает так же параметр -p (--admin_pwd), с помощью которого можно указать пароль, который будет установлен для учетной записи администратора домена admin и суперпользователя LDAP-каталога cn=Directory Manager. Длина пароля должна быть не менее 8 символов, значение нужно заключать в одинарные кавычки, чтобы экранировать специальные символы, включая знак доллара, используемый в bash для подстановки значений переменных. Однако мы не рекомендуем указывать пароль в командной строке, так как в этом случае он может попасть в историю команд и будет отображаться в списке процессов ps. Если вы не укажете параметр -p, то утилита запросит значение пароля в интерактивном режиме.

Дополнительная информация об истории команд

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

Еще вы можете отключить регистрацию команд полностью с помощью опции history:

set +o history

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

set -o history

Если же команда все-таки попала в историю, то эту строку можно удалить с помощью команды history -d $(history 1) или прямым редактированием файла /root/.bash_history.

Для получения дополнительной информации по управлению историей см. Модуль 4. Работа с терминалом и оболочкой Bash, раздел Работа с историей команд Bash.

По завершению установки вы увидите сообщение об успешном выполнении операции. После повышения роли сервера до контроллера домена вы можете проверить содержимое файла /etc/resolv.conf и убедиться, что теперь DNS-запросы обрабатываются собственной службой BIND9:

cat /etc/resolv.conf
# auto-generated by IPA installer
search ald.company.lan
nameserver 127.0.0.1

Где:

• Строка search ald.company.lan — задает DNS-суффикс, используемый при разрешении имен, поэтому при обращении к хосту по короткому имени dc-1 система будет дополнять его до полного имени dc-1.ald.company.lan.

• Строка nameserver 127.0.0.1 — указывает, что разрешение имен должно выполняться через локальную службу ISC Bind, которая обрабатывает запросы, поступающие на 53-й порт сервера.

Контроллер домена готов к работе, осталось только перезагрузить сервер:

sudo reboot

После загрузки контроллера выберите в первом выпадающем списке значение ald.company.lan вместо Этот компьютер и войдите в систему из-под учетной записи доменного администратора admin с высоким уровнем целостности 63, который будет предложен по умолчанию:

рис. 171 Вход в систему под доменной учетной записью

Проверка базовых функций домена

Проверка доменных служб

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

• Если в первом выпадающем списке формы для входа вместо имени домена ald.company.lan отображается строка Ожидание ответа домена..., то пытаться входить в систему доменным пользователем преждевременно. Подождите пару минут и попробуйте еще раз.

• Если при входе доменного пользователя в систему вы получите ошибку «Вход не выполнен», то подождите пару минут и попробуйте войти в систему еще раз, прежде чем начинать отладку.

В случае, если вход в операционную систему доменным пользователем окажется все-таки невозможен, войдите в систему локальным администратором localadmin и проверьте в первую очередь доступность клиентской службы sssd, которая обеспечивает работу операционной системы в составе домена:

systemctl status sssd

Результат проверки в нормальном состоянии:

localadmin@dc-1:~$ systemctl status sssd
o sssd.service - System Security Services Daemon
   Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2025-08-07 09:49:16 MSK; 17min ago
...

При необходимости перезапустите службу командой sudo systemctl restart sssd, повторите вход в систему доменным пользователем еще раз и проверьте новые записи в журналах /var/log/auth.log` и /var/log/messages.

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

sudo ipactl status

Результат проверки в нормальном состоянии:

localadmin@dc-1:~$ sudo ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

Примечание

Для управления базовыми сервисами домена утилиты ipactl будет вполне достаточно, но в ALD Pro есть также и дополнительная утилита aldproctl, которая позволяет управлять состоянием собственных служб, например, модулем глобального каталога или синхронизации. С помощью этой утилиты вы можете отправлять команды в том числе и конкретным службам, для этого нужно использовать ключ --service:

sudo aldproctl status --service=globalcatalog

При необходимости перезапустите доменные службы командой sudo ipactl restart, повторите вход в систему доменным пользователем еще раз и проверьте новые записи в журналах /var/log/auth.log и /var/log/messages.

Проверка Kerberos-аутентификации

При успешном входе в систему доменным пользователем в связке ключей должен появиться TGT-билет, что можно проверить с помощью команды klist:

admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:1902000000:krb_ccache_BUoysxG
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
07.08.2025 12:29:42  08.08.2025 12:01:56  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

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

admin@dc-1:~$ kdestroy
admin@dc-1:~$ klist
klist: Credentials cache keyring 'persistent:1902000000:krb_ccache_BUoysxG' not found

Для запроса нового TGT-билета на доменного пользователя admin воспользуемся утилитой kinit. Как мы видим, после прохождения успешной Kerberos-аутентификации нам был выдан новый билет krbtgt/ALD.COMPANY.LAN:

admin@dc-1:~$ kinit admin
Password for admin@ALD.COMPANY.LAN: ********

admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:1902000000:krb_ccache_BUoysxG
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
07.08.2025 12:31:42  08.08.2025 11:59:45  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Дополнительная информация об алиасе root принципала admin

Обратите внимание, что при запуске команды kinit без указания имени пользователя утилита попытается взять имя пользователя сначала из связки ключей, а если кэш будет удален командой kdestroy, то переключится на имя текущего пользователя Linux.

По указанной причине начинающие администраторы иногда выполняют аутентификацию из-под принципала root@ALD.COMPANY.LAN, который является алиасом для учетной записи admin@ALD.COMPANY.LAN, что может вызывать различные коллизии. Например, до версии 2.4.0 это приводило к тому, что администратор не мог выполнить прозрачную Kerberos-аутентификацию на портале.

Чаще всего это происходит, когда администратор после команды kdestroy запускает аутентификацию командой kinit без указания имени пользователя, но с добавлением sudo:

admin@dc-1:~$ kdestroy
admin@dc-1:~$ sudo kinit
Password for root@ALD.COMPANY.LAN:

admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:1965600000:krb_ccache_o2glwGp
Default principal: root@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
07.08.2025 13:16:02  08.08.2025 12:31:18  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Эта ошибка возникает также и при выполнении kinit без sudo, когда администратор работает в сессии суперпользователя root, в которую можно войти с помощью команды sudo -i.

Проверка портала управления

Для входа на портал управления откройте на контроллере домена страницу https://dc-1.ald.company.lan в браузере Mozilla Firefox. Вы сможете войти в систему как по паролю, так и через прозрачную Kerberos-аутентификацию, если в связке ключей будет действительный TGT-билет.

рис. 172 Прозрачная Kerberos-аутентификация на портале

рис. 173 Портал управления ALD Pro после успешного входа

Чувствительность к регистру в имени пользователя

В версии 2.4.0 веб-форма для входа на портал чувствительна к регистру символов в части имени пользователя, поэтому вам нужно вводить значение admin и не использовать другие варианты написания, такие как Admin или ADMIN. Учитывая, что в службе каталога FreeIPA все учетные записи создаются в нижнем регистре. Начиная с версии ALD Pro 2.5.0, указанное ограничение было снято.

Дополнительная информация для настройки домашней страницы

В версии 2.4.0 домашней страницей FireFox по умолчанию устанавливается короткое имя хоста https://dc-1, которое не рекомендуется использовать для работы с порталом, т.к. в этом случае веб-страница не сможет пройти проверку SSL-сертификата и не будет работать Kerberos-аутентификация. Начиная с версии ALD Pro 2.5.0, указанная настройка уже исправлена, но для любой предыдущей версии вы можете сделать это вручную. Для этого достаточно будет исправить содержимое файла /usr/lib/firefox/distribution/policies.json, например, следующей командой:

sudo sed -i 's/dc-1\|dc-1.ald.company.lan/dc-1.ald.company.lan/g' \
  /usr/lib/firefox/distribution/policies.json

Содержимое файла после коррекции должно быть следующим:

admin@dc-1:~$ cat /usr/lib/firefox/distribution/policies.json
{
         "policies": {
               "BlockAboutAddons": true,
               "BlockAboutConfig": true,
               "Certificates": {
                        "ImportEnterpriseRoots": true,
                        "Install": ["/etc/ipa/ca.crt"]
               },

               "Homepage": {
                        "URL": "https://dc-1.ald.company.lan/",
                        "Locked": true,
                        "StartPage": "homepage-locked"
               }
         }
}

Дополнительная информация о входе на портал с компьютеров вне домена

Если вы откроете портал управления на компьютере, который не является участником домена ALD Pro, то вам потребуется согласиться с риском использования самоподписанного сертификата, и Kerberos-аутентификация работать не будет, потребуется вводить логин и пароль вручную.

Если в момент прозрачной аутентификации в связке ключей не будет действительного TGT-билета, то появится сообщение «Аутентификация с Kerberos не удалась» и нужно будет сначала выполнить полную Kerberos-аутентификацию в терминале с помощью утилиты kinit, а затем повторить попытку еще раз.

После успешной прозрачной аутентификации на портале управления в связке ключей текущего пользователя появится сервисный билет на доступ к службе HTTP/dc-1.ald.company.lan.

admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:1902000000:krb_ccache_BUoysxG
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
07.08.2025 12:32:23  08.08.2025 11:59:45  HTTP/dc-1.ald.company.lan@ALD.COMPANY.LAN
07.08.2025 12:31:42  08.08.2025 11:59:45  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

При повторном входе на портал, если cookie не были удалены и срок жизни предыдущей пользовательской сессии еще не истек, доступ к порталу будет предоставлен без повторной Kerberos-аутентификации, поэтому валидный TGT-билет не потребуется и сервисный билет на доступ к HTTP-службе в связке ключей не появится.

Дополнительная настройка DNS-службы

Отключение DNSSEC и запрета рекурсивных запросов

В качестве DNS-сервера на контроллере домена выступает служба BIND9 (named-pkcs11), основным конфигурационным файлом которой является /etc/bind/named.conf. Дополнительные настройки для службы каталога подключаются из файла /etc/bind/ipa-options-ext.conf с помощью параметра include.

По умолчанию служба BIND9 проверяет DNS-ответы с помощью механизма DNSSEC, но его лучше отключить, т. к. технология все еще не получила широкого распространения, и ошибки в настройках DNS-зон могут приводить к невозможности разрешения имен. Для этого в файле ipa-options-ext.conf параметру dnssec-validation нужно установить значение no.

Еще одной особенностью настроек BIND9 по умолчанию является запрет на обработку рекурсивных DNS-запросов от клиентов из других сетей, что сделано для предотвращения DDoS-атак с DNS-усилением, но является излишней предосторожностью в домене. Для разрешения рекурсивных запросов в файле ipa-options-ext.conf для параметров allow-recursion и allow-query-cache нужно установить значение any.

Для внесения указанных изменений приведите содержание файла /etc/bind/ipa-options-ext.conf к следующему виду:

dnssec-validation no;
allow-recursion { any; };
allow-query-cache { any; };

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

sudo systemctl restart bind9-pkcs11.service

И не забудьте удалить локатор winbind, как было рекомендовано выше в разделе Установка пакетов контроллера домена, т.к. служба BIND9 использует GSSAPI для подключения к LDAP-каталогу, и любые задержки в работе Kerberos-аутентификации будут приводить к задержке в работе BIND9 после перезапуска этой службы.

Настройка глобального перенаправления DNS-запросов

Служба BIND9 может самостоятельно выполнять рекурсивное разрешение имен, последовательно обращаясь ко всем DNS-серверам, обслуживающим зону, начиная с корневых серверов (см. файлы /etc/bind/named.conf.default-zones и /usr/share/dns/root.hints), но этот механизм потребляет дополнительные ресурсы, поэтому для быстрого разрешения публичных DNS-имен рекомендуется использовать глобальный перенаправитель. Эту опцию можно настроить на портале управления в меню Роли и службы сайта ‣ Служба разрешения имен ‣ Глобальная конфигурация DNS.

Чтобы добавить перенаправитель, нажмите кнопку Добавить в списке глобальных перенаправителей и введите адрес DNS-сервера от Яндекс 77.88.8.8. В качестве политики перенаправления выберите «Только перенаправлять», в этом случае BIND9 будет запрашивать ответ только у перенаправителя. Если же вы укажите «Сначала перенаправлять», то в случае неуспешного обращения к серверам перенаправления BIND9 будет пататься разрешить запрос самостоятельно. По завершению редактирования настроек нажмите кнопку Сохранить, чтобы изменения вступили в силу, см. рис. 174 (1).

рис. 174 Глобальная конфигурация DNS

Проверить настройки DNS-службы можно из командной строки:

ipa dnsconfig-show

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

admin@dc-1:~$ ipa dnsconfig-show
Глобальные перенаправители: 77.88.8.8
Политика перенаправления: only
Разрешить PTR-синхронизацию: FALSE
DNS-серверы IPA: dc-1.ald.company.lan

Для проверки того, как именно BIND9 выполняет разрешение имен (самостоятельно или через глобальный перенаправитель), нам потребуется какой-нибудь сниффер сетевого трафика, например, Wireshark или TCP Dump.

Установим пакет tcpdump командой sudo apt install tcpdump и запустим в отдельном окне терминала перехват всех пакетов, в которых фигурирует 53-й порт:

sudo tcpdump port 53

Осталось проверить, что будет происходить при преобразовании DNS-имени dl.astralinux.ru в IP-адрес, например, с помощью утилит host, ping, nslookup или dig:

host dl.astralinux.ru

В окне сниффера можно увидеть, что запрос был направелен на глобальный перенаправитель dns.yandex.ru, и в ответ был получен IP-адрес 130.193.50.59:

admin@dc-1:~$ sudo tcpdump port 53
...
15:36:12.154912 IP dc-1.ald.company.lan.41938 > dns.yandex.ru.domain: 5409+% [1au] PTR? 8.8.88.77.in-addr.arpa. (63)
15:36:12.160096 IP dns.yandex.ru.domain > dc-1.ald.company.lan.40646: 62590 1/0/1 A 130.193.50.59 (61)
...

Присоединение компьютера к домену

Из этого раздела вы узнаете, как настроить рабочую станцию и присоединить ее к домену ALD Pro. Для упрощения развертывания стенда мы создали шаблон виртуальной машины в процессе установки первого контроллера домена, но если у вас нет такой копии виртуальной машины, просто обратитесь к разделу Подготовка виртуальной машины выше.

Подготовка виртуальной машины

Для создания рабочей станции выберите виртуальную машину Шаблон - Стенд ALD Pro и запустите мастер клонирования командой Машина ‣ Клонировать из меню VirtualBox Manager. При выполнении клонирования укажите следующие параметры:

• Имя: pc-1.ald.company.lan - Стенд ALD Pro.

• Путь: Оставьте по умолчанию.

• Тип клонирования: Полное клонирование.

• Цель клонирования: Состояние машины.

• Политика MAC-адреса: Сгенерировать новые MAC-адреса всех сетевых адаптеров.

После клонирования машины оптимизируйте объем вычислительных ресурсов, изменив требуемые параметры RAM и CPU.

Для возможности работы клонированной машины в одной компьютерной сети с другими копиями нам нужно обязательно назначить машине уникальный MAC-адрес сетевого интерфейса. Мы можем сделать это как в момент клонирования машины, так и после. При использовании NetworkManager иногда может потребоваться также выбрать новое устройство в настройках сетевого подключения после загрузки операционной системы.

Однако настройка машины на этом не заканчивается. Как вы знаете, в Windows нужно обязательно выполнить еще процедуру подготовки sysprep (англ. system preparation — подготовка системы), в ходе которой из системы удаляются все сведения, относящиеся к конкретному экземпляру, включая идентификатор безопасности компьютера (SID). Для систем Linux это действие не является обязательным, но лучше все-таки удалить некоторые данные, относящиеся к конкретному экземпляру операционной системы.

Сгенерируем новый идентификатор машины, чтобы при необходимости использования динамической настройки от DHCP она получала собственный IP-адрес:

sudo rm -fv /etc/machine-id
sudo rm -fv /var/lib/dbus/machine-id
sudo dbus-uuidgen --ensure
sudo systemd-machine-id-setup

Сгенерируем новые ssh-ключи, чтобы у всех компьютеров они были разными:

sudo rm -fv /etc/ssh/ssh_host_*
sudo ssh-keygen -A -v

Исправление порядка загрузки для клонированной машины

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

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

1. Введите команду exit и нажмите клавишу Enter.

2. В открывшемся интерфейсе перейдите в меню Boot Maintenance Manager ‣ Boot Options ‣ Change Boot Order и нажмите Enter.

3. Клавишами + и - задайте правильный порядок устройств для загрузки, при котором CD-ROM будет на первом месте, а системный жесткий диск на втором:

4. Подтвердите свой выбор нажатием клавиши Enter, сохраните изменения клавишами F10 и Y, вернитесь в главное меню клавишей Esc и загрузите машину, выбрав пункт меню Continue.

Настройка сетевого интерфейса для постоянной работы

Для управления сетевыми подключениями на рабочих станциях рекомендуется использовать службу NetworkManager, т.к. она позволяет автоматически переключаться на доступные Wi-Fi сети и устанавливать VPN-соединения. Откройте настройки сети в апплете NetworkManager и на вкладке «Параметры IPv4» установите значения:

• Метод: Вручную.

  Рабочие станции обычно получают сетевые настройки от DHCP-сервера, но в целях упрощения мы будем назначать адрес вручную.

• Адрес: 10.0.1.51 (в соответствии с описанием тестового стенда).

• Маска: 24 или 255.255.255.0.

• Шлюз: 10.0.1.1 (адресом шлюза VirtualBox является первый IP-адрес сети).

• Серверы DNS: 10.0.1.11 (адрес dc-1.ald.company.lan).

• Поисковый домен: ald.company.lan (это значение будет добавляться к коротким именам).

рис. 175 Настройка сети на рабочей станции

Обратите внимание на два момента:

1. При использовании DNS-сервера от Microsoft он должен резолвить записи не только из прямой, но и обратной зоны тоже. Если перенаправить обратную зону на сервер ALD Pro невозможно, то на DNS-сервере Microsoft нужно вручную добавить PTR-записи контроллеров домена ALD Pro, иначе ввод машин в домен будет невозможен из-за дополнительной проверки безопасности на стороне клиента FreeIPA.

2. Если у компьютера будет IP-адрес из другой подсети, то в домене ALD Pro нужно будет создать обратную зону для этой сети.

Для применения новых настроек необходимо выключить и повторно включить поддержку сети в контекстном меню апплета NetworkManager.

Настройка репозиториев продукта ALD Pro

Для установки клиентской части ALD Pro используются те же репозитории, что и для установки серверной части, поэтому содержимое файлов /etc/apt/sources.list и /etc/apt/sources.list.d/aldpro.list должно быть аналогичным.

Установите для файла /etc/apt/sources.list следующее содержимое:

deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-base/ 1.7_x86-64 main contrib non-free
deb https://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/uu/2/repository-extended/ 1.7_x86-64 main contrib non-free

Установите для файла /etc/apt/sources.list.d/aldpro.list следующее содержимое:

deb https://dl.astralinux.ru/aldpro/frozen/01/3.0.0/ 1.7_x86-64 main base

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

sudo apt update

Установка пакетов клиентской части

Теперь система готова к установке клиентской части ALD Pro. Выполните следующую команду:

sudo DEBIAN_FRONTEND=noninteractive \
  apt-get install -y -q aldpro-client

Для получения дополнительной информации по использованным ключам см. раздел Установка пакетов контроллера домена.

Если перезагрузить пользовательский компьютер прямо сейчас, то в сообщениях ядра можно будет увидеть ошибки запуска службы sssd и других зависящих от нее сервисов (журнал загрузки можно найти в файле /var/log/boot.log). Это происходит по причине того, что служба еще не настроена соответствующим образом (журнал службы sssd можно найти в файле /var/log/sssd/sssd.log).

Проверка имени хоста на уникальность

Как вы знаете, имя компьютера должно быть уникальным в домене. В системе Windows имена компьютеров задаются в верхнем регистре символов и по умолчанию представляют собой случайную строку в формате DESKTOP-S16CV34. В системе Astra Linux имена задаются в нижнем регистре и по умолчанию предлагается использовать имя astra. Чтобы сгенерировать случайную строку как в Windows, вы можете воспользоваться следующей командой:

$ echo "desktop-$(expr $RANDOM$(date +%s) | md5sum | head -c 7)"
desktop-711eaaf

Проверить значение на уникальность можно с помощью утилиты host. По приведенному далее примеру можно заметить, что имя dc-1 уже используется хостом с IP-адресом 10.0.1.11, а имя pc-1 еще свободно:

admin@dc-1:~$ host dc-1.ald.company.lan
dc-1.ald.company.lan has address 10.0.1.11

admin@dc-1:~$ host pc-1.ald.company.lan
Host pc-1.ald.company.lan not found: 3(NXDOMAIN)

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

Консольная утилита aldpro-client-installer

Ввод компьютера в домен

Вводом компьютера в домен или присоединением к домену (англ. Domain Join) называют процедуру, в ходе которой для компьютера создается учетная запись в домене и выполняется настройка компьютера, чтобы он мог выполнять аутентификацию/авторизацию пользователей и получать параметры групповых политик из домена. После присоединения компьютера его называют участником домена (англ. Domain Members) или просто доменным компьютером.

В домене MS AD присоединение компьютеров к домену выполняется с помощью оснастки Свойства компьютера или командлета Add-Computer, а в домене ALD Pro для этого предназначена утилита aldpro-client-installer. Утилита имеет графический интерфейс, но используется преимущественно в неинтерактивном консольном режиме, в котором все параметры являются обязательными. Перед вызовом утилиты рекомендуется отключать запись истории команд, так как в одном из параметров передается пароль администратора в открытом виде.

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

sudo /opt/rbta/aldpro/client/bin/aldpro-client-installer \
  --host pc-1 --domain ald.company.lan --account admin --gui

Комментарии по использованным ключам:

• Параметр -n (--host) — короткое имя хоста без доменной части, например, pc-1. Значение должно быть указано в нижнем регистре.

• Параметр -d (--domain) — полное имя домена, к которому нужно присоединить хост, например, ald.company.lan.

• Параметр -u (--account) — логин администратора домена или другой учетной записи, обладающей достаточными привилегиями для присоединения компьютеров к домену.

• Ключ --gui (guiless) — указывает, что присоединение компьютера нужно выполнить в консоли без использования графического интерфейса.

Утилита поддерживает так же параметр -p (--password), с помощью которого можно указать пароль от учетной записи из параметра -u (--account). Если вы не укажете параметр -p, то утилита запросит пароль в интерактивном режиме.

Интерес представляет так же параметр -f (--force), с помощью которого можно присоединить компьютер к домену, даже если в домене уже есть учетная запись компьютера с таким именем.

Стандартное описание всех параметров скрипта вы можете получить с помощью ключа -h или --help.

В ходе присоединения компьютера к домену для него создается учетная запись, с помощью пароля которой он сможет проверять аутентичность доменных пользователей и выполнять авторизованные запросы в домене. На компьютерах Windows учетные данные компьютера хранятся в защищенной части реестра, в так называемом менеджере учетных записей безопасности (англ. Security Accounts Manager, SAM). На компьютерах Linux они находятся в файле /etc/krb5.keytab, и их можно посмотреть с помощью утилиты klist:

localadmin@pc-1:~$ sudo klist -ket
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 07.08.2025 14:36:35 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96)
   1 07.08.2025 14:36:35 host/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)

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

sudo reboot

После перезагрузки войдите в систему, используя учетную запись администратора домена. Для первого входа в систему доменной учетной записью нужен будет доступ к контроллеру домена, а в дальнейшем проверка аутентичности возможна будет через кэш службы sssd. Подробно о том, как эта служба встраивается в PAM и NSS для обеспечения работы компьютера в домене, смотрите Модуль 5. Работа Linux-компьютера в домене.

Вывод компьютера из домена

Вывод компьютера из домена (англ. Unjoin from the Domain) выполняют, когда требуется изменить назначение компьютера или полностью вывести его из эксплуатации, чтобы пользователи этого компьютера не могли получить доступ к ресурсам домена, участником которого он являлся. Мы рассмотрим особенности этой процедуры как со стороны рабочей станции, так и со стороны домена

Действия на рабочей станции

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

Чтобы вывести компьютер из домена, на рабочей станции в первую очередь нужно откатить настройки клиента FreeIPA, то есть привести содержание общих конфигурационных файлов, включая настройки PAM стека, в исходное состояние. Для этого войдите в систему под учетной записью локального администратора, например, localadmin, и выполните команду astra-freeipa-client с ключом -U:

# Выполните команду на pc-1 под локальным администратором localadmin
sudo astra-freeipa-client -U -y

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

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

• Ключи хоста удаляются из файла /etc/krb5.keytab.

• Содержимое конфигурационных файлов /etc/krb5.conf, /etc/ldap/ldap.conf и др. приводится в исходное состояние.

• К имени файла конфигурации /etc/sssd/sssd.conf добавляется суффикс .deleted.

Далее следует удалить пакеты приложений, указав явно aldpro*, freeipa*, sssd* и krb5* (все остальные пакеты будут удалены через зависимости):

sudo apt purge 'aldpro*' 'freeipa*' 'sssd*' 'krb5*'
sudo apt autoremove --purge

Если не удалить приложения, то после перезагрузки останутся включенными, но будут работать некорректно такие службы как aldpro-salt-minion, aldpro-client-service-discovery, aldpro-client-rdm.

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

sudo rm -rf /home/admin

Если в домене используются механизмы мандатного управления доступом, не забудьте удалить также домашние директории доменных пользователей из папки /home/.pdp.

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

sudo rm -rf /var/lib/sss/pubconf/krb5.include.d/
sudo rm -rf /etc/krb5.conf.d/
sudo rm -rf /var/lib/sss/
sudo rm -rf /etc/sssd/
sudo rm -rf /opt/rbta/aldpro/
sudo rm -rf /etc/syslog-ng/aldpro/
sudo rm -rf /etc/salt/minion.d/
sudo rm -rf /var/log/salt/
sudo rm -rf /var/lib/certmonger/
sudo rm -rf /var/tmp/aldpro-salt.ccache

Далее следует удалить корневой сертификат домена из файла /etc/ssl/certs/cacertificates.crt, для этого нужно выполнить команду update-ca-certificates:

sudo update-ca-certificates

В завершение компьютеру нужно установить короткое имя, которое было назначено машине при установке, например, astra, чтобы при выполнении команд sudo не получать предупреждений о невозможности разрешения полного имени pc-1.ald.company.lan. Точное имя вы можете увидеть в файле /etc/hosts. Для этого выполните команду:

sudo hostnamectl set-hostname astra

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

Действия на контроллере домена

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

Для того, чтобы никто не смог воспользоваться аккаунтом компьютера, который выведен из домена, при выполнении этой процедуры на клиентском компьютере утилита astra-freeipa-client автоматически удаляет из LDAP-каталога Kerberos-пароль для учетной записи этого компьютера.

Если выполнение команд на стороне клиента невозможно, то для удаления Kerberos-пароля хоста из LDAP-каталога вы можете воспользоваться командой host-disable утилиты ipa:

admin@dc-1:~$ ipa host-disable pc-1.ald.company.lan
ipa: ERROR: Эта запись уже отключена

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

Если же вы захотите привести LDAP-каталог в исходное состояние, как до ввода компьютера в домен, то нужно будет полностью удалить аккаунт компьютера и его DNS-записи. Сделать это можно из терминала следующими командами:

kinit admin
ipa dnsrecord-del ald.company.lan. pc-1 --del-all
ipa host-del pc-1.ald.company.lan

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

admin@dc-1:~$ kinit admin

admin@dc-1:~$ ipa dnsrecord-del ald.company.lan. pc-1 --del-all
---------------------
Удалена запись "pc-1"
---------------------

admin@dc-1:~$ ipa host-del pc-1.ald.company.lan
----------------------------------
Удалён узел "pc-1.ald.company.lan"
----------------------------------

Информация для устаревших редакций продукта

В устаревших редакциях продукта до 2.3 включительно при выводе компьютера из домена нужно было удалить Salt-ключи этого компьютера на всех контроллерах домена командой sudo salt-key -y -d pc-1.ald.company.lan. Начиная с версии 2.4.0, управление подсистемами переведено полностью на автономную службу aldpro-salt-minion, поэтому компонент Salt Master более не используется и удалять Salt-ключи при выводе компьютера из домена теперь не требуется.

Вывод машины из домена с помощью ключа --remove

Начиная с версии 2.5, в утилите aldpro-client-installer появился ключ --remove, с помощью которого можно вывести машину из домена. Для этого потребуется выполнить следующие действия:

1. Войдите в систему с помощью учетной записи локального администратора localadmin.

2. Откройте окно терминала и выполните Kerberos-аутентификацию из-под администратора домена или любой другой привилегированной учетной записи, используя утилиту sudo, чтобы TGT-билет был сохранен в связке ключей суперпользователя root.

   Утилиту aldpro-client-installer в дальнейшем нужно будет запускать из-под суперпользователя, а для удаления хоста из домена она выполнит команду ipa host_del, которая использует билеты из связки ключей текущего пользователя, поэтому kinit нужно выполнять через sudo.

localadmin@pc-1:~$ sudo kinit admin
Password for admin@ALD.COMPANY.LAN:

3. Выполните команду aldpro-client-installer с ключами --remove и --gui:

localadmin@pc-1:~$ sudo /opt/rbta/aldpro/client/bin/aldpro-client-installer --remove --gui

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

Под капотом утилита aldpro-client-installer остановит службы, удалит учетную запись хоста с помощью команды ipa host_del, выведет хост из домена командой astra-freeipa-client -U и удалит ненужные файлы.

localadmin@pc-1:~$ sudo /opt/rbta/aldpro/client/bin/aldpro-client-installer --remove --gui
Введите пароль:
systemctl disable aldpro-client-rdm.service aldpro-client-service-discovery.service zabbix-agent.service --now
Synchronizing state of zabbix-agent.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable zabbix-agent
Removed /etc/systemd/system/multi-user.target.wants/aldpro-client-service-discovery.service.
Removed /etc/systemd/system/multi-user.target.wants/aldpro-client-rdm.service.
Removed /etc/systemd/system/multi-user.target.wants/zabbix-agent.service.
ipa host_del pc-1.ald.company.lan --updatedns --continue
/usr/bin/astra-freeipa-client -U -y
Unenrolling client from IPA server
Unenrolling host failed: Error obtaining initial credentials: Client not found in Kerberos database.

Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted
Restoring client configuration files
Unconfiguring the NIS domain.
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Some installation state for ntp has not been restored, see /var/lib/ipa/sysrestore/sysrestore.state
Some installation state has not been restored.
This may cause re-installation to fail.
It should be safe to remove /var/lib/ipa-client/sysrestore.state but it may
mean your system hasn't been restored to its pre-installation state.
Systemwide CA database updated.
Client uninstall complete.
The original nsswitch.conf configuration has been restored.
You may need to restart services or reboot the machine.
The ipa-client-install command failed. See /var/log/ipaclient-uninstall.log for more information
Use of uninitialized value $fieldname in hash element at /usr/sbin/pam-auth-update line 704, <PROFILE> line 1.
Use of uninitialized value $fieldname in hash element at /usr/sbin/pam-auth-update line 705, <PROFILE> line 1.
Use of uninitialized value $fieldname in hash element at /usr/sbin/pam-auth-update line 704, <PROFILE> line 1.
Use of uninitialized value $fieldname in hash element at /usr/sbin/pam-auth-update line 705, <PROFILE> line 1.
rm -f /etc/salt/minion_id
rm -f /etc/salt/minion.d/masters.conf
rm -rf /etc/salt/pki/*
rm -f /etc/zabbix/zabbix_agentd.conf.d/00-servers.conf
rm -rf /etc/syslog-ng/aldpro/*
rm -rf /var/tmp/aldpro-salt.ccache
rm -rf /var/run/aldpro-client-discovering/masters_dict.json
systemctl restart syslog-ng

Графическая утилита aldpro-join

Если запустить утилиту aldpro-client-installer без параметров, то откроется окно графического интерфейса, см. рис. 176. Однако следует принять во внимание, что графический режим стандартной утилиты предоставляет только базовые возможности для интерактивного заполнения полей и считается уже устаревшим.

рис. 176 Устаревший графический интерфейс для ввода компьютера в домен

Запуск в графическом режиме после изменения имени хоста

Если при запуске утилиты в графическом режиме возникнет ошибка qt.qpa.xcb: could not connect to display :0, значит имя хоста было изменено после входа в систему. В этом случае вам нужно просто перезапустить графическую сессию следующей командой:

sudo systemctl restart fly-dm

Для удобства присоединения компьютеров Astra Linux к домену ALD Pro была разработана дополнительная графическая утилита aldpro-join, которая предоставляет Windows-администраторам знакомый интерфейс и дополнительные преимущества, в том числе возможность присоединения компьютера в заданное структурное подразделение. Утилита предоставляется через личный кабинет, начиная с релиза 2.5.0, но поддерживает работу в том числе и с предыдущей LTS-версией 2.4.0. В последующих релизах код утилиты aldpro-join будет включен в состав утилиты aldpro-client-installer.

Ввод компьютера в домен с помощью утилиты aldpro-join

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

Далее нужно выполнить следующие действия:

1. Скачайте архив с deb-пакетом по прямой ссылке или из личного кабинета и установите его следующей командой:

sudo DEBIAN_FRONTEND=noninteractive \
  apt-get install -y -q ./aldpro-join_2.0-2_amd64.deb

2. Запустите утилиту из меню Пуск ‣ ALD Pro ‣ Ввод компьютера в домен ALD Pro v2.0, этот ярлык использует команду aldpro-join --gui.

рис. 177 Запуск приложения для присоединения к домену v2.0

3. Чтобы изменить имя компьютера, нажмите кнопку Изменить… напротив имени компьютера и установите желаемое значение, например, pc-14.

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

рис. 178 Изменение имени компьютера

4. Установите переключатель в положение Участник домена ALD Pro и введите имя домена, например, ald.company.lan. Нажмите кнопку ОК, чтобы начать присоединение компьютера к домену.

5. В окне аутентификации введите учетные данные доменного администратора. Это может быть пользователь admin, но можно создать отдельную учетную запись, привилегий которой будет достаточно только для ввода машин в домен. Информация представлена в руководстве администратора.

рис. 179 Ввод имени администратора домена для присоединения компьютера

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

рис. 180 Выбор организационного подразделения

7. Если процедура присоединения компьютера ALSE к домену прошла успешно, вы увидите соответствующее уведомление. Обратите внимание, что утилита сразу применяет групповые политики, политики ПО и задания автоматизации, поэтому процедура может занять некоторое время, наберитесь терпения.

рис. 181 Выполните перезагрузку системы

Журнал событий вы сможете посмотреть в файле /var/log/.aldpro-join.log. После перезагрузки компьютера вам станет доступен вход в систему доменным пользователем.

Вывод компьютера из домена

Если вы захотите вывести компьютер из домена, вам достаточно будет запустить приложение еще раз из-под локального администратора localadmin, установить переключатель в положение Недоменный компьютер и нажать кнопку ОК. Учетная запись компьютера и его DNS-записи будут удалены из домена.

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

Проверка доверия с доменом

При вводе компьютера в домен для него создается учетная запись, пароль которой сохраняется в файле /etc/krb5.keytab. Если компьютер располагает актуальным паролем от своей учетной записи в домене, говорят, что между компьютером и доменом установлены доверительные отношения (англ. Trust relationship between a domain-joined device and its domain).

Срок действия пароля компьютера не ограничен, но в домене MS AD он обновляется каждые 30 дней, поэтому при восстановлении компьютера из старой резервной копии вы можете столкнуться с тем, что он потеряет доверие с доменом. В домене FreeIPA пароль компьютера автоматически не обновляется, но вы можете настроить доп. параметр групповой политики ALD Pro, с помощью которого реализовать ту же логику, поэтому в утилиту aldpro-join встроен механизм для проверки и восстановления доверия с доменом.

Чтобы проверить актуальность пароля компьютера, нажмите кнопку Проверить… напротив имени домена. В поле Версия ключа и дата выдачи будет отображать значение в следующем формате: <Версия пароля> <Дата изменения пароля> <Время изменения пароля>.

рис. 182 Проверка доверия с доменом

Обновление пароля компьютера и восстановление доверия с доменом

Если нажать кнопку Обновить, то приложение установит компьютеру новый пароль и сохранит его в файл /etc/krb5.keytab.

рис. 183 Обновление пароля компьютера

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

Настройка балансировки DNS-запросов на рабочих станциях Linux в домене

Для обеспечения надежной работы компьютера в составе домена в его настройках указывают только имя домена, а не IP-адреса конкретных контроллеров, которые со временем могут оказаться недоступны или вовсе выведены из эксплуатации. Автоматическое обнаружение доступных контроллеров домена выполняется с помощью SRV-записей, извлекаемых из DNS, например, для аутентификации в домене ald.company.lan компьютер выбирает Kerberos-сервер из списка SRV-записей, зарегистрированных по адресу _kerberos._tcp.ald.company.lan. Отказоустойчивость самой функции разрешения имен достигается за счет того, что в настройках сетевого интерфейса указывают сразу несколько DNS-серверов, чтобы компьютер мог автоматически переключиться на следующий доступный DNS-сервер из предложенного списка.

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

Как механизм разрешения доменных имен работает в Windows

На компьютерах Windows разрешение доменных имен выполняется через DNS-клиент, который использует список серверов, заданных в настройках сетевых интерфейсов.

Порядок разрешения имен одинаковый на всех Windows-хостах, вне зависимости от того, являются ли они рабочими станциями, серверами или им назначена роль контроллера домена. Если настройками определено три DNS-сервера, то порядок разрешения имен выглядит следующим образом:

табл. 16 Порядок разрешения имен в Windows

Сколько времени прошло с момента получения запроса, сек	Выполняемое действие	Время ожидания, сек
0	Клиент направляет запрос первому DNS-серверу	1
1	Если ответ не получен за 1 секунду, то запрос направляется второму DNS-серверу. Если второй DNS-сервер не задан, то запрос будет направлен повторно первому DNS-серверу.	1
2	Если ответ не получен за 1 секунду, то запрос направляется третьему DNS-серверу. Если третий DNS-сервер не задан, то запрос будет направлен повторно второму DNS-серверу, а если и второй DNS-сервер не задан, то первому DNS-серверу.	2
4	Если ответ не получен за 2 секунды, то запрос направляется сразу всем оставшимся DNS-серверам, т.е. четвертому и последующим.	4
8	Если ответ не получен за 4 секунды, то запрос еще раз направляется всем DNS-серверам с первого по третий.	2
10	Если ответ не получен за 2 секунды, то клиент прекращает попытки выполнения запросов.

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

• через 15 минут по истечении таймаута ServerPriorityTimeLimit;

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

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

Настройки DNS-клиента могут быть заданы в ветке реестра Windows HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters.

Как механизм разрешения доменных имен работает в Linux

Базовый механизм разрешения доменных имен в библиотеке glibc (утилиты ping, getent)

Для большинства Linux-утилит, таких как ping или getent, в роли DNS-клиента выступает функция getaddrinfo() из стандартной библиотеки glibc, которая в своей работе использует диспетчер имен (Name Service Switch, NSS). При каждом вызове этой функции выполняется подключение к Unix-сокету, который является частью системы NSS.

По умолчанию в файле /etc/nsswitch.conf определена строка hosts: files dns, поэтому в соответствии с параметром files система NSS проверяет сначала записи из локального файла /etc/hosts, а затем в соответствии с параметром dns переходит к опросу серверов из файла /etc/resolv.conf, см. рис. 184.

рис. 184 Порядок обработки DNS-запросов в glibc

Системная функция gethostbyname() может работать только с тремя DNS-серверами и по умолчанию использует настройки options attempts:2 timeout:5, поэтому в случае трех серверов порядок разрешения доменных имен будет следующим:

табл. 17 Порядок разрешения имен в библиотеке glibc

Сколько времени прошло с момента получения запроса, сек	Выполняемое действие	Время ожидания, сек
0	Попытка 1: клиент направляет запрос первому DNS-серверу.	5
5	Попытка 1: если ответ не получен за 5 секунд, то запрос направляется второму DNS-серверу. Если второй DNS-сервер не задан, то шаг пропускается.	3 (2/3 от таймаута)
8	Попытка 1: если ответ не получен за 3 секунды, то запрос направляется третьему DNS-серверу. Если третий DNS-сервер не задан, то шаг пропускается.	6 (4/3 от таймаута)
14	Попытка 2: если ответ не получен за 6 секунд, то запрос повторно направляется первому DNS-серверу.	5
19	Попытка 2: если ответ не получен за 5 секунд, то запрос повторно направляется второму DNS-серверу. Если второй DNS-сервер не задан, то шаг пропускается.	3 (2/3 от таймаута)
22	Попытка 2: если ответ не получен за 3 секунды, то запрос повторно направляется третьему DNS-серверу. Если третий DNS-сервер не задан, то шаг пропускается.	6 (4/3 от таймаута)
28	Если ответ не получен за 6 секунд, то клиент прекращает попытки выполнения запросов.

В конфигурационном файле /etc/resolv.conf может быть определен ряд параметров, с помощью которых можно повлиять на алгоритм работы DNS-клиента:

• nameserver — определяет список DNS-серверов.

• search — определяет список поисковых суффиксов, которые будут добавляться к неполным именам, которые не заканчиваются символом точки.

• options ndots:n – определяет логику обработки неполных адресов, которые не завершаются символом точки. Если в запрашиваемом адресе количество точек будет соответствовать указанному значению или превышать его, то этот адрес будет интерпретирован сначала как полный адрес, и только затем к нему будет предприняты попытки добавления поисковых суффиксов, которые заданы параметром search. По умолчанию ndots:1, поэтому при наличии одной и более точек адрес считается полным.

• options attempts:n – определяет количество попыток обращения к DNS-серверам, причем каждая попытка предполагает полный проход по списку всех DNS-серверов. Например, по умолчанию опция attempts равна 2, поэтому при недоступности указанных DNS-серверов клиент суммарно сделает по два обращения к каждому из них. Для функций glibc допустимыми являются значения 1-5. Значение меньше 1 отключает функцию разрешения имен. Значение более 5 интерпретируется как 5.

• options timeout:n – определяет время ожидания ответа на отправленный DNS-запрос, прежде чем будет выполнен переход к следующему DNS-серверу. Для функций glibc максимальное значение timeout составляет 30 секунд, и если установить значение больше, то оно будет усечено до максимально допустимого значения. По умолчанию опция timeout равна 5 секундам.

• options rotate – определяет, что DNS-клиент будет ротировать DNS-сервера, выбирая их случайным образом из списка, чтобы распределить нагрузку. По умолчанию считается, что параметр не задан, поэтому клиент перебирает DNS-серверы по очереди в соответствии с указанным порядком.

Если никакие кэширующие сервисы не используются, то для ускорения обработки запросов к glibc мы рекомендуем установить параметр options attempts:1 timeout:1. По нашему мнению, при хорошей доступности DNS-сервера задержки в одну секунду вполне достаточно для обработки запросов, а дополнительные попытки являются излишними — намного полезнее дать быстрый отказ, чем тратить время на повторные обращения к недоступным серверам.

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

time ping dc-1.ald.company.lan. -n -c 1

Пояснения:

• Точка в конце запрашиваемого адреса dc-1.ald.company.lan. указывает, что значение следует интерпретировать только как полный адрес и не пытаться дополнять его поисковыми суффиксами, которые могут быть заданы параметром search. Если этого не сделать, то при недоступности DNS-серверов суммарное время ожидания может быть больше в несколько раз по количеству поисковых суффиксов, т.к. система сначала проверит указанный адрес, а затем будет проверять его еще раз с добавлением поисковых суффиксов.

• В файле /etc/resolv.conf может быть определен параметр ndots, который определяет порядок обработки неполных адресов, не заканчивающихся символом точки. По умолчанию опция ndots равна 1, поэтому, если в запрашиваемом адресе будет одна и более точек, например, dc-1.ald.company.lan, то этот адрес сначала будет интерпретирован как полный адрес, и только затем к нему будет предпринята попытка добавления поисковых индексов, например, dc-1.ald.company.lan.ald.company.lan. В том случае, когда один из DNS-серверов доступен, наличие точки в конце адреса не мешает, но если они все недоступны, это может привести к увеличению суммарного времени ожидания в несколько раз, в зависимости от количества поисковых индексов.

• Ключ -n позволит отключить отправку запроса на получение PTR-записи, иначе суммарное время ожидания будет больше в два раза.

• Ключ -c позволит остановить работу после передачи одного пакета, чтобы трассировка не внесла существенных искажений в итоговые результаты.

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

time getent ahosts dc-1.ald.company.lan.

Пояснения:

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

• Обращение к базе данных ahosts позволит вам запросить только A-записи. Если же обращаться к базе данных hosts, то будет последовательно отправлено два запроса на получение записей A и AAA, что увеличит суммарное время ожидания в два раза.

Механизм разрешения доменных имен в утилитах BIND (host, nslookup, dig)

Более продвинутые приложения, такие как host, nslookup и dig, созданные в рамках открытой реализации DNS от Berkeley Internet Name Domain (BIND), используют собственный DNS-клиент, не обращаясь к системной функции getaddrinfo(), поэтому изменения в файле /etc/nsswitch.conf никак не отразятся на их работе. Вместе с тем, они используют общие настройки из файла /etc/resolv.conf, интерпретируя их почти также, но с некоторыми отличиями:

• nameserver — так же, как для glibc, определяет список DNS-серверов;

• search — так же, как для glibc, определяет список поисковых суффиксов, которые будут добавляться к неполным доменным именам, которые не заканчиваются точкой;

• options ndots:n – так же, как для glibc, определяет логику обработки неполных адресов и использует значение 1 по умолчанию. Но при этом есть существенное отличие: если в запрашиваемом адресе количество точек будет соответствовать указанному значению или превышать его, то этот адрес будет интерпретирован только как полный адрес. Это означает, что при недоступности серверов утилиты не будут предпринимать попытки добавления к запрашиваемому адресу поисковых суффиксов, поэтому указывать точку в конце адреса не требуется;

• options attempts:n – так же, как для glibc, определяет количество попыток и использует значение 2 по умолчанию. Но при этом есть ряд существенных отличий:

• нумерация попыток начинается с нуля, поэтому при значении attempts:2 будет выполнено три цикла обращений к серверам, при значении attempts:3 уже четыре цикла и так далее. Таким образом для утилит BIND опция определяет не совсем «количество попыток» (attempts), а больше «количество повторных попыток» (retries);

• если установить значение attempts:0, то оно будет интерпретировано как attempts:1, т.е. в этом случае будет выполнено как минимум два цикла обращений к DNS-серверам. Разрешение имен в утилитах BIND перестанет работать, только в том случае, если для опции attemtps установить отрицательное значение.

• значение attempts не ограничено сверху 5 попытками. Вы можете использовать любое целое положительное значение, что соответствующим образом повлияет на общую продолжительность обработки запросов утилитами BIND.

• options timeout:n — так же, как для glibc, определяет время ожидания ответа на отправленный DNS-запрос, но резолвер BIND реализует более сложную логику работы с таймаутами, поэтому есть ряд существенных отличий:

• если резолвер не получит ответ от DNS-сервера за 1 секунду, то обращение будет направлено параллельно к следующему серверу;

• следующая серия DNS-запросов (следующая попытка) не начнется, пока не будут получены ответы на запросы, отправленные в рамках предыдущей серии.

• options rotate – точно так же, как для glibc, определяет, что DNS-клиент будет ротировать DNS-сервера, выбирая их случайным образом из списка, чтобы распределить нагрузку. По умолчанию считается, что параметр не задан, поэтому клиент перебирает DNS-серверы по очереди в соответствии с указанным порядком.

Утилиты BIND могут работать только с тремя DNS-серверами. В случае трех серверов с настройками по умолчанию порядок разрешения доменных имен будет следующим:

табл. 18 Порядок разрешения имен в утилитах BIND

Сколько времени прошло с момента получения запроса, сек	Выполняемое действие	Время ожидания, сек
0	Попытка 0: клиент направляет запрос первому DNS-серверу.	1
1	Попытка 0: если ответ не получен за 1 секунду, то запрос направляется второму DNS-серверу. Если второй DNS-сервер не задан, то шаг пропускается.	1
2	Попытка 0: если ответ не получен за 1 секунду, то запрос направляется третьему DNS-серверу. Если третий DNS-сервер не задан, то шаг пропускается.	5
7	Попытка 1: если ответ не получен за 5 секунд, то запрос повторно направляется первому DNS-серверу.	1
8	Попытка 1: если ответ не получен за 1 секунду, то запрос направляется второму DNS-серверу. Если второй DNS-сервер не задан, то шаг пропускается.	1
9	Попытка 1: если ответ не получен за 1 секунду, то запрос направляется третьему DNS-серверу. Если третий DNS-сервер не задан, то шаг пропускается.	5
14	Попытка 2: если ответ не получен за 5 секунд, то запрос повторно направляется первому DNS-серверу.	1
15	Попытка 2: если ответ не получен за 1 секунду, то запрос направляется второму DNS-серверу. Если второй DNS-сервер не задан, то шаг пропускается.	1
16	Попытка 2: если ответ не получен за 1 секунду, то запрос направляется третьему DNS-серверу. Если третий DNS-сервер не задан, то шаг пропускается.	5
21	Если ответ не получен за 5 секунд, то клиент прекращает попытки выполнения запросов.

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

time host -t A dc-1.ald.company.lan

Пояснения:

• Ключ -t позволит запросить только A-запись. Если же его не указывать, то будет отправлено три запроса на получение записей A, AAA, MX, что увеличит суммарное время обработки запроса в три раза. При недоступности сервера это не повлияет на время ожидания.

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

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

time nslookup -q=A dc-1.ald.company.lan

Пояснения:

• Ключ -q=A позволит запросить только A-запись. Если же его не указывать, то будет отправлено два запроса на получение записей A и AAAA, что увеличит суммарное время обработки запроса в два раза. Обратите внимание, что при недоступности сервера запрос на получение AAAA-записи к нему не отправляется, поэтому в таком сценарии значение этого параметра не повлияет на общее время ожидания.

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

Механизм разрешения доменных имен в службе sssd

Для разрешения доменных имен служба sssd, также как утилиты BIND, использует собственный DNS-клиент, не обращаясь к системной функции getaddrinfo(), поэтому изменения в файле /etc/nsswitch.conf никак не отразятся на работе sssd. Параметры конфигурационного файла /etc/resolv.conf служба sssd интерпретирует следующим образом:

• nameserver — точно так же, как для glibc, определяет список DNS-серверов;

• search — точно так же, как для glibc, определяет список поисковых суффиксов, которые будут добавляться к неполным доменным именам, которые не заканчиваются точкой. Использование поисковых суффиксов можно отключить в конфигурационном файле /etc/sssd/sssd.conf с помощью параметра dns_resolver_use_search;

• options ndots:n — точно так же, как для glibc, определяет логику обработки неполных адресов: если в запрашиваемом адресе количество точек будет соответствовать указанному значению или превышать его, то этот адрес будет интерпретирован сначала как полный адрес, и только затем к нему будет предприняты попытки добавления поисковых суффиксов, которые заданы параметром search;

• options attempts:n — не используется. Служба sssd предпринимает только одну попытку обращения ко всем DNS-серверам, а следующую попытку выхода из автономного режима служба sssd предпримет по истечению таймаута, заданного параметром offline_timeout (по умолчанию 60 секунд) + случайная задержка продолжительностью от 0 секунд до offline_timeout_random_offset (по умолчанию составляет 30 секунд). Параметр offline_timeout_random_offset можно настроить в конфигурационном файле /etc/sssd/sssd.conf, начиная с версии ALSE 1.8, что связано с переходом на SSSD версии 2.5;

• options rotate — точно так же, как для glibc, определяет, что нужно ротировать DNS-серверы, выбирая их из списка случайным образом, чтобы распределить нагрузку.

Для настройки баланса между производительностью и надежностью разрешения имен в секции домена конфигурационного файла /etc/sssd/sssd.conf можно использовать следующие параметры:

• dns_resolver_server_timeout — максимальное время (в миллисекундах) ожидания ответа до перехода к следующему DNS-серверу. По умолчанию параметр имеет значение 1000 миллисекунд.

• dns_resolver_op_timeout — максимальное время (в секундах) ожидания для разрешения одного DNS-запроса (например, разрешение имени хоста или получение SRV-записей) до перехода к следующему имени. Это значение должно быть больше значения параметра dns_resolver_server_timeout. По умолчанию параметр имеет значение 3 секунды.

• dns_resolver_timeout — максимальное время (в секундах) получения ответа от резолвера. При достижении этого лимита служба sssd переключает домен в автономный режим. Это значение должно быть больше значения параметра dns_resolver_op_timeout. По умолчанию параметр имеет значение 6 секунд.

• try_inotify — позволяет включить/отключить отслеживание изменений в конфигурационном файле /etc/resolv.conf через механизм inotify. По умолчанию параметр имеет значение TRUE. Параметр имеет смысл только в том случае, если система поддерживает функцию inotify.

• lookup_family_order — порядок выбора сетевых протоколов для разрешения имен. Допустимые значения:

• ipv4_first — сначала использовать IPv4, в случае неудачи — использовать IPv6 (это значение используется по умолчанию);

• ipv4_only — использовать только IPv4;

• ipv6_first — сначала использовать IPv6, в случае неудачи — использовать IPv4;

• ipv6_only — использовать только IPv6.

• dns_resolver_use_search_list — определяет, должна ли служба sssd пытаться дополнять доменные имена поисковыми суффиксами. По умолчанию используется значение TRUE, что может привести к задержкам в обработке запросов при неправильных настройках DNS. Например, если в файле /etc/sssd/sssd.conf в параметре ipa_server указать короткое имя, то служба sssd будет по очереди подставлять все известные суффиксы и проверять доступность полученных имен.

• ldap_opt_timeout — значение параметра определяет время в секундах, за которое должен быть получен ответ на синхронный LDAP-запрос. Этот параметр напрямую не связан с настройками DNS, но если в качестве бэкенда используется обычный LDAP-сервер, то операция разрешения имен будет частью синхронного запроса на подключение к LDAP-серверу, поэтому значение ldap_opt_timeout должно быть обязательно больше значения dns_resolver_timeout.

Как в Linux реализовать кэширование DNS-ответов и переключение на предпочтительный DNS-сервер с помощью службы systemd-resolved

Базовая настройка службы systemd-resolved

В операционной системе Astra Linux есть служба systemd-resolved, которая как DNS-клиент Windows способна запоминать предпочтительный DNS-сервер и кэшировать DNS-ответы, включая ненайденные результаты (негативный кэш). В этой службе реализован следующий алгоритм разрешения доменных имен:

• Резолвер начинает обработку запроса с обращения к предпочтительному серверу. Если служба systemd-reolved была перезапущена, то предпочтительным сервером назначается первый DNS-сервер по списку.

• Обращение к DNS-серверам выполняется по кругу (round robin): если DNS-сервер окажется недоступен, то запрос будет направлен к следующему серверу по списку. При достижении конца списка служба перейдет к его началу.

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

• Резолвер попеременно выполняет попытки подключения по UPD с таймаутом 5 секунд и по TCP с таймаутом 10 секунд.

• В рамках проверки каждого протокола резолвер совершает по 3 попытки с полным обходом всех DNS-серверов. Общая продолжительность попытки зависит от количества серверов, служба поддерживает более трех DNS-серверов.

• Обработка запроса прекращается по достижению 24 попыток разрешения запрашиваемого имени через серверы из списка либо по достижению лимита времени обработки запроса в 120 секунд.

• Все указанные значения (5 секунд ожидания для UDP, 10 секунд ожидания для TCP, 3 попытки обхода DNS-серверов, 24 попытки на разрешение запроса и общее время ожидания в 120 секунд) определены в программном коде как константы и их нельзя переопределить через конфигурационный файл.

В Astra Linux Special Edition 1.7 эта служба является частью systemd, поэтому уже установлена, но по умолчанию отключена.

$ sudo systemctl status systemd-resolved.service
systemd-resolved.service - Network Name Resolution
  Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
 Drop-In: /usr/lib/systemd/system/systemd-resolved.service.d
          └─resolvconf.conf
  Active: inactive (dead)
    Docs: man:systemd-resolved.service(8)
          https://www.freedesktop.org/wiki/Software/systemd/resolved
          https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
          https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

Включить службу systemd-resolved в ALSE 1.7 можно через systemctl командами enable и start:

$ sudo systemctl enable systemd-resolved.service
Created symlink /etc/systemd/system/dbus-org.freedesktop.resolve1.service → /lib/systemd/system/systemd-resolved.service.
Created symlink /etc/systemd/system/multi-user.target.wants/systemd-resolved.service → /lib/systemd/system/systemd-resolved.service.

$ sudo systemctl start systemd-resolved.service

В Astra Linux Special Edition 1.8 служба находится в отдельном deb-пакете systemd-resolved из основного репозитория main, который нужно дополнительно установить с помощью пакетного менеджера:

$ apt policy systemd-resolved
systemd-resolved:
  Установлен: 252.17-1~deb12u1astra.se3+ci2
  Кандидат:   252.17-1~deb12u1astra.se3+ci2
  Таблица версий:
 *** 252.17-1~deb12u1astra.se3+ci2 900
        900 https://download.astralinux.ru/astra/frozen/1.8_x86-64/1.8.2/uu/1/repository-main 1.8_x86-64/main
amd64 Packages

Служба запускает процесс /lib/systemd/systemd-resolved, который начинает прослушивать порты 53/TCP и 53/UDP на адресах IPv4 127.0.0.53 и IPv6 :::5355.

netstat -ntlupaW | grep resol
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      13665/systemd-resol
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      13665/systemd-resol
tcp6       0      0 :::5355                 :::*                    LISTEN      13665/systemd-resol
udp        0      0 127.0.0.53:53           0.0.0.0:*                           13665/systemd-resol
udp        0      0 0.0.0.0:5355            0.0.0.0:*                           13665/systemd-resol
udp6       0      0 :::5355                 :::*                                13665/systemd-resol

Чтобы переключить операционную систему Linux на использование кэширующего сервера systemd-resolved в некоторых инструкциях предлагается установить пакет libnss-resolve, который содержит модуль libnss_resolve.so.2, позволяющий перехватывать системные вызовы на разрешение имен через nsswitch и обрабатывать их напрямую через systemd-resolved, отправляя этой службе запросы по шине dbus. После установки пакета в файле /etc/nsswitch.conf в параметре hosts перед обращением к dns появится вызов модуля resolve:

cat /etc/nsswitch.conf | grep hosts
hosts:          files resolve [!UNAVAIL=return] dns

Но поскольку служба sssd и большинство других приложений (таких как host, nslookup, dig) не обращаются к системным вызовам, а отправляют запросы к DNS-серверам напрямую, мы не рекомендуем устанавливать пакет libnss-resolve и использовать его NSS-модуль, т.к. это только усложнит процесс отладки. Для переключения службы NetworkManager на использование кэширующего сервера systemd-resolved в секции main конфигурационного файла /etc/NetworkManager/NetworkManager.conf нужно определить параметры dns=systemd-resolved и rc-manager=symlink.

cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile
dns=systemd-resolved
rc-manager=symlink

[ifupdown]
managed=false

В этом случае служба NetworkManager в файл /etc/resolv.conf будет вписывать адрес локального кэширующего сервера 127.0.0.53:

$ cat /etc/resolv.conf
# Generated by NetworkManager
search ald.company.lan
nameserver 127.0.0.53

В некоторых инструкциях предлагается альтернативный вариант настройки, который позволяет добиться того же результата. Вместо параметра dns=systemd-resolved вы можете для файла /etc/resolv.conf просто создать символическую ссылку, которая будет указывать на файл /run/systemd/resolve/stub-resolv.conf:

ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

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

Полезные команды

Список необходимых DNS-серверов служба NetworkManager будет передавать в службу systemd-resolved напрямую через шину dbus. Текущее состояние резолвера можно будет посмотреть командой resolvectl status (или аналогичной командой systemd-resolve --status):

$ resolvectl status
...
Link 2 (eth0)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
DefaultRoute setting: yes
      LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
      DNSSEC setting: allow-downgrade
   DNSSEC supported: yes
Current DNS Server: 10.0.1.11
         DNS Servers: 10.0.1.11
         DNS Domain: ~.
                     ald.company.lan

Для очистки кэша используется команда flush-caches:

$ resolvectl flush-caches

В случае, если разрешение имён не работает, то мы смотрим список DNS-серверов при помощи resolvectl status, затем выполняем последовательно запрос при помощи dig или nslookup к службе systemd-resolved и к DNS-серверу:

dig ya.ru @127.0.0.53
dig ya.ru @77.88.8.8

# или nslookup

nslookup ya.ru 127.0.0.53
nslookup ya.ru 77.88.8.8

Оптимизация настроек службы sssd

Исходя из особенностей алгоритма разрешения имен службами sssd и systemd-resolved, в настройках конфигурационного файла /etc/sssd/sssd.conf рекомендуется задать следующие значения параметров:

• Параметр dns_resolver_server_timeout установить равным 15000. Данная настройка задает максимальное время ожидания ответа от одного сервера. При установке службы systemd-resolved она является единственным DNS-сервером (stub-резолвером), указанным на рабочей станции, поэтому значение необходимо установить в соответствии с максимальным временем ожидания этой службы. Так как максимальным временем ожидания ответа от сервера службой systemd-resolved является 5 секунд, то при наличии 3 серверов имён максимальное время опроса составит 15 секунд (в случае отсутствия ответа от всех 3 серверов).

• Параметр dns_resolver_op_timeout установить равным 15. Эта настройка задает максимальное время ожидания на разрешение одного имени несколькими серверами. Так как DNS-сервер один, выставление значения больше, чем dns_resolver_server_timeout, не имеет смысла.

• Параметр dns_resolver_timeout установить равным 30. Эта настройка задает максимальное время службы DNS на разрешение имен. Следует выставить её равной разрешению двух DNS-имен, так как при невозможности автоматического обнаружения контроллера домена служба перейдет к разрешению имени контроллера, указанного в ее настройках (15 с + 15 с).

Оптимизация параметров загрузки службы systemd-resolved

Учитывая важность функции разрешения имен для современных компьютеров, служба dnscache запускается в Windows автоматически при загрузке операционной системы и так же автоматически перезапускается в случае падения. В процессе работы службы кэш очищается автоматически по мере старения записей в соответствии с значением их TTL (Time to Live), но полной очистки кэша при включении/выключении сетевых интерфейсов или изменении DNS-серверов не происходит. По указанной причине в домене настоятельно не рекомендуется использовать технологию «DNS Split», когда клиенты получают разные DNS-записи при работе из офиса и за пределами локальной сети. Полностью очистить DNS-кэш на Windows-компьютерах можно только вручную с помощью команды ipconfig -flushdns.

При настройке службы systemd-resolved на Linux-компьютере мы включили ее командой systemctl enable, поэтому при загрузке операционной системы служба будет запускаться автоматически. Для того, чтобы служба еще и перезапускалась автоматически при падении, нам нужно будет настроить параметры Restart и RestartSec. Также, во избежание проблем с очередностью загрузки служб, установим еще параметр Before, чтобы служба sssd запускалась гарантированно после загрузки службы systemd-resolved. Изменения будем вносить с помощью команды edit утилиты systemctl:

systemctl edit systemd-resolved.service

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

[Unit]
Before=sssd.service

[Service]
Restart=on-failure
RestartSec=2s

Сниппет будет сохранен в файле /etc/systemd/system/systemd-resolved.service.d/override.conf, изменения в конфигурации службы будут применены автоматически утилитой systemctl при выходе из редактора, поэтому вызывать systemctl daemon-reload вручную не потребуется.

Повышение безопасности при вводе компьютеров в домен

При вводе машины в домен происходит выполнение утилиты ipa-getkeytab, которая устанавливает Kerberos-пароль для учетной записи компьютера в домене, используя привилегированную учетную запись. В небольших компаниях для этого используют учетную запись admin или включают персональную учетную запись сотрудника в группу admins, но это не подходит для крупных организаций с большим штатом ИТ-специалистов, где эту задачу поручают сотрудникам, не имеющим отношения к администрированию серверной группировки. Рассмотрим несколько способов повышения безопасности процедуры ввода компьютера в домен.

Присоединение к домену из-под учетной записи с ограниченными правами

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

Права доступа в службе каталога FreeIPA делегируются с помощью трехуровневой модели безопасности, которая включает в себя Роли (Roles), Привилегии (Privileges) и Разрешения (Permissions). На базовом уровне разрешениям соответствуют инструкции управления доступом 389 Directory Server (Access Control Instructions, ACI), с помощью которых можно предоставить доступ на чтение, запись, поиск и другие действия применительно ко всему каталогу, его ветке или конкретной записи. Разрешения группируются в привилегии, привилегии группируются в роли, а роли уже назначаются пользователям.

В службе каталога FreeIPA уже есть роль Enrollment Administrator, но у нее нет разрешения на создание хостов System: Add Hosts, поэтому она подходит для присоединения к домену только тех компьютеров, у которых уже есть учетная запись в домене:

admin@dc-1:~$ ipa role-show 'Enrollment Administrator'
  Имя роли: Enrollment Administrator
  Описание: Участники роли имеют привилегии, необходимые для регистрации компьютеров в домене: - регистрация компьютеров в домене; - управление аутентификационными данными компьютеров.
  Privileges: Host Enrollment

admin@dc-1:~$ ipa privilege-show 'Host Enrollment'
  Имя привилегии: Host Enrollment
  Описание: Host Enrollment
  Разрешения: System: Add krbPrincipalName to a Host, System: Enroll a Host, System: Manage Host Certificates, System: Manage Host Enrollment Password, System: Manage Host Keytab,
              System: Manage Host Principals
  Предоставление привилегий ролям: Enrollment Administrator

Чтобы с помощью этой роли можно было присоединять к домену новые компьютеры, которых еще нет в службе каталога, мы могли бы добавить разрешение System: Add Hosts к привилегии Host Enrollment, которой обладает роль Enrollment Administrator, но лучше будет создать новую роль, которая будет вбирать в себя все необходимые разрешения.

Создадим новую роль Enrollment Manager, которой в дополнение к существующей привилегии Host Enrollment добавим новую привилегию Host Creation с разрешением System: Add Hosts:

ipa privilege-add 'Host Creation' \
  --desc='Создание новых хостов в домене'

ipa privilege-add-permission 'Host Creation' \
  --permissions='System: Add Hosts'

ipa role-add 'Enrollment Manager' \
  --desc='Участники имеют право создавать хосты и присоединять их к домену'

ipa role-add-privilege 'Enrollment Manager' \
  --privileges='Host Creation' \
  --privileges='Host Enrollment'

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

admin@dc-1:~$ ipa privilege-add 'Host Creation' \
>      --desc='Создание новых хостов в домене'
------------------------------------
Добавлена привилегия "Host Creation"
------------------------------------
Имя привилегии: Host Creation
Описание: Создание новых хостов в домене

admin@dc-1:~$ ipa privilege-add-permission 'Host Creation' \
>      --permissions='System: Add Hosts'
Имя привилегии: Host Creation
Описание: Создание новых хостов в домене
Разрешения: System: Add Hosts
-----------------------------------
Количество добавленных разрешений 1
-----------------------------------

admin@dc-1:~$ ipa role-add 'Enrollment Manager' \
>      --desc='Участники имеют право создавать хосты и присоединять их к домену'
-----------------------------------
Добавлена роль "Enrollment Manager"
-----------------------------------
Имя роли: Enrollment Manager
Описание: Участники имеют право создавать хосты и присоединять их к домену

admin@dc-1:~$ ipa role-add-privilege 'Enrollment Manager' \
>      --privileges='Host Creation' \
>      --privileges='Host Enrollment'
Имя роли: Enrollment Manager
Описание: Участники имеют право создавать хосты и присоединять их к домену
Privileges: Host Enrollment, Host Creation
-----------------------------------
Количество добавленных привилегий 2
-----------------------------------

Создадим нового пользователя Tech Support Engineer и назначим ему роль Enrollment Manager:

ipa user-add tse --first='Tech Support' --last='Engineer' --random

ipa role-add-member 'Enrollment Manager' --users=tse

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

admin@dc-1:~$ ipa user-add tse --first='Tech Support' --last='Engineer' --random
---------------------------
Добавлен пользователь "tse"
---------------------------
  Имя учётной записи пользователя: tse
  Имя: Tech Support
  Фамилия: Engineer
  Полное имя: Tech Support Engineer
  ...

admin@dc-1:~$ ipa role-add-member 'Enrollment Manager' --users=tse
  Имя роли: Enrollment Manager
  Описание: Участники имеют право создавать хосты и присоединять их к домену
  Пользователи-участники: tse
  Privileges: Host Enrollment, Host Creation
-----------------------------------
Количество добавленных участников 1
-----------------------------------

Возможности по управлению системными ролями и привилегиями на портале несколько ограничены, но вы можете назначать эти роли через веб-интерфейс на вкладке Роли страницы Пользователи и компьютеры ‣ Пользователи ‣ Пользователь, см. рис. 185. Для этого достаточно выполнить следующие три действия:

1. Найти нужную запись в списке всех ролей с помощью поиска по подстроке «enroll».

2. Кликнуть по стрелке «влево», чтобы перенести найденную запись в список назначенных (выбранных) ролей.

3. Нажать кнопку Сохранить, чтобы зафиксировать изменения.

рис. 185 Назначение роли «Enrollment Manager»

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

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

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

1. Откройте на портале управления раздел Управление доменом ‣ Роли и права доступа.

2. Создайте роль Spb Enrollment Manager для подразделения «Офис Спб» и назначьте ей следующие роли:

   • Computers - Read

   • Computers - Delete

   • Computers - Modify

   • Computers - Set organization unit

   • Organization units - Read

   • DNS Zones - Read

3. Нажмите кнопку Активировать роль и дождитесь, когда роль станет активна.

4. Через портал управления FreeIPA на странице разрешений найдите запись с именем вида ALDPRO ROCO Computers - Delete..., в которой дополнительный фильтр целей имеет значение (rbtadp=*ou=Офис Спб... и добавьте к этому разрешению право add к уже имеющемуся праву delete.

5. Назначьте пользователю эту роль чтобы он имел права на присоединение компьютеров в подразделение «Офис Спб».

Присоединение к домену с помощью одноразового пароля

Чтобы уменьшить риск разглашения паролей доменных администраторов при вводе компьютеров домен, в FreeIPA есть возможность присоединения машин по собственному паролю компьютера. В качестве такого пароля может выступать одноразовый LDAP-пароль или Kerberos-ключи компьютера. В этом курсе мы рассмотрим способ с использованием временного LDAP-пароля.

Этот способ обладает несколькими преимуществами:

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

• Учетную запись хоста можно сразу включить во все группы, чтобы на него распространялось действие необходимых правил HBAC и SUDO.

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

Продемонстрируем работу данного сценария на примере утилиты aldpro-client-install.

Сначала администратор домена должен создать учетную запись хоста с помощью команды ipa host-add, используя ключ --random для генерации одноразового пароля:

ipa host-add pc-2.ald.company.lan --random --ip-address=10.0.1.52 \
  --force --department='ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan'

Где:

• Параметр pc-2.ald.company.lan — имя компьютера в формате FQDN.

• Ключ random — это опция указывающая на требование сгенерировать случайный одноразовый пароль.

• Параметр ip-address — адрес компьютера для создания DNS-записи в домене.

• Ключ force — опция, которая позволяет принудительно установить значение имени узла, даже если такого имени нет в DNS.

• Параметр --department — аргумент, который позволяет создать хост в нужном подразделении.

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

admin@dc-1:~$ ipa host-add pc-2.ald.company.lan --random --ip-address=10.0.1.52 \
>      --force --department='ou=Московский офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan'
------------------------------------
Добавлен узел "pc-2.ald.company.lan"
------------------------------------
   Имя узла: pc-2.ald.company.lan
   Случайный пароль: 2LyXwGJItweZbvJP3LLqFCT
   Link to department: ou=Московский
         офис,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
   Link to head department: Московский офис
   Пароль: True
   Таблица ключей: False
   Managed by: pc-2.ald.company.lan

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

sudo /opt/rbta/aldpro/client/bin/aldpro-client-installer --host pc-2 \
  --domain ald.company.lan --pc --password '2LyXwGJItweZbvJP3LLqFCT' \
  --gui --force

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

• Требования, правила и цели выполнения практической работы
• Практическая работа: Модуль 2. Развертывание ALD Pro
• Тест: Модуль 2. Развертывание ALD Pro

Заключение

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

Дополнительные источники информации

• ALSE 1.7.7 UU2

• Рекомендуем ознакомиться также с видеороликами нашего хорошего товарища на канале «ИТ-Проповедник». Учитывайте, что ролики записаны для версии 2.2.1, поэтому часть информации потеряла актуальность, но в целом они могут быть крайне полезны.

  • ALD PRO 2.2.1 - развертывание первого контроллера домена

  • Сервер разрешения имен BIND 9 в ALD Pro 2.2.1

  • ALD PRO 2.2.1 - ввод клиента в домен

Обратная связь

Если остались вопросы, то их всегда можно задать в специальной теме.