SC VMM 2012 R2, Distributed Key Management и Error 635

В несвойственном для себя амплуа выступаю я сегодня. System Center Virtual Machine Manager 2012 R2. Да.

А все потому, что бросил меня один нехороший человек (шучу, хороший он, отличный даже, просто пошел дальше развиваться, а я остался досиживать в болоте положенный по договору срок) и оставил в наследство приличное хозяйство с гордым названием СИЧО (Службы Инфраструктуры Частного Облака, ГОСТ34 привееет!). И теперь волей-неволей приходится заниматься подсистемой виртуализации и управления ей.

Но речь пойдет о более другом заказчике и его инсталляции VMM.

Раздался звонок и голос, близкий к паническому, сказал, что «Этот ваш VMM вообще не работает со вчерашнего дня! Вообще! Весь! Ничего не работает вообще!». Я зашел посмотреть и увидел следующие симптомы:

  1. Консоль VMM запускается и работает, что уже вселяет надежду.
  2. Все VM в консоли красные с крестиками, в статусе Missing.
  3. Все хосты виртуализации в консоли красные с крестиками в статусе Host not responding.
  4. При попытке выполнить Refresh получаю сообщение о том, что недостаточно прав на хосте у учетной записи, проверьте бла-бла (на самом деле ошибка коряво описывает ситуацию. Не прав недостаточно, а учетная запись НЕ МОЖЕТ ПОЛУЧИТЬ ДОСТУП к хосту).
  5. Учетная запись, которая имеет права Hyper-V Host Administrator (от имени которой выполняются все операции на хостах виртуализации) в состоянии locked out и попытка ее разблокировки безуспешна, она моментально блокируется обратно.
  6. При попытке смены пароля в RunAs account вылетает пресловутая Error 635, говорящая о том, что не получается сохранить пароль в безопасном варианте на этой машине. В оригинале звучит так:

    «Virtual Machine Manager is unable to securely store the password information on this machine. Ensure that the Microsoft Cryptographic Service has been installed on the VMM management server and try the operation again.»

  7. На контроллере домена видно, что учетная запись, используемая для Hyper-V Host Administrator RunAs Account стучится примерно 6 раз в секунду с неправильным паролем и, что закономерно, блокируется.

Собственно все. Давайте чинить J

Часть действий по диагностике я описал в разделе «Симптомы», часть выполнил далее:

  1. Ни один RunAs account не работает для выполнения своих обязанностей. Например, аккаунт, который должен управлять хостами виртуализации через интерфейс iLO (да-да, используется продукция фирмы Hewlett-Packard), или аккаунт для управления СХД, или сетевыми устройствами. Ни один.
  2. На контроллере домена появляются ошибки Audit Failure, сообщающие о попытке входа под этими аккаунтами, но с неправильным паролем.
  3. Замена пароля, как я уже говорил, вылетает с ошибкой 635, создание нового RunAs Account вылетает ровно с такой же ошибкой.

Итак, в чем же причина? А причина в том, что это высокодоступная (high-availability) инсталляция VMM. А для такого сценария обязательно использование DKM (Distributed Key Management).

Что такое Distributed Key Management? А это хранение криптографических ключе в месте, доступном для всех участников спектакля. В нашем случае узлы VMM должны иметь доступ к этим самым ключам, даже если один из узлов по каким-то причинам вылетел. Команда SC VMM придумала замечательное решение – хранить эти ключи в Active Directory. Для этого рекомендуется создать контейнер и указать путь к нему на этапе установки сервера VMM. Примерно вот так: https://technet.microsoft.com/en-us/library/gg697604(v=sc.12).aspx

Для чего вообще нужны эти самые ключи? А дело в том, что есть такое понятие, как sensitive data. К ним относятся пароли RunAs Accounts в том числе. Т.е. они хранятся, как и все в VMM, в соответствующей базе данных в SQL Server, но вот доступ к ним можно получить, только предварительно расшифровав таким вот криптографическим ключом. В сценарии, когда вы используете один сервер VMM ключи могут запросто храниться на самом сервере (кому интересны кишочки – вам сюда https://msdn.microsoft.com/en-us/library/windows/desktop/bb204778%28v=vs.85%29.aspx). А вот для сценариев с высокой доступностью этот вариант не подходит, т.к. при падении активного узла, на котором, вы, предположим, создали новый RunAs Account и зашифровали sensitive data ключом, хранящимся на этом же сервере, доступ к этим данным получить не получится. Вот тут и приходит на выручку DKM. Ключи хранятся в специальном контейнере и при переходе роли VMM Server с ноды на ноду доступ к ним сохраняется.

В документации по настройке DKM (ссылка была выше) не заостряется особого внимания на Best Practice и рекомендациях вообще. Парни просто рекомендуют создать контейнер в корне того же домена, к которому принадлежат ваши Management Servers и указать пусть к нему в LDAP-формате в мастере установки VMM. Некоторые VMM-related блогеры описывают создание этого контейнера в System (CN=System, DC=Contoso, DC=com). Но есть два забавных момента в этом всем:

  1. Вы не можете изменить расположение DKM-хранилища после установки VMM. Никак. В теории (мои предположения) данные об этом, скорее всего, хранятся в двух местах: в конфигурационной базе SQL и в реестре на каждом из узлов (мои предположения совпали с предположениями одного PFE из американского Microsoft, но тем не менее это теперь просто предположение двух людей, т.к. подтвердить это он не смог).

    UPDATE: Поиск по реестру ничего не дал, так что возможно, что все хранится ТОЛЬКО в базе SQL.

  2. С учетом п.1 даже переустановка SC VMM с опцией retain database не спасет, ибо см п.1, раздел предположений. Т.е. как только VMM подцепит базу – он сразу же полезет в AD искать те самые ключи. Предположения! Не ругайтесь, проверять не было ни времени, ни сил, ни необходимых навыков J
  3. Установщик SC VMM парень нетребовательный, и с удовольствием съест не только контейнер, но и Organizational Unit. Далее в нем он создаст контейнер с именем VMMDKM__GUID, а туда уже положит объекты типа Contact, в которых ключи и хранятся.

В моем варианте тот, кто устанавливал VMM заказчику использовал для хранения DKM Organizational Unit, в котором были объекты серверов и CNO кластера VMM. Я предполагаю, что он не хотел парится, но т.к. HA завести без DKM невозможно, решил сложить все яйца в одну корзину.

В итоге он скормил установщику примерно такой путь:

OU=VMM,OU=Management Servers, OU=Servers, DC=Contoso, DC=com.

Путем опроса «Что делали» (мои знания SQL не позволяют мне, надеюсь пока не позволяют, искать строку конфигурации в базе (и кто напишет, как это можно сделать – получит персональную благодарность)) выяснилось, что администратор Active Directory Domain Services от нечего делать решил навести «красивость» в подотчетном хозяйстве и переименовал OU=Servers в OU=Infrastructure Servers. Следовательно, изменился аттрибут Distinguished Name контейнера DKM, следовательно изменился путь к нему в формате LDAP. Т.к. VMM ищет эти ключи по полному LDAP-пути, он не смог получить к ним доступ и не смог расшифровать sensitive data в базе SQL. Что и вызвало такое вот поведение системы. Самое интересное, что администратор не помнил, как называлась OU до переименования, и для того, чтобы это понять, мне пришлось еще поприседать с восстановлением System State недельной давности из копии в DPM, монтировании всего этого дела с помощью DSAMain.exe и поиске через LDP.exe. Но это совсем другая история. После переименования OU в исходное состояние все завелось.

Выводы:

А какие тут могут быть выводы? Документация штука хорошая, но Best Practices и рекомендации писать тоже надо. Почему в примерах на TechNet всегда кладут контейнер DKM в корень домена? Да потому, что этот корень никому в здравом уме и трезвой памяти переименовывать не придет в голову (и не удастся даже если придет). Почему некоторые MVP кладут это дело в System? Да потому же. Почему контейнер, а не OU? Не могу сказать определенно. Может быть и потому, что не требуется делегирование и назначение GPO на него.

Поэтому, думайте головой во время установки VMM, и думайте головой во время выполнения любых операций с AD DS, последствия могут быть непредсказуемыми.

Видите Error 635 – сразу смотрите в хранилище DKM. Есть оно? Там ли оно, где было? Права на него? (должны быть Read\Modify у учетной записи, от имени которой запущен SCVMMService, как минимум). Такие дела.

UPDATE:

«А теперь мазурка!» По наущению одного хорошего человека, имя которого я не могу разглашать, чтобы не разбудить силы зла, я расскажу о том, где же все-таки хранится строка доступа к контейнеру DKM, как ее можно изменить и все такое. Обращаю отдельное внимание: Этот способ недокументирован, следовательно неподдерживаем. Все это вы проделываете (если проделываете) на свой страх и риск и никто, кроме вас, ответственности за это не несет. Ни Microsoft, ни я, ни тот самый таинственный «хороший человек» :)
Итак, как я и предполагал, строка, определяющая адрес контейнера VMM хранится в базе SQL. Найти ее можно вот таким запросом по базе:

SELECT [PropertyValue] FROM [VirtualManagerDB].[dbo].[tbl_VMM_GlobalSetting] where PropertyName=’ContainerName’

По идее, в запросе вам нужно заменить только название базы, если оно у вас отличное от приведенного. Т.е. меняете VirtualManagerDB на что надо.

Это посмотреть. А как изменить? А вот так:

UPDATE [VirtualManagerDB].[dbo].[tbl_VMM_GlobalSetting] SET [PropertyValue]=’CN=VMMDKM,dc=Contoso,dc=com’ where PropertyName=’ContainerName’

После этого перезапустить SCVMMService.
Т.е. даже в моем сценарии, чтобы отвязаться от кривого расположения контейнера DKM, мне надо сделать четыре шага:
1. Создать контейнер CN=VMMDKM,DC=Contoso,DC=com
2. Переместить туда контейнер VMMDKM_VMMServer_GUID
3. Выполнить модификацию свойства в базе
4. Перезапустить сервис SCVMMService.

Скажу честно: я этого не пробовал, пробовать пока не собираюсь, и не буду точно этого делать в продуктиве какого-бы то ни было заказчика. Но в лабе попробовать все-таки стоит, правда? Ну чтобы просто знать способ :)

Реклама
SC VMM 2012 R2, Distributed Key Management и Error 635

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

w

Connecting to %s