Собрание заметок об информационных технологиях
После установки актуальной версии программной дедупликации QUADStor Storage Virtualization 3.2.13 на только что развёрнутой системе Debian GNU/Linux 9 (Stretch) столкнулся с проблемой работы службы quadstor.service. Фактически служба запускалась, но работала некорректно, так как не давала возможности управлять никакими настройками дедупликации. Выяснилось, что проблема связана с функционированием PostgreSQL.
В этой маленькой заметке мы снова поговорим о древностях. На этот раз речь пойдёт о "бородатом" контроллере управления IBM Remote Supervisor Adapter II Refresh 1, у которого имеется функция удалённого доступа к консоли сервера через механизм Remote Control. В старо-древние глиняные времена на Windows-системе с Internet Explorer и предустановленной Java Runtime Environment (JRE) особых проблем с использованием этой функции у меня не возникало. С тех пор прошло немало времени, и вот мне снова потребовалось воспользоваться функцией Remote Control с клиентской машины на базе ОС Windows 10 c актуальной версией Internet Explorer 11 и предустановленной в эту систему Java 8. Оказалось, что это задача не тривиальна, и для получения желаемого результата в такой клиентской системе, как у меня, потребуется выполнить ряд манипуляций.
System Security Services Daemon (SSSD) – это пакет приложений для управления аутентификацией и авторизацией в операционных системах на базе Linux. SSSD является отличной альтернативой монструозной Samba, позволяя подключить Linux машину к уже имеющемуся домену Active Directory.
Большинство статей в интернет, описывающих использование SSSD для подключения к Active Directory, ставят перед собой задачу показать, насколько это легко и непринужденно. Зачастую, это очень короткие "истории успеха", в которых берется SSSD и Realmd, вводится пара команд, и все! Авторизация настроена.
Спорить тут не с чем, так оно и есть. Но при этом надо держать в уме, что SSSD – это довольно сложный программный продукт, взаимодействующий с целым рядом отдельных подсистем хоста. В этой статье мне бы хотелось остановиться на некоторых нюансах настройки SSSD в Debian GNU/Linux и дать несколько полезных советов по его использованию в боевых условиях.
В Октябре был выпущен ряд обновлений, относящихся к категории обновлений безопасности Windows, установка которых может вызвать ошибки в приложениях, использующих программный интерфейс устаревшего Поставщика OLE DB для Jet (Microsoft.Jet.OLEDB.4.0), например, при попытке программного доступа в Microsoft Office Excel или Access версии 2007 и более старых версий Office или сторонних приложений, таких как 1С, самописных АРМ-ов и т.п., использующих данный интерфейс.
Опубликовав последнюю заметку об Icinga, я решил поискать в русскоязычном сегменте Интернета последние материалы по теме Icinga и попал на сайт, который уже как-то ранее мне попадался на глаза (ссылку на сайт не привожу намеренно, хотя дальше всё итак будет понятно). Попытавшись просмотреть последние заметки на этом сайте, я обратил внимание на появившуюся через несколько минут звуковую индикацию материнской платы моего компьютера, характерную для ситуаций с перегревом процессора. Это меня несколько смутило, ибо, как я думал, ничего ресурсоёмкого в моей пользовательской сессии в этот момент не выполнялось. Читать далее...
После базовой настройки мониторинга сетевых устройств (Хостов) по протоколу SNMP в Icinga Director, может возникнуть желание как-то расширить объём информации, хранящейся в Icinga об этих самых Хостах. Например, у тех же модулей управления ИБП в интерфейсе Icinga Web 2 хочется видеть серийные номера устройств, версии прошивок firmware и т.п.. Учитывая то, что в нашем случае в Icinga уже есть базовая информация, необходимая для того, чтобы подключаться к Хостам по протоколу SNMP, возникла идея как-то автоматизировать процесс сбора дополнительных данных о Хосте, используя этот самый протокол SNMP.
Представим себе ситуацию, что есть некий сервер на базе 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.
Внимание. Если в вашей инфраструктуре компьютеры c Windows 10 включены в домен Active Directory и при этом на компьютерах используется программный пакет КриптоПро CSP версий 3.9 и 4.0 c хранением ключей в системном реестре Windows, то стоит воздержаться от развёртывания свежего Октябрьского обновления Windows 10 Fall Creators Update (версия 1709), так как данное обновление способно нарушить работу с ключами КриптоПро для непривилегированных пользователей. Об этом недавно было объявлено на сайте ООО "Крипто-Про": Проблемы доступа к ключам КриптоПро CSP в случае обновления до Windows 10 Fall Creators Update.
Учитывая характер описанной проблемы, нельзя исключать, что сложности могут возникнуть и с другим программным обеспечением, которое хранит данные пользователя в системном реестре и имеет при этом явно настроенные разрешения на ключи реестра пользователя.
Внимание. Октябрьские обновления для Windows 10 v1703 (KB4041676), Windows 10 v1607 (KB4041691) и Windows Server 2016 (KB4041691), которые ранее были загружены в локальные хранилища WSUS и SCCM SUP, способны вывести из строя целевые ОС, сделав невозможной загрузку ОС, выполненную после установки обозначенных обновлений.
Сообщения о проблемах начали появляться пару дней назад, и на данный момент уже опубликована статья, описывающая ситуации, при которых возможно столкнуться с проблемой и известные методы её решения для тех, кто уже "приплыл": Windows devices may fail to boot after installing October 10 version of KB4041676 or KB4041691 that contained a publishing issue
Для обхода проблемы с данным обновлением рекомендуем выполнить повторную синхронизацию метаданных и контента Ваших локальных хранилищ обновлений в WSUS и SCCM SUP, после чего выполнить тестирование развёртывания данных обновлений.
На днях получил по электронной почте интересный комментарий к статье про подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd от одного из наших читателей - Степана Кохановского. В силу того, что данный комментарий объёмен и описывает некоторое обходное решение известной проблемы, я решил опубликовать его в виде отдельного поста.
Можешь подсказать, как поставить Виндовс сервер 2012
Особенность восстановления хранилища из локального ресурса в том, что не важно, включен или выключен wuauserv. Специально подготовленный локальный ресурс можно…
RSS - Записи
Последние комментарии