Vcenter single sign on что это
Vcenter single sign on что это
Добрый день уважаемые читатели и гости блога, я продолжаю вам освещать технологии виртуализации от компании VMware и сегодня я хочу вам рассказать как производится настройка SSO в VMware VirtualCenter Server. Так как благодаря этой технологии вы сможете произвести аутентификацию в VMware VirtualCenter Server, через Active Directory, что согласитесь с наличием домена в вашей локальной сети, очень гибко позволит разграничивать права на нужные объекты виртуальной инфраструктуры.
Что такое SSO
Давайте для начала разберемся, что такое Single Sign-On (SSO) и как эта технология работает. Если в двух словах, то это механизм единого входа в систему или в приложения, где одна есть куча корпоративных сервисов, которые благодаря базе данных SSO, идентифицируют вас и автоматически предоставляют доступ к корпоративным ресурсам, без вашего участия (повторного ввода логина и пароля)
Сама VMware настоятельно рекомендует производить установку SSO вместе с сервером vCenter. Одна версия SSO может обслуживать до 1000 хостов ESXi и 10 000 виртуальных машин.
Зеленым отмечено, какие компоненты можно настраивать с помощью Single Sign-On
Настройка Single Sign-On
Установку Single Sign-On мы производили в момент установки VMware VirtualCenter Server, посмотреть можно вот тут, там и задавался пароль для административной, учетной записи administrator@vsphere.local. Я же хочу показать, как настроить SSO, чтобы вы могли раздавать права пользователям Active Directory в VMware VirtualCenter Server.
Открываем любой браузер, я лично пользуюсь Google Chrome 57 версии и переходим по адресу https://адрес вашего сервера:9443/vsphere-client и логинимся. При первом обращении у вас может появиться сообщение, что ваше подключение не защищено. Нажмите кнопку дополнительно.
В итоге у вас появится возможность перейти на сайт.
У вас откроется форма ввода логина и пароля.
Далее переходим в административный раздел, вкладка Administration.
Далее идем в Configuration > identity Sources и нажимаем кнопку плюсик, для добавления подключения к Active Directory.
в окне identity Source у вас будет вот такой выбор:
Настройка Active Directory (integrated Windows Autentification)
Настройка Active Directory (integrated Windows Autentification), как метода аутентификации, наверное самая простая, от вас потребуется две вещи:
Преимущество, что данный метод, настраивается за пол минуты, но он менее безопасный, по сравнению использованием SPN имени. Первым делом вам нужно проверить нет ли у вас для вашего VMware VirtualCenter Server созданного SPN. Формат команды в командной строке Windows вот такой:
Думаю вы в первый раз уж точно получите, что SPN не найден. Далее нам его нужно задать для SSO.
Далее заполняете нужные поля в Active Directory (integrated Windows Autentification)
Все SSO должно работать. Если, что ссылка на рекомендации VMware https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058298
Кстати можно посмотреть в Active Directory параметр в учетной записи службы, где прописывается ServicePrincipalName
Настройка Active Directory as a LDAP Server
И еще хочу показать, как настроить SSO через Active Directory as a LDAP Server, то же распространенный метод. Давайте просто пробежимся, по нужным полям.
После ввода данных, нажмите кнопку Test Connection, для понимания того, получилось ли подключиться по LDAP.
В принципе этих двух методов, достаточно для настройки SSO в VMware VirtualCenter Server,
Что такое VCENTER Single Sign-On 5.5 (SSO)?
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).
Каковы минимальные системные требования для работы SSO 5.5?
Процессор — Intel или AMD процессор x64 с двумя или более логических ядер, каждое со скоростью 2 ГГц
Память — 3 Гб
Дисковое хранилище — 2 Гб
Сеть скорость — 1 Гбит
Что происходит, когда 5.5 сервер SSO не работает?
Если 5.5 сервер SSO не работает, вы не можете войти в VCENTER сервера или любой из компонентов, которые зависит от него.
Примечание: Ваш VCENTER Сервер будет еще и работает, но без интерфейса управления.
Нужно ли мне базу данных для успешной установки / запуска SSO 5.5?
Подготовка к миграции vCenter Server в vSphere 6.0 Update 2m. Часть 1
Недавно VMware объявили о выходе vSphere 6.0 Update 2m, официально поддерживающего инструмент миграции. Под катом чеклист, как подготовится к миграции (важные точки проверки), какие модели миграции есть, и на что обратить внимание при миграции с 5.5 Windows vCenter на версию 6.0
Миграция автоматически включена в новый vCenter Server Appliance 6.0 Update 2, уже доступна конфигурация миграции, и включена по умолчанию функция сохранения критических данных из Windows vCenter Server 5.5.
Если в вашей среде vSphere используются VDS (virtual distributed switch), то они мигрируют автоматически без дополнительных действий. Если вы хотите сохранить свою историю конфигураций и данные о производительности (статистику, события, задачи) с конфигурациями, есть опция которая позволяет перенести и эти данные. Только нужно помнить — это увеличит время вашей миграции и объем данных в вашей БД в vCenter Server.
Очень рекомендую использовать статью из вики KB 214620, которая поможет оценить и показать каким будет процесс миграции (как долго, какие ресурсы задействует и т.д.). В этом посте есть чек-лист того что нужно учитывать при подготовке к миграции, это имеет отношение к vSphere Single Sign-On домену и модели развертывания vCenter Server. Есть два самых главных момента, о инструменте миграции, которые я бы хотел особо подчеркнуть.
Первое. Будет выполнена не только ваша миграция, но и обновление версии 5.5 (с любыми апдейтами) до версии 6.0 (Update 2). Перед миграцией проверьте все ли части VMware и все решения сторонних вендоров поддерживают vSphere 6.0. Процедура миграции и апдейта не изменилась с прошлой версии, но сейчас есть механизм, который значительно упростил этот процесс.
Второй важный момент – нужно удостоверится что все конфигурации Windows vCenter Server уже сохранены. Сюда входят такие (но не только) данные и настройки: IP адреса, FQDN, UUID, сертификаты и MoRef IDs. Это делает процесс миграции намного проще, так как все части структуры общаются с vCenter Server через стандарт идентификации UUID, и они будут задействованы уже после миграции, как было и в старой версии. Этот список пунктов проверки очень важная часть подготовки процесса безболезненной миграции.
vSphere домен
Золотое правило подготовки к любой миграции и апдейтам: «нужно хорошо знать свою ИТ-инфраструктуру». Есть две сферы, на которых также нужно сфокусироваться — это модели развертывания vSphere Single Sign-On домен (SSO) и vCenter Server.
Давайте вначале разберемся с SSO доменом. В vSphere 5.5 у вас должна быть возможность объединить vSphere SSO домен, если вам это необходимо. Единственная ваша возможность сделать такое объединение – это в версии 5.5, потому что в версии 6.0 это сделать будет невозможно.
Если у вас есть желание объединить домены vSphere SSO, необходимо до миграции сделать следующее:
• Разверните новый внешний SSO сервер
• Укажите vCenter Inventory Service, Web Client, и vCenter Server Service на новом SSO сервере
• Если вы идете от внутренней модели развертывания к внешней, должен быть установлен внутренний SSO компонент
После того, как процесс завершен, ваш SSO домен будет объединен, как показано на диаграмме справа, и вы можете приступать к процессу миграции. Во время этого объединительного процесса, обратите внимание, что есть — vSphere 6.0 SSO maximums. В этом гайде – детали, которые важны при объединении vSphere SSO домена в версии 5.5. Если вас устраивают ваша существующая топология vSphere SSO, тогда вы можете спланировать развертывание vCenter Server.
Модели развертывания
Это следующий важный момент в развертывании vCenter Server. Windows vCenter Server 5.5 имеет две модели развертывания: простая и пользовательская.
Простая модель включена во все службы vCenter Server, на одной виртуальной машине. С другой стороны, пользовательская модель позволяет разделить службы vCenter Server (SSO, Inventory Service, Web Client и vCenter Server) на разные виртуальные машины. В vSphere 6.0 упрощена модель развертывания благодаря внедренному компоненту Platform Services Controller (PSC). Теперь мы можем управлять разными службами, которые распределены по единичному домену vSphere SSO. В такие службы входят: Single Sign-On (SSO), управление сертификатами, лицензирование, роли, тегирование и категоризацию, управление общим доступом).
В vSphere 6.0 у нас также две модели развертывания, только теперь они называются «внутренняя» и «внешняя». Внутренняя модель развертывания vSphere 6.0 соответствует простой модели в версии 5.5. Это значит, что все сервисы vCenter Server и компонент PSC остаются на той же виртуальной машине. Во внешнем развертывании vSphere 6.0 на виртуальных машинах уже есть PSC компонент и vCenter. Сейчас каждый компонент отвечает и управляет службами. Список рекомендованных топологий для версии 6.0 здесь.
Среди преимуществ внешней модели внедрения Enhanced Linked Mode может делать автоматические масштабирование через добавление Enhanced Linked Mode и vCenter Server.
Важно! vSphere 6.0 Update 2m – НЕ позволяет менять топологию развертывания по время процесса миграции.
Правила внешней модели миграции версии 5.5:
• Не держите vCenter Inventory Service на той же виртуальной машине, что и внешний SSO Server. Внутренний SSO Server выключится после того как vSphere SSO Service мигрирует, сделав vCenter Inventory Service недоступным.
• Когда все службы разделены (SSO, vCenter Inventory Service, Web Client и vCenter Server, есть отдельно на каждой виртуальной машине) вам нужно всего лишь запустить ассистент миграции.
• Ассистент миграции сделает блокировку, когда все расширения с сохранными настройками будут установлены на vSphere SSO Server. Расширение с сохранением настроек – это может быть один из сервисов, таких как vCenter Inventory Service, Auto Deploy, и vSphere Authentication Proxy.
• Ассистент миграции просигнализирует, когда расширения без сохранения настроек будут установлены на vSphere SSO Server. Расширение без сохранения настроек, которые используют данные, но не хранят их — vSphere Web Client и Dump Collector.
• Доступна миграция vSphere SSO Servers в обход балансировщика загрузки.
VMware получили много вопросов о том, стоит или нет менять модель разворачивания vCenter Server из внутренней на внешнюю, и когда стоит менять модель внедрения — до или после процесса миграции. Если вам не нужно объединять домены SSO – тогда вначале используйте встроенную модель. После этого используйте cmsso-команду, чтобы пересобрать и заново сконфигурировать вашу внутреннюю модель на внешнюю. Больше информации по использованию cmsso для изменения своей топологии доступно здесь. Если вам нужно объединить SSO домены, тогда ваша внутренняя модель станет внешней как часть процесса объединения доменов. Когда процесс объединения завершен, вы можете начать процесс миграции. В миграции внешних моделей сначала идет миграция всех vSphere SSO серверов в рамках vSphere домена, а затем миграция всех серверов vCenter. Это ничем не отличается от процесса обновления.
Как было отмечено выше, процесс миграции и обновления не изменился. До сих пор есть много действий, которые нужно выполнить, перед тем как начать миграцию, но сейчас у нас появился инструмент, позволяющий сделать процесс миграции гораздо проще.
И дайте нам знать, у вас получилось мигрировать или нет, можете отписаться в комментариях или в Твиттере через тег #migrate2vcsa так что техподдержка VMware может это отследить и ответить.
Сейчас мы разобрались с разными моделями миграции, внутренней, внешней для SSO доменов и серверов vCenter, в следующем посте в этой серии мы узнаем больше насчет Windows vCenter Server.
Мы разобрали чеклист, на что стоит обратить внимание при миграции, в версии 5.5 Windows vCenter.
Выделенные серверы в надежных дата-центрах Германии!
Любая конфигурация, быстрая сборка и бесплатная установка
Как работает single sign-on (технология единого входа)?
Что такое single sign-on?
Технология единого входа (Single sign-on SSO) — метод аутентификации, который позволяет пользователям безопасно аутентифицироваться сразу в нескольких приложениях и сайтах, используя один набор учетных данных.
Как работает SSO?
SSO базируется на настройке доверительных отношений между приложением, известным как провайдер услуг, и системой управления доступами, например, OneLogin. Такие доверительные отношения часто базируются на обмене сертификатом между системой управления доступами и провайдером услуг. Такой сертификат может использоваться, чтобы обозначить идентификационную информацию, которая отправляется от системы управления доступами провайдеру услуг, таким образом провайдер услуг будет знать, что информация поступает из надежного источника. В SSO идентификационные данные принимают форму токенов, содержащих идентификационные значения информации о пользователе такие, как email или имя пользователя.
Порядок авторизации обычно выглядит следующим образом:
Если пользователь попробует получить доступ к другому сайту, то понадобится настройка подобных доверительных отношений в соответствии с методом SSO. Порядок аутентификации в этом случае будет состоять также из вышеизложенных шагов.
Что такое токен в контексте SSO?
Токен — это набор информации или данных, который передается из одной системы в другую в процессе исполнения SSO. Данные могут быть просто email адресом и информацией о системе, отправившей токен. Токены должны обладать цифровой подписью для получателя, чтобы подтвердить, что он поступил из надежного источника. Сертификат для электронной подписи предоставляется во время первоначального этапа настройки.
Является ли технология SSO безопасной?
Ответом на этот вопрос будет «в зависимости от ситуации».
Есть несколько причин, по которым стоит внедрить SSO. Метод единого входа может упростить работу с логином и паролем, как для пользователя, так и для администратора. Пользователям больше не придется держать в голове все учетные данные, теперь можно просто запомнить один более сложный пароль. SSO позволяет пользователям намного быстрее получить доступ к приложениям.
SSO также сокращает количество времени, потраченного на восстановление пароля с помощью службы поддержки. Администраторы могут централизованно контролировать такие факторы, как сложность пароля и многофакторную аутентификацию (MFA). Администраторы также могут быстрее отозвать привилегии на вход в систему, если пользователь покинул организацию.
Однако, у SSO есть некоторые недостатки. Например, вероятно, вам захочется, чтобы определенные приложения оставались заблокированы/менее открыты к доступу. По этой причине важно выбрать то решение SSO, которое, к примеру, даст вам возможность запросить дополнительный фактор проверки аутентификации прежде, чем пользователь авторизуется или оградит пользователей от доступа к определенным приложениям пока не обеспечено безопасное соединение.
Как внедрить SSO?
Особенности внедрения SSO могут отличаться с учетом того, с каким именно решением SSO вы работаете. Но вне зависимости от способа, вам нужно точно знать какие цели вы преследуете. Убедитесь, что вы ответили на следующие вопросы:
Что отличает настоящую SSO от хранилища или менеджера паролей?
Важно понимать разницу между SSO (Технологией единого входа) и хранилищем или менеджерами паролей, которые периодически путают с SSO, но в контексте Same Sign-On — что означает “такой же/одинаковый вход”, а не “единый вход” (Single Sign-On). Говоря о хранилище паролей, у вас может быть один логин и пароль, но их нужно будет вводить каждый раз при переходе в новое приложение или на новый сайт. Такая система попросту хранит ваши идентификационные данные для других приложений и вводит их когда это необходимо. В данном случае между приложением и хранилищем паролей не установлены доверительные отношения.
С SSO, после того, как вы вошли в систему, вы можете получить доступ ко всем одобренным компанией сайтам и приложениям без необходимости авторизовываться снова. Это включает в себя как облачные, так и локально установленные приложения, часто доступные через сам сервис SSO (также известный, как сервис авторизации).
В чем разница между программным обеспечением единого входа и решением SSO?
Изучая доступные варианты единого входа, вы можете увидеть, что их иногда называют программным обеспечением единого входа, а не решением единого входа или провайдером единого входа. Часто разница состоит лишь в том, как позиционируют себя компании. Фрагмент программного обеспечения предполагает локальную установку. Обычно это то, что разработано для определенного набора задач и ничего более. Программный продукт предполагает, что есть возможность расширяться и кастомизировать потенциальные возможности исходного варианта. Провайдер будет отличным вариантом, чтобы обратиться к компании, которая производит или пользуется программным продуктом. Например, OneLogin в качестве провайдера SSO.
Бывают ли разные типы SSO?
Когда мы говорим о едином входе (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.
Система 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.