Служба 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, то:
ALD Pro как замена Active Directory?
Сегодня многие западные корпорации ввели против России санкции. Не стала исключением и Microsoft. В результате у российских клиентов этого софтверного гиганта встал вопрос: что делать со всем тем, что ранее работало под управлением продуктов данной компании? Альтернативы операционным системам и офисным пакетам худо-бедно есть (здесь мы это обсуждать не будем), но есть один продукт, который является краеугольным камнем практически любой корпоративной информационной инфраструктуры — Active Directory (AD). Как быть с ней? За предыдущие 22 года этот продукт прочно вошел в подавляющее большинство предприятий, став основой для централизованного управления учетными записями пользователей и компьютеров, а также централизованного управления настройками компьютеров посредством групповых политик. Это мощный, но при этом достаточно простой и понятный в применении инструмент.
Рассмотрим какие у нас есть альтернативы Active Directory.
· SAMBA — программный комплекс, который изначально строился как свободная альтернатива продуктам Microsoft. В 4 версии был реализован режим Active Directory.
· FreeIPA — разрабатывался изначально как нечто альтернативное AD, но не повторяет его в деталях. Общего с AD — LDAP и Kerberos, но внутреннее техустройство другое. Свободное ПО.
· ALD — разработка РусБИТех-Астра. Построена на базе SAMBA. Реализован домен наподобие NT 4.0.
· ALD Pro — новый продукт от РусБИТех-Астра на основе FreeIPA.
Итак, у нас имеется несколько альтернатив. В чем их особенности, преимущества и недостатки?
SAMBA — подходит как для работы с Windows клиентами, так и с Linux. Для Windows клиентов можем применить групповую политику, но для Linux групповые политики недоступны. Плюс к этому имеется ряд ограничений (см. например: https://habr.com/ru/post/272777/).
FreeIPA — ориентирована на работу с клиентами *nix систем (не только Linux). Но Windows клиенты фактически не поддерживаются (условно поддерживаются, но после танца с бубном, см. к примеру https://redos.red-soft.ru/base/arm/arm-domen/windows-in-ipa/ ). Вторя проблема — это отсутствие групповых политик от слова совсем.
ALD — модифицированный РусБИТех-Астра домен SAMBA. Функционал подобен домену NT 4.0 (SAMBA3). Ориентирован на клиентов под управлением Astra Linux. Считается устаревшим, хотя в версии 1.7.х пакеты для него все еще присутствуют.
ALD Pro — новый продукт от РусБИТех-Астра (http://www.aldpro.ru/). В основе домен FreeIPA. Основные компоненты которого:
· 389 Directory Server — служба каталогов LDAP;
· MIT Kerberos — аутентификация клиентов и сервисов;
· BIND9 — DNS сервер;
· SaltStack — реализует механизм групповых политик.
Помимо этого, могут быть настроены дополнительные службы для домена, а именно: мониторинга (Zabbix + Graphana), централизованного сбора журналов (Fluentd), DHCP, репозиториев, автоматической установки ОС, печати и файловый сервер.
Ориентирован ALD Pro на работу прежде всего с Astra Linux. Потенциально другие клиенты Linux работать в домене будут, но как централизовано управлять ими вам придется самим решать.
Управление компонентами системы и клиентами в ALD Pro реализовано через веб-интерфейс. Что существенно упрощает жизнь администраторам, особенно тем, кто не желает вдаваться в подробности внутреннего мира Linux.
В службе каталогов ALD Pro реализована возможность создать организационную структуру, которая (как и в AD) используется как для организации объектов, так и для применения политик и делегирования полномочий.
Помимо непосредственно службы каталога в ALD Pro имеется механизм централизованной настройки клиентов. Этот механизм можно разделить на три составляющие групповые политики, управление программным обеспечением клиентов и задания автоматизации. Применяется все это посредством Saltstack. Для групповых политик вы можете использовать уже имеющиеся политики или создать свои, для этого придется написать скрипт на Saltstack. Принцип работы групповых политик похож на то, что имеется в AD: на сервере определяется политика, она назначается на подразделение и применяется к пользователям или компьютерам. Задания автоматизации, в отличие от политик, применяются однократно и на выбранные компьютеры. Задания автоматизации необходимо предварительно создать.
Еще несколько важных слов в отношении ALD Pro
Можно ли с помощью ALD Pro полностью заместить Active Directory? Нет, нельзя. Она поддерживает только клиентов Astra Linux, потенциально и другие ОС Linux. Вы можете настроить доверительные отношения с доменом AD или сд елать миграцию пользователей. Но просто заменить одно на другое не получится.
Сможет ли условный администратор AD пересесть на ALD Pro? Это тоже не так. Интерфейс и логика управления совершенно другие. Придется все это изучать. Хотя ALD Pro предлагает упрощенный способ управления доменной средой, но не стоит забывать поговорку: «Гладко было на бумаге, да забыли про овраги». Стандартные задачи решаются довольно просто, но любое отклонение от заданного шаблона приводит к необходимости детального изучения вопроса и выработки соответствующего решения, что невозможно без досконального знания внутреннего строения операционной системы и ALD Pro.
Стоит ли это все применять? Да, стоит! ALD Pro — это законченное решение в отличие от других. В ALD Pro сосредоточены не только управление доменом, но и жизненным циклом операционных систем, которые работают в этом домене, от установки ОС до настройки индивидуальных параметров. И управление в общем реализовано не в виде привычного для администратора Linux копания в командной строке, но посредством удобного и стандартизированного веб-интерфейса.
А для тех, кого все это заинтересовало милости просим к нам на курсы по ALD Pro — AP-1101 и другие курсы для администраторов Astra Linux.
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.
– 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.
– 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, то:
Администрирование 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.