Сообщения
Очень меня порадовали эксперименты с доменной аутентификацией на серверах 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 – а правами в консоли что-то можно придумать? Чтобы достаточно было доменной учетной записи, и для работы в командной строке?
По поводу su
ОтветитьУдалитьВы Майкрософтское говнецо то в Linux не тащите :)
С БЕЗОПАСНОСТЬЮ не шутят.
эээ
ОтветитьУдалитьа обосновать?
Михаил, не подумайте, что я встаю на сторону неизвестного коллеги, просто я так же не в восторге от идей т.н. "сквозной" аутентификации.
ОтветитьУдалитьНе впадая в ажитацию ("говнецо" и пр.эмоционально акцентированные термины оставим фанатикам), скажу лишь, что (ИМХО) виртуализуЮЩАЯ (VI) и виртуализуЕМАЯ (vI) инфраструктуры должны быть максимально изолированы по вектору "изнутри наружу" - из VI дОлжно иметь доступ к объектам vI (в т.ч. и внутрь их - например, консоль ВМ), но никак не наоборот. Это примерно (на уровне грубой аналогии) как ОС, установленная в ВМке, ничего не знает о "внешней сфере" VI - вот пускай принципалы безопасности внутри vI и остаются внутри, а для VI должны существоать отдельные собственные принципалы безопасности.
Впрочем, свою "кочку зрения" я уже имел возможность обозначить в приснопамятном треде на Варерусишгруппенфоруме - http://communities.vmware.com/thread/271380?start=0&tstart=0 - не думаю, что стОит дублировать аргУменты "про" и "контра" ещё и в данном треде.
С уважением,
Umlyaut.
Михаил
ОтветитьУдалитьА так как было в незапамятные времена - http://www.vmware.com/pdf/esx_authentication_AD.pdf & http://www.vmware.com/pdf/esx3_esxcfg_auth_tn.pdf что не работает?
> ... Вы Майкрософтское говнецо ....
Там Kerberos к MS отношения никакого, жалуйтесь в MIT :)
не знаю работает ли сейчас старый способ,
ОтветитьУдалитьзнаю что сейчас то же самое реализовано гораздо удобнее.
Схема аутентификации by AD получается достаточно требовательной к настройкам сообственно AD (читаем MS DNS & Kerberos реализации), и не безболезненна по производительности для хоста ESX (много сетевых обменов - ждать нужно что ответит AD).
ОтветитьУдалитьПри dc в виртуалке становится, на мой взгляд неоптимальной - недоступен kdc или dns (а они и стартуют минуты на живой машине) нет возможности попасть на консоль ESX.
если перед кем-то стоит задача обслуживать локальных пользователей на каждом из большого количества серверов, такого рода централизация имхо оправдана.
ОтветитьУдалитьпользоваться ею все равно придется лишь для редкого траблшутинга\автоматизации действий скриптами, так что часто дергать AD хостам вряд ли потребуется.
michigun>если перед кем-то стоит задача обслуживать локальных пользователей на каждом из большого количества серверов, такого рода централизация имхо оправдана.
ОтветитьУдалитьМихаил, не в укор Вам будь сказано, но фраза у Вас получилаcь какая-то "ватная" (по крайней мере, я в ней вязну :)). "Перед КЕМ-ТО"... "обслуживать"... "большое количество ПОЛЬЗОВАТЕЛЕЙ"... "на серверах"... :D:D:D
Если я правильно всё попутал :), то дискутируемый механизм должен позволять доступ на хост VI не по логину-паролю аккаунта ESX(i), а по логину-паролю учётки из соответствующей группы AD - но таких учёток по определению не может быть много, бо доступ к VI должны иметь только админы VI. Соответственно, смысл слов "обслуживать(?) большое кол-во пользователей" мне как-то не очень ясен.
И уж в любом случае для админа VI, даже если он по совместительству админ vI (читай, Domain Admin в AD), кошернее будет не смешивать эти две ипостаси - в AD он будет ходить под учёткой AD, а в VI - под учёткой ESX(i).
И М Х О !!! :)
С уважением,
Umlyaut.
вдогонку:
ОтветитьУдалитьmichigun>централизация имхо оправдана.
пользоваться ею все равно придется лишь для редкого траблшутинга\автоматизации действий скриптами, так что часто дергать AD хостам вряд ли потребуется.
В том-то и состоит сермяжная правда (ранее подмеченная ув.KobaSurf), что одним из эффектов trouble`ов, которые придётся _нечасто_ shооt`ить, запросто может оказаться недоступность DC - тогда Вы не попадёте на хост именно в тот момент, когда это будет очень нужно...
С уважением,
Umlyaut.
Централизация - на мой взгляд - нужна тогда когда есть под нее задачи.
ОтветитьУдалитьСкажем - городить на одиноком ESXi схему аутентификации связанную с AD смысла не вижу.
С другой стороны при наличии развесистой инфраструктуры и большого количества админ персонала выбора нет - или пароль который известен всем (даже не будем перечислять чем это черевато) или AD аккоунты + root который известен только vi team.
ЗЫ ув Umlyaut на мой взгляд - усугубляйте :), на ESXe так или иначе есть локальные пользователи (как минимум root), и если побеспокоиться заранее (например разрешить root входить по ключу) то достучаться до хоста, даже если kdc & dns нет, получится.
>+ root который известен только vi team
ОтветитьУдалитьа если это 50 разных учеток root?
я и имел в виду, что когда есть пара доменных учеток, обслуживать (всякие смены паролей) их проще чем root отдельно на каждом сервере.
KobaSurf>Централизация - на мой взгляд - нужна тогда когда есть под нее задачи.
ОтветитьУдалить+100500
Сразу скажу - я не идейный противник централизации. И с тем, что сказал чуть ранее Михаил:
michigun>когда есть пара доменных учеток, обслуживать (всякие смены паролей) их проще чем root отдельно на каждом сервере
вполне соглашусь - да, при большом числе хостов централизация рулит.
Только мне не очень нравится пара моментов:
- что механизм аутентификации может находиться "по ту сторону" забора - внутри виртуальных DC (возможные проблемы при отсутствии физ.DC уже озвучивались)
- и что доступ к доменным учёткам группы "ESX(i)" (как и к самой группе) будут иметь админы домена: сие несекурно ни разу, бо админ домена всегда сможет добавить себя (или ещё какую учётку... даже и временную) и зайти на хост VI.
ИМХО, обе проблемы решаются централизованным же методом аутентификации... но на основе распределённой между серверами vCenter базы аккаунтов на основе ADAM, НЕ связанной с AD.
Поймите, коллеги - я за РАЗУМНУЮ централизацию, а не за лемминговое кочевание вслед за модой/привычкой/"бестпрактисами"/etc. под обветшавшими лозунгами об "отраслевых стандартах" и всё такое... :)))
С уважением,
Umlyaut.
Коллеги,дискуссия в том виде, в котором она сейчас проходит - бессмысленна. Доказать, что однозначно один вариант лучше другого не получится, все зависит от конкретной архитектуры, политики, настроек и разбирать необходимо конкретные примеры.
ОтветитьУдалитьНа форуме свою точку зрения я уже выссказала. Это только моя точка зрения. Ни в коем случае не настаиваю и не утверждаю её, как истину в последней инстанции.
Справедливости ради нужно отметить что постановка вопроса тут отличается от форумной - речь не Virtual Center, а о отдельном хосте ESX, об определенном протоколе аутентификации вместо их перебора в случае win хоста с VC, этот ряд отличий можно продолжить, только а нужно ли?
ОтветитьУдалитьБез граничных условий постановки задачи говорить о предпочтительности одного варианта над другим говорить сложно.
К сожалению 4.1 нет и проверить не могу, но если они используют likewise, то достаточно прописать в
ОтветитьУдалить/etc/sudoers
строку
%vm4.ru\\ESX_Admins ALL=(ALL) ALL
И дальше для получения прав прилегированного пользователя достаточно выполнить
sudo bash
а можно просто разрешить доменной группе делать su в рута не вводя пароль:
ОтветитьУдалитьCmnd_Alias SU_ROOT = /bin/su - root
%имя_AD_группы ALL = NOPASSWD: SU_ROOT
>а можно просто разрешить доменной группе делать su в рута не вводя пароль:
ОтветитьУдалитья бы сказал, что это Dangerous practice
кстати, если доменной группе дать роль администратора в esx консоли, то любой член этой группы сможет поменять пароль у root.
ОтветитьУдалитьэто конечно очевидная весчь, но эт я так для уточнения.
коллеги, а подскажите пожалуйста по подробнее, как можно доменной группе прикрутить права root.
где именно надо прописать команды описанные выше:
Cmnd_Alias SU_ROOT = /bin/su - root
%имя_AD_группы ALL = NOPASSWD: SU_ROOT
Нужна Ваша консультация. Удалось зарегистрировать ESXi-сервера в домене и прописать разрешения, но у меня они управляются через vCenter. А вот его зарегистрировать в домене не получается. Вхожу через web-интерфейс под root, закладка Authentication, ставлю галочку Active Directory Enabled и ввожу реквизиты домена и получаю сообщение Error: Enabling Active Directory failed. Версия vCenter 5.1. В чем может быть проблема?
ОтветитьУдалитьПохоже, vCenter 5.1 перестал поддерживать домены Windows 2000...
ОтветитьУдалить