Служба ald astra linux что это

единое пространство пользователей astra linux

Использование службы ALD ОССН Astra Linux для защиты информации.

1. Формирование корпоративного уровня сетевой инфраструктуры ОССН. Единое пространство пользователей

Рисунок 1. Вариант реализации корпоративной ЗЛВС для мультисервисной системы связи на базе ОССН Astra Linux Special Edition (релизы Смоленск, Мурманск, Новороссийск).

На рис. 1 представлен вариант реализации корпоративной ЗЛВС для мультисервисной системы связи на базе ОССН. При этом рабочие станции пользователей ЗЛВС являются клиентами доменной сетевой инфраструктуры, координируемой первичным контроллером домена (Primary Domain Controller

PDC) под управлением ОССН.

Текущий релиз ОССН поддерживает доменную сетевую инфраструктуру, основанную на технологии Active Directory (AD), которая является совместимой с технологией Microsoft Directory Service и базируется на реализации следующих протоколов:

Определение из Википедии:

Kerberos /kɛərbərəs/ — сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними, причём в протоколе учтён тот факт, что начальный обмен информацией между клиентом и сервером происходит в незащищенной среде, а передаваемые пакеты могут быть перехвачены и модифицированы.

Благодаря поддержке указанных протоколов в рамках корпоративного уровня сетевой инфраструктуры ОССН зарегистрированные пользователи получают возможность:

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

В общем виде схема организации ЕПП показана на рис. 2, при этом её логическими составляющими являются:

В рамках клиента домена ЕПП реализует:

Рисунок 2. Схема организации ЕПП домена на основе ОССН.

В рамках контроллера домена ЕПП реализует:

Реализацию политики безопасности в рамках доменной сетевой инфраструктуры выполняет LSM-модуль parsec-cifs подсистемы безопасности PARSEC, который инициализируется на контроллере и клиентах домена в процессе инсталляции на них ОССН в ролях контроллера и клиента домена соответственно. По своим функциональным возможностям модуль parsec-cifs идентичен модулю parsec, функционирующему в случае применения ОССН на компьютерах, не входящих в состав доменной сетевой инфраструктуры.

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

В ОССН локальное и глобальное пространства имён (систем учётных записей пользователей и групп пользователей) функционируют параллельно. Для их различения выполнено разграничение диапазонов UID: значения UID меньшие 2500 относятся к локальному пространству имён, а значения UID больше либо равные 2500 к глобальному пространству имён.

Механизм «I&А» (Identification and Authentication), в пределах локального пространства имён на клиенте домена под управлением ОССН реализуется с использованием архитектуры РАМ, особенности использования которой рассмотрены в предыдущей лекции. Реализация этого механизма в рамках глобального пространства имён в домене на базе ОССН основана на инфраструктуре LDAP (хранение и администрирование учётных записей пользователей домена), функционирующей совместно с протоколом Kerberos.

База данных учётных записей глобального пространства имён реализована в виде «Дерева директорий информации» (Directory Information Tree — DIT). Подобная модель хранения данных основана на записях, содержащих наборы атрибутов, различающиеся по «Отличительному имени» (Distinguished Name — DN), которые используются для реализации однозначности при обращении к записи. Каждый из атрибутов записи относится к конкретному типу и имеет одно или несколько значений. Типы обычно представлены строковыми переменными.

DIT глобального пространства имён контроллера домена на базе ОССН разделено на две DN-ветви: ou = People и ои = Group₎ которые свою очередь имеют дочерние DN-ветви, имеющие тип сп и содержащие атрибуты учётных записей самих пользователей домена, групп пользователей домена и их теневых паролей. В общем DIT ресурсе контроллера домена указанные DN-ветви включены в DN-ветви dc = engine и dс = local. В графическом виде общее DIT контроллера домена на базе ОССН показано на рис. 3.

c users svetlana appdata local temp finereader12

Рис. 3. Структура DIT-дерева, реализующего глобальное пространство пользователей домена на базе ОССН

Таблица. Расшифровка названий атрибутов ГПП ОССН.

Атрибут	Англоязычное название	Русскоязычное название	Value\Значение
DN	Distinguished Name	Отличительное (уникальное) имя	CN=Сергей Петрович Иванов,OU=Компания,DC=domain,DC=com
DC	Domain Component	Компонент(класс) доменного имени.	DC=domain,DC=com
OU	Organizational Unit	Подразделение	Компания
CN	Common Name	Общее имя	Сергей Петрович Иванов

word image 12 С учётом МРОСЛ ДП-модели атрибуты DIT-дерева дополняются DN-ветвями, определяющими информационные сервисы для мандатных уровней конфиденциальности и целостности. Эти дополнительные атрибуты находятся в файле /etc/parsec/mldap.conf (рис. 4).

Рисунок 4. Дополнительные атрибуты DIT-дерева, определяющие информационные сервисы для реализации МРОСЛ ДП-модели

c users svetlana appdata local temp finereader12 1 1 В зависимости от необходимости использования локальной или глобальной реализации механизма «I&А» на клиенте домена производится их динамическое переключение, основанное на технологии NSS (Name Service Switch). Эта технология создаёт модульное окружение для управления пользовательскими учётными записями, реализованное в виде набора загружаемых библиотек (backends). При этом базовые системные вызовы при применении технологии NSS реализованы в библиотеке glibc, которая в зависимости от конфигурации NSS вызывает те или иные backend (рис. 5).

Рисунок. 5. Схема реализации технологии NSS на клиенте домена под управлением ОССН.

Функции библиотеки glibc, реализующие технологию NSS на клиенте домена под управлением ОССН, вызывают два backend:

• libnss_file — модуль, обеспечивающий идентификацию локальных учётных записей пользователей и групп пользователей с использованием конфигурационных файлов /etc/passwd, /etc/group, /etc/shadow, /etc/gshadow (авторизация при этом выполняется соответствующим РАМ-модулем);

• libnss_ldap — модуль, обеспечивающий идентификацию учётных записей пользователей и групп пользователей домена с использованием соответствующих DN-ветвей DIT-дерева на контроллере домена (авторизация при этом может выполняться как с использованием РАМ-модуля libpam_ldap — связка NSS/PAM, так и с использованием сквозной аутентификации по протоколу Kerberos — метод аутентификации по умолчанию). Конфигурация NSS задаётся в файле /etc/nsswitch.conf. Таким образом, при выполнении процессов, требующих обращения к именованным сущностям, соответствующие вызовы функций библиотеки glibc будут обращаться к функциям backend, указанных в файле /etc/nsswitch.conf. Пример файла /etc/nsswitch.conf клиента домена на базе ОССН приведён на рис. 6.

Рисунок 6. Пример конфигурационного файла NSS на клиенте домена

Кроме имён и идентификаторов учётных записей пользователей и групп пользователей технология NSS позволяет определять имена и идентификаторы протоколов, номера портов сервисов, IP-адреса и имена хостов, а также другие данные. В частности, применительно к МРОСЛ ДП-модели технология NSS позволяет определять источники данных для задания мандатных уровней конфиденциальности и целостности, для этого используется конфигурационный файл /etc/parsec/mswitch.conf подсистемы безопасности PARSEC (рис. 7).

Для сквозной аутентификации пользователей домена на базе ОССН применяется протокол Kerberos. В рамках доменной инфраструктуры, основанной на применении OpenLDAP (представлена демоном slapd) и протокола Kerberos, механизм единого входа реализуется с использованием технологии SASL (Simple Authentication and Security Layer). В частности, для версии MIT Kerberos 5, используемой в ОССН, в рамках технологии SASL применён механизм GSSAPI (The Kerberos Version 5 Generic Security Service Application Program Interface Mechanism). Таким образом, модель механизма единого входа в ОССН именуется LDAP based on Kerberos (SASL/GSSAPI).

word image 14

Рисунок 7. Конфигурационный файл для определения источников данных на клиенте домена.

word image 15

Рис. 8. Конфигурационный файл механизма Kerberos 5 GSSAPI.

Конфигурационным файлом механизма GSSAPI является файл
/etc/gssapi-mech.conf, с котором определяется функция инициализации механизма при вызове библиотеки Kerberos 5 GSSAPI (рис. 8). При этом общим конфигурационным файлом реализации протокола MIT Kerberos 5 является файл /etc/krd5.conf, конфигурация KDC задаётся в файле /etc/krb5kdc/kdc.conf.

Организация механизма «I&А» в пределах глобального пространства имён ЕПП, реализуемого в ОССН, обеспечивает возможность пользователям доменной сетевой инфраструктуры на базе ОССН получать доступ к глобальному пространству ресурсов, поддержка которого возложена на модифицированную реализацию пакета программ Samba, именуемую сетевая защищённая файловая система (СЗФС). СЗФС может функционировать как в составе контроллера домена (выполняющего при этом дополнительные функции файл-сервера), так и в составе клиентов домена, реализующих функции файл-сервера для предоставления доступа к собственным разделяемым ресурсам. Поскольку СЗФС является модификацией пакета программ Samba, она состоит из следующих компонент:

Дополнительно для администрирования СЗФС имеется графическая утилита «Общие папки (Samba)» (fly-admin-samba), расположенная в меню «Настройки» главного пользовательского меню.

Базовыми компонентами СЗФС являются демоны smbd и nmbd, а также клиентское приложение smbclient. Демон smbd реализует функции сервиса сетевой печати и разделения файлов для клиентских приложений smbclient, функционирующих в рамках доменной сетевой инфраструктуры на базе ОССН, а также клиентских приложений, функционирующих под управлением ОС семейства Microsoft Windows. Конфигурация демона smbd в ОССН задаётся в файле /etc/samba/smb.conf. Демон nmbd по умолчанию реализует функции сервиса имён протокола NetBIOS, а также может использоваться для запроса других сервисных служб имён.

2. Служба ALD. Администрирование доменной сетевой инфраструктуры ОССН

Рассмотренные компоненты доменной сетевой инфраструктуры ОССН требуют конфигурирования в процессе её установки на хосты, реализующие контроллеры и клиенты домена, а также администрирования в процессе эксплуатации домена. Для этого в ОССН имеется служба ALD, схема которой показана на рис. 9.

Таким образом, служба ALD состоит из следующих компонент.

Базовые компоненты, представленные пакетами программ конфигурирования:

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

Базовый администратор домена ALD, используя набор программ базовых компонентов службы ALD, а также их расширений и графическую утилиту «Управление политикой безопасности» (.fly-admin-smc) рабочего стола Fly, может выполнять следующие операции:

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

На первом этапе учитывается, что способ сетевого соединения контроллера и клиентов домена ALD зависит от типа адресации, используемой в сетевом сегменте. Статическая адресация целесообразна при небольшом числе хостов, входящих в состав домена ALD. При этом сетевой интерфейс каждого хоста, входящего в домен ALD, конфигурируется индивидуально. Динамическая адресация целесообразна при значительном числе хостов, входящих в состав домена ALD или их большой территориальной удалённости. В этом случае на контроллере ALD (или на другом специально выделенном хосте) конфигурируется и запускается сервер динамической сетевой адресации DHCP (Dynamic Host Configuration Protocol).

