Служба ald astra linux что это
Перейти к содержимому

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

  • автор:

ALD PRO решение для централизованного управления

ALD PRO

ALD PRO расшифровывается как Astra Linux Directory PRO — решение для централизованного управления.

Операционная система Astra Linux
Система Виртуализации Брест
VDI Termidesk
Хранения данных RuBackup
Безопасное мобильное рабочее место WorksPad
Управление через единую консоль ALD PRO

Решение для автоматизации и централизованного управления

Компьютерами и пользователями
Иерархией подразделений и групповыми политиками
системнымии сервисами и службами
Простое внедрение оточественного ПО с последующей миграцией
Удобство развёртывания, отказоустойчивость и возможность масштабирования
Инновационное решение для Linux-подобных систем

Описание:
Программный комплекс «ALD Pro» — решение компании ООО «РусБИТех-Астра», которое позволяет объединить объекты инфраструктуры (компьютеры, серверы, принтеры) в единую систему, выступая в роли каталога, в котором хранится информация о пользователях, компьютерах, серверах и периферийных устройствах.
Решение помогает организовать централизованное управление компьютерами, пользователями, политиками и программными комплексами.
Продукт подходит тем организациям, которым требуется удобный инструмент администрирования в части управления объектами инфраструктуры и групповыми политиками.
Мониторинг Почтовый домен Почтовый ящик Служба каталогов Шаблоны конфигураций

Функциональные возможности Astra Linux Directory PRO

Настройка параметров домена
Управление иерархией организационной структуры
Управление объектами домена: компьютерами, пользователям и группами
Миграция данных из MS Active Directory
Применение и назначение групповых политик на компьютеры и пользователей
Управление и настройка системных сервисов и служб
Автоматизированная установка ОС и ПО по сети на компьютеры в домене
Удаленный доступ к рабочим столам пользователей
Мониторинг состояния домена и серверов
Журналирование событий и просмотр системных логов

Эффекты внедрения ALD PRO

Снижение санкционных рисков
Снижение требований к квалификации персонала
Снижение трудоемкости администрирования
Единая точка контроля и отчетности

Лицензирование ALD Pro

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

Сервер + пакет клиентских лицензий
Сервер + клиентская лицензия

В рамках модели лицензирования «сервер + пакет клиентских лицензий» организация должна иметь лицензию на сервер и право на использование пакета клиентских лицензий.
Лицензирование сервера
Организации предоставляется право на воспроизведение одного экземпляра Программы на 1 (одном) сервере, без учета количества ядер или процессоров.
Пользователю предоставляется право однократной записи в энергонезависимую память сервера.
В комплект поставки входит:
Одна лицензия Программного комплекса «ALD Pro» на 1 (один) сервер и 5 (пять) лицензий на операционную систему специального назначения «Astra Linux Special Edition».
Операционная система специального назначения «Astra Linux Special Edition», предоставляет конечным пользователям возможность однократно установить и использовать необходимый уровень защищенности.
На операционную систему специального назначения «Astra Linux Special Edition» для 5 (пяти) устройств предоставляется стикер в количестве 1 шт. Операционная система специального назначения «Astra Linux Special Edition», поставляемая вместе с серверной лицензией Программного комплекса «ALD Pro», предназначена исключительно для использования совместно с Программным комплексом «ALD Pro».
Лицензирование пакетов
Пакет клиентских лицензий предоставляет право определенному количеству устройств на подключение к серверной лицензии Программного комплекса «ALD Pro».
Один пакет клиентских лицензий назначается для определенного количества устройств, указанного в пакете.
Организация платит только за тот пакет лицензий, который необходим, в зависимости от размера организации.
Каждому устройству, для которого необходимо подключение к серверной лицензии, должна соответствовать лицензия из пакета.

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

12 месяцев
36 месяцев

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

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

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

Форма поставки:
Серверная лицензия поставляется в следующих форматах:

материальный носитель

Пакеты клиентских лицензий:

электронно
электронно

Установка продукта
Программный комплекс «ALD Pro» функционирует на базе операционной системы специального назначения «Astra Linux Special Edition».
Для развертывания Программного комплекса «ALD Pro» на севере необходимо установить операционную систему, предоставляемую в комплекте поставки, на сервер, далее установить серверную лицензию Программного комплекса «ALD Pro», при необходимости можно развернуть на виртуальных машинах операционные системы, предоставленные в комплекте поставки.
Техническая поддержка
Каждая лицензия поставляется с включенной технической поддержкой уровень «Стандарт» или «Привилегированный».
Техническую поддержку любого уровня можно приобрести на срок:

12 месяцев
36 месяцев

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

Расчет стоимости Astra Linux Directory PRO

ALD Pro

Сценарий 1 :

Планируется использовать 1 сервера

Необходимо купить:

Продуктовый номер Описание продукта Кол-во Цена Итого
AD1200Х8610DIG000SR01-ST12 Лицензия на право установки и использования Программного комплекса «ALD Pro» РДЦП.10101-01 на 1 устройстве и операционной системы специального назначения «Astra Linux Special Edition» для 64-х разрядной платформы на базе процессорной архитектуры x86-64 РУСБ.10015-01 (ФСТЭК) на 8 устройствах, способ передачи электронный, для сервера, без ограничения срока, с включенной технической поддержкой тип «Стандарт» на 12 мес. 1 261691₽ 261691₽
AD0000Х8610DIG000DV01-ST12 Лицензия клиентская, на право подключения 1 устройства к Программному комплексу «ALD Pro» РДЦП.10101-01, способ передачи электронный, без ограничения срока, с включенной технической поддержкой тип «Стандарт» на 12 мес. 50 1430₽ 7800₽
Итого: 269491₽

Чтобы купить и разместить заказ.
Достаточно написать нам.
e-mail: vmware@v-grade.ru

Сертификат Astra Linux

Компания ООО «Прогресс-Медиа» V-GRADE — — является Официальным Партнером Astra Linux

Возможно, Вам будет также интересна следующая информация:

  • Российская виртуализация | Что же выбрать? Как купить?
  • Termidesk | VDI виртуальных рабочих мест
  • RuPost | Современная Корпоративная почтовая система
  • RuBackup | Что такое? Как и какие лицензии купить?
  • Виртуализация ПК СВ Брест | Что такое? Как купить?
  • Astra Linux | Российский Windows
  • ALD PRO это Astra Linux Directory PRO

ALD Pro для централизованного администрирования компьютеров на ОС Astra Linux

ивент

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

В ноябре 2021 года на конференции «ГК «Астра» 2022: Решения и стратегия» представители одноименной группы компаний объявили о создании стека продуктов, которые пополнят уже существующую экосистему «Астра». Один из этих продуктов – ALD Pro – решение для централизованного управления компьютерами на ОС Astra Linux. Уже сейчас ALD Pro обладает базовой функциональностью известного Microsoft Active Directory и имеет ряд дополнительных преимуществ перед другими подобными решениями для администрирования Linux.

«Мы понимаем, что переход на Linux – это сложная и трудоемкая задача, требующая нового опыта администрирования. Привычные вещи становятся более сложными, не вся функциональность доступна, а для выполнения стандартных операций требуется определенная экспертиза и высокий уровень квалификации сотрудников. Чтобы ответить на эти вызовы и сделать переход на Linux более простым, мы и начали разрабатывать решение ALD Pro», – рассказал заместитель руководителя департамента разработки ГК «Астра» Алексей Фоменко.

Алексей Фоменко, заместитель руководителя департамента разработки ГК «Астра»

Алексей Фоменко, заместитель руководителя департамента разработки ГК «Астра»

ALD Pro – это программный комплекс для централизованного управления объектами домена: администрирование учетных записей пользователей, компьютеров и подразделений. Он предназначен, в первую очередь, для автоматизации рутинных задач системных администраторов Linux. Поскольку интерфейс, базовые возможности и категории объектов ALD Pro схожи с Microsoft AD, ознакомление и начало работы в нем возможны даже без специфических знаний системы Linux. Среди других преимуществ решения в области пользовательского опыта – легкое развертывание, работа без использования командной строки или скриптов, выполнение основных действий с использованием графического интерфейса.

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

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

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

Сценарии использования ALD Pro

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

Функция иерархии подразделений позволяет выстроить в системе реальную структуру организации, которой впоследствии удобно управлять. При этом, выбирая нужное подразделение, администратору в правой части окна доступен перечень всех объектов подразделения: компьютеры, пользователи и группы. Управление на базе групповых политик – это одна из ключевых возможностей, которая ранее была доступна в Windows, а теперь стала доступна и для Linux-систем. Параметры политик сгруппированы по типам и по категориям, что позволяет администратору удобнее и быстрее производить их настройку. Сам механизм настройки выполняется полностью из интерфейса только кликами мышки без необходимости программирования.

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

Также администратор может выгружать отчеты по установке ПО и мониторить состояние серверных компонент домена. Для плавного перехода на отечественное решение доступна возможность параллельной работы ALD Pro с MS Active Directory. Реализованы механизмы миграции данных из домена MS в ALD Pro, а также настройка доверительных отношений между доменами.

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

«Наше решение позволяет ответить на современные вызовы: снижаются требования к персоналу и его квалификации, клиент получает единую точку контроля и отчетности. Мы учитывали лучшие современные мировые практики, чтобы функциональность решения позволила полноценно использовать продукт как Enterprise-решение».

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

ALD Pro поддерживает работу в территориально-распределенных организациях, где важна непрерывность работы даже в условиях не всегда стабильной сети или слабых каналов. Например, если связь территориального подразделения с центральным сервером временно прервалась, то оно может продолжить работу автономно. Когда связь восстановится, данные будут синхронизированы.

Перспективы развития ALD Pro

«Сегодня мы создали определенный базис решения и собираемся расширять его функциональность. Поскольку наши заказчики обладают большим опытом администрирования крупных систем, мы открыты к предложениям по доработке нашего продукта. У нас есть определенный roadmap, мы готовы его приоритизировать на основе пилотных кейсов и обратной связи. Мы нарастили команду, компетенции и готовы активно двигаться вперед», – замечает Алексей Фоменко.

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

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

Лекция №12

YZTM.RU

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

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

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

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

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

  • OpenLDAP — реализация протокола прикладного уровня LDAP (Lightweight Directory Access Protocol) с открытым исходным кодом, обеспечивающего механизм «I&А» (Identification and Authentication), а также поиск, добавление, изменение и удаление записей в единый каталог сетевых объектов;
  • Samba — реализация протокола прикладного уровня SMB/CIFS (Server Message Block/Common Internet File System) с открытым исходным кодом, обеспечивающего удалённый доступ к сетевым ресурсам (файлам, принтерам), а также реализацию механизма IPC (Inter-Process Communication) для удалённого выполнения приложений;
  • Kerberos — протокол взаимной аутентификации хостов перед установлением соединения между ними, реализующий механизм единого входа (Single Sign-On — SSO).

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

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

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

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

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

В общем виде схема организации ЕПП показана на рис. 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.00\media\image23.jpeg

Рис. 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 Общее имя Сергей Петрович Иванов

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

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

C:\Users\SVETLANA\AppData\Local\Temp\FineReader12.00\media\image24.jpeg

В зависимости от необходимости использования локальной или глобальной реализации механизма «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).

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

Рис. 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, она состоит из следующих компонент:

  • серверного набора программ: демоны smbd и nmbd;
  • клиентского приложения: smbclient;
  • набора утилит администрирования: testparam и smbstatus;
  • конфигурационных файлов: /etc/smbnetfs.conf и /etc/samba/smb.conf.

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

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

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

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

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

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

C:\Users\SVETLANA\AppData\Local\Temp\FineReader12.00\media\image29.jpeg

  • контроллера ALD;
  • клиента ALD;
  • хоста, выполняющего функции узла администрирования ALD (может располагаться на одном контроллере ALD или одном из клиентов ALD);
  • клиента ALD, реализующего функции файл-сервера (может также располагаться на контроллере ALD.
  • Так как ряд функций базовых компонентов являются обязательными для различных ролей хостов домена ALD, указанные пакеты собираются в кумулятивные пакеты. Например, кумулятивный пакет контроллера домена ALD — ald-server-dc содержит в своём составе пакеты клиента и администратора ALD.
  • Расширения службы ALD, предназначенные для обеспечения большей функциональности базовых компонентов службы ALD за счёт подключения дополнительных функций, например, следующих:
  • организация и администрирование резервных контроллеров домена ALD и установление междоменных отношений доверия;
  • централизованное хранение настроек аудита и ОССН в целом;
  • конфигурирование подсистемы управления доступом к подключаемым носителям.
  • Наименование пакета расширения отражает его назначение, например:
  • ald-client-… — расширение клиентской части домена ALD;
  • ald-admin-… — расширение администрирования домена ALD;
  • ald-server-… — расширение для организации хранения настроек на контроллере домена ALD.
  • Рисунок 9. Схема службы ALD.

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

  • корневой администратор (имя admin/admin) — основной администратор домена ALD, обладающий всеми полномочиями по управлению доменом;
  • администраторы — пользователи с привилегией admin, обладающие полномочиями по управлению конфигурацией домена и учётными записями пользователей домена;
  • ограниченные администраторы — пользователи с привилегиями hosts-add или all-hosts-add, обладающие полномочиями по добавлению хостов в состав домена;
  • пользователи утилит администрирования — пользователи с привилегией a dm-user, обладающие полномочиями по запуску утилит администрирования.

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

  • создание нового домена;
  • резервирование/восстановление конфигурации домена;
  • контроль целостности конфигурации домена;
  • добавление/удаление хостов в состав хостов домена;
  • управление учётными записями пользователей домена;
  • управление учётными записями сетевых служб домена;
  • управление параметрами ОССН, в первую очередь соответствующих МРОСЛ ДП-модели.

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

  1. Настройка сетевого соединения на контроллере домена и хостах рабочих станций пользователей.
  2. Настройка именования сервера и клиентов ALD.
  3. Конфигурирование и запуск сервера ALD на хосте, реализующем функции контроллера домена.
  4. Запуск клиентов 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:

  • редактируя файл конфигурации /etc/aid/aid.conf (рис. 11);
  • запуская или повторно инициализируя демон a ldd с помощью команд ald-init (на контроллере ALD) и aid-client (на клиенте ALD) (рис. 3.46);
  • конфигурирования параметры пароля базового администратора ALD для реализации сквозной аутентификации на контроллере ALD (рис. 3.47).
  • Рис. 10. Пример конфигурирования файла /etc/hosts на хосте, реализующем функции контроллера домена.

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

C:\Users\SVETLANA\AppData\Local\Temp\FineReader12.00\media\image32.jpeg

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

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

C:\Users\SVETLANA\AppData\Local\Temp\FineReader12.00\media\image33.jpeg

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

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

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

  • создание и/или администрирование учётных записей пользователей ALD;
  • создание и/или администрирование групп пользователей ALD;
  • добавление и удаление хостов рабочих станций в/из состава домена;
  • резервирование/восстановление учётной информации баз данных домена;
  • конфигурирование привилегий и параметров безопасности ОССН для учётных записей пользователей и групп пользователей домена;
  • конфигурирование политик паролей Kerberos;
  • администрирование доступа к съёмным устройствам;
  • администрирование учётных записей сетевых служб (сервисов) домена;
  • контроль целостности (аудит) конфигурации домена.

Рисунок. 14.

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

Для корректной работы надо убедиться, что доменные имена сервера и клиентов корректно отображаются. В файле /etc/hosts к полному доменному имени должен быть короткий псевдоним, дублирующую запись для 127.0.1.1 стоит закоментировать или удалить

$ cat /etc/hosts 127.0.0.1 localhost # 127.0.1.1 ald-server 192.168.15.132 ald-server.example.ru ald-server 192.168.15.129 astra.example.ru astra # The following lines are desirable for IPv6 capable hosts . 

комадна hostname на сервере и клиенте должна выводить короткое имя, если требуется, необходимо отредактировать /etc/hostname . На примере ald-сервера

$ cat /etc/hostname ald-server 

Доменные имена в конфигурационном файле ald-сервера должны совпадать с hosts

$ cat /etc/ald/ald.conf . DOMAIN=.example.ru . SERVER=ald-server.example.ru 

На сервере выполняем команду

$ sudo ald-init init 

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

На клиенте выполним

$ sudo ald-client join ald-server 

Которая так же автоматически всё сконфигурирует. Но прежде на сервере надо создать пользователя для клиента. Для управления ald есть отличная графическая утилита fly-admin-smc

Добавляем пользователя и создаем ему пароль

Указываем нужные нам уровни

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

Даем право пользователю добавить компьютер в домен (нужно для команды ald-client join ald-server ) и указываем, с какого компьютера пользователь может залогиниться

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *