OTRS: LDAP аутентификация, авторизация и синхронизация (FreeIPA, AD)
OTRS — система обработки заявок с открытым кодом (Open-source Ticket Request System), написанная на Perl.
Существует в двух вариантах:
Клиенты, очереди, агенты и группы
После установки OTRS у вас сразу будут доступны:
Стандартные группы
После установки системы вы увидите три созданные группы:
Права, связанные с группами
Основные права
Основные права, которые можно настроить в группе, ограничивающие действия агентов:
Дополнительные права
Также существуют и дополнительные права, отображение которых можно включить в настройках (System::Permission):
Аутентификация с использованием базы данных
Стандартный способ аутентификации и авторизации агентов и клиентов — это база данных.
Например, настройки аутентификации агентов, используя базу данных, выглядит так:
Мы также оставим этот способ аутентификации и добавим в дополнение с нему аутентификацию через LDAP.
Роли и компании
Так же мы расширим возможности авторизации, добавив роли и компании:
Постановка задачи
Вы — администратор системы OTRS в компании my-it-company.com, предоставляющей сервисные услуги другим компаниям (или подразделениям внутри вашего холдинга).
Вам очень бы не хотелось заводить учетные записи новых агентов и клиентов вручную, а также заполнять дополнительную информацию, такую как адрес электронной почты, телефон, должность, адрес и номер кабинета — ведь это все уже есть в каталогах LDAP.
И ваша компания также получит очевидные плюсы — единый пароль сотрудника во все системы, блокировка учетной записи в LDAP заблокирует доступ и во все остальные сервисы.
my-it-company.com работает на Linux и использует в качестве сервера каталогов Red Hat FreeIPA, а обслуживаемые вами подразделения — различные леса Microsoft Active Directory, с которыми у вас нет федерации, но есть возможность подключения к контроллерам домена.
Вам нужно разделить потоки заявок от различных клиентов, а также реализовать различные уровни доступа агентов к очередям — менеджеры должны иметь возможность менять приоритет задач в системе.
Сотрудники вашей компании так же могут ставить задачи в системе для внутренних нужд my-it-company.com, иногда являясь и агентами, и клиентами одновременно (а иногда и нет).
Подготовка
Учетные записи для просмотра LDAP
Если запрещен анонимный просмотр дерева каталогов, то создадим в доменах my-it-company.com, pear.com и macrohard.com учетные записи, прав которых нам хватит, чтобы делать запросы к LDAP (назовем их, например, ldap-bot)
Группы FreeIPA для синхронизации с ролями OTRS
Заведем на FreeIPA три группы пользователей, которые будут синхронизироваться с нашими ролями OTRS, например:
Атрибут, определяющий принадлежность к компании
Выберем атрибут, по которому будем определять принадлежность к компании. Пусть это будет атрибут «Организация». Например, у вас все получилось организационно и технически, и все пользователи во всех доменах всегда имеют значение в поле «Организация»:
Определим атрибуты пользователя, используемые FreeIPA
Изучим схему FreeIPA, выяснив названия атрибутов, которые нам понадобятся для синхронизации (ФИО, логин, телефон и т. п.).
dn: uid=laptevs,cn=users,cn=accounts,dc=my-it-company,dc=com
uid: laptevs
givenname: Stanislav
sn: Laptev
cn: Laptev Stanislav
mail: laptevs@MY-IT-COMPANY.COM
l: Moscow
telephonenumber: +7(863)999-99-99
mobile: +7(999)999-99-99
ou: My-it-company
title: SysAdm
Настройка конфигурации OTRS
Файлы конфигурации
Настройка агентов
Аутентификация агентов
Синхронизация агентов (групп LDAP с ролями OTRS)
Если вы решили, что роли вам не подходят, и вы хотите только группы, приведу два примера синхронизации групп LDAP с группами OTRS — упрощенный и с настройкой прав по каждой группе.
Linuxoid
OpenSource forever
Централизованное управление сетью с FreeIPA
Централизованное управление учетными записями пользователей и ресурсами это одно из требований организации любого размера. Проект FreeIPA призван заменить Active Directory.
Известно, что наличие нескольких точек управления порождает ряд проблем, главная из которых несогласованность. Наличие дубликатов записей означает, что вероятность ошибки в администрировании возрастает, да и сам процесс усложняется на порядок. Все изменения необходимо отслеживать в нескольких местах. Отсутствие единого входа делает работу пользователей с несколькими сервисами неудобной. Именно хорошая управляемость приводит к тому, что в организациях крупного размера предпочитают использовать Windows с Active Directory. Самостоятельно настроить альтернативное решение при помощи OpenSource компонентов работающих по протоколам LDAP и Kerberos, под силу далеко не каждому системному администратору. Да и то после внедрения остается ряд вопросов удобства управления.
Разработчики Fedora/RedHat предлагают свое решение в виде проекта FreeIPA (Free Identity, Policy and Audit, http://freeipa.org/) позволяющий создать централизованную систему управления компьютерной сетью, способной заменить Active Directory для аутентификации пользователей, установок политик доступа и аудита. Собственно задачи полностью показывает девиз проекта – Identity, Policy, Audit (идентичность, политика, аудит). Как и водится разработчики не изобретают велосипед. Базой для FreeIPA является несколько открытых протоколов реализованных при помощи OpenSource решений — Fedora, 389 Directory Server (бывший FDS, Fedora Directory Server), MIT Kerberos, NTP и DNS. По сути 389 DS является частью проекта FreeIPA. Впервые код FreeIPA был включен в состав Fedora 9.
Сообщество разработчиков финансово поддерживается RedHat, которая в конце июня 2008 представила свой продукт на его основе Red Hat IPA. Главный плюс, что все решения из RedHat хорошо документированы, причем сразу отражаются все изменения. Учитывая, что по сути Red Hat IPA это переименованный FreeIPA, мы имеем ответы практически на все вопросы. Хотя документацию FreeIPA и Fedora не стоит сбрасывать со счетов.
После анонса Red Hat IPA проект FreeIPA представил еще две версии 1.2 и 1.2.1 соответственно в (ноябре и декабре 2008), затем развитие FreeIPA впало в спячку. Следующий стабильный релиз 1.2.2, появился уже в сентябре 2009 года, который без изменений благополучно дожил до наших дней и представлен в частности в основном репозитарии Fedora 14:
Установка сервера FreeIPA
Функционально сеть построенная с применением FreeIPA может состоять из трех типов систем: одного или нескольких серверов, клиентских машин и компьютера администратора. Последний по сути является клиентской системой на котором дополнительно установлены консольные утилиты для управления FreeIPA. Хотя в его отсутствие вполне можно обойтись веб-интерфейсом.
Минимальные системные требования для сервера FreeIPA соответствуют предъявляемым к дистрибутиву. В качестве дистрибутива будем использовать Fedora 14, но это может быть RedHat или CentOS [5]. Инсталляцию рекомендуется производить на “чистую” систему не исполняющую никаких других функций.
Перед началом установки необходимо настроить сеть, установив на сервере FreeIPA статический адрес. Имя должно разрешаться через службу DNS или файл /etc/hosts, иначе процесс настройки будет прерван.
В репозитарии Fedora 14 доступна версия 1.2.2, названия пакетов которой отличаются. Чтобы установить 2.x следует подключить репозитарий разработчиков FreeIPA, для чего копируем файл http://freeipa.org/downloads/freeipa-devel.repo в /etc/yum.repos.d.
Теперь команда:
Покажет наличие ряда новых пакетов (для версии 1.2.х следует устанавливать ipa-*).
Здесь пока находится предрелиз, в котором исправлено ряд мелких ошибок. В рабочей системе очевидно лучше самостоятельно собрать пакеты последней версии:
Но мы будем использовать репозитарий. Версия 2.0 требует 389 Directory Server > 1.2.8 (на момент написания этих строк на официальном сайте 1.2.8 RC2). В репозитарии Updates Fedora 14 пока версия 1.2.7, поэтому подключаем updates-testing (epel-testing для RHEL) и устанавливаем пакет 389-ds.
Устанавливаем сервер FreeIPA:
Или если все компоненты:
Сервер FreeIPA может управлять настройками BIND, желательно (но необязательно) чтобы BIND также работал на одном компьютере. Если такое размещение планируется то используем команду:
В процессе установки будет скачано почти 100 Мб зависимостей, в том числе и веб-сервер Apache, JDK и Tomcat.
Далее необходимо сконфигурировать сервер, для чего вводим:
Скрипт запущенный при помощи этой команды произведет настройку ntpd, 389-ds, Kerberos KDC и Apache, плагин WinSync для синхронизации с Active Directory, установит политики SELinux (из пакета freeipa-server-selinux). По запросу указываем имя узла и домена, область Kerberos (Kerberos realm), пароли администраторов Directory Manager (используется редко для низкоуровневых задач по настройке LDAP) и учетной записи “admin” IPA сервера. После будут настроены и перезапущены все серверы, администратор получит список портов, которые необходимо открыть в брандмауэре:
Работа установочного скрипта
Кроме этого в каталоге /tmp создается файл настроек для BIND. В файл /root/cacert.p12 и /etc/ipa/ca.crt будет сохранен сгенерированный сертификат (для доступа понадобится ввести пароль администратора Directory Manager). В каталоге /etc/ipa также находится конфигурационный файл сервера /etc/ipa/default.conf (варианты /etc/ipa/server.conf или /etc/ipa/cli.conf.), но редактировать его вручную вряд ли понадобится.
К слову ipa-server-install поддерживает дополнительные параметры, список которых можно получить при помощи ключа —help.
Так, например, для настройки интеграции с DNS следует использовать —setup-dns, или скрипт ipa-dns-install. Чтобы создавался самоподписанный сертификат, добавляем в вызов –selfsign.
На клиентские компьютеры устанавливается пакет freeipa-client, для настройки в комплекте идет скрипт ipa-client-install, который изменит настройки PAM (/etc/pam.conf) и Kerberos (/etc/krb5.conf). Другие утилиты — ipa-replica-install, ipa-replica-prepare, ipa-replica-manage служат для настройки и репликации данных с мастер сервера FreeIPA.
Следующим шагом следует получить сертификат администратора Kerberos при помощи команды:
В процессе будет запрошен пароль администратора.
Важно: команду необходимо вводить под той учетной записью, которая будет использована для управления FreeIPA.
Команда klist покажет информацию по полученному билету.
Для более удобного контроля всех сервисов необходимых для работы FreeIPA разработчики предлагают утилиту ipactl:
Управление FreeIPA из консоли
Для управления настройками FreeIPA предлагает два способа – утилита командной строки ipa и веб-интерфейса. Оба отлично дополняют друг друга. Все параметры команды ipa можно получить в справочной странице “man ipa”, введя ipa без параметров, а более подробную информацию “ipa help команда”. Поддерживается два режима работы: командный, когда все параметры вводятся за раз и интерактивный, когда по запросу администратор указывает недостающие параметры. Кроме того доступна Python интерактивная консоль:
Начать изучение стоит из команды:
Которая выведет значения всех переменных FreeIPA сервера.
Добавим новую учетную запись в базу IPA:
По сути необходимо ввести лишь имя пользователя, скрипт сам предложит логин, который можно принять просто нажав Enter. Все остальное будет сделано автоматически. Чтобы задать пароль следует добавить ключ —password или выполнить команду:
Теперь пользователь может получить сертификат введя “kinit vpupkin” и работать через IPA. При первом подключении последует запрос на изменение пароля.
Все это можно ввести одной строкой:
Поддерживаются и другие поля, полный их список можно получить при помощи:
Добавление учетной записи при помощи ipa
Чтобы просмотреть информацию об учетной записи, используем ключ user-show:
Дополнительный параметр —all выведет все атрибуты. Модифицировать их можно при помощи ipa user-mod.
Удалить, отключить и включить учетную запись можно при помощи ключей — ipa user-del, user-disable и user-enable. Реализован и поиск:
Если в сети уже установлен 389-ds сервер, учетные записи легко перенести оттуда:
По умолчанию все учетные записи пользователей подключаются к группе ipausers (можно изменить в настройках сервера). Для более гибкого определения прав, следует их распределять по группам. Группы создаются аналогично:
И добавляем учетные записи:
После установки в списке известных узлов будет только сервер, остальные системы добавляются при помощи команд — host-add, hostgroup-add, hostgroup-add-member.
Целая группа параметров позволяет управлять сертификатами:
Аналогичные команды доступны для управления SUDO
И других настроек сервера.
Веб-интерфейс FreeIPA
Официально работа веб-интерфейса протестирована на Internet Explorer, Firefox, Chrome и Safari. В процессе подключения принимаем сертификат веб-сервера, после скорее всего получаем сообщение о том, что сертификат Kerberos не действителен. Чтобы исправить, следует его установить (он располагается http://ipa.example.com/ipa/config/ca.crt). Для этого переходим по ссылке в окне сообщения. Указываем, для каких действий использовать сертификат (активируем два — веб и идентификация приложений), далее нажав кнопку (Configure Firefox) и затем Allow, конфигурируем браузер для поддержки SSO. Теперь если ранее выполнена команда “kinit admin” мы автоматически регистрируемся в консоли.
В версии 2.0 разработчиками сделано все, чтобы упростить процесс локализации (используется gettext и UTF8). 
Настройка HBAC
В каталоге install/po доступен файл ru.po, в котором переведены лишь некоторые сообщения. Язык интерфейса выбирается автоматически по настройкам веб-браузера.
Консоль содержит три вкладки:
Параметры FreeIPA сервера
В принципе интерфейс повторяет все настройки при полощи ipa о которых говорилось выше, но в более наглядном виде. И главное не требует особой подготовки от пользователя. Познакомиться с его возможностями можно просмотрев видео.
Подключение клиента
В качестве клиентских систем поддерживаются не только Fedora/RedHat, но и Windows для которых можно установить пакет MIT Kerberos for Windows (http://web.mit.edu/kerberos/). В Fedora процесс очень прост. Настраиваем разрешение имен прописав данные DNS сервера в /etc/resolv.conf. Затем устанавливаем пакет ipa-client и если необходимы инструменты управления то и ipa-admintools.
После установки следует ввести команды ipa-client-install и ipa-join. По умолчанию домашний каталоги пользователей располагаются в /home, но FreeIPA не создает их при подключении клиента. Для удобства лучше использовать NFS. Если же необходима такая функция, просто добавьте ключ –mkhomedir при запуске ipa-client-install.
После подключения к серверу можно проверить корректность данных, введя:
Кроме этого утилита system-config-autentification из состава Fedora, содержит вкладку позволяющую активировать подключение через FreeIPA. 
Настройка аутентификации Fedora при помощи system-config-autentification
Вот собственно и все основные настройки FreeIPA. Знакомство показывает, что это очень простое в освоении решении управляя которым забываешь, что в его основе несколько проектов, каждый из которых приходилось изучать отдельно.
Набор полезных советов для эффективного использования FreeIPA
В процессе эксплуатации FreeIPA часто возникают нетривиальные задачи, которые упираются в не очень хорошо документированные или не полностью реализованные места. Поэтому я решил дополнить свою предыдущую статью некоторыми решениями, которые помогут сэкономить вам немного времени.
FreeIPA агент в lxc контейнерах
У нас для dev-окружений в некоторых местах используется такая штука, как Proxmox и lxc-контейнеры в нём. Темплейт для контейнера был взят стандартный centos-7-default версии 20170504, который мы кастомизировали. Но при банальной установке агента он отказался работать. После разбора выяснилось, что в этой сборке нет пакетов с sudo и в контейнерах нет SELinux. Итак, по пунктам, что нужно сделать:
В случае, если конфиги раскатываются при помощи Ansible, можно использовать переменные:
Библиотека для использования API в Python
В современных версиях FreeIPA появился замечательный API, но вот полноценных библиотек для Python нам найти не удалось. На гитхабе есть репозиторий, но реализованного там нам оказалось мало. Так как решение распространяется под MIT лицензией, мы решили скопировать его и дополнить сами. Наша реализация доступна по этой ссылке.
Она будет еще допиливаться по необходимости, но вы можете забирать ее уже сейчас, доделывать и мёржить изменения. В настоящий момент реализовано только то, что необходимо было нам.
Несколько слов про Ansible модули
Оговорюсь сразу, речь пойдёт про версию Ansible 2.3.1.0, установленную через pip. В целом модули добавления юзеров и групп работают нормально. Но при добавлении sudoroles возникли некоторые проблемы. Первая и самая неприятная — они просто не добавляются. Ошибка выглядит вот так:
Лечится на скорую руку, это довольно элементарно. В файле модуля ipa_sudorule.py нам нужна строка 307. Вот она:
Меняем ее на такую:
Добавление начинает работать. Прочитать про это можно тут и тут, но нами еще не проверено.
Вторая проблема связана с добавлением опций для sudoroles, с которой мы планируем разобраться в ближайшее время.
FreeIPA агент в debian
Установка агента в debian like системы почему-то у некоторых людей вызывает ряд проблем. Я хочу изложить наш вариант развертки агентов на debian подобных системах:
Реплика в Amazon
Как известно, в амазоне внешние адреса не указываются непосредственно на хостах. И установщику это очень сильно не нравится. В целом это актуально не только для амазона, а для всех вариантов, когда внешний адрес не настроен непосредственно на хосте.
Для решения этой проблемы при установке достаточно на время установки добавить на любой интерфейс внешний IP. Как пример, это можно сделать при помощи ip addr add:
После успешной установки и настройки с помощью ip addr del:
Также не забудьте указать разные днс имена для внешнего и внутреннего адреса, иначе будет путаница.
В итоге мы получаем, что клиенты в lxc и debian подобных системах вполне реальны и никаких особых проблем не имеют. Все эти решения работают у нас без каких-либо заметных проблем уже довольно длительное время. Управлять полноценно доступами через Ansible не вполне удобно, но можно ускорить и автоматизировать часть рутинной работы. Что касается библиотеки для Python — надо реализовать еще довольно много, но все основные функции там уже имеются. Впрочем, новые идеи тоже приветствуются.
Операционные системы 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 требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.
Очередные обновления (версии) предназначены для:
Оперативные обновления предназначены для оперативного устранения уязвимостей в экземплярах, находящихся в эксплуатации, и представляют собой бюллетень безопасности, который доступен в виде:
Ввиду совершенствования нормативно-правовых документов в области защиты информации и в целях обеспечения соответствия информационных актуальным требованиям безопасности информации, а также обеспечения их долговременной эксплуатации, в том числе работоспособности на современных средствах вычислительной техники, рекомендуется на регулярной основе планировать проведение мероприятий по применению очередных и оперативных обновлений операционной системы.
Настройка репликации во FreeIPA 4.4 с domain level 1
У нас в компании для организации и управления доступами для Linux-серверов
используется такой сервис как FreeIPA. FreeIPA — это вполне полноценная замена AD для Linux-систем от RHEL. В новой версии появились уровни доменов и был переработан процесс настройки репликации. Так как инструкций вменяемого вида в рунете найти не удалось, я решил написать собственную.
Для начала нам понадобится два сервера с CentOS 7. Сервера будут такие:
На каждом сервере вносим в /etc/hosts адреса мастера и реплики. В нашем случае это:
Дальше на мастере устанавливаем необходимые пакеты. В нашем случае мы используем сервера FreeIPA как DNS-сервера. Поэтому устанавливем и пакет DNS-сервера:
Итак установка сервера:
Далее отвечаем на вопросы.
1. Имя хоста должно быть прописано в хост и резолвится. Оставляем как есть.
2. Доменное имя тоже оставляем как есть.
3. Realm name тоже без изменений.
4. Пароль для менеджмента лдап-директорий нужен сложный. И не потерять.
5. Пароль администратора самого сервиса.
6. Указываем dns forwarders, к примеру, на гугловые сервера. Чтобы закончить указывать форвардеры, достаточно в пустой строке нажать ENTER.
7. Разрешаем реверс зону.
8. Дальше нам выводят данные для проверки. Проверяем, продолжаем.
Начинается довольно долгий процесс установки. Одна из самых долгих частей это генерация сертификатов, так что можно сходить попить чаю.
В финале установки нам покажут какие порты используются. Настраиваем фаерволл, чтобы он принимал соединения на этих портах. В нашем случае тестовое окружение и все друг другу доверяют.
Можем зайти в веб-интерфейс, проверить работу.
Убедились, что всё работает. Теперь переходим к повышению уровня домена. Нам необходимо пройти по вкладкам IPA SERVERS → Topology. Где нас сразу предупреждают, что СА-серверов должно быть больше одного.
Отвечаем ОК. И проверяем уровень домена на вкладке Domain Level. Если это свежая установка, он по умолчанию будет 1.
ВНИМАНИЕ! Если вы это делаете на проде, то повышение уровня домена без предварительной подготовки может всё сломать. Делайте это только в том случае, когда понимаете зачем и как.
После этих операций переходим к настройки реплики. И вот тут начинаются отличия от старых механизмов. Если раньше нужно было генерировать ключи, переносить на реплику и делать множество телодвижений, то теперь всё значительно проще.
Итак проверяем что реплика берёт днсы с мастера.
Теперь устанавливаем ipa-client.
После этого устанавливаем и настраиваем клиента. Тут такая же история как с сервером — есть куча ключей для автоматизации, поэтому выполняем.
После этого хост должен появиться в веб-интерфейсе.
Дальше переходим к настройке репликации. Выполняем.
У нас попросят пароль админа. Вводим, жмем ENTER.
Далее дожидаемся установки и настройки репликации. После завершения можно зайти на ipareplica0.org.lan там в IPA SERVERS → Topology → Topology Graph мы увидим, что реплика появилась и реплицируется только доменная часть.
Но мы также помним про назойливое упоминание, что СА-сервер один и что нам нужен резервный днс. Переходим к настройке днс-сервера на реплике.
И по аналогии с мастером разрешаем форвардеров. Если вдруг наша реплика находится в другом регионе, можно указать другие форвардеры.
После этого переходим к установке СА сервера.
Тут у нас спросят наш Directory Manager password. Вы ведь его ещё не потеряли?
Это займет довольно много времени, поэтому ждём. После завершения идём на любой веб-интерфейс и проверяем топологию. Пропало назойливое сообщение о том, что СА в единственном экземпляре. И появилась новая связь в графике топологий.
Как видим, теперь всё относительно отказоустойчиво. Масштабирование в новой версии стало гораздо более простым и понятным.
Теперь пару слов о том, что стоит не забывать мониторить. Мы мониторим запущенные процессы, открытые порты и самое главное мониторим срок действия корневого СА-сертификата. Потому как в случае, если он прострочится, может возникнуть куча ручной волокиты которая никому не нужна.
