Разные службы и приложения, работающие в Linux и использующие аутентификацию Kerberos, например в связке с контроллерами домена Active Directory (AD), используют для механизмов этой самой аутентификации специальный keytab-файл, который содержит хеши пароля доменной учётной записи пользователя, с которым ассоциирована та или иная служба в Linux-системе (как с Kerberos Principal). И вполне типичной и распространённой практикой является создание отдельного keytab-файла для каждого принципала Kerberos. То есть, как правило, прослеживается такая логика: отдельная учётная запись служебного пользователя в AD, для которого зарегистрировано конкретное имя службы ServicePrincipalName (SPN) => отдельный keytab-файл, сопоставимый с записью SPN в AD.
-
Создание keytab-файла, содержащего несколько разных Kerberos Principal
-
Разграничение прав доступа к Linux-системе и её сервисам через доменные группы безопасности с помощью SSSD и PAM
Когда мы рассматривали настройку SSSD на Debian 8 (Jessie), немного упоминали о возможности ограничения доступа к Linux-системе через группы безопасности в домене Active Directory. Однако рассматриваемый в том случае пример предполагает безусловное глобальное ограничение доступа на уровне всей Linux-системы. То есть, указанная в секции описания домена конфигурационного файла sssd.conf опция simple_allow_groups ограничивает доступ не только для входа в систему, но и для всех других служб внутри этой системы, которые будут использовать возможности SSSD. Таким образом, рассмотренный ранее пример настройки авторизации с помощью SSSD в Apache точно также, как и другие сервисы, использующие SSSD, будет ограничен глобальной опцией simple_allow_groups. Но как же быть, если доступ к Linux-системе и её отдельным сервисам требует гранулированной настройки? Например, требуется, чтобы право локального и/или удалённого входа в систему имели члены одной доменной группы безопасности, а право доступа к какому-то сайту веб-сервера Apache (или даже отдельному веб-каталогу) имели члены другой группы безопасности домена Active Directory. Попробуем решить эту задачу с помощью настройки механизма подключаемых модулей аутентификации - Pluggable Authentication Modules (PAM), а конкретнее с помощью использования возможностей библиотеки pam_listfile.so.
-
Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 7. Переопределение аргументов выполнения Команд в Icinga Director 1.3 (на примере стандартного плагина check_http)
Прошлую заметку про основные приёмы использования Icinga Director мы закончили на том, что после создания Служб из базового набора Команд Icinga, автоматически импортированных в Icinga Director, можно столкнуться с ситуацией, когда стандартные настройки Команд приводят к не совсем ожидаемому результату. Например, используемые по умолчанию аргументы Команды http приводят к переводу созданной нами Службы http в состояние WARNINIG для некоторых клиентов Icinga, хотя на самом деле веб-сервер на этих системах работает штатно. Попробуем разобраться с тем, почему так происходит, и как в Icinga Director 1.3 можно решить этот вопрос.
-
Разворачиваем сеть тонких клиентов Thinstation с подключением к серверу Windows Server 2012 R2 Remote Desktop Services
Рассмотрим пример организации выделенной сети тонких клиентов, подключающихся по протоколу RDP к центральному серверу служб удалённых рабочих столов Microsoft Windows Server (Remote Desktop Services). В качестве ОС тонкого клиента будем использовать свободно распространяемую среду Thinstation из проекта Thinstation by Donald A. Cupp Jr., в составе которой присутствует RDP-клиент FreeRDP. Читать далее...
-
Заливаем прошивку AOS 3.9.2 в контроллер APC NMC AP9618 для поддержки TLS 1.0
В очередной раз мне в руки попалась пара старых контроллеров первого поколения APC UPS Network Management Card (NMC1) AP9618, которые потребовалось настроить для удалённого управления и мониторинга ИБП серии APC Smart-UPS. И в очередной раз столкнулся с проблемой настройки повышения уровня безопасности доступа к этим контроллерам. После обновления до последней имеющейся на сайте APC для этих контроллеров версии Firmware AOS 3.7.3 / SUMX 3.7.2 и включения поддержки HTTPS, я не смог получить доступ по протоколу HTTPS к такому контроллеру ни из одного из современных браузеров.
-
Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 2. Установка Icinga Web 2
В прошлый раз мы выполнили установку ядра Icinga 2 на Debian 8.6. В этой части будет рассмотрена процедура установки веб фронт-энда для нашего сервера Icinga 2 - современного модульного веб-интерфейса Icinga Web 2.
-
Настройка Kerberos аутентификации с SSO на веб-сервере Apache с помощью SSSD
В прошлой заметке был рассмотрен пример простейшего ограничения доступа к веб-серверу 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.
-
Развёртывание и настройка oVirt 4.0. Часть 10. Настройка Single sign-on (SSO) на базе Kerberos для упрощения аутентификации на веб-порталах oVirt
В этом части описания мы продолжим тему интеграции oVirt 4.0 с внешним LDAP-каталогом на базе домена Microsoft Active Directory (AD) и поговорим о настройке механизма Single sign-on (SSO) средствами протокола Kerberos для веб-сервера Apache с целью облегчения процедуры аутентификации пользователей при входе на веб-порталы oVirt. Читать далее...
-
Развёртывание и настройка oVirt 4.0. Часть 2. Замена сертификата веб-сервера oVirt Engine
После развёртывания oVirt Engine, при попытке подключения к веб-порталам oVirt мы каждый раз будем получать предупреждение системы безопасности веб-браузера о том, что веб-узел имеет сертификат, которому нет доверия. Это происходит из-за того, что на веб-узле oVirt используется сертификат выданный локальным Центром сертификации (ЦС), который был развёрнут в ходе установки oVirt Engine. Для того, чтобы избавиться от этих предупреждений, а также для того чтобы веб-браузер корректно работал со всеми функциями, доступными на веб-порталах oVirt, нам потребуется сделать так, чтобы веб-браузер доверял SSL сертификату веб-сервера oVirt. Решить этот вопрос можно двумя способами.