На втором этапе для функционирования домена ALD обеспечивается настройка сетевых имён таким образом, чтобы сетевое имя хоста разрешалось, в первую очередь, как полное имя (например, astra-server.example.ru). При этом команда hostname должна возвращать короткое сетевое имя хоста (например, astra-server).

При небольшом количестве хостов, входящих в домен ALD, такую настройку, как правило, выполняют вручную, конфигурируя файл /etc/hosts (рис. 10). В случае большого количества хостов в составе домена ALD на контроллере домена (или на специально выделенном хосте) конфигурируют службу доменных имён DNS (Domain Name Service).

На третьем этапе конфигурируют серверную и клиентскую части домена ALD, реализованные в виде одного демона aldd:

word image 17

Рис. 11. Пример конфигурирования файла /etc/ald/ald.conf на хосте, реализующем функции контроллера домена

c users svetlana appdata local temp finereader12 1 1

Рис. 12. Пример выполнения команды ald-init с параметром commit-config на хосте, реализующем функции контроллера домена

Эти действия осуществляются путём редактирования параметров файла /etc/aid/ald.conf (при этом в большинстве случаев для всех этих параметров используются значения по умолчанию). Обязательной модификации подлежит параметр SERVER, в качестве значения которого указывается выбранное на втором этапе имя сервера (в примере на рис. 11 это dc1.example.ru).

c users svetlana appdata local temp finereader12 1 2

Рис. 13. Пример выполнения команды ald-init с параметром init на хосте, реализующем функции контроллера домена

На четвёртом этапе базовый администратор домена с использование команды
ald-admin или графическую утилиты «Управление политикой безопасности» (рис. 14, 15) создаёт или редактирует учётные записи пользователей домена, управляет компьютерами домена, а также политиками безопасности на активном сервере ALD.

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

Операционные системы Astra Linux

Оперативные обновления и методические указания

Операционные системы Astra Linux предназначены для применения в составе информационных (автоматизированных) систем в целях обработки и защиты 1) информации любой категории доступа 2) : общедоступной информации, а также информации, доступ к которой ограничен федеральными законами (информации ограниченного доступа).

1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).

Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».

На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.

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

Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.

В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.

Очередные обновления (версии) предназначены для:

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

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

Операционные системы Astra Linux

Оперативные обновления и методические указания

Очередные обновления (версии) предназначены для:

Вы используете устаревшую версию браузера.
Обновите Ваш браузер для надежной и безопасной работы.

ИНОВАЦИОННОЕ РЕШЕНИЕ ДЛЯ ЦЕНТРАЛИЗОВАННОГО УПРАВЛЕНИЯ И АВТОМАТИЗАЦИИ LINUX-ПОДОБНЫХ СИСТЕМ

Программный комплекс ALD Pro на базе ОС Astra Linux предназначен для централизованного управления объектами организаций различного масштаба

ALD Pro — оптимальный выбор для импортозамещения в любых организациях

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

Возможность комфортной поэтапной миграции

Ключевые преимущества

функциональные
возможности ALD PRO

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

Миграция данных из MS Active Directory

Создание иерархии подразделений

Удаленная установка ОС

Автоматизированная установка ПО на клиенты

Управление подразделениями, компьютерами и пользователями

Управление групповыми политиками

Инвентаризация, отчетность и мониторинг

Сбор и хранение событий безопасности

Лицензионное соглашение

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

Правообладатель ALD Pro — ООО «РусБИТех-Астра» (ГК Astra Linux).

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

Техническая поддержка

В лицензию на ALD Pro по умолчанию входит «Стандартный» пакет услуг технической поддержки.

Для бессрочных лицензий он действует 1 год, для «срочных» — в течение всего срока действия лицензии. При этом мы готовы предложить вам намного больше: пакет «Привилегированный» с максимальным набором возможностей: персонализированным сервисом 24х7, ускоренным решением вопросов и расширенным спектром услуг.

Настройка двухфакторной аутентификации в домене Astra Linux Directory

В этом посте мы решили рассказать о доменной аутентификации в Linux, с использованием смарт-карт и USB-токенов JaCarta PKI в качестве второго фактора аутентификации. Если о локальной аутентификации через PAM-модуль информации существует довольно много, то вопрос доменной инфраструктуры и аутентификация по Kerberos-билетам в Linux рассмотрен слабо, особенно на русском языке. В качестве операционной системы возьмем Astra Linux и на примере Astra Linux Directory (ALD) это и покажем.

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

Немного вводных об Astra Linux Directory (ALD) и JaCarta PKI

Домен Astra Linux Directory (ALD) предназначен для организации единого пространства пользователей (домена локальной вычислительной сети) в автоматизированных системах.

ALD использует технологии LDAP, Kerberos5, Samba/CIFS и обеспечивает:

В среде Astra Linux Directory (ALD) электронные ключи JaCarta PKI могут использоваться для двухфакторной аутентификации пользователя в домене ALD и отказа от паролей. Кроме того, с этими же электронными ключами можно выполнять различные сценарии внутри ОС, после аутентификации, такие, как: электронная подпись, хранение ключевых контейнеров, доступ к Web-ресурсам, проброс ключа в сессии MS Windows. Доступ к VDI сервисам, таким, как VmWare или Citrix.

Процесс настройки

Пример демо-зоны

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

Для обеспечения работы со смарт-картой JaCarta PKI на клиенте и сервере установите следующие пакеты: libccid, pcscd, libpcsclite1. После установки этих обязательных пакетов установите пакет драйверов IDProtectClient, который можно загрузить с официального сайта «Аладдин Р.Д.».

Для обеспечения работы со смарт-картой подсистемы Kerberos добавочно к предустановленным пакетам ald/kerberos установите пакет krb5-pkinit на клиенте и сервере.

Для обеспечения возможности выпуска ключей и сертификатов на JaCarta PKI на сервере также установите пакеты libengine-pkcs11-openssl и opensc.

Установка и настройка центра сертификации на сервере

В качестве центра сертификации (CA) будет использован OpenSSL.

OpenSSL — криптографический пакет с открытым исходным кодом для работы с SSL/TLS. Позволяет создавать ключи RSA, DH, DSA и сертификаты X.509, подписывать их, формировать CSR и CRT.

Все настройки в руководстве выполняются для тестового домена EXAMPLE.RU. Примем, что сервер и клиент принадлежат домену EXAMPLE.RU, имя сервера – kdc, а клиента – client. При настройке используйте имя вашего домена, сервера и клиента. Выполните следующие действия.

Подготовка смарт-карты. Выпуск ключей и сертификата пользователя

Убедитесь в том, что установлены пакеты libengine-pkcs11-openssl и opensc. Подключите устройство, которое следует подготовить.

Проинициализируйте устройство, установите PIN-код пользователя. Помните, что инициализация устройства удалит все данные на JaCarta PKI без возможности восстановления.

Для инициализации необходимо воспользоваться утилитой pkcs11-tool.

—slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

—init-token – команда инициализации токена;

—so-pin 00000000 – PIN-код администратора JaCarta PKI. По умолчанию имеет значение 00000000;

—label ‘JaCarta PKI’ – метка устройства;

—module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so. Устанавливается в рамках пакета idprotectclient см. раздел «Установка драйверов на сервер и клиент».

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

—init-pin – команда установки PIN-кода пользователя;

—so-pin 00000000 – PIN-код администратора JaCarta PKI. По умолчанию имеет значение 00000000;

—login – команда логина;

—pin 11111111 – задаваемый PIN-код пользователя;

Сгенерируйте ключи на устройстве, для этого введите следующую команду:

—id 42 — устанавливает атрибут CKA_ID ключа. CKA_ID может быть любым;

Запомните это значение! Оно необходимо для дальнейших шагов подготовки устройства к работе.

—label “test1 key” — устанавливает атрибут CKA_LABEL ключа. Атрибут может быть любым;

Сгенерируйте запрос на сертификат с помощью утилиты openssl. Для этого введите следующие команды:

Информацию, которую необходимо указать в запросе, следует задавать в поле «/C=RU/ST=Moscow/L=Moscow/O=Aladdin/OU=dev/CN=test1 (! Ваш_Пользователь!)/emailAddress=test1@mail.com».

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

$ export REALM=EXAMPLE.RU #Ваш домен
$ export CLIENT=test1 #Ваш пользователь

и выпустить сертификат на пользователя.

Далее перекодируйте полученный сертификат из PEM в DER.

Запишите полученный сертификат на токен.

—type ‘cert’ — указывает, что тип записываемого объекта – сертификат;

—id 42 — устанавливает атрибут CKA_ID сертификата. Должен быть указан тот же CKA_ID, что и для ключей;

—module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so.

Настройка клиента. Проверка работоспособности

Создайте на клиенте каталог /etc/krb5/. Скопируйте в /etc/krb5/ сертификат CA (cacert.pem) c сервера.

Настройте kerberos в /etc/krb5.conf. Секцию [libdefaults] дополните следующими строками.

kinit Когда появится строка запроса PIN-кода к карте, введите его.

Для проверки того, что kerberos-тикет был успешно получен для пользователя, введите команду klist. Для удаления тикета — kdestroy.

Для входа в домен по смарт-карте на экране входа в ОС вместо пароля введите PIN-код от смарт-карты.

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

Настройка astra linux directory

Комплекс программ Astra Linux Directory (ALD) является нашей разработкой и предназначен для организации единого пространства пользователей (домена локальной вычислительной сети) в автоматизированных системах.

ALD использует технологии LDAP, Kerberos 5, Samba/CIFS и обеспечивает:

централизованное хранение и управление учетными записями пользователей и групп;
сквозную аутентификацию пользователей в домене с использованием протокола Kerberos 5;
функционирование глобального хранилища домашних директорий, доступных по Samba/CIFS;
автоматическую настройку всех необходимых файлов конфигурации UNIX, LDAP, Kerberos, Samba, PAM;
поддержку соответствия БД LDAP и Kerberos;
создание резервных копий БД LDAP и Kerberos с возможностью восстановления;
интеграцию в домен входящих в дистрибутив СУБД, серверов электронной почты, веб-серверов, серверов печати и т.п.

Кроме того, ALD предоставляет программные интерфейсы для интеграции в домен разрабатываемых программных решений.

«Служба Astra Linux Directory (ALD) представляет собой систему управления ЕПП. Таким образом, ALD является надстройкой над технологиями LDAP, Kerberos 5, CIFS и обеспечивает автоматическую настройку всех необходимых файлов конфигурации служб, реализующих перечисленные технологии, а также предоставляет интерфейс управления и администрирования. Все необходимые компоненты службы ALD входят в состав следующих пакетов:

ald-server — серверная часть ALD. Содержит утилиту конфигурации сервера ald-init. Пакет должен устанавливаться на сервер домена. При установке данного пакета также устанавливается ald-admin и, соответственно, клиентская часть. В руководстве man подробно описаны все возможности указанных утилит.

ald-admin — содержит утилиту ald-admin и утилиту администрирования БД ALD. Пакет должен устанавливаться на компьютеры, с которых будет осуществляться администрирование БД ALD. При установке данного пакета также устанавливается клиентская часть;

ald-client — клиентская часть ALD. Содержит утилиту конфигурирования клиентского компьютера ald-client и утилиту автоматического обновления пользовательских билетов -renew-tickets. Пакет должен устанавливаться на все клиентские компьютеры, входящие в домен.

Подготовим ALD сервер

Контроллер — srv.test.local (ip 192.168.1.100)

Клиент — arm.test.local (ip 192.168.1.101)

Установим и настроим ALD

Если сервер ALD не был отмечен при установке ОС, выполняем:

sudo apt-get -y install ald-server-common

sudo apt-get -y install ald-admin smolensk-security-ald fly-admin-ald

Операционные системы Astra Linux

Astra Linux Common Edition предназначена для автоматизации коммерческих предприятий и органов государственного управления.

Astra Linux Special Edition предназначена для применения в автоматизированных системах в защищенном исполнении, обрабатывающих информацию ограниченного распространения, включая государственную тайну до степени секретности «особой важности» .

На сайте представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения. Кроме того, предоставлена возможность скачать дистрибутивы и исходные тексты операционной системы Astra Linux Common Edition, а также задать интересующие вопросы разработчикам .

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить на нашем сайте.

Операционные системы Astra Linux

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить на нашем сайте.

Операционные системы Astra Linux

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить на нашем сайте.

Настройка двухфакторной аутентификации в домене Astra Linux Directory

Немного вводных об Astra Linux Directory (ALD) и JaCarta PKI

ALD использует технологии LDAP, Kerberos5, Samba/CIFS и обеспечивает:

централизованное хранение и управление учетными записями пользователей и групп;
сквозную аутентификацию пользователей в домене с использованием протокола Kerberos5;
функционирование глобального хранилища домашних директорий, доступных по Samba/CIFS;
автоматическую настройку файлов конфигурации UNIX, LDAP, Kerberos, Samba, PAM;
поддержку соответствия БД LDAP и Kerberos;
создание резервных копий БД LDAP и Kerberos с возможностью восстановления;
интеграцию в домен входящих в дистрибутив СУБД, серверов электронной почты, Web-серверов, серверов печати и другие возможности.

JaCarta PKI — это линейка PKI-токенов для строгой аутентификации пользователей в корпоративных системах, безопасного хранения ключевых контейнеров программных СКЗИ и цифровых сертификатов российского производителя – компании «Аладдин Р.Д.».

Процесс настройки

Пример демо-зоны

Сервер — Astra Linux Smolensk SE 1.5 4.2.0-23-generic, x86_64, с установленными пакетами:
- JaCarta IDProtect 6.37;
- libccid;
- pcscd;
- libpcsclite1;
- krb5-pkinit;
- libengine-pkcs11-openssl;
- opensc.
- JaCarta IDProtect 6.37;
- libccid;
- pcscd;
- libpcsclite1;
- krb5-pkinit.
Предполагается, что ALD уже развернут, существует минимум один доменный пользователь, который может аутентифицироваться по паролю, время клиента и сервера совпадают.

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

Для обеспечения работы со смарт-картой JaCarta PKI на клиенте и сервере установите следующие пакеты: libccid, pcscd, libpcsclite1. После установки этих обязательных пакетов установите пакет драйверов IDProtectClient, который можно загрузить с официального сайта «Аладдин Р.Д.».

Для обеспечения работы со смарт-картой подсистемы Kerberos добавочно к предустановленным пакетам ald/kerberos установите пакет krb5-pkinit на клиенте и сервере.

Для обеспечения возможности выпуска ключей и сертификатов на JaCarta PKI на сервере также установите пакеты libengine-pkcs11-openssl и opensc.

Установка и настройка центра сертификации на сервере

В качестве центра сертификации (CA) будет использован OpenSSL.

OpenSSL — криптографический пакет с открытым исходным кодом для работы с SSL/TLS. Позволяет создавать ключи RSA, DH, DSA и сертификаты X.509, подписывать их, формировать CSR и CRT.

Все настройки в руководстве выполняются для тестового домена EXAMPLE.RU. Примем, что сервер и клиент принадлежат домену EXAMPLE.RU, имя сервера – kdc, а клиента – client. При настройке используйте имя вашего домена, сервера и клиента. Выполните следующие действия.
1. Создайте каталог CA командой mkdir /etc/ssl/CA и перейдите в него. В этом каталоге будут размещаться сгенерированные ключи и сертификаты.
2. Создайте ключ и сертификат CA:
  $ openssl genrsa -out cakey.pem 2048
  $ openssl req -key cakey.pem -new -x509 –days 365 -out cacert.pem
  В диалоге заполните необходимую информацию о вашем центре сертификации. В Common name указать EXAMPLE.RU.
3. Создайте ключ и сертификат KDC:
  $ openssl genrsa -out kdckey.pem 2048
  $ openssl req -new -out kdc.req -key kdckey.pem
  В диалоге заполните необходимую информацию о вашем сервере. В Common name указать kdc.
4. Установите переменные среды. Переменные среды устанавливаются в рамках сессии и не устанавливаются для других сессий и не сохраняются после закрытия сессии.
  export REALM=EXAMPLE.RU — Ваш домен
  export CLIENT=kdc — Вашего сервер
Содержимое файла pkinit_extensions (его следует положить в тот каталог, откуда вы выполняете команды):
Файлы kdc.pem, kdckey.pem, cacert.pem перенесите в /var/lib/krb5kdc/

Создайте резервную копию файла /etc/krb5kdc/kdc.conf. Отредактируйте /etc/krb5kdc/kdc.conf, дополнив секцию [kdcdefaults] следующими записями:
pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem
pkinit_anchors = FILE:/var/lib/krb5kdc/cacert.pem
Первая запись задает ключи и сертификат сервера, а вторая указывает на корневой сертификат центра сертификации.

Подготовка смарт-карты. Выпуск ключей и сертификата пользователя

Убедитесь в том, что установлены пакеты libengine-pkcs11-openssl и opensc. Подключите устройство, которое следует подготовить.

Проинициализируйте устройство, установите PIN-код пользователя. Помните, что инициализация устройства удалит все данные на JaCarta PKI без возможности восстановления.

Для инициализации необходимо воспользоваться утилитой pkcs11-tool.

pkcs11-tool —slot 0 —init-token —so-pin 00000000 —label ‘JaCarta PKI’ —module /lib64/libASEP11.so,

—slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

—init-token – команда инициализации токена;

—so-pin 00000000 – PIN-код администратора JaCarta PKI. По умолчанию имеет значение 00000000;

—label ‘JaCarta PKI’ – метка устройства;

—module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so. Устанавливается в рамках пакета idprotectclient см. раздел «Установка драйверов на сервер и клиент».

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

pkcs11-tool —slot 0 —init-pin —so-pin 00000000 —login —pin 11111111 —module /lib64/libASEP11.so,

—slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

—init-pin – команда установки PIN-кода пользователя;

—so-pin 00000000 – PIN-код администратора JaCarta PKI. По умолчанию имеет значение 00000000;

—login – команда логина;

—pin 11111111 – задаваемый PIN-код пользователя;

—module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so. Устанавливается в рамках пакета idprotectclient см. раздел «Установка драйверов на сервер и клиент».

Сгенерируйте ключи на устройстве, для этого введите следующую команду:

pkcs11-tool —slot 0 —login —pin 11111111 —keypairgen —key-type rsa:2048 —id 42 —label “test1 key” —module /lib64/libASEP11.so,

—slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

—login —pin 11111111 — указывает, что следует произвести логин под пользователем с PIN-кодом «11111111». Если у Вашей карты другой PIN-код пользователя, укажите его;

—keypairgen —key-type rsa:2048 — указывает, что должны быть сгенерированы ключи длиной 2048 бит;

—id 42 — устанавливает атрибут CKA_ID ключа. CKA_ID может быть любым;

Запомните это значение! Оно необходимо для дальнейших шагов подготовки устройства к работе.

—label “test1 key” — устанавливает атрибут CKA_LABEL ключа. Атрибут может быть любым;

—module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so. Устанавливается в рамках пакета idprotectclient см. раздел «Установка драйверов на сервер и клиент».

Сгенерируйте запрос на сертификат с помощью утилиты openssl. Для этого введите следующие команды:

Обратите внимание на -new -key 0:42, где 0 — номер виртуального слота с устройством, 42 — атрибут CKA_ID сгенерированных раннее ключей.

Информацию, которую необходимо указать в запросе, следует задавать в поле «/C=RU/ST=Moscow/L=Moscow/O=Aladdin/OU=dev/CN=test1 (! Ваш_Пользователь!)/emailAddress=test1@mail.com».

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

$ export REALM=EXAMPLE.RU #Ваш домен
$ export CLIENT=test1 #Ваш пользователь

и выпустить сертификат на пользователя.

$ openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem –days 365

Далее перекодируйте полученный сертификат из PEM в DER.

# openssl x509 -in client.pem -out client.cer -inform PEM -outform DER

Запишите полученный сертификат на токен.

pkcs11-tool —slot 0 —login —pin 11111111 —write-object client.cer —type ‘cert’ —label ‘Certificate’ —id 42 —module /lib/libASEP11.so,

—slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

—login —pin 11111111 — указывает, что следует произвести логин под пользователем с PIN-кодом «11111111». Если у Вашей карты другой PIN-код пользователя, укажите его;

—write-object ./client.cer — указывает, что необходимо записать объект и путь до него;

—type ‘cert’ — указывает, что тип записываемого объекта – сертификат;

‘cert’ —label ‘Certificate’ — устанавливает атрибут CKA_LABEL сертификата. Атрибут может быть любым;

—id 42 — устанавливает атрибут CKA_ID сертификата. Должен быть указан тот же CKA_ID, что и для ключей;

—module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so.

Настройка клиента. Проверка работоспособности

Создайте на клиенте каталог /etc/krb5/. Скопируйте в /etc/krb5/ сертификат CA (cacert.pem) c сервера.

Настройте kerberos в /etc/krb5.conf. Секцию [libdefaults] дополните следующими строками.

kinit Когда появится строка запроса PIN-кода к карте, введите его.

Для проверки того, что kerberos-тикет был успешно получен для пользователя, введите команду klist. Для удаления тикета — kdestroy.

Для входа в домен по смарт-карте на экране входа в ОС вместо пароля введите PIN-код от смарт-карты.

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

Записки IT специалиста

Astra Linux 2.12 Orel — избавляемся от стереотипов о российском ПО
- Автор: Уваров А.С.
- 26.05.2019
Хорошо говорить об отечественном ПО у нас почему-то не принято. Да, многие образцы ведомственных программ представляют шедевры криворукости, но это не повод мазать всю отрасль одной краской. Сегодня существует определенный ажиотаж вокруг отечественной ОС и темы импортозамещения. Если отбросить отсюда всю информационную мишуру, то мы не видим в данной затее ничего плохого, особенно если речь идет об информационных структурах государственных и силовых ведомств. Сегодня мы решили рассмотреть отечественную ОС Astra Linux, недавно получившую допуск для работы с данными высшей степени секретности.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

В отличие от недавно рассмотренного нами Эльбруса, который был выложен в виде мало к чему пригодного полуфабриката, Astra Linux является завершенным коммерческим продуктом. Существуют две основных редакции ОС: общего назначения ( Common Edition) — релиз «Орел» и специального назначения (Special Edition) — релиз «Смоленск». Понятно, что все доступы и сертификаты имеет ОС специального назначения и просто так получить ее не представляется возможным, в то же время «Орел» доступен всем желающим и бесплатен для некоммерческого применения.

Чтобы сразу пресечь спекуляции по поводу платного Linux, скажем, что свободное ПО не ставит знак равенства с бесплатным. Хотя мы и считаем, что финансирование отечественной ОС должно производиться государством, коммерческая модель здесь тоже имеет место и если деньги за систему пойдут отечественным разработчикам — ничего плохого в этом не будет. Тем более основные заказчики Astra Linux — это силовые ведомства, а там свои методы финансирования и взаимоотношений с подрядчиками.

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

Но не будем долго растекаться мыслью по дереву, а собственными глазами посмотрим на продукт отечественных разработчиков. Astra Linux основан на базе Debian, поэтому уже становится понятно, что нам следует ожидать и как должна работать данная ОС. Debian — хорошая система, стабильная, с большим набором ПО и документации, а также наиболее свободная из основных дистрибутивов (никакая зарубежная корпорация за ней не стоит), поэтому ее выбор за основу вполне обоснован.

Инсталлятор представляет собой стандартный инсталлятор Debian, поэтому мы не будем подробно на нем останавливаться, все привычно и понятно. Сразу обратим внимание на предлагаемый выбор ПО, а именно на графическую оболочку Fly, которая является собственной разработкой. Это сразу ставит Astra Linux несколько особняком от других дистрибутивов на базе Debain, собственными графическими оболочками могут похвастаться немногие из них.

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

Отдельно предлагается ряд специфичных настроек, скажем, возможность использовать ядро Hardened, включающее в себя дополнительные настройки безопасности или возможность использовать службу ALD (Astra Linux Directory). Про нее следует сказать отдельно, это не очередная свободная реализация Active Directory, а полностью самостоятельная разработка с прицелом на создание собственной доменной системы. Процитируем разработчиков:

При разработке ALD задача имитации контроллера домена Microsft Windows не решалась. Таким образом, включение машины ОС Microsft Windows в домен ALD штатными средствами ОС Microsft Windows невозможно. Установив в ОС Microsft Windows клиента MIT Kerberos вы сможете получить билеты Kerberos на сервере ALD. Далее вы получите доступ к серверам печати, СУБД, WEB и электронной почты в сеансе с нулевыми мандатными атрибутами. Если вам необходимо получать доступ к ресурсам серверов, работающих под управлением Astra Linux, в ненулевом мандатном контексте, то вам необходимо самостоятельно разработать клиента ALD под Microsft Windows.

Может показаться, что разработчики изобретают очередной велосипед, но это не так, обычные, «гражданские» системы, в том числе и Active Directory, применяют дискреционное (избирательное) управление доступом. Это предполагает, что у каждого объекта системы есть свой владелец, который и устанавливает права доступа к нему, также может быть суперпользователь (Администратор, root и т.д.) который может изменить владельца и права доступа к любому объекту.

В структурах с конфиденциальной и секретной информацией применяется иной подход — мандатное (принудительное) управление доступом, основанное на имеющихся у субъекта уровнях доступа.

Простой пример: допустим Василий на некоторое время был переведен в отдел A, получил на файловом сервере свою папку и работал в ней с документами, потом вернулся в отдел B. При избирательном доступе Василий потеряет доступ к папкам отдела А, но сохранит доступ к собственной папке и файлам, так как является их владельцем. При мандатном доступе, покинув отдел А от потеряет право доступа к документам с отметкой «для служебного использования», в том числе и к тем, что он создал.

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

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

После входа в систему нас встречает рабочий стол. От былой аляповатости не осталось и следа, все строго и выверено. И если встречать по одежке, то здесь у Astra Linux все хорошо, а сам рабочий стол чем-то напоминает KDE и Windows одновременно, представляя собой классическое рабочее пространство, что не должно вызвать сложностей с его освоением.

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

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

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

Но есть и интересные «фишки» вроде двухпанельного режима:

Также обращает внимание довольно скромное потребление системных ресурсов, на виртуальной машине с 2 ГБ памяти Astra Linux чувствует себя достаточно комфортно.

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

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

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

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

Скажем настройка автозагрузки:

Или переменных окружения:

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

Одним из недостатков системы некоторые обозреватели ставят отсутствие магазина приложений. Да это так, и это можно было бы записать в недостаток, если бы не четкое позиционирование данной системы для государственных и силовых учреждений. Спросите любого системного администратора что он думает о магазине в Windows 10, узнаете много интересного, скорее всего в непечатной форме. Исходя из этого, отсутствие магазина становится не столь критичным. Нужное ПО установит администратор, а у пользователей будет меньше соблазнов.

Из графических инструментов доступен привычный Synaptic и простая утилита для обновления:

Второй из озвучиваемых недостатков — слабая поддержка Samba из коробки. Действительно, ее нужно настраивать руками. Хотя, учитывая стремление разработчиков к собственной экосистеме со своим доменом, это выглядит вполне обоснованным. Там, где будет применяться Astra Linux, особенно специальный выпуск, взаимодействие с Windows машинами будет далеко не самой главной задачей, а скорее наоборот.

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

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

Так как у нас система общего назначения, то попробуем установить что-нибудь со стороны, для этого выпуска это вполне допустимо, в отличии от систем специального назначения. Попробуем скачать и установить Google Chrome. Никаких проблем у нас при этом не возникло, а все зависимости подтянулись из собственных репозиториев дистрибутива.

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

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

За все время работы в Astra Linux у нас не возникло каких-либо серьезных проблем. По большинству ощущений это все тот же Debain, если вы умеете работать с ним или его производными, то и с Astra проблем не возникнет. Но в тоже время Astra Linux не просто еще один Debian, многие пакеты, такие как SSH, OpenVPN, веб-сервера скомпилированы с поддержкой отечественной криптографии, что важно для определенных сфер применения.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Настройка домена ALD в Astra Linux

Я администрирую серверы на базе Astra Linux и хочу рассказать о своем видении настройки ALD домена: серверной части, клиентской, использовании файла hosts (по сравнению с DNS сервером). Также дам описание настройки резервного сервера.

ALD мне интересен в первую очередь потому, что уже имеет интеграцию с Astra Linux. Статья будет вам полезна, если вы собираетесь узнать больше о Astra Linux не только из официальной wiki. Кроме того, эту операционную систему (вместе с рядом других решений компании «Астра») смогут поставить на виртуальную машину клиенты публичного облака #CloudMTS.

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

Настройку произвожу на виртуальных машинах в virtualbox, на сервере ip-адрес 192.168.1.1, также на данном сервере расположен репозиторий (настройка ip-адресов и репозиториев ничем не отличаются от настроек в Debian, на базе которой построена Astra). Первое, что необходимо настроить — это синхронизацию времени: поднимем ntp сервер, который будет брать время с текущей машины. Для это нужно отредактировать файл /etc/ntp.conf, внеся в него следующие изменения:

Параметры подсети укажите в соответствии с вашими ip адресами.

Вы можете использовать DNS сервер — bind, например. Он присутствует в стандартном репозитории Astra Linux. На мой взгляд, использование файл hosts — это более простая реализация, чем полноценный DNS сервер. При этом корректно настроенный файл /etc/hosts должен быть одинаковый на всех машинах в домене. Перед редактированием данного файла зададим корректное hostname для сервера:

В данной ситуации hostname сервера будет dc1, а имя домена, соответственно, local, именно на эти параметры будет ориентироваться ald-server при инициализации. Последним штрихом перед инициализацией ald сервера будет корректная настройка файла /etc/hosts:

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

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

Пакет smolensk-security-ald добавит возможность администрировать ald сервер в стандартной утилите fly-admin-smc (об этом будет рассказано далее).

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

ВАЖНО. Если по каким-то причинам у вас сбились настройки сервера, то их можно отредактировать в файле /etc/ald/ald.conf. В текущем файле важен параметр DOMAIN, значение данного параметра всегда должно начинаться с . (точки), т.е. в текущем примере данная строка будет выглядеть так:

Инициализируем сервер командой:

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

Теперь приступим к настройке клиентской части.

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

Настроим ntp клиента для синхронизации времени, скопируем файл hosts с сервера, зададим имя хоста, а также настроим /etc/ald/ald.conf. В файле /etc/ntp.conf необходимо добавить строки:

Запустим службу ntp:

Зададим имя хоста (в данном пример ip адрес хоста 192.168.1.101):

Перед настройкой ald.conf необходимо установить необходимые пакеты:

Ниже представлен пример файла ald.conf (данный файл аналогичен файлу ald.conf с сервера):

Теперь можно ввести машину в домен командой:

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

Если все прошло удачно, то на экране отобразится следующий текст:

Резервный сервер ald

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

И отредактировать файл /etc/ald/ald.conf, изменив один параметр:

Далее зададим корректное имя хоста для резервного сервера:

Теперь инициализируем резервный сервер командой:

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

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

Необходимо на всех клиентских рабочих станциях отредактировать файл /etc/ald/ald.conf. Как это сделать одной командой — расскажу в разделе «Дополнительно».

В данном файле необходимо изменить параметры SERVER и SERVER_ID:

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

Администрирование ald сервера

Как было написано ранее, администрирование можно производить через стандартную системную утилиту fly-admin-smc. Ее можно запустить через консоль, либо в панели управления, перейдя на вкладку «Безопасность» и запустив аплет «Политика безопасности». Первым делом необходимо настроить политику паролей в соответствии с вашими требованиями:

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

На вкладке «Пользователи» необходимо нажать кнопку +, ввести имя пользователя, тип файловой системы, установить local (также можно хранить каталоги на сетевых ресурсах), а также убрать галку «новая» напротив надписи «Первичная группа». При этом пользователь будет добавлен в группу «domain user». Далее создадим пароль для пользователя.

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

На вкладке «МРД» указываем, к каким меткам пользователь имеет доступ, а также уровень целостности.

Дополнительно: «заливка» hosts на все рабочие станции

Представьте ситуацию, в будущий домен будет входить 100 или более машин. Раскидать в ручную файл hosts — проблематично. В данной ситуации поможет bash с СИ подобным синтаксисом.

На тестовом стенде имеется подсеть 192.168.1.0/24, 192.168.1.1 — сервер, 192.168.1.2 — 192.168.1.100 — рабочие станции. На каждой машине (в том числе и на сервере) имеется пользователь user с паролем 12345678. Данный пользователь должен быть полноценным администратором (с доступом к sudo, во время установки системы создается пользователь имеющий данные права) и иметь уровень целостности 63. Для данной цели необходимо выполнить следующие команды:

Если пользователь user отсутствует в системе, выполним следующие команды:

Чтобы не вводить пароль при распространении ключей, необходимо установить утилиту sshpass:

Теперь можно приступить к формированию ключа (без sudo, с правами пользователя user), для беспарольного доступа:

Распространим ключи на рабочие станции:

Скопируем файл hosts на все машины с помощью утилиты scp:

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

Таким же образом можно редактировать данный файл на всех хостах в домене. Например, нам необходимо удалить строку с именем хоста host40:

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

На этом у меня сегодня всё, спасибо за ваше внимание.

Делитесь в комментариях вашим опытом.

Выбрать готовые образы программных решений для виртуальных машин IaaS можно в личном кабинете на сайте #CloudMTS.
Похожие публикации: