Troubleshooting SSOv1

Вот и моя очередь настала написать о полученных с SSO граблях. Ранее об этом уже писал Виктор.

Итак, на исходной – перестал работать доменный вход в vCenter 5.1. Попытка узнать, насколько глубока кроличья нора, привела меня под кат 🙂

Толстый клиент выдавал “A general system error occured: Authorize Exception”:

Тонкий ругался более витиевато – “The authentication server returned an unexpected error: ns0:RequestFailed: Failed to connect to the identity source…”:

Попытки поиска решения в гугле привели меня к этой статье: vCenter Server login fails with the error: A general system error occurred: Authorize Exception (1015639).

А причины такого поведения:

• отключение vCenter от домена;
• неправильно настроенный источник SSO.

Опытным путем было выяснено, что vCenter от домена не отключен, так как по RDP сервер пускает, да и в самом vCenter (если зайти под локальным админом) авторизация членам домена выдана. Значит, нам дорога к SSO.

Попытка зайти под стандартным пользователем SSO выдала другую замечательную ошибку:

Поиски решения по сбросу пароля этой учетной записи, привели меня сюда: Resetting an expired password in vCenter Single Sign-On (SSO) (2035864).

Закономерный результат:

Опытным путем было выяснено, что переменную JAVA_HOME необходимо настроить немного не так, как в статье. Почему-то отличался путь. Переменную исправил, после чего получил другую ошибку 🙂

Повторное гугление привело меня к тому, что можно изменить срок хранения пароля (отсюда) в базе SSO. Соответственно, открываем в SQL Management Studio нашу базу (у меня она называлась RSA), открываем на редактирование таблицу dbo.IMS_AUTHN_PASSWORD_POLICY (Edit Top 200 Rows) и редактируем столбец MAX_LIFE_SEC (вместо 31536000 я установил значение 61536000). В таблице всего две строки, с значением в столбце MAX_LIFE_SEC только одна из них – так что не промахнетесь.

После этого я смог зайти в веб-клиент и посмотреть на свои источники SSO.

Ёкарный бабай. Этот идиотизм использовал подключение к домену с использованием всего двух контроллеров домена. Соответственно, последовательный демонтаж обоих накрыл работу механизма медным тазом.

Попытка изменить контроллеры успехом не увенчалась – выдавался невнятный мат без сохранения изменений. В результате, вооружившись Configuring a vCenter Single Sign-On 5.1 Identity Source using LDAP with SSL (LDAPS) (2041378), я решил удалить источник и создать его заново.

Перед использованием такого варианта необходимо выгрузить сертификат сервера с помощью оснастки MMC.

Экспортировать нужно сертификат сервера, идентичный названию самого сервера, причем в формате Base-64. Закрытый ключ не экспортируется.

Судя по комментарию Кузнецова Александра, да и по внимательному прочтению статьи становится ясно, что экспорту подлежит сертификат контроллера домена. Читайте KB внимательнее!

Мой вариант действий прокатил потому, что мои контроллеры домена не изменили свои сертификаты.

Сразу скажу, что у меня добавленный источник не заработал. Поэтому привожу свою последовательность действий, приведших к успеху:

1. Сначала я добавил источник с подключением по LDAP и указанием логина/пароля;
2. Затем проверил подключение, сохранил источник и изменил тип аутентификации на Reuse Session;
3. А уже после этого настроил подключение через ldaps://dc#.domain:3269 и указал сертификат

А вообще, вся эта развлекуха привела меня к списку основных статей KB по SSO.

Побочным эффектом явилось то, что слетели все разрешения, выданные на инфраструктуру vCenter.