Vmware sso что это

Обновлено: 04.07.2024

VMware vSphere – широко используемая популярная платформа виртуализации, и сегодня темой нашего разговора станет инсталляция и разворот ее последней актуальной – 7.0 версии.

Требования

Для начала, огласим ряд минимальных требований к аппаратному оборудованию для успешной установки VMware vSphere 7.0.

Требования для ESXi 7.0:

CPU. Двухъядерный x86_64 CPU на компьютере, на котором будет работать ESXi хост. Функции Intel-VT-x или AMD-v (RVI) следует включить в UEFI/BIOS.

RAM. Для запуска ESXi понадобится не менее 4 ГБ RAM, а для запуска виртуальных машин на хосте – от 8 ГБ и выше. Больше памяти – большее количество ВМ будет бегать.

Хранилище. ESXi 7.0 требует не менее 8 ГБ дискового пространства для установки и загрузки. Устанавливать можно на отдельный SSD/HDD, RAID и даже держать на SD-карте или флешке.

Важно! В случае SD-карты или флешки не предусмотрено постоянного или временного раздела для хранения журналов.

На загрузочном девайсе рекомендуется выделить более 32ГБ под ESXi, и он не должен совместно использоваться с прочими хостами ESXi. Оптимальными для хранения виртуальных машин являются SCSI (SAS) диски.

Сеть. Понадобится минимум один сетевой контроллер Gigabit Ethernet. Должна быть совместимость сетевого адаптера с ESXi 7.0. Хорошо иметь несколько сетевых адаптеров на сервере ESXi – тогда можно пользоваться утилитой агрегирования каналов NIC Teaming (настраивается отдельно). Это полезно, если есть нужда в функциях кластеризации. Для всех компонентов vSphere (хостов ESXi, серверов vCenter и т.п.) рекомендовано применять статическую IP-конфигурацию.

Естественно, если в vSphere планируется развернуть дополнительные компоненты, например, Kubernetes или NSX, минимальные требования растут. Перед расчетом спецификации оборудования под инсталляцию ESXi обязательно проверьте его совместимость в VMware Compatibility Guide.

Важно! Для полноценной поддержки оборудования серверов Hewlett Packard , DELL и других рекомендуются специальные установочные образы. Например, для HP и DELL:
VMware_ESXi_7.0.0_15843807_HPE_700.0.0.10.5.0.108_April2020.iso
VMware-VMvisor-Installer-7.0.0-15843807.x86_64-DellEMC_Customized-A00.iso.

Требования для vCenter 7:

Для централизованного управления хостами ESXi традиционно используется vCenter Server. Его можно развернуть исключительно как работающую на хосте ESXi виртуальную машину (VCSA). Контроллер сервиса платформы (PSC) интегрирован в саму VCSA.

Важно! В vSphere 7.0 нельзя инсталлировать PSC отдельно или поставить vCenter на машину под управлением Windows – отличие от версии 6.7.

CPU. Минимально (среда до 10 хостов и до сотни ВМ) потребуется два виртуальных процессора.

RAM. 12 ГБ ОЗУ необходимо для обслуживания максимум 10 хостов и 100 виртуальных машин.

Рост количества машин и хостов эквивалентен росту параметров CPU и RAM. Кроме того, обратите внимание, с этим увеличением следует выбирать и соответствующий режим установки (Tiny, Small, Medium, Large, X-Large).

Хранилище. vCenter Server Appliance 7.0 нуждается в 415-3665 ГБ, исходя из количества виртуальных машин. В реальности используется меньше, так как часть зарезервирована под обновления Lifecicle Manager. Часто используется тонкий диск.

Схема развертывания

Для примера возьмем инсталляцию двух серверов ESXi и разворот vCenter Server Appliance на первом из них. Второй отдадим под запуск других виртуальных машин. Назначим:

Далее рассмотрим подключение ESXi-хостов и виртуальных машин к одной сети, но при желании можно создавать отдельные сети для каждой ВМ или их группы. Последнее особенно актуально, когда разворачивается очень большое количество машин, и тогда с помощью VLAN можно заизолировать их друг от друга на втором уровне модели OSI.

Важно! VLAN должен поддерживаться имеющимся маршрутизатором для внешних соединений.

Если используется кластеризация, следует настроить отдельные сети для vMotion и SAN.

Развертывание хостов ESXi. Инсталляция ESXi на серверах

ESXi представляет собой гипервизор первого типа (инструмент запуска виртуальных машин на физическом оборудовании при помощи аппаратной эмуляции). Перед его установкой следует подготовить компьютеры/серверы, проверив соответствие указанным выше требованиям, обеспечив доступ в сеть и назначив всю адресацию.

Инсталляция первого хоста ESXi

Для установки первого хоста ESXi (192.168.11.30) загружаемся с подготовленного носителя, на котором уже записан VMware-VMvisor-Installer-7.0.0-15843807.x86_64.iso. Жмем Enter после приветствия и подтверждаем лицензионное соглашение в следующем окне:

Вводим пароль root и подтверждаем желание инициировать процесс установки, нажав F11:

Базовая конфигурация ESXi-хоста

Первое, что мы увидим при запуске новоустановленного ESXi-хоста, будет его прямая консоль DCUI с версией гипервизора, номером сборки, данными по CPU, памяти и IP-адресации, кроме того там содержится ссылка на браузерное управление ESXi-хостом:

Для настройки системы жмем F2.

Удовлетворяем запрос на аутентификацию (пароль root, который использовался в процессе установки):

Для продолжения жмем Enter.

После этого перед нами появится меню настройки системы. Правая часть интерфейса содержит IP-адрес, назначенный через DHCP. Давайте поменяем настройки сети и присвоим статический IP этому ESXi-хосту, выбрав «Configure Management Network»:

В появившемся окне выбираем «IPv4 Configuration» и подтверждаем решение:

Далее выбираем «Set static IPv4 address and network configuration» и жмем пробел, после чего заходим в следующие настройки IPv4:

Pv4 Address: 192.168.11.30

Subnet Mask: 255.255.255.0

Default Gateway: 192.168.11.2

Чтобы сохранить настройки жмем Enter. Если этот сетевой протокол не используется, можно отключить IPv6.

Затем переходим в DNS Configuration. Выбираем «Use the following DNS server address and hostname» и нажимаем пробел. У нас используется такая конфигурация DNS:

Primary DNS Server: 192.168.11.2

Alternative DNS Server: 192.168.11.1

Для сохранения настроек жмем Enter.

После нажатия Escape выходим из меню «Configure Management Network». Чтобы применить все прописанные изменения, жмем Y (перезапустится демон сети). Перезагрузка потребуется, если мы выключили/включили IPv6:

Теперь переходим к «Troubleshooting options» в меню «System Customization»:

Здесь включаем при необходимости ESXi Shell и SSH-доступ к нашему ESXi-хосту путем выбора соответствующих строк и жмем Enter:

Создание хранилища данных

Для хранения файлов виртуальных машин можно создать специальное хранилище данных. Для этого подключаем диск (или несколько) к серверу ESXi.

Важно! Для производственных сред рекомендуется использовать RAID 1 или RAID 10. Это поможет создать достаточный запас места и снизить вероятность потерять данные при повреждении диска. Но, применение RAID не является заменой организации резервного копирования.

Теперь будем использовать VMware Host Client для управления ESXi-хостом. Если выберем пункт «Host» в навигации, сможем просмотреть всю информацию о нем (версия, имя, CPU, память и состояние хранилища):

Перейдем непосредственно к созданию стораджа. В навигации в разделе «Virtual Machines» выбираем «Storage» и кликаем на кнопку «New datastore»:

Здесь проходим следующие шаги:

  • Выбираем параметры разбивки. Пока пусть будет все по умолчанию (полный диск);
  • Для завершения создания нового хранилища данных нажимаем кнопку «Finish» в пункте «Ready to complete», после чего появится предупреждение: «The entire contents of this disk are about to be erased and replaced with the specified configuration, are you sure?».
  • Подтверждаем. После этого новый сторадж появится в списке хранилищ на соответствующей вкладке.

Проделав все эти операции, мы полностью подготовили наш первый хост ESXi (192.168.11.30) к созданию виртуальных машин.

Развертывание других ESXi-хостов

По аналогии с предыдущим разворачиваем второй хост ESXi (192.168.11.27), который планируем применять для запуска виртуальных машин.

Развертывание vCenter Server

Мастер-установщик vCenter Server проходит два этапа.

Stage 1

Introduction. Здесь нам подробно показывают, как будет устанавливаться наш vCenter. Кнопочкой «Next» проходим до конца:

End user license agreement. Здесь лицензионное соглашение, которое следует принять.

vCenter Server deployment target. На этом этапе следует указать параметры первого хоста ESXi, где будет развернут в итоге vCenter:

ESXi host or vCenter Server name: 192.168.11.30

Set up vCenter Server VM. Здесь вводится имя vCenter VM и устанавливается пароль администратора для vCenter Server Appliance:

Select datastore. В этом разделе выбирается место хранения этого vCenter Server, достаточное для развертывания виртуальной машины. У нас он уже готов – это «datastore100». Включаем режим тонкого диска («Enable Thin Disk Mode»):

Configure network settings. Сетевые настройки в нашем случае будут следующими:

Network: VM Network

IP version: IPv4

IP assignment: static

IP address: 192.168.11.31

Subnet mask of prefix length: 255.255.255.0

Default gateway: 192.168.11.2

DNS servers: 192.168.11.2

Ready to complete stage 1. Проверяем все настройки и соглашаемся с завершением первого этапа установки:

Какое-то время на экране будет прогресс-бар разворота vCenter 7.0.

Stage 2

Introduction. Нам аналогично сообщают, что будет происходить на данном этапе. Чтобы продолжить, нажимаем «Next».

vCenter Server configuration. Выбираем настройки синхронизации времени и включаем доступ к SSH:

Time synchronization mode: Synchronize with the ESXi host

SSH access: Enabled

SSO configuration. Выбираем опцию «Create a new SSO domain»:

Single Sign-On domain name: vsphere.local

Single Sign-On user name: administrator

Single Sign-On password: Enter a password and confirm the password

Configure CEIP. Убираем галочку, если не хотим отправлять статистику в VMware и идем далее:

Ready to complete. Проверяем все, что задали, и жмем «Finish».

Важно! Ни в коем случае не прерывайте процесс установки vCenter. Иначе придется все начинать сначала.

Снова видим прогресс-бар установки. По завершению автоматически запустится vCenter Server Appliance. Если этого не случилось, нужно подключиться к хосту ESXi с VCSA и запустить в VMware Host Client виртуальную машину вручную:

К vCenter VM можно подключиться через консоль VCSA напрямую. Для этого в клиенте щелкаем на предварительный просмотр ВМ, после чего перейдем в автономное приложение VMware Remote Console или же в VMware Workstation, чтобы открыть управление клавиатурой и мышью. Здесь будут отображены все данные vCenter: версия, конфигурация ЦП, памяти, IP-адрес, а также ссылки для управления VCSA. Нажимаем F2 и вводим назначенные в процессе установки vCenter данные – точно так же, как редактировались настройки для ESXi:

Перейдем в раздел «Administration» и в «Edit» поменяем срок действия пароля. Можно отключить эту функцию вообще, чтобы не отслеживать его истекание в дальнейшем.

Настройка среды vSphere 7.0

После создания и конфигурирования ESXi, инсталляции и настройки vCenter, можно приступать к созданию виртуальных машин и применению разнообразных функций vSphere.

Важно! Веб-клиент на Flash для этой версии vSphere является устаревшим – доступен только HTML5 vSphere Client.

Создание дата-центра

Дата-центр представляет собой логический контейнер, используемый для организации ESXi-хостов, кластеров и виртуальных машин. Правой кнопкой мыши кликаем на vCenter server (у нас 192.168.11.31) и выбираем в открывшемся меню «New Datacenter»:

В появившемся окне вбиваем его имя.

Добавление хостов ESXi

Теперь, когда у нас есть новый дата-центр, необходимо добавить в него ESXi-хосты. Кликаем правой кнопкой мыши на его имя и в открывшемся меню выбираем «Add Host»:

Откроется окошко мастера добавления хоста, где, двигаясь по пунктам меню при помощи кнопки «Next», мы обозначим все его параметры:

Name and location. Задание имени/IP-адреса хоста ESXi (192.168.11.30 у нас):

Connection settings. Вводим имя пользователя и пароль.

Host summary. Проверяем сводку по хосту.

Assign license. Вводим серийный номер vSphere 7.0. Либо же останется режим Evaluation:

Lockdown mode. Рекомендуется выключать этот режим для сохранения возможности подключаться к ESXi-хосту напрямую, в обход vCenter. То есть даже если машина vCenter не работает:

VM location. Здесь надо выбрать дата-центр для размещения ВМ (в нашем случае Datacenter1):

Ready to complete. Проверяем все выбранные нами параметры хоста и, если все хорошо, жмем «Finish».

Итак, один хост нам удалось добавить в окружение vCenter. У нас, к примеру, vCenter VM работает на 192.168.11.30. Аналогичным образом добавляем и второй хост ESXi (192.168.11.27):

В развороте большого количества машин очень полезны рекомендованные вендором шаблоны, а также VMware vApps для апробированных конфигураций. Но, это уже тема для отдельного подробного разговора.

Настройка SSO в VMware VirtualCenter Server

Что такое SSO

Давайте для начала разберемся, что такое Single Sign-On (SSO) и как эта технология работает. Если в двух словах, то это механизм единого входа в систему или в приложения, где одна есть куча корпоративных сервисов, которые благодаря базе данных SSO, идентифицируют вас и автоматически предоставляют доступ к корпоративным ресурсам, без вашего участия (повторного ввода логина и пароля)

Настройка SSO в VMware VirtualCenter Server-2

Сама VMware настоятельно рекомендует производить установку SSO вместе с сервером vCenter. Одна версия SSO может обслуживать до 1000 хостов ESXi и 10 000 виртуальных машин.

  • Поддержка односторонних и двусторонних AD-трастов
  • Поддержка нескольких лесов
  • Можно использовать локальную аутентификацию без домена, если это необходимо
  • Появилось множество средств для траблшутинга и диагностики решения

Зеленым отмечено, какие компоненты можно настраивать с помощью Single Sign-On

Настройка SSO в VMware VirtualCenter Server-9

Настройка Single Sign-On

Установку Single Sign-On мы производили в момент установки VMware VirtualCenter Server, посмотреть можно вот тут, там и задавался пароль для административной, учетной записи administrator@vsphere.local. Я же хочу показать, как настроить SSO, чтобы вы могли раздавать права пользователям Active Directory в VMware VirtualCenter Server.

Настройка Single Sign-On-1

В итоге у вас появится возможность перейти на сайт.

Настройка Single Sign-On-2

У вас откроется форма ввода логина и пароля.

Настройка SSO в VMware VirtualCenter Server-4

Далее переходим в административный раздел, вкладка Administration.

Настройка SSO в VMware VirtualCenter Server-5

Далее идем в Configuration > identity Sources и нажимаем кнопку плюсик, для добавления подключения к Active Directory.

Настройка SSO в VMware VirtualCenter Server-6

в окне identity Source у вас будет вот такой выбор:

  • Active Directory (integrated Windows Autentification)
  • Active Directory as a LDAP Server
  • Open LDAP
  • Local OS

Настройка SSO в VMware VirtualCenter Server-7

Настройка Active Directory (integrated Windows Autentification)

Настройка Active Directory (integrated Windows Autentification), как метода аутентификации, наверное самая простая, от вас потребуется две вещи:

  • Чтобы сервер VMware VirtualCenter Server был присоединен к домену
  • Вы должны в настройках указать название доменного имени

Active Directory (integrated Windows Autentification)-1

Преимущество, что данный метод, настраивается за пол минуты, но он менее безопасный, по сравнению использованием SPN имени. Первым делом вам нужно проверить нет ли у вас для вашего VMware VirtualCenter Server созданного SPN. Формат команды в командной строке Windows вот такой:

Active Directory (integrated Windows Autentification)-3

Думаю вы в первый раз уж точно получите, что SPN не найден. Далее нам его нужно задать для SSO.

Далее заполняете нужные поля в Active Directory (integrated Windows Autentification)

Active Directory (integrated Windows Autentification)-2

Кстати можно посмотреть в Active Directory параметр в учетной записи службы, где прописывается ServicePrincipalName

Настройка SSO в VMware VirtualCenter Server-8

Настройка Active Directory as a LDAP Server

И еще хочу показать, как настроить SSO через Active Directory as a LDAP Server, то же распространенный метод. Давайте просто пробежимся, по нужным полям.

Минусом данного решения, является, то что если контроллер домена не доступен, то вы не сможете пройти аутентификацию
  • Name > указываете любое понятное вам имя, оно не на что не влияет
  • Base DN for users > поиск по пользователям
  • Dmain name > FQDN имя домена
  • Domain alies > краткое имя домена
  • Base DN for groups> поиск по группам
  • Primary server URL > LDAP сервер
  • Secondary server URL > LDAP сервер
  • Username > имя пользователя, от имени которого будет подключение к AD
  • Password > пароль

После ввода данных, нажмите кнопку Test Connection, для понимания того, получилось ли подключиться по LDAP.

Настройка Active Directory as a LDAP Server

В принципе этих двух методов, достаточно для настройки SSO в VMware VirtualCenter Server,

VCENTER Single Sign-On (SSO) является составной частью инфраструктуры VMware Cloud. SSO занимается управление идентификацией для администраторов и приложений, которые взаимодействуют с VSPHERE платформы.

Как SSO 5.5 отличается от SSO 5.1?

Архитектура остается тем же самым. Тем не менее, есть много изменений в SSO 5.5.

Каковы ключевые возможности SSO 5.5?
SSO 5.5 теперь мульти-мастер модель.
Он имеет встроенную функцию автоматического репликации между различными сайтов SSO.
Это не есть база данных.
Существует только одна домена по умолчанию для источников, удостоверяющих личность.

Каковы компоненты, которые устанавливаются с SSO 5.5?

Компоненты, которые устанавливаются с SSO 5.5 включают в себя:

VMware Службы сертификации
VMware Directory Services
VMware управления идентификацией услуги
VMware KDC услуги
VMware маркеров безопасности Службы

Какие существуют продукты / компоненты, с которыми SSO 5.5 поддерживается?
SSO 5.5 поддерживается:
VMware VCENTER Сервер
VMware VCENTER Инвентаризация Услуги
VMware VSPHERE защите данных
VMware VCENTER Orchestrator
Веб-клиент VMware VSPHERE
VMware Обозреватель журнала
VMware VSHIELD менеджер
Примечание: VMware vCloud директор частично интегрирована с SSO.

Как SSO 5.5 распостраняется?

VCENTER Single Sign-On доступен как пакетом, Windows. SSO также встроены в VCENTER сервера Appliance (VCSA).

Какие простые режимы развертывания Sign-On возможны с Appliance VCENTER Server? С помощью Windows на основе VCENTER сервер?

В настоящее время основной режим поддерживается с Appliance VCENTER Server. Appliance VCENTER Сервер может быть указал на отдельном VCENTER один экземпляр Sign-On, если вам нужен высокого уровня доступности конфигурации (HA).

Окна на основе единого входа требуется в данный момент для развертывания высокой доступности или географически дисперсной (многоузловое) реализации. Для получения дополнительной информации см. Определение VCENTER однопользовательский режим развертывания Sign-On сервера (2035817) .

Что происходит, когда 5.5 сервер SSO не работает?

Если 5.5 сервер SSO не работает, вы не можете войти в VCENTER сервера или любой из компонентов, которые зависит от него.

Примечание: Ваш VCENTER Сервер будет еще и работает, но без интерфейса управления.

Нужно ли мне базу данных для успешной установки / запуска SSO 5.5?

Технология единого входа (Single sign-on SSO) — метод аутентификации, который позволяет пользователям безопасно аутентифицироваться сразу в нескольких приложениях и сайтах, используя один набор учетных данных.

