Собрание заметок об информационных технологиях
В этой заключительной части нашего плана развёртывания Icinga на Debian GNU/Linux 12 "Bookworm" мы коротко обозначим основные моменты конфигурации веб-сервера Apache для интеграции Icinga Web 2 со службой каталогов Microsoft Active Directory, опираясь на более подробный материал, изложенный ранее в статье "Аутентификация и авторизация пользователей Active Directory в Icinga Web 2 (Kerberos и SSO)".
В ходе тестирования аутентификации RADIUS на платах управления ИБП ПСУ Спутник, обнаружили одну интересную проблему. У одного из проверяемых пользователей не отрабатывала аутентификация при том, что у других подопытных пользователей данной проблемы не наблюдалось. После допроса пользователя с пристрастием выяснилось, что его текущий доменный пароль содержит кириллицу. Так как предметом нашего исследования был функционал ПСУ Спутник, мы предположили, что источником проблемы может быть реализация RADIUS в ПСУ. Специалисты тех.поддержки Инматикс уверили нас в том, что проблема не в ПСУ. Для проверки мы попробовали настроить аутентификацию RADIUS на плате APC NMC2 и там проблема воспроизвелась. Таким образом мы пришли к выводу, что сам используемый в нашем случае RADIUS сервер из роли NPS в составе Windows Server 2016 не обрабатывает корректно пароли с кириллицей.
В этой статье мы рассмотрим примеры базовой настройки протокола аутентификации Kerberos для пула приложений IIS v10 на сервере с ОС Windows Server 2022. При этом мы отдельно поговорим о разных вариантах настройки в зависимости от типа учётной записи, в контексте которой выполняется пул приложений IIS. Кроме того, попробуем рассмотреть задачу подключения к веб-сервису IIS (фронтенд) стороннего файлового ресурса (бэкенд) и делегирования аутентификации пользователей от фронтенда к бэкенду.
Имеется сервер на базе ОС Windows Server 2012 R2 с несколькими экземплярами СУБД Firebird 2.5, выполняющимися в режиме службы Windows от имени разных учётных записей Group Managed Service Account (gMSA). Для некоторых баз данных (БД), выполняемых в экземпляре Firebird, необходимо настроить периодическое резервное копирование. При этом к разным БД выдвигаются разные требования по срокам хранения количества последних полных резервных копий. В этой заметке мы рассмотрим вариант решения поставленной задачи с помощью PowerShell и штатных инструментов Firebird. Читать далее...
При использовании удалённого подключения к операционным системам Microsoft Windows/Windows Server по протоколу RDP в некоторых случаях может возникать потребность в смене пароля учётной записи пользователя. При этом инициатором смены пароля в разных ситуациях может выступать как сам пользователь, так и администратор Windows-системы. В некоторых сценариях может получиться так, что, казалось бы, несложная задача смены пароля может стать не такой уж и простой. Поэтому в данной записи я попробую собрать информацию о самых разнообразных способах смены пароля учётной записи пользователя в RDP-сессии.
Представим себе ситуацию, что есть некий сервер на базе Debian GNU/Linux, который уже введён в домен Active Directory с помощью SSSD и realmd и на нём уже имеется keytab-файл, который используется для механизмов аутентификации Kerberos и Single sign-on (SSO) при подключении к серверу по протоколу SSH. И вот возникает необходимость на данном Linux-сервере дополнительно настроить роль веб-сервера для служебных администраторских задач и организовать Kerberos SSO при подключении к веб-узлам этого веб-сервера. По ранее описанным примерам (здесь, здесь и здесь), предполагается, что для целей Kerberos-аутентификации веб-сервера Apache в домене Active Directory (AD) создаётся отдельная сервисная учётная запись типа User, для которой генерируется keytab-файл и в последствии привязывается к настройкам Apache на стороне Linux-сервера. С точки зрения аспектов безопасности такой поход (отдельный Linux-сервис = отдельная учётная запись в AD со своим keytab-файлом) можно считать вполне правильным. Но что, если Linux-сервис, использующий Kerberos-аутентификацию, используется не широким кругом пользователей, а исключительно для административных целей парой-тройкой системных администраторов? В таком случае создание отдельной учётной записи типа User в домене со своим keytab-файлом может показаться избыточным. В этой заметке мы рассмотрим пример того, как добавить дополнительную нужную нам запись servicePrincipalName (SPN) (на примере SPN-записи типа HTTP/) в уже имеющийся на Linux-сервере keytab-файл, ориентированный на сам хост (содержащий SPN-записи типа HOST/). В результате мы получим Kerberos аутентификацию на веб-узлах нашего Linux-сервера и при этом не будем плодить в домене лишние сервисные учётные записи типа User.
В развёрнутой ранее конфигурации Icinga Web 2 по умолчанию отсутствует возможность просматривать исторические графики изменения показателей производительности объектов мониторинга. Однако фронтенд Icinga Web 2 имеет модуль расширения, который позволяет получать данные из Graphite. В этой заметке мы рассмотрим пример интеграции Graphite в Icinga Web 2.
В этой части нашего цикла заметок об 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-каталогу.
Разные службы и приложения, работающие в Linux и использующие аутентификацию Kerberos, например в связке с контроллерами домена Active Directory (AD), используют для механизмов этой самой аутентификации специальный keytab-файл, который содержит хеши пароля доменной учётной записи пользователя, с которым ассоциирована та или иная служба в Linux-системе (как с Kerberos Principal). И вполне типичной и распространённой практикой является создание отдельного keytab-файла для каждого принципала Kerberos. То есть, как правило, прослеживается такая логика: отдельная учётная запись служебного пользователя в AD, для которого зарегистрировано конкретное имя службы ServicePrincipalName (SPN) => отдельный keytab-файл, сопоставимый с записью SPN в AD.
Когда мы рассматривали настройку 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.
печально, у меня такая проблема на 2016. и во многих источниках писали что все решено в 2022
В данном случае это непринципиальный вопрос. Утилита обновления микрокода не предъявляет претензий к версии драйвера.
RSS - Записи
Последние комментарии