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

Введение

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

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

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

Минимальные требования для тестовой среды в рамках настоящего курса

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

  • 8 ядер CPU

  • 12 ГБ свободной памяти (без учета нужд хостовой машины)

  • 255 ГБ свободного места на устройстве хранения. Желательно, чтобы диск был SSD, т.к. производительность работы контроллеров домена сильно зависит от скорости дисковой подсистемы.

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

Компонент системы

CPU Ядер

RAM

SSD

Кол-во

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

2

4 ГБ

30 ГБ

1 шт.

Резервный контроллер домена

2

4 ГБ

30 ГБ

1 шт.

Подсистема «Репозиторий ПО»

1

2 ГБ

50 ГБ

1 шт.

Подсистема «Общий доступ к файлам»

1

2 ГБ

25 ГБ

1 шт.

Подсистема «Служба печати»

1

2 ГБ

25 ГБ

1 шт.

Подсистема «Мониторинг»

1

2 ГБ

25 ГБ

1 шт.

Подсистема «Аудит»

1

2 ГБ

25 ГБ

1 шт.

Клиентская машина

1

2 ГБ

20 ГБ

1 шт.

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

Подготовка тестового стенда

Все восемь виртуальных машин будут работать в одной натированной сети, см. рис. 162.

../_images/aldpro_mod2_image4.png

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

Для установки ОС вам потребуется загрузить образ диска ALSE 1.7.4, доступный по ссылке. Сохраните его в любом удобном для вас месте.

Создание сети в VirtualBox

Взаимодействие между хостами в домене осуществляется через компьютерную сеть по стеку протоколов TCP/IP. Серверы из соображений безопасности обычно выносят в отдельную подсеть, чтобы ограничить к ним доступ правилами межсетевого экрана, но так как изучение этих аспектов безопасности не является предметом данного курса, то в нашем случае все хосты будут размещены в общей сети 10.0.1.0/24, созданной средствами VirtualBox.

Важно

Для правильной настройки межсетевых экранов в соответствии с концепцией нулевого доверия (Zero Trust) ознакомьтесь с полным перечнем правил межсетевого экрана xlsx

Чтобы создать сеть в VirtualBox, вам нужно выполнить следующие действия:

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

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

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

    • Имя сети: «Стенд ALD Pro»

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

    • Поддержка DHCP: «Откл» (сначала будем настраивать вручную, а потом с помощью собственной службы динамической настройки узлов)

../_images/aldpro_mod2_image5.png

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

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

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

Нам потребуется 8 виртуальных машин (VM) с установленной на них ОС Astra Linux 1.7.4, причем системные требования для контроллеров домена и остальных компьютеров будут немного отличаться. Но если количество виртуальных ЦПУ и объем памяти можно изменить в любой момент, то для выделения дополнительного места на диске потребуется расширять файловую систему внутри ОС, поэтому мы рекомендуем установить размер динамических дисков с запасом, так как это никак не скажется на размере файлов. Для упрощения процесса подготовки тестового стенда на всех машинах, в том числе и клиентской, будем использовать систему с максимальным уровнем защищенности и накопителем в 30 ГБ.

На контроллерах домена и подсистемах ALD Pro операционная система должна быть установлена в максимальном режиме защищенности «Смоленск», а для установки продукта администратору нужно будет войти в систему под высоким уровнем целостности 63. На рабочих станциях можно использовать любой уровень защищённости.

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

  1. Создать VM для контроллера домена ALD Pro.

  2. Установить на ней ОС Astra Linux с максимальным уровнем защищённости «Смоленск». Провести первоначальную настройку и установку гостевых дополнений (англ. Guest Additions), чтобы вам стал доступен буфер обмена и автоматическая подстройка под ширину экрана.

  3. Клонировать первую VM для резервного контроллера домена ALD Pro и одной из подсистем.

  4. Оптимизировать количество ресурсов VM подсистемы.

  5. Клонировать VM подсистемы еще пять раз для получения нужного количества машин.

Внимание

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

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

Из уникального в Linux только имя хоста, а с «SID компьютера» мы сталкиваемся только на контроллерах домена, где установлен набор программного обеспечения Samba AD, но установка контроллеров методом клонирования виртуальных машин и не предполагается.

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

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

  • Укажите имя и тип:

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

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

    • Тип: Linux

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

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

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

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

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

  • Укажите имя и размер файла

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

    • Размер: 30 ГБ

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

  • На вкладке Система ‣ Процессор укажите:

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

  • На вкладке Система ‣ Ускорение укажите: KVM

  • На вкладке Носители для компакт-диска укажите установочный файл Astra Linux Special Edition 1.7 «1.7.4-24.04.2023_14.23.iso».

  • На вкладке Сеть выберите:

    • Тип подключения: Сеть NAT

    • Имя: Стенд ALD Pro

../_images/aldpro_mod2_image7.png

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

Установите ОС и выполним первоначальную настройку:

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

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

  • Использовать логин - “localadmin”

  • Использовать пароль - “AstraLinux_174”

  • Пропустить настройку сети

  • При разметке диска выбрать пункт “Авто – использовать весь диск и настроить LVM”

  • Выбрать ядро по умолчанию – “linux-5.15-generic”. Ядра hardened система ALD Pro не поддерживает.

  • Установить пакеты программ по умолчанию за исключением средств работы с графикой (в дальнейшем потребуется LibreOffice для просмотра CSV-файлов в табличном виде).

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

  1. Отредактируйте файл /etc/apt/source.list для подключения репозиториев base и extended. Напоминаем, что base вбирает в себя репозитории main и update, поэтому использовать их все сразу необязательно.

#deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-main 1.7_x86-64 main non-free contrib
#deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-update 1.7_x86-64 main contrib non-free

deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-base 1.7_x86-64 main non-free contrib
deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-extended 1.7_x86-64 main contrib non-free
  1. Настройте сеть машины:

    • IP-адрес: 10.0.1.11 (но можно использовать и другой адрес, например, 10.0.1.10, чтобы не приходилось потом выключать dc-1 при включении клонированной VM)

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

    • Шлюз: 10.0.1.1

    • Сервер DNS: 77.88.8.8

    ../_images/aldpro_mod2_image8.png

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

    ../_images/aldpro_mod2_image9.png

    Убедитесь, что настройки сети применились, разрешение имен работает и внешние адреса доступны с помощью команд ip a show dev eth0 и ping -c 1 astralinux.ru

    ../_images/aldpro_mod2_image10.png
  2. Установите пакеты, необходимые для VBoxLinuxAdditions, следующей командой:

sudo apt install gcc make linux-headers-5.15

  1. Подключите и примонтируйте диск с гостевыми дополнениями:

    ../_images/aldpro_mod2_image11.png
  2. Установите VBoxLinuxAdditions следующей командой:

sudo sh /media/cdrom0/VBoxLinuxAdditions.run

  1. В настройках машины включите двунаправленный буфер обмена:

    ../_images/aldpro_mod2_image12.png
  1. Включите VM и установите ОС. Процесс установки ОС и её первоначальная настройка подробно рассматривались в первой части курса.

  2. Выключим VM и создадим снимок машины.

Клонирование виртуальной машины для резервного контроллера домена

Создадим виртуальную машину для резервного контроллера домена методом клонирования. В окне VirtualBox Manager выделите созданную ранее VM «Стенд ALD Pro — dc-1.ald.company.lan», выполните команду :Машина ‣ Клонировать и укажите следующие параметры:

  • Укажите имя и тип:

    • Имя: «Стенд ALD Pro — dc-2.ald.company.lan»

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

  • Дополнительные опции:

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

    ../_images/aldpro_mod2_image13.png

    рис. 165 Клонирование VM

Включите клонированную VM.

Примечание

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

../_images/aldpro_mod2_image15.png

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

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

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

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

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

Клонируем виртуальные машины остальных подсистем

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

../_images/aldpro_mod2_image18.png

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

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

Развертывание первого контроллера домена можно разбить на несколько этапов:

  1. Подготовка машины (физической или виртуальной, в нашем случае виртуальной)

  2. Установка ОС

  3. Предварительная настройки ОС

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

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

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

Предварительная настройка ОС

На момент написания модулей курса актуальной версией был релиз ALD Pro 2.3.0, который для установки серверной части поддерживает совместимость с ОС Astra Linux 1.7.4, 1.7.5 и 1.7.5 UU1. Клиентская часть поддерживает более широкий диапазон версий операционной системы: 1.7.1, 1.7.2, 1.7.3, 1.7.4, 1.7.5 и 1.7.5 UU1. Клиент ALD Pro для ALSE 1.8.1 до релиза ALD Pro 2.4.0 предоставляется только по запросу через техническую поддержку.

На контроллерах домена и подсистемах должна быть установлена операционная система с уровнем защищенности «Максимальный» («Смоленск»). Для рабочих станций можно использовать любой уровень защищённости.

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

localadmin@astra:~$ cat /etc/astra/build_version
1.7.4.7
localadmin@astra:~$ sudo astra-modeswitch getname
[sudo] пароль для localadmin:
maximum(smolensk)

Примечание

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

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

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

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

localadmin@astra:~$ sudo -i
root@dc-1:~# exit
выход

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

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

Если операционная система была установлена с графическим интерфейсом fly-wm, то в качестве менеджера сетевых подключений предлагается использовать службу NetworkManager. Эта служба очень удобна для автоматической настройки сети на рабочих станциях, но в случае серверов обычно рекомендуют пользоваться более простой службой Networking (команды ifup и ifdown).

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

localadmin@astra:~$ sudo systemctl stop NetworkManager
localadmin@astra:~$ sudo systemctl disable NetworkManager
Removed /etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service.
Removed /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service.
Removed /etc/systemd/system/multi-user.target.wants/NetworkManager.service.
localadmin@astra:~$ sudo systemctl mask NetworkManager
Created symlink /etc/systemd/system/NetworkManager.service → /dev/null.
localadmin@astra:~$ sudo systemctl status NetworkManager
 ● NetworkManager.service
 Loaded: masked (Reason: Unit NetworkManager.service is masked.)
 Active: inactive (dead) since Mon 2024-01-15 11:49:50 MSK; 1s ago
Main PID: 509 (code=exited, status=0/SUCCESS)
     CPU: 264ms

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

Примечание

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

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

После отключения NetworkManager сетевые настройки нужно задавать вручную в файлах interfaces и resolv.conf. Файл /etc/network/interfaces используется командами ifup и ifdown для конфигурирования сетевых интерфейсов. Изменим его в любом тестовом редакторе, например, vim:

localadmin@astra:~$ sudo vim /etc/network/interfaces vim

Вставим горячими клавишами Shift + Ins в файл interfaces текст:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
  address 10.0.1.11
  netmask 255.255.255.0
  gateway 10.0.1.1

Внимание

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

localadmin@astra:~$ cat /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

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» указывает способ назначения настроек: вручную или динамически.

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

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

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

localadmin@astra:~$ sudo ip addr flush dev eth0
[sudo] пароль для localadmin:
localadmin@astra:~$ sudo systemctl restart networking
localadmin@astra:~$

Убедимся, что сеть работает с помощью ping:

localadmin@astra:~$ ping -c 2 77.88.8.8
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
. . .

Для возможности обращения к публичным репозиториям следует настроить функцию разрешения имен. Файл /etc/resolv.conf определяет настройки для процедур разрешения имен из библиотеки glibc, которая используется в сетевых утилитах ping, dig и т. д. В этом файле следует указать, например, бесплатный сервер разрешения имен от Яндекс.

В нашем случае корректный DNS-сервер уже должен был быть прописан службой NetworkManager при установке гостевых дополнений Virtual Box, а если это не так, то пропишите правильное значение и можете удалить неактуальный комментарий о том, что файл resolv.conf сгенерирован NetworkManager:

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

После настройки службы разрешения имен проверьте подключение к репозиториям Astra Linux:

localadmin@astra:~$ ping -c 4 dl.astralinux.ru
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
. . .

Примечание

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

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

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

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

localadmin@astra:~$ sudo hostnamectl set-hostname dc-1.ald.company.lan

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

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

Изменим содержимое файла в любом текстовом редакторе, чтобы он соответствовал настройкам для dc-1, где 10.0.1.11 — статичный IP-адрес контроллера домена, который был выбран на шаге настройки сетевого интерфейса

localadmin@astra:~$ sudo vim /etc/hosts
127.0.0.1 localhost.localdomain localhost
#127.0.1.1 dc-1 - закомментируйте или удалите строку с адресом локальной петли на dc-1
10.0.1.11 dc-1.ald.company.lan dc-1

После изменения имени хоста желательно сделать перезагрузку:

localadmin@astra:~$ sudo reboot

Подключение репозиториев

Файлы программ Linux объединяются в пакеты и распространяются через специальные хранилища, называемые репозиториями. Основным файлом для хранения списка доступных репозиториев является /etc/apt/sources.list. Дополнительные списки могут храниться в файлах *.list в директории /etc/apt/sources.list.d/.

Для установки на сервере под управлением Astra Linux 1.7.4 программного продукта «ALD Pro» версии 2.2.0 из официальных интернет-репозиториев РусБИТех-Астра содержание этого файла должно включать следующие строки:

deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-main 1.7_x86-64 main non-free contrib
deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-update 1.7_x86-64 main contrib non-free

Или строки:

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

Напоминаем, что репозиторий base включает репозитории main и update, а репозиторий extended содержит большое количество дополнительного программного обеспечения.

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

Отредактируем файл /etc/apt/sources.list, чтобы он соответствовал требованиям:

localadmin@dc-1:~$ sudo vim /etc/apt/sources.list
localadmin@dc-1:~$ cat /etc/apt/sources.list
deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-base 1.7_x86-64 main non- free contrib
deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-extended 1.7_x86-64 main contrib non-free

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

localadmin@dc-1:~$ sudo vim /etc/apt/sources.list.d/aldpro.list

Вставим в этот файл ссылку на deb-репозиторий продукта:

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

Проверим наличие репозитория ALD Pro:

localadmin@dc-1:~$ cat /etc/apt/sources.list.d/aldpro.list
deb https://dl.astralinux.ru/aldpro/frozen/01/2.2.0 1.7_x86-64 main base

Напомним, что в source-листы менеджера apt добавляются строки, каждая из которых указывает путь к репозиторию в формате:

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

Где:

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

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

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

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

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

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

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

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

localadmin@dc-1:~$ sudo apt update

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

Приоритеты программных пакетов

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

По умолчанию для всех пакетов, находящихся в репозиториях, приоритет P=500. Переопределить приоритет по умолчанию можно с помощью конфигурационных файлов в директории /etc/apt/preferences.d/. В системе Astra Linux уже есть один такой конфигурационный файл, устанавливающий приоритет 900 для пакетов релиза 1.7_x86-64.

Посмотрим его содержимое:

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

Это правило позволяет избежать установки и обновления пакетов из сторонних репозиториев, если компанией РусБИТех-Астра для операционной системы под релиз 1.7_x86-64 была разработана специальная версия.

Примечание

Ранее продукт ALD Pro использовал другой идентификатор релиза, поэтому нужно было создавать дополнительно файл /etc/apt/preferences.d/aldpro с настройкой приоритета для пакетов ALD Pro. В крайних версиях продукта этого уже не требуется.

Обновление программных пакетов

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

localadmin@dc-1:~$ sudo apt update
...
localadmin@dc-1:~$ sudo apt list --upgradable
...
localadmin@dc-1:~$ sudo apt dist-upgrade -y -o Dpkg::Options::=--force-confnew

Внимание

Использовать команду sudo apt upgrade для обновления операционной системы категорически запрещается, т. к. она не удаляет устаревшие пакеты, даже если это требуется для обновления приложений, что может нарушить работу операционной системы. Поэтому вместо нее следует использовать утилиту astra-update.

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

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

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

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

localadmin@dc-1:~$ sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -q aldpro-mp aldpro-gc aldpro-syncer

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

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

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

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

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

  • aldpro-gc — установить инсталляционный пакет модуля глобального каталога.

  • aldpro-syncer — установить инсталляционный пакет модуля синхронизации с MS AD.

Примечание

Если планируется использовать двусторонние доверительные отношения с лесом доменов Microsoft Active Directory, то нужно будет дополнительно установить модуль глобального каталога. В этом случае будет работать поиск объектов из домена ALD Pro в стандартных приложениях Microsoft Windows.

Если планируется использовать расширенные функции интеграции с доменом Microsoft Active Directory, то нужно будет дополнительно выполнить установку модуля синхронизации, который обеспечивает поддержание целостности в двух доменах ALD Pro и AD DS. В этом случае у вас в двух доменах будет один и тот же состав пользователей и групп, синхронизироваться будет необходимый список атрибутов, включая пароли. Это позволит пользователям получать доступ к любым информационным системам по логину и паролю вне зависимости от того, через контроллер какого домена информационная система проверяет аутентичность пользователей.

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

localadmin@dc-1:~$  sudo grep error: /var/log/apt/term.log

Примечание

В предыдущих версиях ALD Pro перед повышением роли сервера до контроллера домена необходимо было вручную указать IP-адрес 127.0.0.1 в качестве DNS-сервера в файле /etc/resolv.conf и перезагрузить систему, чтобы заработали Salt-Master и Salt-Minion, но в крайних релизах продукта этого уже не требуется.

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

Все готово для продвижения контроллера (англ. domain controller promotion) или, как обычно говорят, для повышения роли сервера до контроллера домена. В ходе этой процедуры выполняется установка и настройка всех необходимых компонентов, чтобы сервер начал выполнять функции контроллера домена.

Далее мы запустим утилиту aldpro-server-install. Она является неинтерактивной, поэтому все параметры обязательны, включая пароль, иначе повышение роли не будет выполнено успешно. Учитывая, что команде требуется указать пароль в открытом виде, перед ее вызовом рекомендуется отключать запись истории команд.

Примечание

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

Отключите историю, чтобы не записать пароль в журнал:

localadmin@dc-1:~$ set + o history

Запустите скрипт повышения роли сервера:

localadmin@astra:~$ sudo aldpro-server-install -d ald.company.lan -n dc-1 -p 'AstraLinux_174' --ip 10.0.1.11 --no-reboot
[INFO    ] Executing command systemctl in directory '/root'
[INFO    ] Executing command systemd-run in directory '/root'
local:
  **True**
Был произведен перезапуск salt-master. Ожидаем 60 сек.
 . . .

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

  • -d (domain) — имя домена.

  • -n (name) — имя сервера.

  • -p (password) — пароль администратора домена.

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

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

Описание параметров скрипта можно получить с помощью ключа -h.

Внимание

В параметре -n нужно передать короткое имя сервера без указания домена, т. е. первую часть от полного FQDN имени, которое выдает команда hostname -f.

Пароль должен быть не менее 8 символов. Для использования специальных символов в пароле, например, знака доллара, заключите пароль в одинарные кавычки, например: 'pa_s$w0rd'.

Теперь можно включить ведение истории команд:

localadmin@dc-1:~$ set -o history``

Проверьте настройки cat /etc/resolv.conf. В обновленном скрипте установки этот файл настраивается на службу bind9 и поиск имен в домене ald.company.lan (этот суффикс будет добавляться к коротким именам). Если файл resolv.conf по-прежнему обращается на 77.88.8.8, то замените его следующим содержимым:

search ald.company.lan
nameserver 127.0.0.1

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

localadmin@dc-1:~$ sudo reboot

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

../_images/aldpro_mod2_image20.png

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

Примечание

Сразу после белой надписи Вход в dc-1.ald.company.lan есть поле выпадающий список, если в нем написано Этот компьютер, то нужно сменить на домен ald.company.lan

Проверка работы и настройка нового контроллера домена

Окно для входа может отобразиться раньше, чем станут доступны доменные службы. В этом случае вместо имени домена будет отображаться строка «Ожидание ответа домена…», и проверять работу аутентификации в этот момент будет преждевременно. Пожалуйста, дождитесь полной загрузки всех сервисов.

Если у вас не получится войти в операционную систему под доменной учетной записью, войдите локальным пользователем и проверьте журналы /var/log/auth.log`, /var/log/messages и доступность доменных служб утилитой ipactl:

admin@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

Проверка выдачи Kerberos TGT-билета

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

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

Valid starting       Expires              Service principal
29.01.2024 11:23:27  30.01.2024 11:23:27  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 admin.

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
29.01.2024 11:23:56  30.01.2024 11:23:52  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Если вы не укажете имя пользователя для Kerberos-аутентификации, то утилита kinit возьмет имя текущего локального пользователя. Это очень удобно, когда вы работаете в терминале из-под своего доменного пользователя, но может вас очень сильно запутать, если вы попытаетесь выполнить sudo kinit или будете работать из-под root-пользователя.

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

admin@dc-1:~$ kdestroy
admin@dc-1:~$ sudo kinit
Password for root@ALD.COMPANY.LAN:
admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:310400000:krb_ccache_UoKCDTe
Default principal: root@ALD.COMPANY.LAN

Valid starting       Expires             Service principal
29.01.2024 11:23:56  30.01.2024 11:23:52 krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN`

Проверка работы портала управления на контроллере домена

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

Начальная страница контроллера домена для браузера Firefox задана политикой, которую можно изменить в файле с помощью редактора sed:

admin@dc-1:~$ sudo sed -i 's/dc-1/dc-1.ald.company.lan/g' /usr/lib/firefox/distribution/policies.json

Посмотрим содержимое файла /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».

../_images/aldpro_mod2_image21.png

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

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

../_images/aldpro_mod2_image22.png

рис. 169 Портал управления ALD Pro

Если же билета нет, то будет высвечено сообщение о провале аутентификации с Kerberos. В этом случае выполните предварительно Kerberos-аутентификацию в консоли с помощью команды kinit и проверьте наличие билета с помощью команды klist.

После успешной аутентификации на портале в связке ключей появится сервисный билет на доступ к службе HTTP/dc-1.ald.company.lan@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
29.01.2024 11:26:19  30.01.2024 11:23:52  HTTP/dc-1.ald.company.lan@ALD.COMPANY.LAN
29.01.2024 11:23:56  30.01.2024 11:23:52  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

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

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

Отключение DNSSEC и настройка глобального перенаправления

Как упоминалось ранее, в качестве DNS-сервера выступает служба bind9. Конфигурационный файл /etc/bind/ipa-options-ext.conf содержит настройки её работы в разрезе службы FreeIPA. Посмотрим его содержимое по умолчанию:

admin@dc-1:~$ sudo cat /etc/bind/ipa-options-ext.conf
/* User customization for BIND named
*
* This file is included in /etc/bind/named.conf and is not modified during IPA
* upgrades.
*
* It must only contain "options" settings. Any other setting must be
* configured in /etc/bind/ipa-ext.conf.
*
* Examples:
* allow-recursion { trusted_network; };
* allow-query-cache { trusted_network; };
*
*
/* turns on IPv6 for port 53, IPv4 is on by default for all ifaces */
listen-on-v6 { any; };
/* dnssec-enable is obsolete and 'yes' by default */
dnssec-validation yes;
Отключение DNSSEC

Служба bind9 по умолчанию использует механизм DNSSEC для проверки ответов, но его лучше отключить, т. к. технология все еще не получила широкого распространения, и ошибки в настройках зон могут приводить к невозможности разрешения имен. Для этого в файле /etc/bind/ipa-options-ext.conf для параметра «dnssec-validation» рекомендуется задать значение «no». Сделать это можно командой sed:

admin@dc-1:~$ sudo sed -i 's/dnssec-validation yes/dnssec-validation no/g' /etc/bind/ipa-options-ext.conf
admin@dc-1:~$ sudo grep "dnssec-validation" /etc/bind/ipa-options-ext.conf
dnssec-validation no;
Разрешение рекурсивных запросов и кэширования

Еще одной особенностью настроек bind9 по умолчанию является запрет на обработку рекурсивных DNS-запросов от клиентов, находящихся за пределами той же подсети, в которой находится сам DNS-сервер. Сделано это для предотвращения DDoS-атак с DNS-усилением, но эта защита не актуальна для контроллеров домена, которые работают в закрытом периметре, поэтому в файле ipa-options-ext.conf рекомендуется задать также значение «any» для параметров «allow-recursion» и «allow-query-cache» или определить в файле /etc/bind/ipa-ext.conf список доверенных сетей.

Изменим эти настройки командой sudo tee:

admin@dc-1:~$ echo 'allow-recursion { any; };' | sudo tee -a /etc/bind/ipa-options-ext.conf
allow-recursion { any; };
admin@dc-1:~$ echo 'allow-query-cache { any; };' | sudo tee -a /etc/bind/ipa-options-ext.conf
allow-query-cache { any; };
admin@dc-1:~$ sudo grep "allow" /etc/bind/ipa-options-ext.conf
* allow-recursion { trusted_network; };
* allow-query-cache { trusted_network; };
allow-recursion { any; };
allow-query-cache { any; };

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

admin@dc-1:~$ sudo systemctl restart bind9-pkcs11.service
Настройка глобального перенаправления DNS-запросов

Если до установки пакетов ALD Pro перенаправление DNS-запросов на localhost (127.0.0.1) привело бы к отказу в работе механизма разрешения имен, то сейчас этого не произойдет, т. к. в системе работает сервис bind9, который выполняет функцию рекурсивного разрешителя имен. Bind9 сам находит запрашиваемые DNS-записи, последовательно обращаясь ко всем DNS-серверам, обслуживающим зону, начиная с корневой (см. файлы /etc/bind/named.conf.default-zones и /usr/share/dns/root.hints).

Но этот механизм потребляет дополнительные ресурсы, поэтому для разрешения DNS-имен в сети Интернет рекомендуется использовать глобальный перенаправитель. Настроить эту опцию можно на портале управления в меню Роли и службы сайта ‣ Служба разрешения имен ‣ Глобальная конфигурация DNS

Нажмем на кнопку добавить и введем адрес DNS-сервера, см. рис. 170 (1). Рекомендуется установить адрес публичного DNS, например, от Яндекс 77.88.8.8. Политику перенаправления рекомендуется выбрать Только перенаправлять или Сначала перенаправлять, где:

  • Только перенаправлять — сервер запрашивает ответ только у серверов пересылки.

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

Для сохранения и применения изменений нажмем кнопку Сохранить в правом верхнем углу (2).

../_images/aldpro_mod2_image23.png

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

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

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

Примечание

В некоторых инструкциях для проверки DNS предлагают использовать утилиту dig с ключом +trace, но в этом случае dig вместо того, чтобы обратиться к внешнему DNS-серверу, станет выполнять рекурсивные запросы, начиная с зоны верхнего уровня.

Поэтому, если вы все же хотите увидеть подтверждение, что при разрешении имен запросы пошли к внешнему DNS-серверу, воспользуйтесь wireshark или запустите в отдельном окне tcpdump для прослушивания пакетов, отправляемых на 53 порт:

sudo apt install tcpdump
sudo tcpdump port 53

Откройте страницу портала в браузере, чтобы посмотреть, какие запросы покажет утилита tcpdump:

admin@dc-1:~$ sudo tcpdump port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:23:35.806919 IP dc-1.ald.company.lan.41973 > dns.yandex.ru.domain: 23782+ [1au] NS? . (40)
11:23:35.807228 IP dc-1.ald.company.lan.58425 > dns.yandex.ru.domain: 28077+% [1au] A? detectportal.firefox.com. (65)
11:23:35.808076 IP dc-1.ald.company.lan.55022 > dns.yandex.ru.domain: 48334+% [1au] PT R? 8.8.88.77.in-addr.arpa. (63)
11:23:35.809802 IP dc-1.ald.company.lan.58539 > dns.yandex.ru.domain: 30468+% [1au] AA AA? detectportal.firefox.com. (65)
11:23:35.828463 IP dns.yandex.ru.domain > dc-1.ald.company.lan.41973: 23782|$ 0/0/1 (28)
. . .

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

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

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

К этапам подготовки клиентской машины можно отнести:

  1. Подготовка машины (физической или виртуальной, в нашем случае виртуальной)

  2. Установка ОС

Ввод компьютера в домен можно разбить на три этапа:

  1. Предварительная настройка ОС

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

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

В рамках подготовки тестового стенда виртуальная машина должна была быть создана, а ОС уже установлена. Нам осталось выполнить шаги ввода машины в домен.

Предварительные настройки ОС клиентского ПК

В этом разделе рассмотрим настройки, которые необходимо выполнить для успешного ввода машины в домене ALD Pro и её последующей корректной работы. Включим VM клиентской машины и войдем в неё под локальной учетной записью, созданной в ходе установки ОС.

Настройка сетевого интерфейса клиентского ПК

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

Откройте настройки сети, воспользовавшись апплетом NetworkManager, и на вкладке «Параметры IPv4» установите изменения:

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

  • Адрес: 10.0.1.51

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

  • Шлюз: 10.0.1.1, шлюз маршрутизатора или gateway

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

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

../_images/aldpro_mod2_image24.png

рис. 171 Настройка сети с помощью графического апплета NetworkManager

Для сохранения изменений не забудьте нажать кнопку «Сохранить», однако это не изменит текущих настроек на сетевом интерфейсе.

localadmin@astra:~$ ip a | grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP group default qlen 1000
   inet 10.0.1.10/24 brd 10.0.1.255 scope global noprefixroute eth0

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

../_images/aldpro_mod2_image25.png

рис. 172 Контекстное меню апплета NetworkManager

localadmin@astra:~$ ip a | grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP group default qlen 1000
   inet 10.0.1.51/24 brd 10.0.1.255 scope global noprefixroute eth0

Для установки пакетов компьютеру нужно иметь доступ к репозиториям, расположенным в сети Интернет по адресу https://dl.astralinux.ru. Можете проверить примененный IP, а также доступность сайта и хостов сети командами:

localadmin@astra:~$ ip a
localadmin@astra:~$ ping -c 4 77.88.8.8
localadmin@astra:~$ ping -c 4 dl.astralinux.ru
localadmin@astra:~$ ping -c 4 dc-1.ald.company.lan
localadmin@astra:~$ ping -c 4 dc-1

Подключение репозиториев

Для установки клиентской части «ALD Pro» версии 2.2.0 на ALSE 1.7.4 из официальных интернет-репозиториев РусБИТех-Астра содержание файла /etc/apt/sources.list должно быть таким же, как при установке серверной части.

localadmin@astra:~$ sudo vim /etc/apt/sources.list
localadmin@astra:~$ cat /etc/apt/sources.list
deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-base 1.7_x86-64 main non-free contrib
deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-extended 1.7_x86-64 main contrib non-free

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

localadmin@astra:~$ cat /etc/apt/sources.list.d/aldpro.list
deb https://dl.astralinux.ru/aldpro/frozen/01/2.2.0 1.7_x86-64 main base

Не забудьте обновить индекс пакетов командой sudo apt update.

Обновление программных пакетов

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

localadmin@astra:~$ sudo apt update
localadmin@astra:~$ sudo apt list --upgradable
localadmin@astra:~$ sudo apt dist-upgrade -y -o Dpkg::Options::=--force-confnew

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

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

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

  • В качестве DNS-сервера должен быть указан IP-адрес контроллера домена.

    Обратите внимание, что устанавливать Linux-компьютеры в одной сети с Windows-компьютерами и использовать DNS-сервер от Microsoft с простым перенаправлением зоны не получится. Система FreeIPA будет дополнительно проверять имена через PTR-записи, а перенаправить и обратную зону тоже, если она используется компьютерами Windows, у вас уже не получится.

  • Установлен пакет клиентского программного обеспечения aldpro-client.

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

В нашем случае имя компьютера будет pc-1. Для начала необходимо проверить уникальность имени в домене ald.company.lan. Это можно сделать командой nslookup, которая входит в пакет dnsutil.

localadmin@astra:~$ sudo apt install dnsutils
localadmin@astra:~$ nslookup pc-1
Server:         10.0.1.11
Address:        10.0.1.11#53

** server can't find pc-1: NXDOMAIN

С помощью данной команды мы проверим, что хост с указанным именем не найден на DNS-сервере. Данная команда проверит не только имя «pc-1», но и «pc-1.ald.company.lan», так как в настройках NetworkManager в одном из предыдущих шагов мы указали DNS-суффикс «ald.company.lan».

Примечание

Вместо фиксированного имени компьютера pc-1 вы можете использовать переменную $pc_name, значение которой можно сгенерировать случайным образом:

$ pc_name="pc-`expr $RANDOM$(date +%s) | md5sum | head -c 11)`"
$ echo "$pc_name"
pc-8baad96c232
$ nslookup "$pc_name"
...

Установка пакетов ALD Pro на клиентский компьютер

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

localadmin@astra:~$ sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -q aldpro-client

Комментарии к использованным ключам можно найти в разделе инструкции по установке пакетов на контроллере домена.

При установке клиента в системе устанавливается более 130 зависимостей, отдельного внимания из которых заслуживают freeipa, sssd, krb5, ldap-utils, chrony, salt,zabbix-agent, syslog-ng и td-agent.

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

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

Все готово для ввода компьютера в домен. Выполним ввод pc-1 с помощью команд:

localadmin@astra:~$ set +o history
localadmin@astra:~$ sudo /opt/rbta/aldpro/client/bin/aldpro-client-installer --domain ald.company.lan --account admin --password 'AstraLinux_174' --host pc-1 --gui --force
localadmin@astra:~$ set -o history

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

  • domain — имя домена, которое вы выбрали на основе третьего уровня приобретённого домена, например, ald.company.lan

  • account — логин администратора домена

  • password — пароль администратора домена

  • host — имя компьютера в нижнем регистре

  • gui — использовать интерактивный режим

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

Описание параметров скрипта можно получить с помощью ключа -h. Также доступны короткие псевдонимы, например, в место --domain можно указать , но эти сокращения, на наш взгляд, менее запоминающиеся.

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

../_images/aldpro_mod2_image26.png

рис. 173 Графическая утилита для ввода компьютера в домен

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

localadmin@astra:~$ exec bash
localadmin@pc-1:~$ echo $HOSTNAME
pc-1.ald.company.lan

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

localadmin@astra:~$ sudo reboot

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

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

При запуске утилиты aldpro-client-installer в обоих случаях (текстовом и графическом) утилита установки вызывает ipa-getkeytab, которая устанавливает Kerberos-пароль для учетной записи компьютера, используя привилегированную учетную запись.

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

Существует два способа повышения безопасности процедуры ввода компьютера в домен. Рассмотрим оба.

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

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

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

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

ipa privilege-add-permission 'Host Enrollment' --permissions='System: Add Hosts'
ipa role-add-member 'Enrollment Administrator' --users=enrolladmin

При необходимости вы можете создать и новую роль «New Host Enrollment»:

admin@dc-1:~$ ipa privilege-add 'New Host Enrollment' --desc='Ввод новых хостов в домен'
admin@dc-1:~$ ipa privilege-add-permission 'New Host Enrollment' \
--permissions='System: Add Hosts' \
--permissions='System: Add krbPrincipalName to a Host' \
--permissions='System: Enroll a Host' \
--permissions='System: Manage Host Certificates' \
--permissions='System: Manage Host Enrollment Password' \
--permissions='System: Manage Host Keytab' \
--permissions='System: Manage Host Principals'
ipa role-add 'New Host Enrollment Administrator' \
--desc='Участники роли имеют привилегии, необходимые для регистрации новых компьютеров в домене'
ipa role-add-privilege 'New Host Enrollment Administrator' \
--privileges='New Host Enrollment'
ipa role-add-member 'New Host Enrollment Administrator' --users=enrolladmin

После создания новой роли вы можете назначить ее через веб-интерфейс на странице Управление доменом ‣ Роли и права доступа ‣ Роли в системе, как показано на рисунке ниже:

