Установка Astra Linux Directory
В этой статье будет рассмотрена установка Astra Linux Directory – реализация службы каталогов от компании АО «НПО РусБИТех» (Astra Linux). Особо отмечу, что речь идет про бесплатную версию Astra Linux Directory, а не Pro версию.
Цель статьи – это подготовить руководство для быстрого старта, которое позволило бы вам в разумные строки развернуть стенд для тестирования службы каталогов Astra Linux Directory.
Краткое описание служб каталогов ALD
Существует две версии продукта – Astra Linux Directory и Astra Linux Directory Pro. Как бы это странно не звучало, но технически это два разных продукта. Astra Linux Directory используются свой вариант каталога, а в основе служб каталогов Astra Linux Directory Pro лежит FreeIPA.
Astra Linux Directory доступна из коробки в бесплатной редакции Astra Linux Common Edition.
Кратко опишу основные возможности бесплатной версии Astra Linux Directory:
- Позволяет организовать централизованное хранение и управление учетными записями пользователей и групп.
- Предоставляет сквозную аутентификацию пользователей в домене с использованием протокола Kerberos.
- Обеспечивает функционирование глобального хранилища домашних директорий, доступных по Samba/CIFS.
К основным особенностям я бы отнес следующие:
- Поддерживает только клиенты с ОС Astra Linux.
- Добавление машины ОС MS Windows в домен ALD штатными средствами ОС MS Windows невозможно.
- Одновременной работы нескольких серверов ALD не предусмотрено.
- Переключение на резервный сервер ALD только вручную.
- «Плоская» иерархия пользователей и ПК, т.е. нет возможности, например, создавать OU.
Все приведенные мной выше умозаключения отражают только мое видение продукта и относятся к версии 1.7.37.
Планируемая схема установки
Планируемая к развертыванию схема приведена ниже:
Она включает в себя один сервер (ADC01) и один клиент (ACLT01). В качестве службы разрешения имен я буду использовать сервер BIND. В целом для такой схемы можно вообще не использовать BIND, а просто сделать соответствующие записи в /etc/hosts.
Подготовка операционных систем
У Astra Linux Directory Common Edition нет градации на серверных и клиентские редакции ОС. Поэтому предварительная подготовка сервера и клиента ничем не отличаются.
Во всех примерах этой статьи использовалась версия Astra Linux Directory Common Edition релиза “Орёл” (2.12.43). Версия ядра – 5.10.0.-1038.40-hardened.
Итого подготовка серверной и клиентской системы включает в себя следующие шаги:
1. Установка и первоначальная настройка операционной системы. Можете использовать как физическое устройство, так и виртуальную машину. В целом можно использовать стандартные параметры установки, но вот версия ядра должна быть именно “hardened”:
2. Актуализация репозиториев:
3. Обновление установленных пакетов:
Настройка сервера Astra Linux Directory
Установка Astra Linux Directory включает в себя следующие верхнеуровневые шаги:
- Настройка BIND.
- Установка и настройка серверных служб ALD.
Предварительно неоходимо указать в качестве DNS сервера на сетевом интерфейсе адрес самого сервера.
Настройка BIND
- Устанавливаем пакет BIND:
2. Устанавливаем пакет утилит для работы с DNS (например, в этот пакет входит утилита dig):
3. Корректируем настройка BIND. Нужно указать на каких IP-адресах сервера прослушивать запросы и на какие внешние DNS следует перенаправлять запросы. Открываем на редактирование конфигурационный файл:
Нам нужно скорректировать секции “forwarders” и “listen-on”. В секции “forwarders” нужно указать на какие внешние DNS перенаправлять запросы, а в секции “listen-on” нужно указать локальные адреса, на которых сервер будет прослушивать подключения. Пример моего файла конфигурации:
4. Теперь необходимо внести информацию и прямой и обратной зоне. В моем случае DNS-имя зоны будет itproblog.ru. Открываем на редактирование конфигурационный файл:
Пример моего конфигурационного файла named.conf.local:
В секции type указан тип зоны (основная зона), а в секции file расположение файла с текстом зоны (его мы настроим далее).
5. Создаем каталог для файлов DNS зон, создаем пустые файлы зон и назначаем необходимые разрешения:
6. Редактируем файл с прямой зоной:
Пример моего файла прямой зоны:
7. Редактируем файл с обратной зоной:
Пример моего файла обратной зоны:
8. Проверяем корректность заполнения конфигурационного файла и файлов зон:
Если ваш вывод на консоль отличается от вывода со скриншота выше, то, вероятно, нужно скорректировать ошибки в конфигурационных файлах.
9. Перезагружаем сервис BIND:
10. Проверяем разрешение имени через наш DNS сервер:
т.е. имена сервера и клиента успешно разрешаются в IP-адреса.
Установка служб Astra Linux Directory
- Устанавливаем основной пакет ALD сервера и графический интерфейс администрирования Fly:
В процессе установки нас попросят указать пароль администратора LDAP. Указываем его:
2. Указываем полное доменное имя сервера:
Да, полное доменное имя применилось корректно.
3. Перезагружаем сервер.
4. Теперь необходимо создать домен. Переходим по следующему пути в графическом режиме: “Пуск” – “Панель управления” – “Сеть” – “Доменная политика безопасности“.
5. Указываем пароль, который мы задали на этапе установки сервера ALD.
6. Поскольку пока еще сервер ALD не настроен, то могут возникать ошибки в диалоговых окна. Пока просто игнорируем их.
7. Указываем пароль базы данных Kerberos, пароль администратора ALD.
Я также отметил опцию “Использовать свои настройки сети” и выбрал IP-адрес для службы. После этого нажимаем кнопку “Создать сервер”.
8. Нажимаем “Да” в подтверждении о том, что мы согласны с тем, что предыдущая БД будет перезаписана (если она имеется).
9. В случае успешного завершения создания сервера мы получим соответствующее уведомление:
10. Перезагружаем сервер.
Проверка работы серверных служб ALD
Выполнил проверку сервиса ALD:
Сообщение говорит о том, что сервис сконфигурирован, клиент и сервис работают корректно.
Теперь попробуем открыть графическую оснастку администрирования. Переходим по следующему пути в графическом режиме: “Пуск” – “Панель управления” – “Сеть” – “Доменная политика безопасности“:
Нажимаем кнопку “Подключиться”.
Указываем пароль администратора ALD:
В случае успешного подключения мы должны увидеть древовидно меню слева, как указано на скриншоте ниже.
Создание тестовых пользователей
Для того, чтобы проверить подключение клиента и работу под доменной УЗ создадим две учетные записи – user1 и user2.
Переходим по следующему пути в графическом режиме: “Пуск” – “Панель управления” – “Сеть” – “Доменная политика безопасности“. Указываем пароль администратора ALD.
В контекстном меню элемента “Пользователи” выбираем пункт “Создать“:
Заполняем имя пользователя и указываем первичную группу “Domain Users”:
Подтверждаем наши намерения создать пользователя (зеленая галочка).
Создаем пароль для учетной записи:
Выполняем аналогичные действия для учетной записи user2.
Итого, в нашей директории должно быть два пользователя – user1 и user2:
Присоединение клиента к домену ALD
Предварительно на клиентском ПК необходимо указать в качестве DNS сервера наш сервер с ALD, т.к. именно там мы настроили BIND DNS.
Перезагружаем клиент и проверяем, что имя нашего сервера ALD разрешается в IP:
Указываем полное доменное имя клиента:
Процесс присоединения к домену
1. Устанавливаем необходимые пакеты:
2. Для разнообразия присоединим клиент через командную строку. Это можно сделать вот такой небольшой командой:
где последним параметром передается имя контроллера домена ALD.
3. На этапе выбора пользователя с правами присоединения к домену нажимаем Enter и указываем пароль администратора ALD.
4. В случае успешного присоединения вы должны увидеть следующий вывод:
Если теперь посмотреть в консоль управления ALD на сервере, то вы можете увидеть новый объект компьютера:
Проверка работы клиента ALD
Если мы попробуем сейчас выполнить вход на клиентский компьютер под доменной учетной записью user1, то увидим следующее сообщение – “Доступ запрещен”:
С кем это связано? Все дело в том, что в оснастке управления ALD для учетной записи пользователя необходимо явно указать – на какие клиентские ПК ему разрешен доступ. Давайте добавим доменному user1 разрешения локального входа на доменный ПК aclt01.itproblog.ru.
Для этого на сервере ALD необходимо открыть оснастку управления ALD и в свойствам УЗ user1 на вкладке “Привилегии домена” добавим компьютер aclt01.itproblog.ru:
Сохраните внесенные изменения.
Попробуем выполнить вход теперь:
Да теперь мы успешно выполнили вход под доменной учетной записью.
Установка Astra Linux Directory : 8 комментариев
Добрый день!
Вход в домен приходиться выполнять каждый раз (ald-client join domain). Авторизация проходит успешно. После перезагрузки все по новой. Это нормальное поведение? Как можно автоматизировать вход с пк в домен?
Добрый день! Нет, так не должно быть. ald-client join domain – это разовая операция.
После перезагрузки не получается под доменной УЗ аутентифицироваться? Какая-то ошибка генерируется?
Здравствуйте
в привилегиях домена не появился подключенный компьютер, там вообще пусто, в разделе компьютеров он есть, все делалось в точности, версия астры 1.6 Смоленск, никаких бюллетеней поверх не установлено
Добрый день! А КД и клиент точно видят друг друга? В процессе присоединения клиента никаких ошибок не генерировалось? Попробуйте еще вот этой командой на клиенте статус проверить: sudo ald-client status
Еще из вариантов – последовательно перезагрудить КД и клиента и выполнить проверку снова.
делал по вашей инструкции но при подключении клиента к домену появляется ошибка: ошибка openldap при gssapi соединения local error в aldldapconnection.cpp:747 connect
Как ее исправить?
Добрый день! Разрешение имен точно работает корректно? КД по имени разрешает IP-адрес клиента и наоборот? Обсуждение подобной проблемы есть на форуме вендора – https://forum.astralinux.ru/threads/484/. Из обсуждения я понял, что по итогу былаиз-за ошибок в файлах конфигурации зоны в bind. Я бы на вашем месте проверил всю подсистему разрешения имен.
Здравствуйте, Роман! спасибо, действительно были опечатки в конфигурационных файлах DNS
DNS – это уже почти классика дебага:
– Это точно не DNS.
– Это не может быть DNS.
– Это был DNS.
Администрирование ald домена на Astra Linux
Вот уже более года я занимаюсь администрированием Astra Linux, которая построена на базе ОС Debian. В плане администрирования данные операционные системы имеют различия. Также в Astra Linux есть службы собственной разработки.
В посте пойдет речь об администрировании ald домена, серверной, клиентской части, а также о поднятии резервного сервера.
Серверная часть
Настройку произвожу на виртуальных машинах в virtualbox, на сервере ip адрес 192.168.1.1, также на данном сервере расположен репозиторий(настройка ip адресов и репозиториев ничем не отличаются от настроек в debian). Первое, что необходимо настроить — это синхронизацию времени: поднимем ntp сервер, который будет брать время с текущей машины. Для это достаточно отредактировать файл /etc/ntp.conf, внеся в него следующие изменения:
fudge 127.127.1.0 stratum 10
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
Параметры подсети укажите в соответсвии с вашими ip адресами.
systemctl enable ntp
systemctl start ntp
Так как в ald отсутствует собственный dns сервер, его заменой служит корректно настроенный файл /etc/hosts, который должен быть одинаковый на всех машинах в домене. Перед редактированием данного файла, зададим корректное hostname для сервера:
hostnamectl set-hostname dc1.local
В данной ситуации hostname сервера будет dc1, а имя домена, соответственно, local, именно на эти параметры будет ориентироваться ald-server при инициализации. Последним штрихом перед инициализацией ald сервера буден корректная настройка файла /etc/hosts:
192.168.1.1 dc1.local dc1
192.168.1.2 dc2.local dc2
192.168.1.101 host1.local host1
192.168.1.102 host2.local host2
Обязательно необходимо «закомментировать» 127.0.1.1, а также важна последовательность указания полного имени хоста, т. е. первым должно быть указано имя хоста с доменом, и только потом имя хоста без домена.
В данном примере указан один домен и две рабочие станции. Если рабочих станций больше, то, соответственно, всех их необходимо перечислить в данном файле, а также скопировать данный файл на все машины, которые планируется ввести в домен. После этого можно приступать к установке необходимых пакетов, а также инициализации сервера:
sudo apt install ald-server-common fly-admin-ald-server smolensk-security-ald
Пакет smolensk-security-ald — добавит возможность администрировать ald сервер в стандартной утилите fly-admin-smc (об этом будет рассказано далее).
Во время установки будет запрос на создание пароля администратора домена. Для текущей публикации будет создан пароль 12345678, далее данный пароль будет использован для ввода всех машин в домен.
ВАЖНО: Если по каким то причинам у Вас сбились настройки сервера, то их можно отредактировать в файле /etc/ald/ald.conf, в текущем файле важен параметр DOMAIN, значение данного параметра всегда должно начинаться с . (точки), т.е. в текущем примере данная строка будет выглядеть так:
Инициализируем сервер командой:
После инициализации необходимо перезагрузть сервер. В процессе инициализации домена еще раз будет запрос на создание пароля администратора домена, а также запрос на создание пароля на базу данных kerberos. Если все прошло удачно, то на экране появится сообщение как на рисунке 1.
Рис. 1
После данным манипуляций настройка сервера закончена, приступим к настройке клиентской части.
Клиентская часть
Достаточно настроить ntp клиента для синхронизации времени, скопировать файл hosts с сервера, задать имя хоста, а также настроить /etc/ald/ald.conf. В файле /etc/ntp.conf необходимо добавить строки:
Запустим службу ntp:
systemctl start ntp
systemctl enable ntp
Зададим имя хоста (в данном пример ip адрес хоста 192.168.1.101):
hostnamectl set-hostname host1
Перед настройкой ald.conf необходимо установит необходимые пакеты:
sudo apt install fly-admin-ald-client ald-client
На рисунке 2 представлен пример файла ald.conf (данный файл аналогичен файлу ald.conf с сервера).
Рис. 2
После данным манипуляций можно ввести машину в домен командой:
После ввода машины в домен ее необходимо перезагрузить. Во время инициализации необходимо ввести пароль учетной записи, у которой имеются права на ввод машины в домен.
Если все прошло удачно, то на экране отобразится текст как на рисунке 3
Рис. 3
Резервный сервер ald
Создать резервный сервер также довольно просто. Для этого на будущем резервном сервере (на резервном сервере также необходимо расположить корректный файл hosts), необходимо установить пакеты:
sudo apt install ald-server-common smolensk-security-ald
И отредактировать файл /etc/ald/ald.conf, изменив один параметр:
Рис. 4
Далее зададим корректное имя хоста для резервного сервера:
sudo hostnamectl set-hostname dc2.local
Теперь инициализируем резервный сервер командой:
sudo ald-init init —slave
После выполнения данной команды, сервер перейдет в резервный режим. После инициализации необходимо перезагрузить машину.
Если, например, основной сервер вышел из строя, то для перевода резервного сервера в основной режим необходимо выполнить команду:
sudo ald-init promote
Дополнительно необходимо на всех клиентских рабочих станциях отредактировать файл /etc/ald/ald.conf, как это сделать одной командой будет рассказано в разделе «Дополнительно».
Рис. 5
В данном файле необходимо изменить параметр SERVER и SERVER_ID:
SERVER=dc2.local #dc2.local – резервный сервер
SERVER_ID=2 #2 – id резервного сервера
После манипуляций необходимо выполнить команду:
sudo ald-client commit-config
Администрирование ald сервера
Как было написано ранее, администрирование можно производить через стандартную системную утилиту fly-admin-smc. Ее можно запустить через консоль, либо в панели управления, перейдя на вкладку «Безопасность» и запустив аплет «Политика безопасности». Первым делом необходимо настроить политику паролей в соответствии с вашими требованиями:
Рис. 6
На рисунке 6 представлена вкладка политики паролей. После настройки политики можно приступить к созданию пользователей и настройке их прав.
Рис. 7
На вкладке «Пользователи» необходимо нажать на кнопку +, ввести имя, тип файловой системы установить local (также можно хранить каталоги на сетевых ресурсах), а также убрать галку «новая» напротив надписи «Первичная группа». При этом пользователь будет добавлен в группу «domain user». Далее создадим пароль для пользователя.
Рис. 8
На вкладке «Привилегии домена» можно сделать пользователя «администратором» домена, а также разрешить авторизацию с конкретных доменных машин, или с любых машин, входящих в домен.
Рис. 9 Рис. 10
На вкладке «МРД» указываем, к каким меткам пользователь имеет доступ, а также уровень целостности.
Рис. 11
Дополнительно
Представьте такую ситуацию, в будущий домен будет входить 100, или более машин, раскидать в ручную файл hosts будет довольно проблематично, в данной ситуации поможет bash с СИ подобным синтаксисом.
На тестовом стенде имеется подсеть 192.168.1.0/24, 192.168.1.1 — сервер, 192.168.1.2-192.168.1.100 — рабочие станции. На каждой машине(в том числе и на сервере) имеется пользователь user, с паролем 12345678. Данный пользователь должен быть полноценным администратором(с доступом к sudo, во время установки системы создается пользователь имеющий данные права) системы и иметь уровень целостности 63, для выполнения данной цели необходимо выполнить следующие команды:
sudo usermod -aG astra-admin,astra-console user
sudo pdpl-user -l 0:0 -i 63 user
Если пользователь user отсутствует в системе — выполним следующие команды:
sudo useradd -m -G astra-admin,astra-console -s /bin/bash user
sudo passwd user
sudo pdpl-user -l 0:0 -i 63 user
Для того что бы не вводить пароль при распространении ключей, необходимо установить утилиту sshpass:
sudo apt install sshpass
После данным манипуляций можно приступить к формированию ключа(без sudo, с правами пользователя user), для без парольного доступа:
shh-keygen -t rsa -b 1024
Распространим ключи на рабочие станции:
for((i=2;i<101;i++)); do sshpass -p 12345678 ssh-copy-id -f -o StrictHostKeyChecking=no user@192.168.1.$i; done
Скопируем файл hosts на все машины с помощью утилиты scp:
for((i=2;i<101;i++)); do scp /etc/hosts user@192.168.1.$i:/home/user; ssh user@192.168.1.$i sudo cp /home/user/hosts /etc/hosts; done
После выполнения данных команд файл hosts будет распространен на все машины, которые будут входить в домен.
Таким же образом можно редактировать данный файл на всех хостах в домене(например необходимо удалить строку с именем хоста — host40):
for((i=2;i<102;i++)); do ssh user@192.168.1.$i sudo sed -i ‘/host40/d’ /etc/hosts; done
Если Вам необходимо переключиться на резервный сервер на всех клиентских машинах, выполним команду:
for((i=2;i<102;i++)); do ssh user@192.168.1.$i sudo sed -i ‘s/SERVER=dc1.local/SERVER=dc2.local/g’ /etc/ald/ald.conf; sudo sed -i ‘s/SERVER_ID=1/SERVER_ID=2/g’ /etc/ald/ald.conf; sudo ald-client commit-config -f; done
Заключение
Как видно из данной публикации ald домен довольно просто разворачивать, а также очень просто администрировать используя стандартную системную утилиту fly-admin-smc.
Заметки при изучении ALD Pro
Решил зафиксировать в виде заметок изучение ALD Pro, которая находится на раннем своём этапе развития и полна детских болячек. Чтобы не выносить сор из избы, разработчики Астры прикрыли баг-трекер и теперь всё делается через выделенные каналы поддержки. Данная статья не повод оскорблять Астру, но повод поделиться с вами решёнными проблемами, особенно если вы, так же как и я, вынуждены осваивать ALD Pro в тестовой среде в рамках импортозамещения. Чем старее событие, тем оно будет ниже в тексте статьи.
Обновлено на дату 26.10.2022
Компонентная схема ALD Pro
Компонентная схема устройства Astra Linux Directory Pro для лучшего понимания что спрятано под капотом и как увязано с друг другом для простоты администрирования рядовым администратором.
Всегда отслеживайте репозиторий https://download.astralinux.ru/aldpro/stable/repository-main/dists/ и обновляйте свои тестовые стенды для получения актуальной версии.
Что пока не нравится
Ещё раз напомню, что я не хейтер Astra Linux вообще и ALD Pro в частности. Я линуксоид, хоть и люблю службу каталогов MS Active Directory, так как она мне известна и близка. Но я открыт к новому и к другим концепциям таких каталогов как FreeIPA под капотом у ALD Pro.
-
Версия ALD Pro уже 1.x, но продукт ещё сырой и тянет на альфу. Тем самым разработчики нарушили негласное правило, указав 1.х как некую готовность к производству. На словах у них всё типа готово, а в логах строки вида — использование settings.DEBUG приводит к утечкам памяти и настоятельно запрещается использовать в производственной среде.
Снова не применяются настройки серверов времени. Октябрь 2022
Уже делал тикет на эту проблему, когда ваши настройки и хотелки своих серверов времени не применяются. В рамках тикета мне чётко сказали что проблему устранили в версии ALD Pro 1.1.2. Вот думайте что угодно — соврали и не сделали или снова сломали, но мой тестовый стенд стал версии 1.1.3, а я снова вижу эту проблему. Снова тикет и снова ответ — Проблема известна разработчикам, ожидается исправление в ALD Pro версии 1.2.0.
Я сломал Salt. Октябрь 2022
Целиком и полностью моя вина! Вышел из отпуска и к этому моменту вышла версия 1.1.2, до которой и хотелось обновить свой тестовый стенд. Традиционно в мире Debian, прежде чем прыгать на новую версию, настоятельно рекомендуется вначале обновить систему в рамках релиза и уже потом прыгать в бездну. Запустил просто apt update && apt -y full-upgrade и не заметил как сломал Salt в рамках релиза 1.1.1. В ранее созданных тикетах разработчики часто просили вывод команды sudo salt ‘*’ test.ping , который легко и просто опрашивает всех миньонов. Команда показала что у меня отвалились 2 сервера из 4 в моей будущей армаде серверов ALD Pro .
В логах /var/log/salt/minion на проблемных серверах на каждый вызов sudo salt ‘*’ test.ping можно наблюдать строки:
2022-10-04 09:15:06,812 [salt.crypt :788 ][ERROR ][1451] Sign-in attempt failed: <'enc': 'pub', 'pub_key': '----BEGIN PUBLIC KEY----
nMIIBIjANB. ‘>
2022-10-04 09:15:06,814 [salt.minion :1149][ERROR ][1451] Error while bringing up minion for multi-master. Is master at dc1.company.ru responding?
2022-10-04 09:15:16,581 [salt.minion :1095][ERROR ][1451] Minion unable to successfully connect to a Salt Master.
Гуглёж показал верный ответ, но в то время я его не понял и не был готов воспринять, так как не знаком с Salt. Ошибка намекает на разницу в версиях, но это чуть позже мне разжевал лишь специалист из компании Astra. Из предоставленных отчётов команды sos report он выяснил что я где-то забыл мозги и на проблемных серверах указал совершенно не те адреса репозиториев, нарушив инструкцию.
Адреса репозитория для самой Astra Linux SE как платформы для ALD Pro должны быть пока версии 1.7.1
deb http://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.1/ repository-base 1.7_x86-64 main non-free contrib
deb http://download.astralinux.ru/astra/frozen/1.7_x86-64/1.7.1/ repository-extended 1.7_x86-64 main contrib non-free
Вот цитата ответа специалиста:
Тестирование ПК ALD Pro с ОС Astra Linux Special Edition версии 1.7.2 не окончено. Рекомендуем воздержаться от использования обновления 1.7.2 до окончания тестирования, так как мы не можем гарантировать беспроблемную работу ПК ALD Pro с ОС Astra Linux Special Edition версии 1.7 с установленным оперативным обновлением 2. Совместимость c Astra Linux Special Edition 1.7.2 будет добавлена в будущих версиях ALD Pro. Проблема с работой Salt вероятнее всего была вызвана отличием версий Salt, установленных на контроллере домена и "проблемных серверах".
Команда dpkg -l | grep salt подтвердила расхождение в версиях. Решил сделать ход конём: обновить стенд до версии 1.1.2 и исправить ситуацию с Salt через механизм понижения версии (apt downgrade).
Адреса репозиториев на проблемных серверах были исправлены согласно инструкции и выполнена команда sudo apt install salt-api=3004+ds-1 salt-common=3004+ds-1 salt-master=3004+ds-1 salt-minion=3004+ds-1 salt-ssh=3004+ds-1
dpkg: предупреждение: снижение версии salt-ssh с 3004.2+ds-1 до 3004+ds-1
dpkg: предупреждение: снижение версии salt-minion с 3004.2+ds-1 до 3004+ds-1
dpkg: предупреждение: снижение версии salt-master с 3004.2+ds-1 до 3004+ds-1
dpkg: предупреждение: снижение версии salt-common с 3004.2+ds-1 до 3004+ds-1
dpkg: предупреждение: снижение версии salt-api с 3004.2+ds-1 до 3004+ds-1
После рестарта сервисов sudo systemctl restart salt-master; sudo systemctl restart salt-api; sudo systemctl restart salt-minion ситуация была исправлена.
Мораль сей басни? Быть более внимательным, поменьше отсебятины, безукоснительно следовать инструкции.
Неработоспособность раздела Пользователи при огромном количестве учётных записей. Август 2022
Решено было протестировать работоспособность проекта ALD Pro на большом количестве учётных записей, чтобы рассмотреть ALD Pro НЕ как службу каталогов с кучей функционала, а хотя бы как Identity management (IdM). Обратились в рамках выделенного канала поддержки к разработчикам с вопросом, а есть ли готовые инструменты и/или API ALD Pro? И если нет, то можно ли безопасно использовать инструменты и/или API проекта FreeIPA, который трудится под капотом? Ответ был — вот держите скрипт ald.py, который явно показал что даже сами разработчики не используют API и просто формируют в питоновском скрипте вызовы консольной команды ipa. Данный скрипт так же не подошёл из-за того что просто тупо генерируются учётные записи вида user0, user1 . userN, где N желаемое вами число. Хотелось заранее поучиться массовой заливке учётных записей с заполнением стандартных и своих атрибутов и желательно данными, максимально приближенные к реальности. Жизнь может и часто приподносит сюрпризы.
Попросил у коллег обезличенные данные (ФИО, должность, код подразделения). Знаете ли вы, что Отчество это не обязательно одно слово и может быть несколько слов через пробел? Другими словами, есть мужчины, у которых полное имя состоит из нескольких слов (привет от капитана Очевидность ).
С помощью простого bash скрипта из Comma-Separated Values (CSV) файла создал примерно
10000 учётных записей в ALD Pro. Учётные записи для теста создавались по следующей схеме:
- Русские ФИО преобразовались транслитом в английские буквы с добавлением кода подразделения, чтобы полные тёзки получали уникальную тестовую учётную запись. Так Иванов Иван Иванович из бухгалтерии (код подразделения 010) получит учётку ivanoff.ivan.i.010
- В цикле while команды ipa собственно создавали нужное
ipa user-add $—first=»$» —last=»$ »
ipa passwd $12345678
ipa user-mod $—title=»$ »
ipa user-mod $—setattr=rbtamiddlename=»$ «
После 18 часов работы, так как не оптимизированная версия bash скрипта тратила почти 6 секунд на 1 учётку, тестовый сервер ALD Pro для чистоты эксперимента был перезагружен после заполнения данными.
Работа в веб-интерфейсе показала полную непригодность использования ALD Pro в качестве хотя бы Identity management (IdM):
- Консольная команда ipa user-find находит, к примеру, учётные записи с фамилией Петров. Веб интерфейс — не находит ничего, ни по-русски, ни по-английски по имени учётки petroff!
- Ожидаешь что при большом количестве учётных записей в веб-интерфейсе в разделе Пользователи появится большое количество экранов-страниц (page), но кнопка Далее позволяет лишь "дойти" до цифры 14 (и то иногда), после чего происходит некий сброс-сбой и ты оказываешься на странице с номером 10 или 11, как карта ляжет. На экране будет — не найдено!
Суть проблемы неясна, идёт разбирательство. Конкретная дата исправления пока не ясна. В рамках решения проблемы с поломкой центра помощи ALD Pro был обновлён до версии 1.1.1. Проблема частично сдвинулась с мёртвой точки: страницы (paging) начали работать и корректно оформляют
10000 записей, но поиск не работает до сих пор.
Разработчик в рамках вебинара от 29.09.2022 рассказал что при таких огромных количествах учётных записей требуется создание дополнительных сайтов (site). Но это нужно всё перепроверить в тестовой среде и многое остаётся не понятным. Под капотом многие данные хранятся в PostgreSQL и такие смешные цифры
10000 точно не его ограничение. Пользователи домена и вся информация в атрибутах нормально хранится в LDAP каталоге и нормально оперируется консольными утилитами FreeIPA. Такие смешные проблемы с цифрами выше 10000 это скорее всего ограничение смузихлёбного интерфейса, построенного с помощью Django и ReactJS.
Если нет 2 часа свободного времени, то лучше будет просто посмотреть концовку и ответы на вопросы участников.
Так же разработчик упомянул что доступна новая версия ALD Pro 1.1.2, в которой ряд проблем возможно решены. Всегда отслеживайте репозиторий https://download.astralinux.ru/aldpro/stable/repository-main/dists/ и обновляйте свои тестовые стенды для получения актуальной версии.
Проблема с развёртыванием сервера событий. Август 2022
Журнал заданий автоматизации уведомил об успешном развёртывании роли сервера событий на отдельном выделенном для этих целей сервере (назовём его audit.company.ru), но в разделе "Серверы журнала событий" по-прежнему пусто и если опять нажать кнопку — "Развернуть сервер журнала событий" снова предлагается audit.company.ru как свободный для установки, словно на него и не развёртывалась ранее роль сервера событий.
В рамках поддержки разработчики попросили ввести команду sudo salt ‘*’ test.ping с главного контроллера домена dc1, которая выявила что на втором-контроллере-домена-реплике dc2.company.ru не доступен (не работает, не отвечает) salt-minion: Minion did not return. [Not connected].
Рестарт службы salt-minion на dc2 и sudo salt ‘*’ test.ping рапортует что всё успешно — напротив всех серверов True. После чего развёртывание службы роли сервера событий прошло успешно и сервер audit.company.ru отобразился в разделе "Серверы журнала событий".
По иронии судьбы, рестарт служб salt так же помог с проблемой развёртывания сервера мониторинга. Мне впредь наука — прежде чем делать тикеты, смотреть статус и рестартить службы Salt. Это объясняет, но не извиняет разработчиков. У меня, как у пользователя-потребителя, должно всё работать искаропки. Их лозунги: "Простое управление службой каталогов" и "Простое решение сложных задач".
Безграничный журнал Bind. Август 2022
Для DNS службы в файле /etc/bind/named.conf определён файл журнала /var/cache/bind/named.run
logging <
channel default_debug <
file "named.run";
severity dynamic;
print-time yes;
>;
>;
Но нет ограничивающих параметров в размере файл-журнала средствами самого Bind типа versions 10 size 100m; или, как принято в linux системах, файл-параметр для LogRotate в каталоге /etc/logrotate.d/, регламентирующий смену (rotate) файла журнала и/или упаковку старых журналов Bind.
Файл-журнал /var/cache/bind/named.run довольно быстро нарастает в размере, особенно в изолированных от Интернет сегментах сети из-за недоступности сайтов родительских (upstream) проектов и/или протокола IPv6.
Типа такого
02-Aug-2022 09:42:09.954 network unreachable resolving ‘grafana.com/AAAA/IN’: 2001:503:ba3e::2:30#53
02-Aug-2022 09:42:10.740 host unreachable resolving ‘grafana.com/A/IN’: 202.12.27.33#53
Считаю что неограниченный ничем рост журнала Bind это упущение, требующее контроля и/или ограничений. Место на диске не резиновое и рано или поздно закончится.
Конкретная дата исправления пока не ясна.
Мониторинг не собирается мониторить. Август 2022
Разработчики упустили тот момент, что сервер мониторинга не обязательно будет развёрнут последним, чтобы он принялся обнаруживать (discovery) остальные сервера из группы ipaservers, которые были развёрнуты до него. Глупая и досадная оплошность. Через веб-интерфейс Zabbix в разделе Configuration — Discovery можно наблюдать правило atk_drule, которое НЕ изменилось с даты развёртывания самого сервера мониторинга и НЕ содержит какие либо IP адреса серверов ПОСЛЕ. Поэтому логично что в разделе Configuration — Hosts нет новичков и на мониторинг они не поставлены.
Конкретная дата исправления пока не ясна.
Не применяются настройки серверов времени. Июль 2022
В разделе "Служба синхронизации времени" вкладка "Внешний пул NTP серверов" если указать ваши сервера времени для обкатки работы домена в изолированном сегменте сети без прямого доступа к Интернет, то они не применяются. Если вы вручную измените содержимое /etc/chrony/chrony.conf, то значение естественно будет сброшено Salt в дефолт.
Разработчики вскоре исправят ситуацию, а пока, как обходной манёвр, можно добавить свои сервера напрямую в файл и повесить атрибут неизменяемости (immutable) sudo chattr +i /etc/chrony/chrony.conf
РЕШЕНО в версии ALD Pro 1.1.2.
Поломка Справочного Центра. Июль 2022
К данному моменту ALD Pro был штатно обновлён на новую версию 1.1.0 обязательно через sudo apt update && sudo apt full-upgrade
Не сразу понял что справка сломалась.
Советы НЕ помогли:
cd /opt/rbta/aldpro/mp/api/help-center
python3 manage.py migrate
tar -xzf dump.json.tar.gz
python3 manage.py loaddata dump.json
sudo apachectl graceful
РЕШЕНО в версии ALD Pro 1.1.1.
Поломка системы после ввода мониторинга. Июль 2022
Оказалось что какой-то из разработчиков не доглядел при написании задач для Salt и указал жёстковшитый домен ASTRA-LOCAL вместо вашего домена в виде элемента dirsrv@DOMAIN-NAME.service у Zabbix. В этом месте меня напряг совет исправить ситуацию напрямую в веб-интерфейсе Zabbix с входом через дефолтный логин Admin и пароль zabbix.
Что-то я пока не представляю как мне оптимальнее спрятать армаду серверов ALD Pro от пользователей, кроме как упросить сетевиков-коллег отделить ALD Pro в отдельную подсеть с жёсткой фильтрацией доступа.
Нельзя русскую букву Ё в русской службе каталога. Июль 2022
Просто ужас, когда отгрёб такую дичь. Ответ: Указанная ошибка будет исправлена в версии ALD Pro 1.2.0. Планируемая дата выхода — сентябрь 2022 года.
Ошибки развёртывания сервера мониторинга. Июль 2022
По документу ПРОГРАММНЫЙ КОМПЛЕКС «ALD PRO» Руководство администратора. была попытка развернуть штатно через GUI сервер мониторинга. Сервер мониторинга был установлен, настроен и введён в домен. Оставалось лишь развернуть роль, но задача завершалась с ошибкой.
Помог совет: Попробуйте перед запуском задания установку роли выполнить на контроллере домена команды:
sudo systemctl restart salt-master
sudo systemctl restart salt-api
sudo systemctl restart salt-minion
На сервере мониторинга перед запуском задания выполните команду: sudo systemctl restart salt-minion
Ошибки запроса к LDAP по мере ввода букв. Июль 2022
В поле "Руководитель подразделения" можно указать учётную запись из ниспадающего списка, но в больших организациях при огромном количестве учёток проще начинать набирать нужное в надежде что фильтр начнёт убавлять список. Но возникала ошибка запроса. Ситуация исправлена в ALD Pro версии 1.1.0.
Полезные видеоматериалы ALD Pro на моём канале
Собственное изучение ALD Pro. Ролики воссоздают задания, которые шли к тестовому полигону из 8 готовых виртуальных машин.
Служба Astra Linux Directory
Astra Linux Directory в Astra Linux Special Edition версии 1.2
Служба Astra Linux Directory (ALD) представляет собой систему управления ЕПП. Таким образом, ALD является надстройкой над технологиями LDAP, Kerberos 5, CIFS и обеспечивает автоматическую настройку всех необходимых файлов конфигурации служб, реализующих перечисленные технологии, а так же предоставляет интерфейс управления и администрирования. Все необходимые компоненты службы ALD входят в состав следующих пакетов:
– ald-client — клиентская часть ALD. Содержит утилиту конфигурирования клиентского компьютера ald-client и утилиту автоматического обновления пользовательских билетов -renew-tickets. Пакет должен устанавливаться на все клиентские компьютеры, входящие в домен; – ald-admin — содержит утилиту ald-admin и утилиту администрирования БД ALD. Пакет должен устанавливаться на компьютеры, с которых будет осуществляться администрирование БД ALD. При установке данного пакета также устанавливается клиентская часть; – ald-server — серверная часть ALD. Содержит утилиту конфигурации сервера ald-init. Пакет должен устанавливаться на сервер домена. При установке данного пакета также устанавливается ald-admin и, соответственно, клиентская часть. В руководстве man подробно описаны все возможности указанных утилит.
Для поддержки централизации хранения атрибутов СЗИ в распределенной сетевой среде предназначены дополнительные пакеты ALD, первая часть наименования которых соответствует одному из основных пакетов:
– ald-client-parsec — расширение, необходимое клиентской части ALD; – ald-admin-parsec — расширение утилиты администрирования БД ALD; – ald-server-parsec — расширение, необходимое для организации хранения атрибутов СЗИ на сервере ALD;
Без установки пакетов расширения совместно с соответствующими основными пакетами невозможна централизация хранения атрибутов СЗИ в распределенной сетевой среде, что может привести к невозможности входа пользователей в систему. В состав ОС входит графическая утилита fly-admin-ald, которая позволяет администратору произвести управление ЕПП в графическом режиме (см. электронную справку).
Настройка
Настройка всех компонентов ALD осуществляется автоматически утилитами конфигурирования. Настройки сервера и клиентов ALD содержатся в файле /etc/ald/ald.conf. После изменения данного файла необходимо выполнить команду commit-config для того, чтобы изменения вступили в силу:
ald-init commit-config (на сервере)
ald-client commit-config (на клиентах)
Формат файла: ИМЯ_ПАРАМЕТРА=значение # Комментарий
В файле для системы ALD задаются следующие параметры:
– VERSION — для текущей версии должно быть установлено значение 1.3;
– DOMAIN — имя домена. Должно быть задано в формате:
.example.ru
для сервера ALD. Если данный параметр меняется, то необходимо заново инициализировать сервер командой:
Можно также воспользоваться командами:
ald-init backup-ldif
ald-init restore-backup-ldif
для переименования домена;
– SERVER — полное имя серверного компьютера ALD.
Минимальный номер глобального пользователя. Пользователи с номером меньше данного считаются локальными и аутентифицируются через локальные файлы /etc/passwd и /etc/shadow. П р и м е ч а н и е. Для нормальной работы домена не рекомендуется пересечение по номерам локальных и глобальных пользователей и групп. Не рекомендуется задавать MINIMUM_UID меньше 1000;
– TICKET_MAX_LIFE=10h — максимальное время жизни билета Kerberos (если его не обновлять). Формат параметра: NNd (дни), или NNh (часы), или NNm (минуты).
При входе в домен пользователь получает билет. При выходе из домена билет уничтожается. Если билет не обновлять, то после истечения срока действия билета пользователь потеряет доступ к своему домашнему каталогу. Чтобы восстановить доступ, ему придется выполнить команду kinit или зайти в систему заново. Чтобы доступ не был потерян, билет следует периодически обновлять (до истечения срока действия). Настроить автоматическое обновление можно с помощью утилиты ald-renew-ticket.
Для удобства можно настроить данный параметр на большое количество времени, например 30d. Но это менее безопасно;
– TICKET_MAX_RENEWABLE_LIFE=7d — максимальное обновляемое время жизни билета Kerberos. Формат параметра: NNd (дни), или NNh (часы), или NNm (минуты).
По истечении данного срока билет не может быть обновлен. Данный параметр должен быть больше, чем параметр TICKET_MAX_LIFE.
П р и м е ч а н и е. Для клиентских компьютеров параметры TICKET_MAX_LIFE и TICKET_MAX_RENEWABLE_LIFE определяются как наименьшие значения этих параметров, заданных в файлах ald.conf на сервере и на клиентском компьютере;
– NETWORK_FS_TYPE — определяет, какая сетевая ФС будет использоваться для глобальных пользовательских домашних каталогов. Возможные значения:
– none — сетевая ФС не используется. Работает только аутентификация глобальных пользователей. Используются локальные домашние каталоги пользователей. (Следующие параметры, относящиеся к сетевой ФС, игнорируются);
– cifs — используется Samba/CIFS;
– SERVER_EXPORT_DIR — (только для сервера). Задает абсолютный путь к каталогу на сервере, где будет располагаться хранилище домашних каталогов. Данный каталог будет экспортирован по Samba/CIFS;
– CLIENT_MOUNT_DIR — задает абсолютный путь к точке монтирования хранилища домашних каталогов на клиентских компьютерах;
– SERVER_FS_KRB_MODES — (только для сервера). Задает режимы экспорта сервера Samba/CIFS (перечисленные через запятую). Возможные режимы:
– krb5 — только Kerberos-аутентификация;
– krb5i — (integrity) аутентификация и проверка целостности (подпись) пакетов.
Должен быть указан хотя бы один режим;
– CLIENT_FS_KRB_MODE — задает Kerberos-режим монтирования на клиентском компьютере. Должен быть указан один из режимов: krb5 или krb5i;
– SERVER_ON — включает/выключает сервер. Присвоенное значение может быть 0 или 1.
Если на клиентском компьютере SERVER_ON=0, это аналогично CLIENT_ON=0. Если на сервере SERVER_ON=0, то:
– домашние каталоги не экспортируются;
– разрешение имен по LDAP выключается в nsswitch.conf;
– все принципалы Kerberos деактивируются (allow_tickets=0);
– службы LDAP, Samba, Kerberos, nss-ldapd останавливаются;
– служба nscd перезапускается;
– CLIENT_ON — включает/выключает клиентскую часть ALD. Присвоенное значение может быть 0 или 1. Если CLIENT_ON=0, то: