Troubleshooting SSOv1

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

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

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

sso1

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

sso2

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

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

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

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

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

sso3

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

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

sso4

Опытным путем было выяснено, что переменную 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.

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

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

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

sso6

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

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

sso8

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

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

Запись опубликована в рубрике 5.1, VMware, vSphere с метками . Добавьте в закладки постоянную ссылку.

3 комментария: Troubleshooting SSOv1

  1. Александр говорит:

    а мне помог прсото ребут сервера.

  2. Александр говорит:

    В пятницу была такая же проблема. Симптомы один в один, только мы контроллеры не трогали. Так как я грешил на SSO, то обновил до 5.1.0c — не помогло. При изменении типа подключения в источнике с ldaps на ldap , «Test connection» проходил. После анализа сетевого трафика, увидел, что vCenter отправляет сообщение «Unknown Certificate» в ответ на SSL Hello.
    Администратор AD признался, что сменил сертификаты на DC. Не смотря на то, что новый сертификат на vCenter распространился через GPO и был в доверенных, согласно статье KB2041378 я вгрузил этот сертификат в key store SSO. После этого всё заработало.

  3. Alex говорит:

    И так себя ведёт лучшее решение в отрасли! Охренительный продукт.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *