С тех пор, как мы в одной из прошлых заметок рассматривали процесс развёртывания HP Product Bulletin, прошло немало времени. За это время продукт успел побывать в фазе активной поддержки, после чего был "заморожен" со стороны HP и его обновления какое-то время не выпускались, затем уже в HPE провели его ребрендинг и снова вернули к жизни. Поэтому для тех, кто активно работает с оборудованием HP/HPE, на сегодняшний день этот продукт может быть всё ещё полезен. В этой заметке мы сделаем акцент на то, как развернуть актуальную версию HPE Product Bulletin Gateway таким образом, чтобы она выполнялась в контексте сервисной учётной записи Group Managed Service Account (gMSA).
-
Запуск HPE Product Bulletin Gateway в контексте учётной записи gMSA
-
Исправляем имя доменной группы в SharePoint 2013 после переименования в Active Directory
В SharePoint Server 2013 есть проблема, которая тянется с предыдущих версий SharePoint. Суть её заключается в том, что информация о той или иной доменной группе безопасности, единожды попав в SharePoint из каталога Active Directory, не обновляется в SharePoint в дальнейшем. И если в последствии в Active Directory группа безопасности будет переименована, то получится так, что на всех веб-узлах SharePoint эта группа останется со старым именем, что в некоторых ситуациях может привести к путанице. В этой заметке мы рассмотрим действия, которые можно предпринять на стороне SharePoint Server для актуализации информации об именах групп безопасности. -
Январские обновления безопасности Microsoft Windows Server 2012 R2/2016 вызывают ошибку 0x80071128 "The data present in the reparse point buffer is invalid" при редактировании некоторых групповых политик
Поведение вендоров ПО после публичного раскрытия информации об уязвимостях в процессорах Intel напоминало беспорядочную "стрельбу стоя с лошади из окопа", поэтому мы решили повременить с развёртыванием всех последних "чудо-патчей". По этой причине у нас в продуктивной среде ещё не развёрнуты Январские обновления для Windows Server, и с проблемой о которой пойдёт дальше речь, мы не столкнулись. Однако, возможно, информация будет полезна тем, кто собирается разворачивать эти обновления или уже развернул их и получил "нежелательный эффект". Информация по теме поступила от одного из наших коллег - Евгения Сидорова. Далее привожу его письмо. -
Рекомендации по настройке SSSD в Debian GNU/Linux
System Security Services Daemon (SSSD) – это пакет приложений для управления аутентификацией и авторизацией в операционных системах на базе Linux. SSSD является отличной альтернативой монструозной Samba, позволяя подключить Linux машину к уже имеющемуся домену Active Directory.Большинство статей в интернет, описывающих использование SSSD для подключения к Active Directory, ставят перед собой задачу показать, насколько это легко и непринужденно. Зачастую, это очень короткие "истории успеха", в которых берется SSSD и Realmd, вводится пара команд, и все! Авторизация настроена.
Спорить тут не с чем, так оно и есть. Но при этом надо держать в уме, что SSSD – это довольно сложный программный продукт, взаимодействующий с целым рядом отдельных подсистем хоста. В этой статье мне бы хотелось остановиться на некоторых нюансах настройки SSSD в Debian GNU/Linux и дать несколько полезных советов по его использованию в боевых условиях.
-
Добавление SPN записей в keytab-файл (на стороне сервера Linux с помощью утилиты ktutil), связанный с учётной записью Computer в домене Active Directory
Представим себе ситуацию, что есть некий сервер на базе 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. -
Обходное решение для ошибки регистрации servicePrincipalName (ATT_OR_VALUE_EXISTS) при подключении Debian GNU/Linux Jessie к домену Active Directory с помощью realm join
На днях получил по электронной почте интересный комментарий к статье про подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd от одного из наших читателей - Степана Кохановского. В силу того, что данный комментарий объёмен и описывает некоторое обходное решение известной проблемы, я решил опубликовать его в виде отдельного поста. -
Получаем право SeDebugPrivilege для успешной установки Microsoft SQL Server 2012 при ограниченной доменной политике "Debug programs"
В свете недавних событий с повышением вирусной активности многие организации стали уделять больше внимания вопросам всестороннего усиления мер безопасности в собственных ИТ-инфраструктурах. При этом некоторые из применяемых мер могут создать дополнительные сложности в работе самих ИТ-специалистов. -
Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 10. Аутентификация и авторизация пользователей Active Directory в Icinga Web 2 (Kerberos и SSO)
В этой части нашего цикла заметок об 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-каталогу.
-
Создание keytab-файла, содержащего несколько разных Kerberos Principal
Разные службы и приложения, работающие в Linux и использующие аутентификацию Kerberos, например в связке с контроллерами домена Active Directory (AD), используют для механизмов этой самой аутентификации специальный keytab-файл, который содержит хеши пароля доменной учётной записи пользователя, с которым ассоциирована та или иная служба в Linux-системе (как с Kerberos Principal). И вполне типичной и распространённой практикой является создание отдельного keytab-файла для каждого принципала Kerberos. То есть, как правило, прослеживается такая логика: отдельная учётная запись служебного пользователя в AD, для которого зарегистрировано конкретное имя службы ServicePrincipalName (SPN) => отдельный keytab-файл, сопоставимый с записью SPN в AD. -
Разграничение прав доступа к 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.