Как работает SSO?

SSO базируется на настройке доверительных отношений между приложением, известным как провайдер услуг, и системой управления доступами, например, OneLogin. Такие доверительные отношения часто базируются на обмене сертификатом между системой управления доступами и провайдером услуг. Такой сертификат может использоваться, чтобы обозначить идентификационную информацию, которая отправляется от системы управления доступами провайдеру услуг, таким образом провайдер услуг будет знать, что информация поступает из надежного источника. В SSO идентификационные данные принимают форму токенов, содержащих идентификационные значения информации о пользователе такие, как email или имя пользователя.

Порядок авторизации обычно выглядит следующим образом:

  1. Пользователь заходит в приложение или на сайт, доступ к которому он хочет получить, то есть к провайдеру услуг.
  2. Провайдер услуг отправляет токен, содержащий информацию о пользователе (такую как email адрес) системе SSO (так же известной, как система управления доступами), как часть запроса на аутентификацию пользователя.
  3. В первую очередь система управления доступами проверяет был ли пользователь аутентифицирован до этого момента. Если да, она предоставляет пользователю доступ к приложению провайдера услуг, сразу приступая к шагу 5.
  4. Если пользователь не авторизовался, ему будет необходимо это сделать, предоставив идентификационные данные, требуемые системой управления доступами. Это может быть просто логин и пароль или же другие виды аутентификации, например одноразовый пароль (OTP — One-Time Password).
  5. Как только система управления доступами одобрит идентификационные данные, она вернет токен провайдеру услуг, подтверждая успешную аутентификацию.
  6. Этот токен проходит “сквозь браузер” пользователя провайдеру услуг.
  7. Токен, полученный провайдером услуг, подтверждается согласно доверительным отношениям, установленным между провайдером услуг и системой управления доступами во время первоначальной настройки.
  8. Пользователю предоставляется доступ к провайдеру услуг.

Если пользователь попробует получить доступ к другому сайту, то понадобится настройка подобных доверительных отношений в соответствии с методом SSO. Порядок аутентификации в этом случае будет состоять также из вышеизложенных шагов.

Что такое токен в контексте SSO?

Токен — это набор информации или данных, который передается из одной системы в другую в процессе исполнения SSO. Данные могут быть просто email адресом и информацией о системе, отправившей токен. Токены должны обладать цифровой подписью для получателя, чтобы подтвердить, что он поступил из надежного источника. Сертификат для электронной подписи предоставляется во время первоначального этапа настройки.

Является ли технология SSO безопасной?

Ответом на этот вопрос будет "в зависимости от ситуации".

Есть несколько причин, по которым стоит внедрить SSO. Метод единого входа может упростить работу с логином и паролем, как для пользователя, так и для администратора. Пользователям больше не придется держать в голове все учетные данные, теперь можно просто запомнить один более сложный пароль. SSO позволяет пользователям намного быстрее получить доступ к приложениям.

SSO также сокращает количество времени, потраченного на восстановление пароля с помощью службы поддержки. Администраторы могут централизованно контролировать такие факторы, как сложность пароля и многофакторную аутентификацию (MFA). Администраторы также могут быстрее отозвать привилегии на вход в систему, если пользователь покинул организацию.

Однако, у SSO есть некоторые недостатки. Например, вероятно, вам захочется, чтобы определенные приложения оставались заблокированы/менее открыты к доступу. По этой причине важно выбрать то решение SSO, которое, к примеру, даст вам возможность запросить дополнительный фактор проверки аутентификации прежде, чем пользователь авторизуется или оградит пользователей от доступа к определенным приложениям пока не обеспечено безопасное соединение.

Как внедрить SSO?

Особенности внедрения SSO могут отличаться с учетом того, с каким именно решением SSO вы работаете. Но вне зависимости от способа, вам нужно точно знать какие цели вы преследуете. Убедитесь, что вы ответили на следующие вопросы:

  • С какими типами пользователей вы работаете и какие у них требования?
  • Вы ищете локальное или облачное решение?
  • Возможен ли дальнейший рост выбранной программной платформы вместе с вашей компанией и ее запросами?
  • Какие функции вам необходимы, чтобы убедиться в том, что процесс авторизации проходят только проверенные пользователи? MFA, Adaptive Authentication, Device Trust, IP Address Whitelisting, и т.д?
  • С какими системами вам необходимо интегрироваться?
  • Нужен ли вам доступ к программному интерфейсу приложения (API)?

Что отличает настоящую SSO от хранилища или менеджера паролей?

Важно понимать разницу между SSO (Технологией единого входа) и хранилищем или менеджерами паролей, которые периодически путают с SSO, но в контексте Same Sign-On — что означает “такой же/одинаковый вход”, а не “единый вход” (Single Sign-On). Говоря о хранилище паролей, у вас может быть один логин и пароль, но их нужно будет вводить каждый раз при переходе в новое приложение или на новый сайт. Такая система попросту хранит ваши идентификационные данные для других приложений и вводит их когда это необходимо. В данном случае между приложением и хранилищем паролей не установлены доверительные отношения.

С SSO, после того, как вы вошли в систему, вы можете получить доступ ко всем одобренным компанией сайтам и приложениям без необходимости авторизовываться снова. Это включает в себя как облачные, так и локально установленные приложения, часто доступные через сам сервис SSO (также известный, как сервис авторизации).

В чем разница между программным обеспечением единого входа и решением SSO?

Изучая доступные варианты единого входа, вы можете увидеть, что их иногда называют программным обеспечением единого входа, а не решением единого входа или провайдером единого входа. Часто разница состоит лишь в том, как позиционируют себя компании. Фрагмент программного обеспечения предполагает локальную установку. Обычно это то, что разработано для определенного набора задач и ничего более. Программный продукт предполагает, что есть возможность расширяться и кастомизировать потенциальные возможности исходного варианта. Провайдер будет отличным вариантом, чтобы обратиться к компании, которая производит или пользуется программным продуктом. Например, OneLogin в качестве провайдера SSO.

Бывают ли разные типы SSO?

Когда мы говорим о едином входе (SSO), используется множество терминов:

  • Federated Identity Management (FIM)
  • OAuth (OAuth 2.0 в настоящее время)
  • OpenID Connect (OIDC)
  • Security Access Markup Language (SAML)
  • Same Sign On (SSO)

На самом деле, SSO это часть более крупной концепции под названием Federated Identity Management, поэтому иногда SSO обозначается, как федеративная SSO. FIM просто относится к доверительным отношениям, созданным между двумя или более доменами или системами управления идентификацией. Система единого входа (SSO) — это характеристика/фича, доступная внутри архитектуры FIM.

OAuth 2.0 — это особая программная платформа, которая также может считаться частью архитектуры FIM. OAuth фокусируется на доверительных отношениях, предоставляя доменам идентификационную информацию пользователя.

OpenID Connect (OIDC) — это уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO.

Security Access Markup Language (SAML) — это открытый стандарт, который также разработан для обеспечения функциональности SSO.


image

Система Same Sign On, которую часто обозначают, как SSO, на самом деле, не похожа Single Sign-on, т.к не предполагает наличие доверительных отношений между сторонами, которые проходят аутентификацию. Она более привязана к идентификационным данным, которые дублируются и передаются в другие системы когда это необходимо. Это не так безопасно, как любое из решений единого входа.

Также существуют несколько конкретных систем, которые стоит упомянуть, говоря о платформе SSO: Active Directory, Active Directory Federation Services (ADFS) и Lightweight Directory Service Protocol (LDAP).

Active Directory, который в настоящее время именуется, как Active Directory Directory Services (ADDS) — это централизованная служба каталогов Microsoft. Пользователи и ресурсы добавляются в службу каталогов для централизованного управления, а ADDS работает с такими аутентификационными протоколами, как NTLM и Kerberos. Таким образом, пользователи, относящиеся к ADDS могут аутентифицироваться с их устройств и получить доступ к другим системам, интегрированным с ADDS. Это и есть форма SSO.

Active Directory Federation Services (ADFS) это тип управления федеративной идентификацией (Federated Identity Management system), которая также предполагает возможность Single Sign-on. Он также поддерживает SAML и OIDC. ADFS преимущественно используется для установления доверительных отношений между ADDS и другими системами, такими как Azure AD или других служб ADDS.

Протокол LDAP (Lightweight Directory Service Protocol) — это стандарт, определяющий способ запроса и организации информационной базы. LDAP позволяет вам централизованно управлять такими ресурсами, как пользователи и системы. LDAP, однако, не определяет порядок авторизации, это означает, что он не устанавливает непосредственный протокол, используемый для аутентификации. Но он часто применяется как часть процесса аутентификации и контроля доступа. Например, прежде, чем пользователь получит доступ к определенному ресурсу, LDAP сможет запросить информацию о пользователе и группах, в которых он состоит, чтобы удостовериться, что у пользователя есть доступ к данному ресурсу. LDAP платформа на подобие OpenLDAP обеспечивает аутентификацию с помощью аутентификационных протоколов (например, Simple Authentication и Security Layer SASL).

Как работает система единого входа как услуга?

SSO функционирует также, как и многие другие приложения, работающие через интернет. Подобные OneLogin платформы, функционирующие через облако, можно отнести к категории решений единого входа “Software as a Service” (SaaS).

Что такое App-to-App (приложение-приложение) SSO?

В заключение, возможно вы слышали о App-to-App SSO. Пока еще такой подход не является стандартным. Такое понятие больше используется SAPCloud для обозначения процесса передачи идентификационных данных пользователя из одного приложения в любое из других, состоящих в их экосистеме. В какой-то степени такой метод присущ OAuth 2.0, но хочется снова подчеркнуть, что это не стандартный протокол или метод. В настоящее время он является характерным только для SAPCloud.

Материал написан еще в декабре 13 года, но в связи с редакционными правилами, опубликована только сейчас. К сожалению или к счастью, но те баги, что описаны в этой статье, уже закрыты вышедшими обновлениями.

Введение

Что такое VMware vSphere 5.5

