• Ошибка Workflow Manager "The provided signing certificate is invalid according to its expiration claims" в SharePoint 2013. Обновляем Self-Signed сертификат для служб Service Bus и Workflow Manager

    В рассматриваемой ранее процедуре развёртывания Workflow Manager 1.0 для его последующей интеграции в SharePoint Server 2013 нами была использована схема с генерацией само-подписанного сертификата, который используется для веб-сервисов Workflow Manager (WFM) и Service Bus (SB). С тех пор прошло много времени, и наш экземпляр WFM всё это время выполнял свои задачи вполне себе штатно, пока не наступил момент, когда все новые рабочие процессы дружно перестали выполняться.

    Забегая вперёд, можно сказать, что это ещё одна история о том, как отсутствие проактивного мониторинга срока действия важного цифрового сертификата может в перспективе создать трудности, которые потом придётся героически преодолевать.

    Читать далее...

  • Развёртывание и настройка 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-каталогу.

    Читать далее...

  • Развёртывание и настройка oVirt 4.0. Часть 9. Интеграция oVirt с LDAP-каталогом Microsoft Active Directory

    imageВ этой и последующей части серии записей о настройке среды управления виртуализацией oVirt 4.0 будет рассмотрен практический пример интеграции функционала разграничения прав доступа oVirt с внешним LDAP-каталогом на базе домена Microsoft Active Directory. Сначала мы пошагово рассмотрим процедуру настройки профиля интеграции oVirt c LDAP-каталогом, а затем, в отдельной заметке, рассмотрим настройку автоматической аутентификации пользователей на веб-порталах oVirt, настроив Single sign-on (SSO) на базе протокола Kerberos. Читать далее...

  • Развёртывание и настройка oVirt 4.0. Часть 2. Замена сертификата веб-сервера oVirt Engine

    imageПосле развёртывания oVirt Engine, при попытке подключения к веб-порталам oVirt мы каждый раз будем получать предупреждение системы безопасности веб-браузера о том, что веб-узел имеет сертификат, которому нет доверия. Это происходит из-за того, что на веб-узле oVirt используется сертификат выданный локальным Центром сертификации (ЦС), который был развёрнут в ходе установки oVirt Engine. Для того, чтобы избавиться от этих предупреждений, а также для того чтобы веб-браузер корректно работал со всеми функциями, доступными на веб-порталах oVirt, нам потребуется сделать так, чтобы веб-браузер доверял SSL сертификату веб-сервера oVirt. Решить этот вопрос можно двумя способами.

    Читать далее...

  • Автоматическое обновление хранилища сертификатов доверенных корневых центров сертификации на компьютерах Windows не имеющих прямого доступа в Интернет.

    imageРанее уже приходилось сталкиваться с проблемой невозможности корректного развёртывания ПО из-за того, что на целевых компьютерах с OC Windows не обновляется хранилище сертификатов доверенных корневых центров сертификации (далее для краткости будем называет это хранилище TrustedRootCA). На тот момент вопрос был снят с помощью развёртывания пакета rootsupd.exe, доступного в статье KB931125, которая относилась к ОС Windows XP. Теперь же эта ОС полностью снята с поддержки Microsoft, и возможно, поэтому данная KB-статья более недоступна на сайте Microsoft. Ко всему этому можно добавить то, что уже даже на тот момент времени решение с развёртыванием уже устаревшего в ту пору пакета сертификатов было не самым оптимальным, так как тогда в ходу были системы с ОС Windows Vista и Windows 7, в которых уже присутствовал новый механизм автоматического обновления хранилища сертификатов TrustedRootCA. Вот одна из старых статей о Windows Vista, описывающих некоторые аспекты работы такого механизма - Certificate Support and Resulting Internet Communication in Windows Vista. Недавно я снова столкнулся с исходной проблемой необходимости обновления хранилища сертификатов TrustedRootCA на некоторой массе клиентских компьютеров и серверов на базе Windows. Все эти компьютеры не имеют прямого доступа в Интернет и поэтому механизм автоматического обновления сертификатов не выполняет свою задачу так, как хотелось бы. Вариант с открытием всем компьютерам прямого доступа в Интернет, пускай даже на определённые адреса, изначально рассматривался как крайний, а поиски более приемлемого решения привел меня к статье Configure Trusted Roots and Disallowed Certificates (RU), которая сразу дала ответы на все мои вопросы. Ну и, в общем то, по мотивам этой статьи, в данной заметке я кратко изложу на конкретном примере то, каким образом можно централизованно перенастроить на компьютерах Windows Vista и выше этот самый механизм авто-обновления хранилища сертификатов TrustedRootCA, чтобы он использовал в качестве источника обновлений файловый ресурс или веб-сайт в локальной корпоративной сети.

    Читать далее...

  • WSUS Troubleshooting: WebException: Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS. ---> System.Security.Authentication.AuthenticationException

    При поднятии роли WSUS на только что установленном сервере Windows Server 2008 столкнулся с проблемой при попытке синхронизации с Microsoft:

    WebException: Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS. ---> System.Security.Authentication.AuthenticationException: Удаленный сертификат недействителен согласно результатам проверки подлинности.

    Изучил лог клиента который напрямую обращается на MS WSUS (c:WindowsWindowsUpdate.log) и обнаружил что клиент обращается на узел https://update.microsoft.com.

    Решив воспроизвести ситуацию вручную, открыл этот узел в IE - и посмотрел свойства сертификата.
    Цепочка сетификатов ведёт к корневому сертификату ЦС - GTE CyberTrust Global Root
    Открыл на своем WSUS сервере остнастку certmgr.msc и выполнив поиск обнаружил что у меня нет такого корневого сертификата...

    Пришлось скачать отсюда http://support.microsoft.com/default.aspx/kb/931125 файл rootsupd.exe...далее, по причине того, что этот пакет предназанчен только для WinXP (по крайней мере в Win2008 он просто не запускался) - пришлось распаковать и оттуда открыть файл сauthroots.sst
    В нём то и оказался нужный мне сертификат КЦС - GTE CyberTrust Global Root..Импортировал этот сертификат через Мастер импорта сертификатов в хранилище Доверенные корневые центры сертификации (в хранилище Локальный компьютер)
    ...
    Открываю остнастку WSUS, запускаю синхронизацию с MS WSUS... синхронизация заработала