Аналог групповых политик в linux

Обновлено: 07.07.2024

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

Решения Samba

Политики применяются winbind с произвольным интервалом от 90 до 120 секунд. Политики могут быть применены принудительно с помощью команды samba-gpupdate --force. Чтобы включить управление групповой политикой в winbind, установите глобальный параметр apply group policies в значение yes.

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

Команда samba-tool gpo admxload скопирует шаблоны Samba ADMX в каталог <domain>/Policies/PolicyDefinitions на общем ресурсе SYSVOL.

Утилита GPO Applier

Разработчиками дистрибутива ALT Linux для применения групповых политик был создан инструмент GPO Applier. Он рассчитан на работу на машине, введённой в домен Samba.

Несмотря на то, что изначально инструмент создавался для ALT Linux, он может работать и в других дистрибутивах. Утилита опубликована под лицензией GNU GPL v3.0. [1][2]

Обновление машинных политик происходит раз в час. Среди применяемых настроек присутствуют:

Установка

ALT Linux

На текущий момент для включения инструмента групповых политик на клиентах AD необходимо установить пакеты из репозитория 241549 (для p9) или 241548 (для Sisyphus):

Подключение репозитория и установка производится командами:

Другие дистрибутивы

Развёртывание

Включение работы групповых политик и выбор локальной политики по-умолчанию выполняется командой /usr/sbin/gpupdate-setup от пользователя с правами администратора:

и перезагрузите рабочую машину.

Состав локальной политики

Для клиента также существует понятие локальной политики. Настройки локальной политики находятся в каталоге /usr/share/local-policy/default . Данные настройки по умолчанию поставляются пакетом local-policy . Администраторы инфраструктур имеют возможность поставлять собственный пакет с локальной политикой и развёртывать её единообразно на всех клиентах. Состав локальной политики может меняться или адаптироваться системным администратором.

Описание	Комментарий
Включение oddjobd.service	Необходимо для обеспечения возможности запуска gpupdate для пользователя с правами администратора.
Включение gpupdate.service	Необходимо для регулярного обновления настроек машины.
Включение sshd.service	Необходимо для обеспечения возможности удалённого администрирования.
Включение аутентификации с помощью GSSAPI для sshd	Необходимо для аутентификации в домене при доступе через SSH.
Ограничение аутентификации для sshd по группам wheel и remote	Необходимо для ограничения доступа при доступе через SSH для всех пользователей домена (только при наличии соответствующей привилегии).
Открытие порта 22	Необходимо для обеспечения возможности подключения SSH на машинах при старте Firewall applier.

Internals

Групповые политики кэшируются в файле /var/cache/gpupdate/registry.sqlite (можно просматривать его командой sqlite3 ).

Коды ошибок

Код	Значение
E00001	Недостаточно прав для запуска программы gpupdate . Необходимо повысить уровень привилегий.
E00002	Программа gpupdate не будет запущена из-за предыдущих ошибок.

Конфигурирование с помощью AdminTools

Конфигурирование с помощью RSAT

У Samba нет собственного интерфейса для настройки политик. Настройки производятся с помощью Remote Server Administration Tools. На сервер/клиент ставятся Средства удаленного администрирования сервера, вы подключаетесь к SambaDC и производите настройку.

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

Конфигурирование Firefox

Дополнительное дерево настроек для браузера Mozilla Firefox появится после установки ADMX файлов Firefox. Для Linux поддерживаются только машинные политики вследствие ограничений реализации Firefox for Linux. На данный момент поддерживается только опция URL for Home Page , позволяющая задать URL домашней страницы при старте браузера.

Многие полагают, что на сегодняшний день полноценного интегрированного аналога MS Active Directory, а также Group Policy (Групповых политик) в мире GNU/Linux пока еще не существует. Тем не менее, разработчики со всего мира предпринимают попытки воплотить в жизнь подобные технологии в рамках UNIX-систем. Одним из ярких примеров можно назвать eDirectory от Novell об особенностях которой мы поговорим далее.

Интересно, что поддержка Групповых политик была реализована в Samba 4, после появления которой стали разрабатываться эффективные средства по настройке политик групп. Однако прежде большинству системных администраторов приходилось ограничиваться logon-скриптами или же политиками системы NT4.

Чего же позволяет добиваться Samba4? Многие сегодня наловчились использовать данное решение в качестве AD, то есть контроллера домена в связке с файловыми серверами, базирующимися на этом же решении. В итоге Пользователь получает минимум пару настроенных серверов с Samba4, один из которых выполняет функцию контроллера домена, а второй выступает в качестве Member Server с пользовательскими файлами.

Сегодня проблемы, связанные с техобслуживанием и регистрацией пользователей сети в рамках одноранговых сетей, ответственно берутся решить сразу несколько ведущих компаний-производителей современного ПО. Фаворитами среди таких разработчиков сегодня считаются Microsoft с ее ранее упомянутой Active Directory и Novell со своим eDirectory, также упомянутый вначале данной статьи.

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

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

Active Directory – технологические особенности

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

Для определения расположения в AD используется распределенное именное пространство или DNS (Domain Name System). Для работы с базой данных в AD имеется набор специального ПО, а также инструменты, предназначенные для прикладного программирования.

Даже при неоднородной структуре систем в сети AD позволяет провести единую регистрацию за счет упрощенного протокола, относящегося к LDAP-службе каталогов.

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

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

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

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

Технологии с использованием eDirectory

Еще до появления MS Active Directory активно использовались иные способы управления БД.

Так следует отметить службу «Bindery» («Подшивка») от Novell, которая представляет собой однородную БД. В рамках такой базы данных одни записи не имеют явной взаимосвязанности с другими записями. Такая БД в первую очередь ориентирована на работу с сервером. Это означает, что каждый сервер. Данный вариант управления БД предполагает, что ресурсы сети расцениваются как объекты, имеющие непосредственную связь с корневым серверным каталогом.

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

Свойств – характерных черт для каждого объекта в рамках подшивки (адреса межсетевого типа, ограничительные факторы и пароли);

Объектов – физических и логических составляющих сети, которым могут быть присвоены имена (файл-серверы, пользовательские группы, пользователи).

Свойства наборов инфоданных – это формы инфоданных, которые хранятся в рамках подшивки (числа, таблицы, текст, время, дата, адрес сети и т. п.)

Когда на светпоявился NetWare4xx, компания Novell представила миру и новую службу каталогов eDirectory, которая изначально называлась NDS в данной версии NW. С версии 6.x она стала именоваться не иначе, как eDirectory.

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

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

Также стоит отметить, что eDirectory-сервер может функционировать и на платформах которые отличаются от NetWare.

Во многом возможности данного решения совпадают с аналогичными возможностями, представленными в MS Active Directiry. Так, например, посредством eDirectory можно производить репликацию в автоматическом режиме, а также наследование и делегирование.

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

Традиционно большинство приложений в Linux имеют два уровня настроек — системный и пользовательский. Системные настройки обычно размещаются в директории /etc ; они задаются администратором на подконтрольных ему машинах либо приходят вместе с пакетами дистрибутива. Если пользователю эти настройки не подходят, он их изменяет (обычно с помощью самого приложения). Измененные настройки сохраняются в его домашний каталог, не влияя на других пользователей машины. При этом пользовательские настройки обладают более высоким приоритетом, чем системные — исходя из того, что пользователю лучше знать, что ему нужно, а Linux — дружелюбная пользователю ОС (старается ей быть, по крайней мере).

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

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

По большому счету, это и не нужно для низкоуровневых системных настроек, которые может изменять только администратор — например, набора подключенных репозиториев дистрибутива, используемых DNS-серверов и тому подобного. Но что делать с приложениями, системные настройки которых пользователь может переопределить своими собственными? Есть и здесь свет в конце тоннеля. По крайней мере, для отдельных программ, разработчики которых в курсе потребностей корпоративного сектора и знают, что там используются ОС не только от MS. И хороший пример здесь — браузер Chromium . Пример выше с настройками веб-браузера приведен не зря — в случае с Chromium, параметры такого рода можно намертво зафиксировать на уровне системы так, что пользователи не смогут их перебить.

Реализована такая возможность в Chromium очень просто — здесь предусмотрен системный файл настроек, данные из которго имеют приоритет выше, чем настройки пользователя. По сложившейся терминологии, такие настройки называют «политиками». Политики Chromium описываются файлами формата json, находящимися в директории /etc/chromium/policies . Политики делятся на обязательные (лежат в папке /etc/chromium/policies/managed ) и рекомендуемые ( /etc/chromium/policies/recommended соответсвенно). Рекомендуемые политики — это практически обычные системные настройки, которые пользователь может переопределять. А вот обязательные политики — это то, что нам нужно.

Для примера давайте зададим что-нибудь — например, список сайтов, которые Chromium должен блокировать. Все действия нужно производить с правами root; также не забывайте следить, чтобы у обычных пользователей не было прав на запись в создаваемые файлы.

Для начала, создадим нужную папку, если ее еще нет:

А внутри нее создадим файл test_policy.json со следующим содержимым:

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

Список политик, используемых в данный момент броузером, можно получить по ссылке chrome://policy.

Как и прочие файлы конфигурации, json-файлы с политиками Chromium можно распространить по папкам /etc/chromium/policies целого парка машин с помощью Puppet, CFEngine и подобных программ управления конфигурацией.

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

389 Directory Server

Сервер каталогов уровня предприятия, создаваемый сообществом при спонсорской поддержке Red Hat. Базой для него послужил разрабатываемый с 1996 года Netscape Directory Server. Он получил новое имя — Fedora Directory Server — после того, как права на него в 2005 году приобрела Red Hat. В 2009 году проект снова изменил название на 389 Directory Server (389 — по номеру порта службы LDAP). Причина проста: FDS неразрывно ассоциировался с Fedora, что, по мнению разработчиков, тормозило развитие, в частности интеграцию в другие дистрибутивы. На основе 389DS Red Hat выпустила коммерческую версию Red Hat Directory Server (RHDS) с техподдержкой 24/7. Возможности 389DS включают полную поддержку протокола LDAPv3, SSL/TLS- и SASL-аутентификацию, синхронизацию данных (пользователь, группа, пароль) с Active Directory (при условии, что на КД Win2k3/2k8 установлен компонент Windows Sync), разграничение доступа вплоть до отдельных атрибутов (имя, группа, IP и т. д.) В качестве криптодвижка используется библиотека NSS от Mozilla Project. Конструктивно 389DS состоит из сервера каталогов (Сore Directory Server, CDS) и сервера администрирования (Admin Server). Задача последнего — управление всеми доступными CDS, для чего предлагается графическая консоль (389-console) и утилиты командной строки. В Linux консоль устанавливается автоматически (написана на Java). Для управления из-под Win2k3/2k8 на сайте проекта следует скачать пакет Windows Console.

Консоль управления 389 Directory Server

Разработчики отмечают высокую производительность и масштабируемость 389DS. В одной сети может работать до четырех равноправных мастер-серверов с автоматическим разрешением конфликтов, балансировкой нагрузки и резервированием сервера. Поддерживаются работающие в режиме read-only сервера, некий аналог Read Only Domain Controller в Active Directory Win2k8.

В настоящее время проект официально предлагает репозиторий и пакеты для RHEL/Fedora (подходят и для CentOS). Кроме того, возможна установка в других Linux (Debian, Ubuntu, Gentoo), Solaris, HP/UX 11. Некоторые версии поддерживают также Windows, Irix, AIX и OSF/1. Однако развертывание и последующая поддержка в «неофициальных» системах требует от админа уже некоторой подготовки.

Компоненты 389DS выпускаются по лицензии GNU GPL, но сервер базируется на ряде продуктов с другими лицензиями (MPL/LGPL/GPL/X). Стоит также отметить, что 389DS является составной частью FreeIPA — централизованного решения для управления информацией о пользователях и политиках и для аудита. Речь об этом продукте пойдет чуть ниже.

FusionDirectory

Поскольку доступ к исходному коду GOsa для тех, кто не имеет отношения к компании Gonicus GmbH, был затруднен, разработчики приняли решение о создании более открытого и полностью поддерживаемого сообществом форка для привлечения сторонних специалистов, а также обеспечения условий для написания плагинов под большее количество приложений. Новый проект получил название FusionDirectory. Разработчики обещали не только создать самое «мощное и универсальное» решение для управления, имеющее более удобные инструменты для разработки, но и усовершенствовать документацию. В октябре 2011-го вышла версия FusionDirectory 1.0.2, но, так как работа над проектом началась совсем недавно, о каких-то особых функциональных отличиях от GOsa пока говорить не приходится. Документация, по сути, состоит из пары руководств, но, учитывая родство с GOsa, на стадии ознакомления с FusionDirectory можно использовать документацию на родительский проект. Четко определен список поддерживаемых дистрибутивов (Debian, CentOS 5/RHEL 5, Fedora 14/15, openSUSE 11.3/11.4, SLES 11), и, главное, для каждого из них создан репозиторий, обеспечивающий простую установку.

Mandriva Directory Server

Сервер Mandriva Directory Server (MDS) — простое в использовании решение, позволяющее при помощи наглядного интерфейса управлять учетными записями пользователей и групп, доступом и сетевыми сервисами. По сути, это удобная надстройка над LDAP — OpenLDAP, хотя возможна и совместная работа с 389DS. Функционально может выступать в качестве PDC (уровня Windows NT4), LDAP-сервера с синхронизацией учетных записей и паролей, полностью заменить Active Directory либо интегрироваться в нее. Клиентскими ОС могут служить Windows, Linux и Mac OS X. Интерфейс позволяет производить настройку аккаунтов и ACL в Samba, управлять совместным доступом, печатью на базе CUPS, доставкой почты (Postfix), конфигурировать Squid и службы DNS/DHCP, администрировать учетные записи GLPI. Пакет включает Kerberos и может быть использован для организации однократной аутентификации (SSO). Разграничение доступа для объектов устанавливается вплоть до отдельных атрибутов: пользователь, группа, IP-адрес, время и т. д.

Mandriva Management Console проста и понятна в работе

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

Непосредственно для управления сервисами предназначен модуль MMC agent, написанный на Python и использующий для обмена данными XML-RPC. Агенты настраиваются при помощи очень простого в использовании веб-интерфейса MMC (Mandriva Management Console). Администратор может выбрать один из двух режимов отображения: Normal или Expert.

В отличие от 389DS, пакеты предлагаются не только для «родного» дистрибутива: имеется собственный репозиторий Debian, сборки для CentOS/RHEL/Fedora и openSUSE, а также готовый образ VMware. Таким образом, серверную часть MDS можно относительно быстро и без проблем установить в любой *nix-системе. Продукт включен в комплект поставки Mandriva Enterprise Server. MDS представляет собой самое простое в установке и конфигурировании решение, освещенное в нашем обзоре, однако самостоятельная сборка на других системах, кроме MES, все-таки требует некоторых навыков по работе с LDAP. Документация проекта весьма подробна и позволяет разобраться во всех его нюансах.

FreeIPA

Цель проекта FreeIPA (Free Identity, Policy and Audit) — создание для Linux-систем среды, представляющей собой альтернативу Active Directory и позволяющей централизованно управлять аутентификацией пользователей, устанавливать политики доступа и аудита. Фактически FreeIPA — это симбиоз нескольких опенсорсных проектов, таких как дистрибутив Fedora, 389DS, MIT Kerberos, NTP и BIND. На этом проекте, развиваемом при финансовой поддержке Red Hat, основан используемый в коммерческом дистрибутиве продукт IPA, который Red Hat представила общественности летом 2008 года.

WARNING

В FreeIPA до версии 2.1.3 включительно имеется CSRF-уязвимость (CVE-2011-3636). Для ее устранения следует обновиться до 2.1.4.

централизованное управление учетными записями пользователей, групп, компьютеров и сервисов;
управление доступом к приложениям, установка политик паролей и настроек Kerberos, управление правилами SUDO;
аутентификация Kerberos для пользователей и узлов;
Host Based Access Control — управление и хранение ролей в LDAP;
служба управления сертификатами (Dogtag Certificate Server).

Сеть, построенная с применением FreeIPA, функционально может состоять из трех типов систем: одного или нескольких серверов, клиентских машин и компьютера администратора. Последний, по сути, представляет собой обычный клиентский десктоп с консольными утилитами для удаленного управления FreeIPA (кстати, использовать их совсем не обязательно — вполне можно обойтись веб-интерфейсом, который написан на Java).

Менеджер аутентификации в Fedora
позволяет выбрать FreeIPA

Чтобы снизить нагрузку на канал, клиент использует локальный кеш (LDB и XML), получая из него настройки в том числе и при отсутствии доступа к серверу. На клиентской системе устанавливается агент управления аутентификацией SSSD (System Security Services Daemon). Клиентская часть реализована не только для Red Hat/Fedora и клонов, но и для других ОС и платформ: AIX, HP-UX, Solaris, openSUSE. Что интересно, над сборкой клиентских пакетов для Ubuntu/Debian и обеспечением их совместимости работают два сотрудника Red Hat.

Для настройки FreeIPA можно использовать консоль

Проект активно развивается, и при этом обнаруживаются ошибки. Последний релиз 2.1.4 устраняет CSRF-уязвимость (подделка межсайтовых запросов, CVE-2011-3636).

Apache Directory Server

Сервер каталогов, разрабатываемый Apache Software Foundation. Полностью написан на Java, поддерживает LDAPv3, Kerberos и Change Password Protocol. Позиционируется как встраиваемое в другие Java-приложения решение, однако никто не запрещает использовать его автономно. Обеспечивает выполнение LDAP и Kerberos, возможна реализация поддержки любого протокола. Продукт мультиплатформенный. На сайте проекта доступны пакеты для установки в Linux, Windows и Mac OS X, исходные тексты позволяют собрать ADS на любой системе, для которой имеется Java. Кроме стандартных возможностей LDAP, реализованы хранимые процедуры, триггеры, динамические объекты Java и многое другое. Распространяется под лицензией Apache. В рамках проекта разрабатывается Apache Directory Studio, включающий LDAP-браузер, браузер схем, редакторы LDIF и DSML, клиентские программы для администрирования.

GOsa2

Сайт проекта: oss.gonicus.de/labs/gosa.
Лицензия: GNU GPL.
Дистрибутивы: пакеты — Debian/Ubuntu, RedHat/CentOS/Fedora, openSUSE/SLES, из исходных текстов — любой *nix.

Все функции вынесены в плагины (принцип «один сервис = один плагин»), поэтому админ собирает конфигурацию в соответствии со своими нуждами.

В настоящее время реализовано более 30 плагинов, обеспечивающих управление такими сервисами, как Squid, DansGuardin, Postfix, Courier-IMAP, Maildrop, GNARWL, Cyrus-SASL, OpenSSL, ISC DHCP, WebDAV, PureFTPd, PPTP, Kerberos, Asterisk, Nagios, OPSI, Netatalk, FAI, rsyslog, и серверами коллективной работы: SOGo, OpenGroupware, Kolab, Scalix. При этом все вышеуказанные плагины не обязательно должны работать на одном сервере, некоторые из них можно установить на отдельные хосты.

GOsa позволяет управлять учетными записями *nix и сервисами

Учетные записи пользователей объединяются в группы, для которых назначаются разрешенные приложения. При создании новых аккаунтов применяются шаблоны (админ создает их сам) с прописанными правами доступа к объектам. Набор разрешений ACL состоит из типа, определяющего видимость, объектов (пользователей/групп) и разрешений. Разрешения определяют все возможные действия: создание, удаление, перемещение, чтение, запись и т. д.

GOsa — единственный в нашем обзоре проект с локализованным интерфейсом управления. Правда, локализован он пока не полностью, но использование gettext позволяет при необходимости сделать это самостоятельно.

Поддерживается установка в любом дистрибутиве Linux. Разработчики рекомендуют Debian, под который создан отдельный репозиторий. Также доступны пакеты для Red Hat/CentOS/Fedora и openSUSE/SLES, но, как правило, разработчики не спешат их собирать, поэтому версии немного запаздывают. Можно использовать любой веб-сервер, однако предпочтение отдается Apache2 и nginx. Документация доступна только на английском и не поспевает за развитием проекта, многие моменты отражены в ней весьма поверхностно.

Девиз Identity Policy Audit хорошо поясняет сущность FreeIPA

FreeIPA используется для аутентификации и авторизации в решении oVirt для виртуализации, построенном на основе KVM.

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

Для синхронизации 389DS с Active Directory необходимо установить Windows Sync.

После установки пакета 389-ds для конфигурации 389DS следует запустить скрипт.

Утилита system-config-autentification, входящая в состав Fedora, содержит вкладку, позволяющую активировать аутентификацию через FreeIPA.

Заключение

Даже невооруженным глазом видно, что наиболее многофункциональным инструментом является GOsa2. Это решение обеспечивает управление учетными записями и многочисленными сервисами, поддерживает установку в большинстве дистрибутивов Linux, имеет локализованный интерфейс. Однако окончательный выбор зависит от конкретной задачи.

Читайте также: