Настройка браузера firefox для авторизации kerberos
Обновлено: 05.07.2024
Конечный результат: заходя на URL Zabbix, пользователь автоматически аутентифицируется без ввода учетных данных. Для этого пользователю нужно быть залогиненным в Windows под доменным аккаунтом, который привязан к заббиксу. Также у пользователя должен быть настроен браузер (включена поддержка Kerberos и прописаны доверенные сайты интрасети для IE).
- Ubuntu Server 18.04 LTS;
- Домен Active Directory, функциональный уровень 2008 (или выше);
- Zabbix Server 4.0.11, веб сервер – Apache2 (инструкция по установке Zabbix);
- A Запись в DNS для domain.local.
Настройка LDAP аутентификации Zabbix в Active Directory
Привязка доменного пользователя к Zabbix
Сначала нужно привязать пользователей домена к Zabbix. Для этого достаточно создать в заббиксе пользователя с таким же логином, как и в домене. Например, если ваш логин (атрибут sAMAccountName) user_5, то и пользователь в Zabbix должен иметь такое же имя входа.
Проделайте это с каждым пользователем, который будет пользоваться Zabbix.
Создание Active Directory учетки для связи Zabbix с доменом
Теперь нужно создать в Active Directory отдельного пользователя, через которого будет выполняться привязка Zabbix к домену. На практике, можно использовать любой доменный аккаунт, но лечше создать выделенный служебный аккаунт. В моём случае это будет zabbix_admin. Для создания пользователя в AD я воспользуюсь PowerShell командой New-ADUser:
New-ADUser -Name "zabbix_admin" -GivenName "zabbix_admin" -Surname "zabbix_admin" -SamAccountName "zabbix_admin" -AccountPassword (Read-Host -AsSecureString "Password:") -DisplayName "zabbix_admin" -Enabled $true
Выполните команду в консоли PowerShell и задайте пароль пользователя. Ваш новый пользователь будет находиться в контейнере Users в корне домена.
Настройка LDAP аутентификации в веб интерфейсе Zabbix
Теперь перенастроим Zabbix на LDAP аутентификацию. В веб-интерфейсе перейдите в Administration -> Authentication, вкладка LDAP settings. Включите опцию Enable LDAP authentication и заполните следующие поля.
Перед завершением настройки, обязательно проверьте валидность ваших настроек, выполнив тестовый логин (кнопка Test). Укажите пользователя (мы завели его в zabbix ранее) и его пароль из AD.
Если тест пройден успешно, то сохраняйте настройки и переключите тип авторизации в Zabbix с Internal на LDAP.
На этом настройка LDAP аутентификации завершена.
Совет. В случае недоступности вашего LDAP сервера, вы не сможете попасть в Zabbix. Чтобы переключиться обратно на внутреннею аутентификацию, зайдите в mysql и выполните команду:Настройка прозрачной (Single Sign On) аутентификации в Zabbix (Apache2, krb5-user)
Сначала в файле /etc/hostname укажите FQDN имя сервера, которое должно совпадать с DNS записью в вашем домене, в моём случае это zabbix.domain.local.
В файле /etc/hosts также пропишите FQDN вашего сервера на локальный IP и на IP вашего сервера:
Для корректной работы Kerberos аутентификации необходимо синхронизировать время с контроллером вашего домена. Ставим пакет ntpdate и направляем его на контроллер домена
apt-get install ntp ntpdate
ntpdate dc.domain.local
Сгенерировать keytab файл можно на контроллере домена:
Установим необходимые пакеты для работы Kerberos и модуль для apache2:
apt install krb5-user libapache2-mod-auth-kerb
Сконфигурируем krb5-user. Правим конфигурационный файл /etc/krb5.cnf:
Подставьте свой домен, в некоторых местах домен написан в заглавном виде – соблюдайте это правило.
Примечание. Обратите внимание на строчку с кейтаб файлом “default_keytab_name = /etc/apache2/zabbix.keytab”, убедитесь, что файл доступен по этому пути. Обязательно дайте этому файлу права на чтение для www-data, выполните chown www-data:www-data /etc/apache2/zabbix.keytabПроверяем работу Kerberos аутентификации в Linux:
Вы можете столкнуться с ошибкой
В этом случае прежде всего попытайтесь авторизоваться из-под другого пользователя, например, вашей учетной записи^
Если аутентификация пройдет успешно, то значит дело в кейтаб файле. Убедитесь, что вы правильно сгенерировали его. Проверьте корректность команды для создания keytab файла.
Проверьте наличие SPN записи для вашего служебной учетной записи zabbix в AD. В командой строке контролера домена наберите:
setspn -l zabbix_admin
Если не изменилось, то измените его вручную.
Под строчкой ServerName zabbix.domain.local добавьте
Часто встречается ошибка, которая связана с несовпадением KrbServiceName с тем, что прописан в keytab файле, поэтому на время тестирования можно поставить значение Any. После того как всё заработает, впишите валидное название сервиса. Свериться можно через команду klist -le /etc/apache2/zabbix.keytab .
Настройка браузеров для Kerberos аутентификации
Чтобы браузер Internet Explorer начал использовать Kerberos аутентификацию на сайте, нужно добавить этот URL в Local Intranet сайты. Google Chrome наследует эти настройки Internet Explorer, поэтому отдельно его настраивать не надо.
Заметка. URL вашего сайта Zabbix должен отсутствовать в списке Trusted sites, иначе Kerberos работать не будет. Сайт должен быть прописан только во вкладке Intranet sites.В IE перейдите в Internet Options -> Security.
В Local intranet жмите Sites, проставьте чекбоксы как на скриншоте и жмите Advanced.
Пропишите URL вашего zabbix сервера.
Перейдите во вкладку Advanced и включите параметр Enable Integrated Windows Authentication.
Если у вас не был отмечен этот пункт – перезагрузите компьютер. По умолчанию он включен.
Вы также можете настроить это через групповые политики
В браузере Mozilla Firefox в about:config поменяйте добавьте url адрес zabbix сервера в следующие параметры:
После выполнения этих этапов, настройку можно считать завершенной. При обращении на URL вашего Zabbix, вы должно автоматически аутентифицироваться без ввода пароля..
Отладка и устранение проблем c Kerberos аутентификацией в Apache
При возникновении проблем, включите режим отладки в apache2:
В файле /etc/apache2/sites-available/000-defaults.conf перед закрывающим тегом </VirtualHost> впишите:
Перезагрузите apach, теперь в error.log апача вы сможете видеть какие ошибки выдаёт модуль Kerberos.
Для удобства используйте команду с фильтром по IP
tail -f /var/log/apache2/error.log | grep ‘ваш ип’
Для работы и диагностики с Kerberos можно использовать команды kinit и klist.
kinit – утилита для получения и кеширования Kerberos тикетов. Пример:
Утилитой klist можно посмотреть кэшированные тикеты Kerberos:
При попытке открыть в Mozilla Firefox внутренние корпоративные сайты на SharePoint Server с включённой аутентификацией Kerberos получил запрос на ввод имени пользователя и пароля. То есть прозрачная передача учетных данных текущего пользователя, как в Internet Explorer, не произошла. Просмотрел все доступные опции в меню навигации Firefox "Инструменты" > "Настройки", но с к сожалению не нашёл там ничего, касающегося безопасности передачи учетных данных текущего пользователя. После некоторых поисков в Интернете, обнаружил, что способ передачи учётных данных всё-таки имеется.
В адресной строке Firefox набираем about:config и принимаем предупреждение о том, что неправильная настройка параметров может привести к некорректной работе браузера.
Перед нами предстанет внушительный список настроек. В поле "Фильтр" введём negotiate, после чего в окне настроек отобразятся интересующие нас два параметра:
Двойным кликом откроем свойства этих параметров и введём в поле значения имя локального домена, в рамках которого мы хотим прозрачно передавать учетные данные пользователя.
Если необходимо указать несколько доменов, то их имена можно вводить через запятую.
После настройки браузер потребуется перезапустить, чтобы изменения вступили в силу и механизмы SSO заработали.
Если настройка двух указанных выше параметров обязательна в случае использования Kerberos аутентификации, то для NTLM аутентификации нужно настраивать параметр:
network.automatic-ntlm-auth.trusted-uris
Помимо настройки SSO в корпоративных средах для Firefox может оказаться полезным включение возможности использования встроенного в ОС Windows хранилища корневых сертификатов. Эта возможность имеется в браузерах Firefox 49 и выше.
В прошлой заметке был рассмотрен пример простейшего ограничения доступа к веб-серверу Apache с применением незащищённой Basic-аутентификации и использованием учётных данных из файла. Разумеется такой режим аутентификации нельзя считать безопасным и поэтому в данной заметке мы рассмотрим пример настройки Kerberos-аутентификации и авторизации на веб-сервере Apache c помощью службы SSSD (System Security Services Daemon).
Ранее уже рассматривался пример подобной настройки веб-сервера Apache, однако в том случае для поддержки Kerberos-аутентификации в систему устанавливался пакет krb5-workstation, а для авторизации использовался функционал интеграции oVirt с Active Directory. В этой заметке мы пойдём по несколько иному пути, так как для аутентификации пользователей в домене AD будем использовать модуль Apache mod_auth_gssapi, а для авторизации модуль - mod_authnz_pam, который будет использоваться в связке с SSSD. То есть получать доступ к веб-серверу смогут все те доменные пользователи, что уже имеют доступ на подключение к самому серверу. Такая конфигурация может быть проста в настройке и полезна в тех случаях, когда некоторому кругу администраторов Linux-сервера нужно предоставить возможность прозрачного подключения (Single sign-on) к веб-сайту того или иного сервиса, работающего на этом сервере, как в ранее рассмотренном случае с веб-консолью QUADStor.
Подключаем к веб-серверу модуль mod_authnz_pam
Посмотрим информацию о модуле mod_authnz_pam, который доступен нам в репозиториях CentOS Linux 7.2:
Как видим из описания, этот модуль позволит нам использовать PAM-авторизацию и PAM-аутентификацию (только Basic). В рамках нашей задачи интересна возможность именно PAM авторизации, хотя и пример настройки Basic-аутентификации мы рассмотрим тоже.
Итак, установим в систему модуль:
Так как настройка производиться на CentOS 7.2 с включённым SELinux, то нам потребуется разрешить взаимодействие веб-сервера Apache с модулем:
Откроем на редактирование файл с директивой загрузки модуля:
и раскомментируем в нём единственную строку, чтобы разрешить автоматическую загрузку нужной библиотеки в процессе запуска веб-сервера:
Перезапустим службу веб-сервера и убедимся в том, что модуль загружен:
Создаём службу PAM
Создадим в каталоге /etc/pam.d/ файл описания собственной службы PAM, которая для процедур аутентификации и авторизации будет вызывать библиотеку SSSD (имя файла используем то, которое нам удобно):
Наполним файл содержимым (первая строка определяет вызов библиотеки SSSD для аутентификации, вторая строка – для авторизации):
Apache c Basic-аутентификацией и PAM авторизацией
Теперь попытаемся с клиентского компьютера получить доступ к веб-консоли QUADStor и увидим соответствующий запрос на ввод учётных данных. Здесь введём учётные данные доменного пользователя, который имеет право на вход на наш Linux-сервер согласно настроенных ранее правил в конфигурации SSSD.
В момент отправки введённых учётных данных в логе безопасности на нашем Linux-сервере мы сможем отследить результат попытки аутентификации (в нашем примере он успешный):
Итак, Basic-аутентификация в паре с PAM авторизацией работает, и теперь разрешённые доменные пользователи уже могут использовать привычные им учётные данные для получения доступа к веб-ресурсу. Однако, повторюсь, что с точки зрения информационной безопасности, использовать такой режим аутентификации неправильно, и поэтому мы перейдём к настройке Kerberos-аутентификации.
Apache c Kerberos-аутентификацией и PAM авторизацией
Для работы Kerberos аутентификации в домене AD можно создать отдельную сервисную учётную запись, для которой в дальнейшем зарегистрировать servicePrincipalName (SPN) веб-сервера и сгенерировать keytab-файл, содержащий данную SPN-запись. Повторяться не буду, так как эта процедура пошагово рассмотрена в одной из прошлых заметок (см. пункт "Создание в домене AD сервисной учётной записи" и "Создание keytab-файла для сервисной учётной записи"). Предполагая, что необходимый keytab-файл у нас уже есть, размещаем его в доступном для службы веб-сервера месте и ограничиваем к нему доступ:
Устанавливаем модули необходимые веб-серверу для поддержки Kerberos-аутентификации средствами GSSAPI:
Опять же, после внесённых изменений перезапустим службу веб-сервера:
Теперь попытаемся с клиентского компьютера получить доступ к веб-консоли QUADStor и процедура аутентификации и авторизации должна пройти для пользователя прозрачно без каких либо запросов на ввод учётных данных.
Защита соединений с веб-сервером с помощью SSL-сертификата
Для этого нам потребуется сделать пару несложных вещей – установить модуль веб-сервера для поддержки SSL (mod_ssl) и сгенерировать SSL-сертификат веб-сервера, который в последствии в паре с закрытым ключом от этого сертификата нужно будет привязать к конфигурации веб-сервера.
Устанавливаем модуль веб-сервера:
По поводу генерации закрытого ключа и сертификата веб-сервера я повторяться не буду, так как подобная процедура рассматривалась ранее, например в заметке Установка сертификата от Windows Server CA на веб-сервер Apache . Предполагая, что у нас уже есть на руках готовые файлы ключа и сертификата в формате PEM размещаем их на нашем Linux-сервере в каталогах /etc/pki/tls/private/ и /etc/pki/tls/certs/ соответственно.
Чтобы привязать файлы ключа и сертификата к конфигурации веб-сервера, отредактируем конфигурационный файл, который появился в системе после установки модуля mod_ssl
В этом файле, как минимум, нам нужно изменить два параметра, указав соответствующие файлы сертификата и его ключа:
В качестве последнего штриха можно внести дополнительные параметры в секцию описывающую доступ к каталогу веб-сервера, включив обязательное использование SSL, например:
После всех проделанных изменений перезапустим службу веб-сервера:
В этой части нашего цикла заметок об Icinga будет рассмотрен пример того, как можно организовать доменную аутентификацию пользователей Active Directory (AD) с поддержкой Kerberos и Single sign-on (SSO) при подключении к веб-консоли Icinga Web 2.
Если мы заглянем в опорный документ Icinga Web 2 Authentication , то узнаем, что веб-консоль Icinga Web 2 способна работать с аутентификаций, основанной на каталоге Active Directory, других реализациях LDAP-каталогов, базах данных MySQL или PostgreSQL, а также делегировать процесс аутентификации непосредственно веб-серверу. Так, как в рассматриваемом нами примере будут использоваться такие вещи, как аутентификация с помощью Kerberos и дополнительная авторизация с помощью PAM, выбран вариант с делегированием процесса аутентификации веб-серверу. При этом процедуры внутренней проверки прав доступа к объектам веб-консоли Icinga Web 2 будут выполняться через специально созданное подключение к AD, как к LDAP-каталогу.
Подготовка инфраструктуры
Предполагаем, что наш сервер с Icinga Web 2 уже присоединён к домену Active Directory с помощью SSSD/realmd и на нём настроен Kerberos-клиент для взаимодействия с доменом: Подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd .
Создадим в домене Active Directory две сервисные учётные записи доменного пользователя. Первую - для подключения и поиска в LDAP-каталоге (например DOM\s-Icinga-Apache-LDAP ), вторую - для Kerberos-аутентификации пользователей, вызываемую веб-сервером Apache (например DOM\s-Icinga-Apache-Krb ).
Для учётной записи DOM\s-Icinga-Apache-Krb необходимо зарегистрировать в домене запись servicePrincipalName (SPN) веб-сервера и сгенерировать keytab-файл, содержащий данную SPN-запись. Повторяться не буду, так как эта процедура пошагово рассмотрена в одной из прошлых заметок (см. пункты «Создание в домене AD сервисной учётной записи» и «Создание keytab-файла для сервисной учётной записи»). Предполагая, что необходимый keytab-файл у нас уже есть, размещаем его в доступном для службы веб-сервера месте и ограничиваем к нему доступ:
Используемая здесь учётная запись www-data - это пользователь по умолчанию, от имени которого запускается служба apache2 в Debian.
Создадим в домене Active Directory группы безопасности, через членство в которых мы будем управлять доступом к Icinga Web 2.
Создаём политику PAM
По аналогии с ранее описанным принципом , создадим в каталоге /etc/pam.d/ файл описания отдельной политики PAM, которая для процедур аутентификации и авторизации будет вызывать библиотеку SSSD:
Наполним файл содержимым:
Первая строка определяет вызов библиотеки SSSD для аутентификации, вторая и третья строки отвечают за авторизацию. Вторая строка добавляет проверку членства в группе для аутентифицированного пользователя. При этом группы для проверки считываются из файла /etc/security/icingaweb2 , который нам нужно создать дополнительно. В этом файле будут перечисляться доменные группы безопасности, которым можно разрешить доступ к веб-консоли Icinga:
Добавляем LDAP-ресурс для авторизации в Icinga Web 2
Подключимся к веб-консоли Icinga Web 2 и добавим новый ресурс, который будет использоваться в качестве подключаемого источника данных. В меню навигации перейдём в Configuration > Application, переключимся на закладку Resources и нажмём Create a New Resource.
В открывшейся справа форме создания нового ресурса заполним все необходимые поля:
- В качестве типа ресурса выберем LDAP;
- Присвоим простое имя ресурсу, например " icingaweb_ldap ";
- В качестве хоста укажем имя контроллера домена AD;
- Тип шифрования и порт - 389 (для незащищённого соединения по протоколу LDAP или защищённого по протоколу StartTLS) либо 636 (для защищённого соединения по протоколу LDAPS);
- Root DN – коневой контейнер или OU в AD, в котором будет производиться поиск объектов (группы и пользователи);
- Bind DN/Password – Имя пользователя (в формате distinguishedName) и пароль, от созданной нами ранее в домене служебной учётной записи DOM\s-Icinga-Apache-LDAP
После того, ка все атрибуты создаваемого ресурса заданы, произведём проверку подключения к LDAP-каталогу с помощью кнопки Validate Configuration.
Это вполне резонно, так как в конфигурации по умолчанию ldap-клиент на нашем сервере Icinga настроен таким образом, что перед установкой защищённого соединения пытается провести проверку подлинности цифрового сертификата, который предоставляет ему контроллер домена AD на начальном этапе соединения. И здесь нам придётся немного отвлечься от Icinga, чтобы решить данную проблему.
Есть 2 варианта решения этой проблемы - неправильный и правильный. Начнём с неправильного, так как он наиболее прост. Решение заключается в отключении механизма проверки сертификатов для SSL/TLS и оно коснётся всех сервисов в системе, которые пользуются услугами ldap-клиента (OpenLDAP), что само по себе не очень правильно и хорошо.
Открываем файл /etc/ldap/ldap.conf , комментируем параметр TLS_CACERT и добавляем строчку TLS_REQCERT never :
Правильный же вариант заключается в том, чтобы добавить на наш сервер Icinga доверенные корневые сертификаты корпоративных доменных Центров сертификации, которыми были выданы сертификаты, используемые нашими контроллерами домена AD. В результате этого ldap-клиент сможет использовать добавленные корневые сертификаты для проверки сертификатов, предоставляемых контроллерами домена Active Directory, когда мы будем к ним подключаться с использованием SSL/TLS в процессе аутентификации и авторизации доменных пользователей на веб-консоли Icinga. Описание этой несложной процедуры можно найти на отдельной Вики-странице: Добавление в Linux корневых сертификатов X.509 локального корпоративного Центра сертификации . Так, как в нашем случае сервер Icinga развёрнут на базе Debian GNU/Linux, нам потребуется создать отдельный файл-бандл, который будет содержать в себе все доверенные сертификаты доменных ЦС и указать этот файл в конфигурации клиента OpenLDAP. Имея на руках все корневые сертификаты доменных ЦС, объединяем их в один файл.
Правим конфигурацию клиента OpenLDAP ( /etc/ldap/ldap.conf ), указав в параметре TLS_CACERT путь к файлу, в который мы только что собрали доверенные корневые сертификаты доменных ЦС. При этом прочие параметры TLS_CA* лучше закомментировать:
После сделанных изменений вернёмся в веб-интерфейс Icinga Web 2 и снова проведём валидацию создаваемого нами LDAP-ресурса:
Как видим, на этот раз соединение с использованием защищённого протокола прошло успешно.
После сохранения, заданная нами через веб-интерфейс конфигурация нового ресурса будет сохранена в файле /etc/icingaweb2/resources.ini
Далее созданный LDAP-ресурс мы будем использовать при создании User Group Backend для авторизации в Icinga Web 2.
Добавляем User Backend для аутентификации в Icinga Web 2
Так как мы хотим использовать преимущества Kerberos и SSO для автоматической аутентификации доменных пользователей при подключении к веб-консоли Icinga Web 2, нам потребуется создать User Backend со специальным типом External, то есть передать управление процедурой аутентификации пользователей непосредственно веб-серверу Apache. Однако если в веб-консоли мы заглянем туда, где создаются объекты типа User Backend (Configuration > Application, закладка Authentication - Create a New User Backend), то увидим, что в текущей версии Icinga Web 2 среди возможных для выбора типов Backend Type нет типа External.
Не знаю почему так, но это вполне разрешимый вопрос, так как в создание внешнего аутентификатора описано в документе 05-Authentication.md
Перейдём на консоль нашего сервера Icinga и добавим руками новую секцию [kerberos] перед секцией [icingaweb2] в конфигурационном файле /etc/icingaweb2/authentication.ini
В параметре backend укажем ключевое слово " external ", а в дополнительном параметре strip_username_regexp укажем регулярное выражение, с помощью которого из имени аутентифицированного пользователя будет отсекаться доменный суффикс.
Теперь вернёмся в веб-консоль Icinga Web 2, обновим страницу, и проверим, что в списке User Backend отображается добавленный нами через конфигурационный файл внешний аутентификатор. Нажмём кнопку Validate Configuration и убедимся в том, что веб-консоль не возвращает ошибок:
Аутентификация в Icinga Web 2 настроена, переходим к настройке авторизации.
Добавляем User Group Backend для авторизации в Icinga Web 2
Теперь создадим в Icinga Web 2 объект типа User Group Backend, который будет использоваться для механизма авторизации (проверки членства аутентифицированного пользователя в группах AD). Перейдём в Configuration > Application, выберем закладка Authentication и нажмём Create a New User Group Backend.
В открывшейся справа форме создания User Group Backend выберем тип ActiveDirectory , укажем понятное нам имя, например " icingaweb2_AD_group ". В поле LDAP Connection из выпадающего списка выберем созданный нами ранее LDAP-ресурс. Поле User Backend оставляем без выбора, так как по условиям нашей задачи используется внешний аутентификатор. Отметим опцию Nested Group Search, чтобы при поиске членства в доменных группах учитывались вложенные группы. Остальные параметры можно оставить предложенные по умолчанию, если конечно нам не требуется дополнительная LDAP-фильтрация, которую можно здесь настроить.
После сохранения созданного User Group Backend, его конфигурация попадёт в файл /etc/icingaweb2/groups.ini , который примет примерно следующий вид:
Параметры авторизации настроены, переходим к проверке.
Проверяем возможность поиска доменных групп
На данном этапе фактическое соединение Icinga Web 2 c AD настроено и теперь мы можем проверить, как работает поиск доменных групп безопасности. Перейдём в веб-консоли в Configuration > Authentication и переключимся на закладку User Groups. Здесь из выпадающего списка выберем ранее созданный User Group Backend и убедимся в том, что поиск групп работает и группа отображает свой состав
Если всё в порядке, то можем приступать к созданию Ролей Icinga Web 2, привязанных к доменным группам безопасности.
Создаём роли с привязкой к доменным группам
Для разграничения прав доступа к объектам веб-консоли Icinga Web 2 используется ролевая модель. Давайте попробуем создать пару Ролей. Для этого перейдём в Configuration > Authentication, и на закладке Roles нажмём Create a New Role.
В открывшейся справа форме добавления Роли, укажем понятное нам имя роли. Предположим, это будет роль Администраторов Icinga с неограниченными правами доступа. В поле Groups укажем имя доменной группы безопасности, которая объединяет администраторов Icinga. В перечне набора прав выберем первую позицию – Allow everything , которая определяет неограниченный доступ.
Создадим соответствующую Роль с привязкой к доменной группе безопасности. В наборе прав доступа Permissions Set на этот раз снимем указатель с верхней позиции, разрешающей всё, и отметим только те вещи, к которым нужно разрешить доступ. А в дополнительных полях фильтрации добавим фильтр по имени Группы Хостов:
По аналогии мы можем создать столько Ролей с привязкой к доменным группам безопасности, сколько потребуется. Создаваемые нами роли будут попадать на сервере Icinga Web 2 в конфигурационный файл /etc/icingaweb2/roles.ini :
Можем считать, что с настройкой авторизации закончили, теперь перейдём к настройке внешней аутентификации пользователей средствами веб-сервера Apache.
Настройка Apache на Kerberos-аутентификацию и PAM авторизацию
По началу для аутентификации в Apache я попробовал вместо модуля auth-kerb использовать модуль auth-gssapi, по аналогии с тем, как это было описано ранее , однако такой вариант в моём окружении не заработал, возможно в силу того, что в репозиториях Debian Jessie модуль auth-gssapi довольно старой версии (1.0.3-2) и эта версия имеет какие-то проблемы. Поэтому в данном примере я буду использовать уже проверенный модуль auth-kerb.
Итак, устанавливаем модули, необходимые веб-серверу Apache в Debian для поддержки Kerberos-аутентификации с дополнительной авторизацией через PAM:
Устанавливаемые модули будут автоматически включены в конфигурацию Apache на заключительном этапе установки. Можно проверить, присутствуют ли среди активированных модулей Apache нужные нам модули:
Отредактируем конфигурационный файл Apache, определяющий конфигурацию веб-узла Icinga Web 2 ( по умолчанию это файл /etc/apache2/conf-available/icingaweb2.conf ), дополнив в нём секцию, где описан доступ к каталогу /usr/share/icingaweb2/public :
Как видно, здесь используется аутентификация Kerberos c ранее приготовленным keytab-файлом и вызовом ранее созданной политики PAM " apache2-icingaweb2 " для авторизации пользователей.
После внесённых изменений перезапустим службы Icinga и Apache:
Теперь попытаемся с клиентского компьютера получить доступ к веб-консоли Icinga Web 2 и процедура аутентификации и авторизации должна пройти для пользователя прозрачно без каких либо запросов на ввод учётных данных.
При желании можно дополнительно оформить свою веб-страницу, которая будет показываться пользователям, не имеющим доступа к веб-консоли Icinga Web 2. Для этого в корневой каталог Apache по умолчанию ( /var/www/html/ ) поместим подготовленную HTML-страничку, например IcingaUnauthorized.html :
Однако практические тесты показали, что адекватно такую страницу пользователям отображает только браузер Mozilla Firefox. Internet Explorer, в свойственной ему манере, показывает собственную страницу ошибки (не говорю уже про чудоковатое требование к тому, что размер кастомной страницы ошибок должен превышать определённый размер в байтах ). А Google Chrome вообще выплёвывает из себя что-то типа ERR_INVALID_RESPONSE . Поэтому, делать страницу ошибки или нет - остаётся делом вкуса.
Защита соединений с веб-сервером с помощью SSL-сертификата
Для этого нам потребуется сделать пару несложных вещей – активировать модуль веб-сервера для поддержки SSL (mod_ssl) и сгенерировать SSL-сертификат веб-сервера, который в последствии в паре с закрытым ключом от этого сертификата нужно будет привязать к конфигурации веб-сервера.
Модуль поддержки SSL в Apache на Debian установлен в конфигурации по умолчанию, поэтому нам остаётся только активировать его (при активации этого модуля будет активирован ряд других вспомогательных модулей):
Убедимся в том, что модуль SSL отображается в списке активированных модулей
По поводу генерации закрытого ключа и сертификата для веб-сервера Apache, опять же, я повторяться не буду, так как подобная процедура рассматривалась ранее, например, в заметке Установка сертификата от Windows Server CA на веб-сервер Apache . Предполагая, что у нас уже есть на руках готовые файлы ключа и сертификата в формате PEM размещаем их на нашем сервере Icinga Web 2 в каталогах /etc/ssl/private/ и /etc/ssl/certs/ соответственно.
После внесённых изменений в конфигурацию Apache, произведём перезапуск службы:
Однако, хочу отметить, что не смотря на полученное удобство аутентификации в таком решении имеется своя "ложка дегтя", хоть и несущественная (при условии нормальной работы Kerberos). Дело в том, что Icinga Web 2 спроектирована таким образом, что в процессе аутентификации пользователя предполагается последовательный перебор подключенных методов аутентификации из ранее упомянутого файла /etc/icingaweb2/authentication.ini . То есть, порядок следования секций в этом файле, описывающих тот или иной аутентификатор прямо влияет на последовательность вызова соответствующих методов аутентификации. Однако, у меня пока не получилось настроить откат на использование встроенной Form-based аутентификации (с использованием локальных учётных записей из базы данных Icinga Web 2) в том случае, если по какой-то причине не отрабатывает внешняя Kerberos аутентификация в Apache. В общем вопрос отката на встроенную аутентификацию пока остался открытым.
Отладка
В процессе настройки конфигурации Icinga Web 2 могут возникнуть ситуации неопределённости, разрешить которые может помочь включение расширенного логирования. Для этого откроем веб-консоль и перейдём в Configuration > Application. Здесь на закладке General мы можем изменить уровень логирования в поле Logging Level и подсмотреть имя лог-файла, в который будет вестись логирование.
Читайте также: