Интеграция VMware vCenter Server с Active Directory (AD) позволяет централизовать управление учетными записями и упростить администрирование доступа. Вместо локальной базы пользователей vCenter можно использовать доменную инфраструктуру AD или другой LDAP-сервис как единый источник аутентификации.
Это означает, что администраторы vSphere смогут применять те же учетные записи и группы, что и для остальных ресурсов сети, для доступа к объектам vSphere. Такой подход повышает безопасность за счет единого контроля учетных данных и упрощает управление доступом (например, добавление пользователя в соответствующую доменную группу автоматически дает ему нужные права в vCenter). Кроме того, доменная аутентификация позволяет пользоваться механизмами безопасности AD (политики паролей, многофакторная аутентификация при федерации и т.д.) для доступа к vCenter.
В этой статье представлены подробные инструкции по интеграции vCenter Server 8.0/8.1 с Active Directory и LDAP, а также рассматриваются лучшие практики на 2025 год – рекомендации по безопасности, отказоустойчивости и централизованному управлению. Мы начнем с подготовки системы и затем рассмотрим два основных метода интеграции: (1) через присоединение vCenter к домену AD (Integrated Windows Authentication, устаревающий метод) и (2) через добавление LDAP-источника (рекомендуемый метод). Далее описывается назначение ролей AD-пользователям в vCenter и приводятся советы по оптимальной конфигурации. Наконец, в завершение подведены итоги и приведена HTML-версия статьи.
Предпосылки и требования
Перед началом интеграции убедитесь, что выполнены следующие условия:
Наличие настроенного домена Active Directory – должен быть как минимум один контроллер домена (не в режиме только чтения). Для отказоустойчивости рекомендуется иметь несколько контроллеров.
Корректная настройка DNS – имя vCenter (FQDN) должно соответствовать домену, и сам vCenter должен правильно разрешать DNS-имена контроллеров домена AD. Убедитесь, что vCenter Appliance (VCSA) указывает на DNS-сервер, способный разрешать имя домена AD в IP-адрес контроллера.
Синхронизация времени – vCenter и контроллер(ы) домена должны иметь согласованное время (например, через NTP). Расхождение времени более 5 минут может приводить к сбоям Kerberos-аутентификации.
Учетная запись в AD с правами для присоединения компьютеров к домену (если планируется метод с присоединением) либо для выполнения LDAP-запросов (при методе через LDAP). Рекомендуется создать отдельную учетную запись (например, vmware_svc) с минимально необходимыми правами в домене.
Уникальность домена SSO vCenter – локальный домен единого входа vCenter (по умолчанию vsphere.local) не должен совпадать по имени с вашим доменом Active Directory. Например, если корпоративный домен – company.local, для SSO домена vCenter следует использовать другое имя (например, vsphere.local), иначе при попытке интеграции возникнет ошибка.
Методы интеграции с Active Directory
Существует два подхода к интеграции vCenter с Active Directory:
Присоединение vCenter Server к домену Windows (Integrated Windows Authentication, IWA) – традиционный способ, при котором vCenter становится членом домена AD. Это включает в себя доверие Kerberos и возможность использовать Windows Session Authentication (единый вход для учетной записи, выполнившей вход в Windows) для веб-клиента vSphere. Важно: VMware объявила о выводе этого метода из эксплуатации – поддержка IWA будет удалена в ближайших крупных версиях после vSphere 8.0. Поэтому, хотя в vCenter 8.0/8.1 данный способ еще доступен, планируется переход на альтернативные методы.
Добавление AD как LDAP-источника удостоверений/identity provider (LDAP/LDAPS) – рекомендованный метод на 2025 год. vCenter не присоединяется к домену, вместо этого в настройках SSO добавляется внешний источник идентификации, указывающий на домен Active Directory по протоколу LDAP/LDAPS. Предпочтительно использовать защищенный канал LDAPS (LDAP over SSL) для шифрования трафика аутентификации. Этот метод требует вручную предоставить сертификат контроллера домена для LDAPS и не поддерживает единый вход через Windows session, но является более безопасным и поддерживаемым в долгосрочной перспективе.
Ниже приведены пошаговые инструкции для каждого подхода.
Способ 1: Присоединение vCenter 8.x к домену Active Directory (IWA)
Примечание: Этот метод сейчас считается устаревающим, однако в версиях vCenter 8.0/8.1 он еще поддерживается для обратной совместимости. Его использование может быть оправдано, если требуется возможность входа через текущую сессию Windows (SSPI) или ваш процесс требует именно доменной интеграции. Но планируйте миграцию на способ с LDAP (см. ниже) в ближайшем будущем.
Вход в vSphere Client под учетной записью SSO. Откройте веб-интерфейс vCenter (vSphere Client) и войдите под пользователем администратора SSO – как правило, это administrator@vsphere.local (либо другой, указанный при установке vCenter). Эта учетная запись имеет полные права для настройки SSO. Убедитесь, что у вас есть доступ именно к административному интерфейсу vCenter.
Открытие настроек Single Sign-On. В клиенте vSphere нажмите меню Menu (иконка квадрата вверху) и перейдите в раздел Administration. В разделе Single Sign-On выберите пункт Configuration (Конфигурация). Перейдите на вкладку Identity Provider (поставщик удостоверений).
Присоединение к домену. На вкладке Identity Provider отобразится секция Active Directory Domain. Нажмите кнопку Join AD, чтобы начать процесс присоединения vCenter Server Appliance к домену. Вы увидите диалог ввода параметров домена:
Ввод параметров домена. В открывшемся диалоговом окне укажите учетные данные для присоединения к домену:
Domain – имя домена Active Directory (FQDN), например corp.local. Помните, что имя должно отличаться от домена SSO vCenter.
Organizational Unit (OU) – необязательное поле. Можно указать DN организационного подразделения, куда будет помещен компьютерный объект vCenter в AD. Если оставить пустым, объект будет создан в контейнере по умолчанию (Computers). Например, значение OU=Servers,DC=corp,DC=local поместит запись в OU “Servers” домена corp.local.
Username и Password – учетная запись в домене с правом добавления компьютеров. Укажите формат логина как user@domain или DOMAIN\user. Рекомендуется использовать выделенную учетную запись (например, vmwareadmin), член группы администраторов домена, а не встроенного Administrator.
Заполнив поля, нажмите Join для отправки запроса. При успешном выполнении операция присоединит VCSA к домену AD и запросит перезагрузку vCenter Server.
Перезагрузка vCenter. Выполните рестарт vCenter Appliance, чтобы изменения вступили в силу (в конфигурировании доменных служб часто требуется перезапуск). После перезагрузки vCenter будет членом указанного домена (появится учетная запись компьютера в AD).
Добавление домена как источника удостоверений. Снова войдите в vSphere Client под администратором SSO (administrator@vsphere.local). Перейдите в Administration > Single Sign-On > Configuration > Identity Provider и откройте вкладку Identity Sources. Вы должны увидеть, что появился источник типа Active Directory (Integrated Windows Authentication) для домена, к которому присоединили vCenter, либо при необходимости нажмите Add (Добавить) и выберите тип Active Directory (Integrated Windows Authentication) вручную. Обычно при присоединении к домену vCenter автоматически регистрирует этот домен как идентификационный источник SSO. Если же этого не произошло, добавьте его: выберите ваш домен из выпадающего списка или укажите его имя и NetBIOS-алиас, затем сохраните. После добавления домена в списке Identity Sources отобразится новая запись типа Active Directory.
Установка домена по умолчанию (опционально). Если в вашей среде планируется использовать только один внешний источник (ваш домен AD), имеет смысл сделать его Default Domain – источником по умолчанию для аутентификации. Для этого выделите добавленный домен в списке Identity Sources и нажмите кнопку Set as Default. В колонке Type напротив домена появится отметка «(default)». Теперь при вводе имени пользователя без явного указания домена (например, просто john.dow вместо CORP\john.dow) vCenter будет пытаться аутентифицировать его в вашем домене AD.
Проверка входа через Windows session (SSPI). Преимущество присоединения к домену – возможность входа в vCenter по текущей Windows-сессии без повторного ввода пароля. Чтобы это проверить, используйте браузер Internet Explorer/Edge или клиент vSphere, запущенный на машине, входящей в тот же домен, и выберите опцию Use Windows session authentication на странице логина vSphere Client. Либо в поле имени пользователя можно ввести user@domain и оставить пароль пустым при включенной опции Windows Session. Если все настроено правильно, вы будете автоматически авторизованы под своими доменными учетными данными (SSO передаст Kerberos тикет). Важно: Этот механизм работает только при методе IWA и если браузер/клиент поддерживает SPNEGO-авторизацию, а также если на клиентской машине вы вошли в AD под тем же пользователем.
Способ 2: Добавление Active Directory через LDAP/LDAPS (рекомендуется)
Интеграция vCenter с AD через LDAP не требует присоединения сервера vCenter к домену. vCenter будет направлять LDAP-запросы на контроллер(ы) AD для проверки учетных данных. В 2025 году VMware рекомендует именно этот метод, так как он избавляет от использования устаревшего IWA и позволяет использовать защищенные соединения LDAPS. Ниже описаны шаги по настройке LDAP-источника удостоверений:
Подготовка сертификата LDAPS. Если вы планируете использовать защищенный LDAP (LDAPS, порт 636), заранее подготовьте SSL-сертификат контроллера домена. Как правило, доменные контроллеры имеют сертификат (выданный внутренним enterprise CA или самоподписанный) для LDAP over SSL. Этот сертификат (или сертификат CA, выдавшего его) нужно импортировать в vCenter при настройке источника. Примечание: в веб-интерфейсе vCenter нет автоматического способа получить сертификат с LDAP-сервера, поэтому сделайте это вручную. Вы можете:
Экспортировать сертификат контроллера домена из хранилища Windows (если у вас доступ к нему).
Либо выполнить команду OpenSSL на vCenter Appliance:
Эта команда выведет цепочку сертификатов. Скопируйте текст блока -----BEGIN CERTIFICATE----- ... END CERTIFICATE----- для корневого или выдавшего CA и сохраните в файл (например, ldaps.cer). Предпочтительнее использовать сертификат CA домена, чтобы при обновлении сертификата контроллера не пришлось перенастраивать источник.
Если защищенный LDAP недоступен, временно можно использовать нешифрованный LDAP (порт 389), но это не рекомендуется по соображениям безопасности.
Добавление нового источника идентификации. Войдите в vSphere Client под администратором SSO (administrator@vsphere.local) и перейдите в Administration > Single Sign-On > Configuration. На вкладке Identity Provider откройте секцию Identity Sources и нажмите Add. В мастере добавления источника выберите Identity Source Type = Active Directory over LDAP. Если вы интегрируете не Microsoft AD, а другой LDAP-сервис (например, OpenLDAP), выберите соответствующий тип OpenLDAP – поля будут аналогичны, хотя понятие “Domain name” и “Alias” применимо только к AD.
Заполнение параметров LDAP. Заполните поля конфигурации нового источника:
Identity source name – удобное имя для источника в vCenter. Обычно имеет смысл указать DNS-имя домена, например corp.local.
Base Distinguished Name for users – базовый DN, откуда будут выборки пользователей. Если хотите охватить весь домен, укажите корневой DN домена. Например, для домена corp.local это DC=corp,DC=local. Можно указать более узкий контекст (например, OU), если нужны только пользователи из определенного подразделения.
Base Distinguished Name for groups – базовый DN для групп. Можно указать тот же домен (или OU групп, если они хранятся отдельно).
Domain name – полное имя домена (например, corp.local).
Domain alias (NetBIOS name) – короткое имя домена (NetBIOS), например CORP. Это имя используется для входа в формате DOMAIN\user. Для OpenLDAP-источника это поле недоступно.
Username и Password – учетные данные для подключения к LDAP. Укажите пользователя домена с правом чтения каталогa. Достаточно прав просмотра (browse) – в AD это любой обычный пользователь, т.к. по умолчанию Authenticated Users могут просматривать структуру каталога. Рекомендуется использовать отдельную учетную запись-сервис с ограниченными правами. Формат имени пользователя – либо user@corp.local, либо в DN-формате (например, CN=vmware_svc,CN=Users,DC=corp,DC=local). Если при сохранении настроек возникнет ошибка синтаксиса DN, попробуйте указать имя именно в формате DN.
Connect to – здесь настраиваются адреса контроллеров. Можно выбрать «Connect to any domain controller in the domain» (подключаться к любому контроллеру в домене) для автоматического определения контроллеров через DNS. Это удобно и повышает отказоустойчивость (в случае отказа одного контроллера vCenter переключится на другой по DNS-записи). Альтернативно, можно задать статические адреса: переключите опцию на «Specific domain controllers» и введите один или два URL. Формат URL:
для LDAPS: ldaps://dc01.corp.local:636 (если требуется, можно указать порт 3269 для глобального каталога)
для LDAP без SSL: ldap://dc01.corp.local:389 (порт 3268 для глобального каталога без SSL)
Если указываете два контроллера, первый считается основным, второй – резервным на случай недоступности первого.
Импорт SSL-сертификата. Если вы выбрали использование LDAPS и ваш контроллер использует самоподписанный или корпоративный сертификат, нажмите Browse рядом с полем Certificate и загрузите файл сертификата, полученный на шаге 1. vCenter импортирует сертификат в доверенное хранилище для установления SSL-связи с LDAPS. Убедитесь, что загружен корректный сертификат, иначе подключение не установится.
Завершение добавления источника. Нажмите Add для сохранения настроек. Новый источник удостоверений появится в списке Identity Sources. Теперь vCenter SSO знает о вашем домене AD и сможет аутентифицировать пользователей из него. При необходимости сделайте этот источник доменом по умолчанию (Set as Default), как описано в предыдущем разделе, чтобы упростить ввод логина.
Проверка подключения. После добавления рекомендуются базовые проверки:
Перейдите на вкладку Users and Groups в настройках Single Sign-On (там же в Administration). Попробуйте сменить домен (в выпадающем списке) на добавленный AD-домен – вы должны увидеть список пользователей или групп из AD, что подтвердит успешное соединение.
Если LDAP подключение не удается, перепроверьте правильность Base DN и учетных данных, а также что сертификат LDAPS верный. В случае ошибок аутентификации, смотрите логи vCenter SSO по пути /var/log/vmware/sso на vCenter.
Примечание о других LDAP: Для интеграции с OpenLDAP или сторонними LDAP-сервисами шаги аналогичны. Выбирайте тип источника OpenLDAP и указывайте Base DN для пользователей/групп согласно структуре вашего каталога. Потребуется также сертификат при LDAPS. Разница в том, что поля Domain Name/Alias не нужны (эти понятия специфичны для AD). После добавления OpenLDAP-источника вы сможете создавать в SSO группы, содержащие внешних LDAP-пользователей, и назначать им роли, либо предоставлять права отдельным LDAP-пользователям схожим образом.
Назначение прав AD-пользователям в vCenter
После подключения vCenter к внешнему источнику (будь то AD через IWA или LDAP), сами по себе доменные пользователи еще не имеют доступа к инфраструктуре vSphere. Необходимо явно делегировать им роли и разрешения в vCenter. Лучшей практикой является назначать привилегии группам AD, а не отдельным учетным записям – это упростит администрирование, позволяя добавлять/удалять людей в группе на уровне AD.
Рассмотрим процесс на примере предоставления группе администраторов виртуальной инфраструктуры полного доступа в vCenter:
Создайте группу в Active Directory, например vCenter-Admin, и добавьте в нее соответствующих пользователей-доменных администраторов (если такая группа еще не существует). Это делается на контроллере домена через оснастку Active Directory Users and Computers.
Назначение группы на уровень глобальных прав vCenter. В vSphere Client откройте раздел Administration > Access Control > Global Permissions (Глобальные разрешения). Глобальные разрешения применяются ко всем объектам vCenter (включая все датацентры и кластеры). Нажмите Add. В окне добавления субъекта (Principal) выберите ваш домен (если он не выбран по умолчанию) и в поле поиска начните вводить имя группы, например "vCenter-Admin". Когда система найдет вашу группу, выберите ее (может пройти какое-то время для обнаружения групп AD). Ниже, в выпадающем списке Role, выберите роль Administrator (или другую, в зависимости от требуемых привилегий). Убедитесь, что флажок Propagate to children (применить к вложенным объектам) установлен, если даете права на верхнем уровне. Нажмите OK для применения. Теперь все пользователи, состоящие в группе vCenter-Admin, наследуют права администратора ко всем объектам vCenter.
Проверка авторизации под доменной учетной записью. Откройте новую сессию vSphere Client (или отключитесь от текущей) и на странице входа введите учетные данные пользователя AD, который был включен в группу с назначенными правами. Например, john.dow@corp.local и его пароль. Если домен установлен “по умолчанию” в SSO, можно вводить только логин без @домена. Убедитесь, что вход прошел успешно и вы видите объекты окружения vCenter. В правом верхнем углу интерфейса отобразится имя вошедшего доменного пользователя. Теперь данный пользователь обладает правами согласно присвоенной роли. Повторите для других пользователей или групп, распределяя необходимые роли (например, группы операторов с ролью ReadOnly, группа разработчиков с ролью VM Power User на уровне конкретной папки и т.д.).
Минимизация использования локального администратора. После того как настроена доменная авторизация, постарайтесь не использовать учетную запись administrator@vsphere.local для повседневной работы. Вместо этого храните ее как аварийную (break-glass) учетную запись на случай, если интеграция с AD будет недоступна. Данная учетная запись всегда должна иметь надежный пароль и быть защищена, но не применяться для ежедневных задач. Все регулярные операции рекомендуется выполнять под персональными доменными логинами – это улучшит аудит и соответствие политике безопасности.
Лучшие практики 2025: безопасность, отказоустойчивость, управление
1. Использование LDAPS и отказ от нешифрованного LDAP: начиная с 2020 года Microsoft ужесточила требования к безопасности LDAP – рекомендуется использовать LDAP Signing или полностью переходить на LDAPS. Всегда используйте LDAPS для интеграции vCenter с внешним каталогом. Без шифрования ваши учетные данные могут передаваться в открытом виде. Кроме того, vCenter при IWA ранее использовал несигнатурный LDAP, что вызывает предупреждения (Event ID 2889) на контроллерах AD и может быть запрещено политиками безопасности. Применяя AD over LDAPS или федерацию, вы избегаете этой проблемы. Убедитесь, что в домене настроена служба сертификатов для контроллеров AD, и что vCenter доверяет этим сертификатам. Если необходимо, обновите сертификаты LDAP контроллеров до их истечения и импортируйте новые в vCenter (в противном случае аутентификация прервется, когда сертификат станет недействительным).
2. Планирование вывода IWA из эксплуатации: VMware объявила, что Integrated Windows Authentication будет удален в следующих версиях (после 8.0 Update 3). Рекомендуется уже сейчас мигрировать от схемы с присоединением к домену на схему с AD over LDAPS или рассмотреть внедрение федерации через сторонний Identity Provider. Federation (например, ADFS, Okta, Azure AD и др.) позволяет использовать современные методы аутентификации, включая MFA, но требует дополнительной настройки. Если федерация пока не планируется, переход на LDAP(S) интеграцию – обязательное условие долгосрочной работы. VMware предоставляет рекомендации по миграции с IWA на LDAPS и утилиты для проверки настройки перед обновлением. Вывод: для новых внедрений используйте метод LDAP, а существующие IWA-настройки переводите на LDAP до обновления vCenter до версии, где IWA отсутствует.
3. Минимально необходимые привилегии и роли: следуйте принципу наименьших привилегий. Даже если для удобства часто дают группе администраторов домена полный доступ к vCenter, рассмотрите создание отдельных групп AD для разных ролей vCenter (например, vSphereAdmins, vSphereReadOnly, BackupOperators и т.д.). Назначайте строго те роли, которые нужны группе. Это предотвратит избыточные права. Не добавляйте в vCenter встроенные группы вроде Domain Admins напрямую – лучше используйте специально заведенные группы для vSphere, чтобы четче контролировать кто имеет доступ.
Кроме того, не создавайте локальных пользователей в SSO-домене vCenter (vsphere.local) без необходимости. Все администрирование должно идти через доменные учетные записи, за исключением аварийных случаев. Локальных пользователей vCenter имеет смысл заводить только для интеграций с внешними системами (например, учетная запись для backup-решения, если оно не поддерживает доменную авторизацию).
4. Централизованное управление и аудит: используя Active Directory для vCenter, вы получаете централизованный контроль над учетными записями – отключение или удаление пользователя в AD автоматически лишит его доступа к vCenter (если у него не осталось других учеток). Пользуйтесь этим преимуществом и ведите учет доступа через стандартные средства AD. В vCenter регулярно просматривайте раздел Administration > Roles and Permissions, чтобы инспектировать, какие группы какие роли имеют. При уходе сотрудника достаточно убрать его из AD-группы – в vCenter доступ закроется мгновенно. Также учитывайте, что операции пользователей в vCenter логируются (Events, Tasks) под их доменными именами – это облегчает аудит действий.
5. Обеспечение отказоустойчивости аутентификации: продумайте резервный сценарий на случай недоступности AD или LDAP. Держите учетные данные администратора SSO под рукой (и/или другого локального пользователя с админправами), чтобы можно было войти в vCenter, если интеграция с внешним каталогом нарушена. Регулярно проверяйте, что пароль administrator@vsphere.local известен ограниченному кругу лиц и хранится безопасно. Также, если vCenter управляет критичной инфраструктурой, разверните как минимум два контроллера домена (AD рекомендует минимум два на домен). vCenter при настройке LDAP по умолчанию использует DNS для поиска контроллеров, поэтому при отказе одного он обратиться к другому. Если указываете статические контроллеры, пропишите primary и secondary. Резервирование AD критично: потеря единственного контроллера приведет к тому, что доменные пользователи не смогут войти в vCenter. На случай катастрофы (потери нескольких узлов) полезно иметь офлайн-резервные копии как контроллеров AD, так и самого VCSA.
6. Безопасность vCenter и AD: Размещая vCenter в доменной среде, следите за обновлениями и патчами безопасности как для vCenter, так и для Active Directory. Ограничьте сетевую доступность сервисов: порты LDAP/LDAPS на контроллерах должны быть открыты только для доверенных хостов (включая vCenter). Сам vCenter Appliance должен быть защищен брандмауэром, а доступ к его управлению предоставлен только администраторам. Рассмотрите включение двуфакторной аутентификации для веб-клиента vCenter через решение VMware Identity Manager (Workspace ONE Access) или встроенную поддержку RSA SecurID/SmartCard, если ваша политика требует MFA – в vCenter SSO есть возможность настроить эти методы в дополнение к AD.
Следуя перечисленным рекомендациям, вы построите надежную и удобную систему управления доступом к VMware-инфраструктуре, соответствующую современным требованиям безопасности и готовую к будущим обновлениям.
Заключение
Интеграция VMware vCenter Server с Active Directory или другим LDAP-каталогом – необходимый шаг для предприятий, стремящихся централизовать управление учетными записями и повысить безопасность. Мы рассмотрели два способа интеграции для версий vCenter 8.0 и 8.1: через присоединение к домену Windows (устаревающий метод IWA) и через настройку LDAP(S) источника удостоверений (актуальный метод). Приведенные пошаговые инструкции позволяют настроить связку vCenter-AD, а также назначить необходимые привилегии доменным группам и пользователям.
Современные лучшие практики ориентируют администраторов на использование защищенного LDAP (LDAPS), отказ от устаревающих подходов, обеспечение отказоустойчивости (резервирование контроллеров, бэкапы) и минимизацию локальных учетных записей в пользу доменных. Выполняйте регулярный аудит прав и своевременно удаляйте/отзывайте доступ при изменении состава команды – интеграция с AD значительно облегчает эти задачи. Централизованная аутентификация снизит административное бремя и улучшит безопасность вашей виртуальной инфраструктуры, позволив сконцентрироваться на ее развитии, а не на ручном управлении учетными записями.
RSS