../_images/aldpro_mod2_image27.png

рис. 174 Назначение роли New Host Enrollment, предоставляющей право на ввод машин в домен

После назначения пользователю роли «New Host Enrollment Administrator» он сможет вводить машины в домен, не имея при этом полных административных прав.

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

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

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

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

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

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

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

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

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

Где:

  • pc-2.ald.company.lan – FQDN имя компьютера;

  • random – ключ, указывающий на требование сгенерировать случайный одноразовый пароль;

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

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

На стороне компьютера останется назначить хосту правильное имя и выполнить команду ipa-client-install, используя одноразовый пароль, полученный на предыдущем шаге:

localadmin@astra:~$ sudo hostnamectl set-hostname pc-2.ald.company.lan
localadmin@astra:~$ sudo ipa-client-install --mkhomedir --password='2Hy0bL8abgQ2IOddYwl3TOc' -U

В системе ALSE до 1.7.4 включительно при выполнении скрипта aldpro-client-installer задать пароль без указания имени пользователя было невозможно, поэтому такой способ пока еще недоступен.

Повторное присоединение к домену, используя keytab-файл хоста

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

Посмотрим содержимое доступного нам keytab-файла со старой машины:

admin@pc-1:~$ sudo klist -k /home/localadmin/krb5.keytab
Keytab name: FILE:/home/localadmin/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 host/pc-1.ald.company.lan@ALD.COMPANY.LAN
   1 host/pc-1.ald.company.lan@ALD.COMPANY.LAN

Установим тоже самое имя хоста и введем машину в домен с помощью этого keytab-файла:

localadmin@astra:~$ sudo hostnamectl set-hostname pc-1.ald.company.lan
localadmin@astra:~$ sudo ipa-client-install -U -k /home/localadmin/krb5.keytab
The ipa-client-install command was successful
localadmin@astra:~$ sudo -i
...
root@pc-1:~# klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 host/pc-1.ald.company.lan@ALD.COMPANY.LAN
2 host/pc-1.ald.company.lan@ALD.COMPANY.LAN

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

root@pc-1:~# reboot

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

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

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

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

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

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

localadmin@pc-2:~$ sudo astra-freeipa-client –U
Unenrolling client from IPA server
. . .
Client uninstall complete.

Внимание

Выполнять команду sudo astra-freeipa-client -U нужно из-под учетной записи локального администратора, т.к. после ее выполнения доменный администратор потеряет возможность запускать команды с повышенными привилегиями из-под sudo.

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

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

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

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

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

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

localadmin@pc-2:~$ sudo apt purge 'aldpro*' 'freeipa*' 'sssd*' 'krb5*'
localadmin@pc-2:~$ sudo apt autoremove --purge

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

localadmin@pc-2:~$ sudo rm -rf /home/admin

Также можно использовать bash-скрипт для рекурсивного удаления каталогов, где переменная $adm содержит имя локального администратора:

localadmin@pc-2:~$ adm=localadmin
localadmin@pc-2:~$ ls -1a | grep -v "^$adm\|\.$" | while read line; do echo "removing ./$line"; sudo rm -rf "./$line"; done
removing ./admin
removing ./ivani
removing ./ppetr

Также необходимо удалить каталоги клиентских приложений подсистем ALD Pro:

localadmin@pc-2:~$ sudo rm -rf /var/lib/sss/pubconf/krb5.include.d/
localadmin@pc-2:~$ sudo rm -rf /etc/krb5.conf.d/
localadmin@pc-2:~$ sudo rm -rf /var/lib/sss/
localadmin@pc-2:~$ sudo rm -rf /etc/sssd/
localadmin@pc-2:~$ sudo rm -rf /opt/rbta/aldpro/
localadmin@pc-2:~$ sudo rm -rf /etc/syslog-ng/aldpro/
localadmin@pc-2:~$ sudo rm -rf /etc/salt/minion.d/
localadmin@pc-2:~$ sudo rm -rf /var/log/salt/
localadmin@pc-2:~$ sudo rm -rf /var/lib/certmonger/

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

localadmin@pc-2:~$ sudo update-ca-certificates

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

localadmin@pc-2:~$ sudo hostnamectl set-hostname astra
localadmin@pc-2:~$ sudo reboot

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

На сервере dc-1 нужно удалить учетную запись хоста и ее DNS-записи:

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

Удалить выводимый компьютер из базы системы FreeIPA:

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

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

admin@dc-1:~$ sudo salt-key -y -d pc-2.ald.company.lan
[sudo] пароль для admin:
The following keys are going to be deleted:
Accepted Keys:
pc-2.ald.company.lan
[INFO ] Rotating AES key
Key for minion pc-2.ald.company.lan deleted.

Удалить ключ с резервного контроллера домена dc-2 (у нас его пока нет, но если бы он был, то мы бы выполнили следующие действия):

admin@dc-1:~$ ssh dc-2
admin@dc-2:~$ sudo salt-key -y -d pc-2.ald.company.lan
[sudo] пароль для admin:
The following keys are going to be deleted:
Accepted Keys:
pc-2.ald.company.lan
[INFO ] Rotating AES key
Key for minion pc-2.ald.company.lan deleted.

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

Заключение

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

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