Новые возможности

VMware vSphere 5.5 характерна множественными изменениями и новыми возможностями о которых можно было бы написать целую статью. В данном разделе коснусь только тех, что показались мне наиболее интересными. Кроме некоторых улучшений в работе гипервизора, а так же традиционного увеличения количества поддерживаемой памяти, процессоров, NUMA-узлов, теперь полноценно поддерживаются FC-адаптеры, с пропускной способностью в 16 Гбит/с (ранее до 8 Гбит/с). Подобные положительные изменения затронули и бесплатную версию ESXi. Здесь наконец то сняты ограничения на объем оперативной памяти. Ранее использовалось только 32 Гб. К основным улучшениям виртуальных машин можно отнести обновление виртуального железа до версии 10. Пожалуй, самым примечательным в этом обновлении стал новый виртуальный SATA-контроллер позволяющий подключить к одной ВМ до 120 дисковых устройств. Правда, найти практическое применение такому новшеству, кажется не просто.

Расширена поддержка vGPU. Теперь допустимо использование графических адаптеров от AMD. Ранее возможно было применение только карт от NVIDIA. Полный список поддерживаемых моделей.

Как и в предыдущей версии платформы возможны три техники графического ускорения трехмерной графики:

vDGA — монопольное выделение графического адаптера (GPU) конкретной виртуальной машине. В таком режиме, не поддерживаются динамические сервисы(vMotion, HA, DRS) для этой ВМ.

Касательно версии vSphere 5.5 примечательно, что 3D ускорение поддерживаются не только в Windows 7/8, но и в популярных дистрибутивах Linux таких как Fedora 17, Ubuntu 12, RedHat 7 а так же в более новых версиях этих ОС. Указаны очень старые версии, может написать Fedora 17+. Очень старые? RedHat 7 и Ubuntu 12 – текущие версии да и Fedora 17 не особо старая. Тут указанны минимальные планки и сказано о поддержке более новых. При этом возможно применение миграции ВМ (VMware vMotion) между хостами с графическими адаптерами разных вендоров. В случае если возникнут какие-либо проблемы совместимости или же на целевом хосте, вовсе не окажется графического адаптера, будет задействовано программное 3D-ускорение.

Приятные изменения для пользователей vCenter Server Appliance. В предыдущей версии, при использовании встроенной базы данных было возможно управлять 5-ю хостами ESXi и 50-ю ВМ. В этом обновлении, модуль для управления виртуальной инфраструктурой был существенно переработан и теперь в качестве БД используется vPostgres с поддержкой до 500 хостов ESXi и 5000 виртуальных машин. Данное обновление говорит о большей готовности и надежности модуля, что допускает его применение в крупных инфраструктурах.

Приятные изменения Virtual Machine File System(VMFS). Теперь VMware vSphere 5.5 поддерживает vmdk-диски объемом до 62 Тб! Такого же размера могут быть и RDM-диски в режиме виртуальной совместимости. Ранее, максимальный размер дисков, обоих типов составлял 2 Тб. Такое же ограничение действует и сейчас для технологий FT и vSAN(до 2 Тб).

Обновления поддержки MSCS. Наконец, сняты некоторые ограничения при создании кластеров от Microsoft. Теперь поддерживаются:

  • ОС MicrosoftWindows 2012
  • Политика путей Round-robin
  • Протоколы iSCSI и Fibre Channel over Ethernet(FCoE)

Ранее, поддержка кластеров MSCS была ограничена только протоколом Fibre Channel.

Улучшения механизма vSphere Replication. Появилась новая функция Storage DRS Interoperability. Позволяет балансировать ВМ по хранилищам средствами Storage vMotion, при этом не прерывая процесс репликации. Кроме этого появилась возможность осуществлять реплику виртуальных машин между кластерами не с общими хранилищами (non-shared storage). Поддерживается технология vSAN. Машины на таких хранилищах могут быть реплицированы. Так же улучшили интеграцию с веб-клиентом, что позволяет наблюдать состояние репликации в различных представлениях vCenter.

vSAN (Виртуальная SAN) – это технология позволяющая построить единый пул хранения из множества локальных дисков ESXi-хостов с функциями отказоустойчивости и кэширования. Достигается это путем полного дублирования и репликации данных между узлами кластера. На таком хранилище, безо всяких ограничений поддерживаются снапшоты, связанные клоны, vSphere Replication, а так же работают механизмы HA, DRS, vMoution. Для каждой из ВМ размещаемой на таком хранилище доступны расширенные настройки как; емкость, уровень отказоустойчивости (степень дублирования данных), уровень производительности (количество SSD-кеша).

На смену технологии Swap to SSD пришла vSphere Flash Read Cache (vFRC). Данный механизм позволяет объединить локальные SSD-устройства ESXi-хостов в единый пул для целей кэширования данных хоста или ВМ. Объем ресурсов такого пула указывается для каждой ВМ в отдельности в разделе настроек виртуального диска.

Улучшения Link Aggregation Control Protocol (LACP). Первоначальная поддержка LACP в распределенном коммутаторе VMware была реализована еще в 5.1. В 5.5 она значительно расширена. Теперь доступны 22 алгоритма балансировки и возможно создание до 64 групп агрегации (Link Aggregation Group (LAG)) на одном распределенном виртуальном коммутаторе.

К сожалению, позитивные ожидания по поводу механизма Fault Tolerance(FT) были напрасны. Ограничения для ВМ остались те же: Только один vCPU Отсутствие снапшетов. располагаться на общем хранилище как минимум 2 выделенных сетевых адаптера(1 Гб) помимо сети виртуальных машин (один для FT logging, второй для vMotion). Подробнее про все сохранившиеся ограничения можно ознакомиться тут

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

На встречу тенденциям

Все движется в сторону облачных вычислений и веб-сервисов и VMware не стала тут исключением. В последних версиях vSphere можно наблюдать достаточно уверенные шаги в сторону унификации и приведению некоторых компонентов к сервис-ориентированной архитектуре.

vCenter Single Sign-On server (SSO)

В новой версии SSO появилась улучшенная и новая поддержка следующих компонентов:

vCenter Orchestrator vSphere Replication vSphere AppHA vCloud Director vCloud Networking and Security (vCNS)

БАГ! Как уже сказано ранее, кроме сторонних служб каталогов и внутренней базы учетных записей, для авторизации так же могут быть использованы локальные пользователи и группы сервера на котором установлен SSO. Проблема в том, что доменные учетные записи помещенные в локальную группу не распознаются SSO. То есть при входе с помощью доменной учетной записи вложенной в локальную группу, вы не получите права назначенные родительской локальной группе. Консоль будет пуста. Решение. Добавляйте и назначайте роли доменным группам и пользователям в отдельности.

БАГ! В случае, если vCenter Single Sign-On работает на Windows Server 2012 и контроллер домена, так же под управлением этой ОС. Доменная авторизация при подключении к vCenter с помощью любого клиента, работать не будет. Хотя сопоставление доменных групп и назначение им прав проблем не вызовет, при авторизации, в доступе будет отказано. Решение. Необходимо войти на сервер с установленной ролью vCenter Single Sign-On как администратор. Остановить службу VMware Identity Management Service Заменить %WINDIR%System32idm.dll на одноименную библиотеку (находится в zip-архиве) скачанную тут в разделе Attachments. Запустить выше остановленную службу. Доменная авторизация будет работать.

vSphere Web Client

Ложка дегтя

По мимо небольших проблем, в том числе и описанных выше, хочется отметить некоторые моменты, которые в принципе не влияют на работу продукта, но немного портят о нем впечатление.

Есть такой продукт, vShield Manager входящий в семейство продуктов VMware vCloud Networking and Security представленный в виде готовой виртуальной машины(Virtual appliance). Он является сервером управления инфраструктурой безопасности ЦОД. Конкретно, с его помощью осуществляется управление такими компонентами как:

VMware vSphere 5.5 Новые возможности

Функционал достаточно богатый и возможно я придираюсь. Но его реализация на мой взгляд мягко говоря не самая лучшая. Во первых, Virtual Appliance, а точнее его настройка совершенно не похожа на таковой процесс в других продуктах от VMware. Начиная от не стандартных учетных данных, заканчивая необходимостью выполнять специфические команды в консоли для настройки сети. В конечном итоге получаем, веб-интерфейс у которого из сходств с остальными продуктами VMware, лишь логотип (Рис №3). И никакой интеграции с vSphere Web Client. Но, что расстроило больше всего, так это реализация межсетевого экрана для виртуальных машин. Выполнено это следующим образом. На каждом хосте, помимо созданного вами виртуального коммутатора создается еще один стандартный vSwitch в который включается специальная служебная ВМ. Весь трафик из созданного виртуального свитча через специальный виртуальный интерфейс направляется в новый свитч и в результате проходит через служебную ВМ. В итоге на каждом хосте дополнительно разворачивается по одной служебной ВМ, что на мой взгляд кажется слишком сложным решением. Например, у Citrix в платформе XenServer фильтрация трафика виртуальных машин осуществляется на уровне виртуального коммутатора с помощью простых правил для конкретного виртуального интерфейса, ВМ или всего кластера.
Рис. №3. Интерфейс vShield Manager

Выводы

На различных интернет ресурсах, форумах, бытует мнение что уменьшение сроков выпуска новых релизов не идет VMware на пользу. Подобные высказывания оправданны. Они возникают из-за большего чем в прошлых выпусках количества проблем и откровенных багов. Со своей стороны, как человек осуществлявший на протяжении последних месяцев внедрение этой платформы, хочу сказать, что все закончилось успешно. Даже при том, что разворачивалась самая первая публичная сборка. Сейчас же, доступны обновленные версии продуктов с внесенными исправлениями и доработками. Поэтому, переходить на новый релиз уже не так боязно. Именно в этом внедрении как нельзя кстати пришлась поддержка VMDK дисков и RDM-устройств более 2 Тб, а так же расширенные возможности для построения кластеров Microsoft. Остается только приучить себя использовать vSphere Web Client и дождаться его тесной интеграции со всеми продуктами VMware.

Читайте также: