пятница, 16 июля 2010 г.

ESX(i) AD integration

Очень меня порадовали эксперименты с доменной аутентификацией на серверах ESX(i).

Вот смотрите:

Если указать не только имя домена, а что-то вроде vm4.ru/Computers/vSphere, то записи о серверах ESX(i) попадут в соответствующий контейнер.

Затем, вариантов два.

1) В AD создается группа “ESX Admins”. Ее члены могут авторизовываться на серверах ESX(i), не обладая никакими дополнительными привилегиями.

Вот так выглядят выданные права по умолчанию:

 

2) На закладке Permissions выбрать Add Permission в контекстном меню пустого места, и дать права произвольной доменной группе:

В общем, все легко и просто.

Для полноты картины – выдачу прав пункта 2 можно делать централизованно, через Host Profile:

 

После применения профиля с такой настройкой происходит ожидаемое:

Таким образом, проблема обслуживания учеток и паролей на серверах ESX(i) значительно упрощается.

Однако, в обоих случаях авторизоваться в putty тоже получится, но без прав. Придется использовать su –.
Кстати, коллеги, кто рубит в Linux – а правами в консоли что-то можно придумать? Чтобы достаточно было доменной учетной записи, и для работы в командной строке?

20 комментариев:

  1. По поводу su

    Вы Майкрософтское говнецо то в Linux не тащите :)

    С БЕЗОПАСНОСТЬЮ не шутят.

    ОтветитьУдалить
  2. Михаил, не подумайте, что я встаю на сторону неизвестного коллеги, просто я так же не в восторге от идей т.н. "сквозной" аутентификации.

    Не впадая в ажитацию ("говнецо" и пр.эмоционально акцентированные термины оставим фанатикам), скажу лишь, что (ИМХО) виртуализуЮЩАЯ (VI) и виртуализуЕМАЯ (vI) инфраструктуры должны быть максимально изолированы по вектору "изнутри наружу" - из VI дОлжно иметь доступ к объектам vI (в т.ч. и внутрь их - например, консоль ВМ), но никак не наоборот. Это примерно (на уровне грубой аналогии) как ОС, установленная в ВМке, ничего не знает о "внешней сфере" VI - вот пускай принципалы безопасности внутри vI и остаются внутри, а для VI должны существоать отдельные собственные принципалы безопасности.

    Впрочем, свою "кочку зрения" я уже имел возможность обозначить в приснопамятном треде на Варерусишгруппенфоруме - http://communities.vmware.com/thread/271380?start=0&tstart=0 - не думаю, что стОит дублировать аргУменты "про" и "контра" ещё и в данном треде.

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  3. Михаил
    А так как было в незапамятные времена - http://www.vmware.com/pdf/esx_authentication_AD.pdf & http://www.vmware.com/pdf/esx3_esxcfg_auth_tn.pdf что не работает?

    > ... Вы Майкрософтское говнецо ....
    Там Kerberos к MS отношения никакого, жалуйтесь в MIT :)

    ОтветитьУдалить
  4. не знаю работает ли сейчас старый способ,
    знаю что сейчас то же самое реализовано гораздо удобнее.

    ОтветитьУдалить
  5. Схема аутентификации by AD получается достаточно требовательной к настройкам сообственно AD (читаем MS DNS & Kerberos реализации), и не безболезненна по производительности для хоста ESX (много сетевых обменов - ждать нужно что ответит AD).
    При dc в виртуалке становится, на мой взгляд неоптимальной - недоступен kdc или dns (а они и стартуют минуты на живой машине) нет возможности попасть на консоль ESX.

    ОтветитьУдалить
  6. если перед кем-то стоит задача обслуживать локальных пользователей на каждом из большого количества серверов, такого рода централизация имхо оправдана.
    пользоваться ею все равно придется лишь для редкого траблшутинга\автоматизации действий скриптами, так что часто дергать AD хостам вряд ли потребуется.

    ОтветитьУдалить
  7. michigun>если перед кем-то стоит задача обслуживать локальных пользователей на каждом из большого количества серверов, такого рода централизация имхо оправдана.

    Михаил, не в укор Вам будь сказано, но фраза у Вас получилаcь какая-то "ватная" (по крайней мере, я в ней вязну :)). "Перед КЕМ-ТО"... "обслуживать"... "большое количество ПОЛЬЗОВАТЕЛЕЙ"... "на серверах"... :D:D:D

    Если я правильно всё попутал :), то дискутируемый механизм должен позволять доступ на хост VI не по логину-паролю аккаунта ESX(i), а по логину-паролю учётки из соответствующей группы AD - но таких учёток по определению не может быть много, бо доступ к VI должны иметь только админы VI. Соответственно, смысл слов "обслуживать(?) большое кол-во пользователей" мне как-то не очень ясен.

    И уж в любом случае для админа VI, даже если он по совместительству админ vI (читай, Domain Admin в AD), кошернее будет не смешивать эти две ипостаси - в AD он будет ходить под учёткой AD, а в VI - под учёткой ESX(i).

    И М Х О !!! :)

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  8. вдогонку:

    michigun>централизация имхо оправдана.
    пользоваться ею все равно придется лишь для редкого траблшутинга\автоматизации действий скриптами, так что часто дергать AD хостам вряд ли потребуется.

    В том-то и состоит сермяжная правда (ранее подмеченная ув.KobaSurf), что одним из эффектов trouble`ов, которые придётся _нечасто_ shооt`ить, запросто может оказаться недоступность DC - тогда Вы не попадёте на хост именно в тот момент, когда это будет очень нужно...

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  9. Централизация - на мой взгляд - нужна тогда когда есть под нее задачи.
    Скажем - городить на одиноком ESXi схему аутентификации связанную с AD смысла не вижу.
    С другой стороны при наличии развесистой инфраструктуры и большого количества админ персонала выбора нет - или пароль который известен всем (даже не будем перечислять чем это черевато) или AD аккоунты + root который известен только vi team.
    ЗЫ ув Umlyaut на мой взгляд - усугубляйте :), на ESXe так или иначе есть локальные пользователи (как минимум root), и если побеспокоиться заранее (например разрешить root входить по ключу) то достучаться до хоста, даже если kdc & dns нет, получится.

    ОтветитьУдалить
  10. >+ root который известен только vi team

    а если это 50 разных учеток root?

    я и имел в виду, что когда есть пара доменных учеток, обслуживать (всякие смены паролей) их проще чем root отдельно на каждом сервере.

    ОтветитьУдалить
  11. KobaSurf>Централизация - на мой взгляд - нужна тогда когда есть под нее задачи.

    +100500

    Сразу скажу - я не идейный противник централизации. И с тем, что сказал чуть ранее Михаил:

    michigun>когда есть пара доменных учеток, обслуживать (всякие смены паролей) их проще чем root отдельно на каждом сервере

    вполне соглашусь - да, при большом числе хостов централизация рулит.
    Только мне не очень нравится пара моментов:

    - что механизм аутентификации может находиться "по ту сторону" забора - внутри виртуальных DC (возможные проблемы при отсутствии физ.DC уже озвучивались)

    - и что доступ к доменным учёткам группы "ESX(i)" (как и к самой группе) будут иметь админы домена: сие несекурно ни разу, бо админ домена всегда сможет добавить себя (или ещё какую учётку... даже и временную) и зайти на хост VI.

    ИМХО, обе проблемы решаются централизованным же методом аутентификации... но на основе распределённой между серверами vCenter базы аккаунтов на основе ADAM, НЕ связанной с AD.

    Поймите, коллеги - я за РАЗУМНУЮ централизацию, а не за лемминговое кочевание вслед за модой/привычкой/"бестпрактисами"/etc. под обветшавшими лозунгами об "отраслевых стандартах" и всё такое... :)))

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  12. Коллеги,дискуссия в том виде, в котором она сейчас проходит - бессмысленна. Доказать, что однозначно один вариант лучше другого не получится, все зависит от конкретной архитектуры, политики, настроек и разбирать необходимо конкретные примеры.

    На форуме свою точку зрения я уже выссказала. Это только моя точка зрения. Ни в коем случае не настаиваю и не утверждаю её, как истину в последней инстанции.

    ОтветитьУдалить
  13. Справедливости ради нужно отметить что постановка вопроса тут отличается от форумной - речь не Virtual Center, а о отдельном хосте ESX, об определенном протоколе аутентификации вместо их перебора в случае win хоста с VC, этот ряд отличий можно продолжить, только а нужно ли?
    Без граничных условий постановки задачи говорить о предпочтительности одного варианта над другим говорить сложно.

    ОтветитьУдалить
  14. К сожалению 4.1 нет и проверить не могу, но если они используют likewise, то достаточно прописать в
    /etc/sudoers
    строку
    %vm4.ru\\ESX_Admins ALL=(ALL) ALL

    И дальше для получения прав прилегированного пользователя достаточно выполнить
    sudo bash

    ОтветитьУдалить
  15. а можно просто разрешить доменной группе делать su в рута не вводя пароль:


    Cmnd_Alias SU_ROOT = /bin/su - root
    %имя_AD_группы ALL = NOPASSWD: SU_ROOT

    ОтветитьУдалить
  16. >а можно просто разрешить доменной группе делать su в рута не вводя пароль:

    я бы сказал, что это Dangerous practice

    ОтветитьУдалить
  17. кстати, если доменной группе дать роль администратора в esx консоли, то любой член этой группы сможет поменять пароль у root.
    это конечно очевидная весчь, но эт я так для уточнения.

    коллеги, а подскажите пожалуйста по подробнее, как можно доменной группе прикрутить права root.
    где именно надо прописать команды описанные выше:
    Cmnd_Alias SU_ROOT = /bin/su - root
    %имя_AD_группы ALL = NOPASSWD: SU_ROOT

    ОтветитьУдалить
  18. Нужна Ваша консультация. Удалось зарегистрировать ESXi-сервера в домене и прописать разрешения, но у меня они управляются через vCenter. А вот его зарегистрировать в домене не получается. Вхожу через web-интерфейс под root, закладка Authentication, ставлю галочку Active Directory Enabled и ввожу реквизиты домена и получаю сообщение Error: Enabling Active Directory failed. Версия vCenter 5.1. В чем может быть проблема?

    ОтветитьУдалить
  19. Похоже, vCenter 5.1 перестал поддерживать домены Windows 2000...

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.