База знаний
Войти

Пользователи и роли

Что такое пользователи

В РОСА Виртуализация существует два типа доменов пользователей:

  • локальный домен;
  • внешний домен.

Во время процесса установки виртуализированного ЦУ создается домен по умолчанию с названием internal, а также пользователь по умолчанию admin.

Дополнительных пользователей в домене internal можно создавать с помощью утилиты ovirt-aaa-jdbc-tool. Учетные записи, создаваемые в локальных доменах, называются "локальными пользователями". Также к окружению РОСА Виртуализация можно присоединять внешние серверы каталогов, такие как Active Directory, OpenLDAP и многие другие поддерживаемые серверы, и использовать их в качестве внешних доменов. Учетные записи, создаваемые во внешних доменах, называются "пользователями каталогов".

Как локальным пользователям, так и пользователям каталогов необходимо присваивать соответствующие роли и полномочия на Портале администрирования, для того чтобы эти пользователи могли функционировать в окружении. Существует два основных типа ролей пользователя: конечный пользователь и администратор. Роль конечного пользователя использует и управляет виртуальными ресурсами с Портала ВМ. Роль администратора поддерживает системную инфраструктуру с Портала администрирования. Эти роли можно присваивать пользователям как для работы с отдельными ресурсами, такими как виртуальные машины или хосты, так и для работы с иерархией объектов, например, с кластерами и дата-центрами.

Введение в серверы каталогов

Во время установки СУСВ создает пользователя admin в домене internal. Этот пользователь также называется admin@internal. Назначение этой учетной записи — использование во время создания начальной конфигурации окружения и для устранения неполадок в работе. После присоединения внешнего сервера каталогов, добавления пользователей каталога и присвоения им соответствующих ролей и полномочий учетную запись admin@internal можно отключить, если она больше не нужна.

Поддерживаемые серверы каталогов

Поддерживаются следующие серверы каталогов:

  • 389ds;
  • 389ds RFC-2307 Schema;
  • Active Directory;
  • IBM Security Directory Server;
  • IBM Security Directory Server RFC-2307 Schema;
  • FreeIPA;
  • iDM;
  • Novell eDirectory RFC-2307 Schema;
  • OpenLDAP RFC-2307 Schema;
  • OpenLDAP Standard Schema;
  • Oracle Unified Directory RFC-2307 Schema;
  • RFC-2307 Schema (Generic);
  • Red Hat Directory Server (RHDS);
  • Red Hat Directory Server (RHDS) RFC-2307 Schema;
  • iPlanet.

Важно — Если в качестве сервера каталогов используется Active Directory, а в создании шаблонов и ВМ планируется использовать sysprep, то в этом случае пользователю-администратору РОСА Виртуализация должен быть делегирован контроль над:

  • присоединением компьютеров к домену;
  • изменением членства в группах.

Настройка внешнего поставщика LDAP

Создание конфигурации внешнего поставщика LDAP (интерактивная установка)

Расширение ovirt-engine-extension-aaa-ldap дает пользователям возможность легко настроить параметры их внешнего каталога. Расширение ovirt-engine-extension-aaa-ldap поддерживает множество различных типов серверов LDAP, а для помощи в настройке большинства типов LDAP предоставляется интерактивный сценарий установки.

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

Пример для Active Directory см. в п. Присоединение Active Directory.

Предварительные условия для настройка внешнего поставщика LDAP:

  • Должно быть известно доменное имя сервера DNS или сервера LDAP.
  • Для настройки защищенного соединения между сервером LDAP и диспетчером следует убедиться в том, что был подготовлен сертификат удостоверяющего центра в формате PEM.
  • Необходимо иметь как минимум одну пару "имя учетной записи ‒ пароль" для выполнения поисковых запросов и запросов по входам в Систему в Active Directory.

Последовательность действий по созданию конфигурации внешнего поставщика LDAP:

  1. для начала интерактивной установки запустить команду:
ovirt-engine-extension-aaa-ldap-setup
  1. выбрать тип LDAP, введя соответствующий номер. Если схема сервера LDAP неизвестна, выбрать стандартную схему для имеющегося типа сервера LDAP. Для Active Directory следовать последовательности действий для присоединения Active Directory;
Available LDAP implementations:
- 389ds
- 389ds RFC-2307 Schema 3 ‒ Active Directory
- IBM Security Directory Server
IBM Security Directory Server RFC-2307 Schema 6 ‒ IPA
Novell eDirectory RFC-2307 Schema 8 ‒ OpenLDAP RFC-2307 Schema
- OpenLDAP Standard Schema
Oracle Unified Directory RFC-2307 Schema 11 ‒ RFC-2307 Schema (Generic)
- RHDS
- RHDS RFC-2307 Schema
- iPlanet Please select:
  1. для принятия значений по умолчанию и конфигурации разрешения доменного имени для имени сервера LDAP нажать клавишу Enter:
It is highly recommended to use DNS resolution for LDAP server.
If for some reason you intend to use hosts or plain address disable DNS usage. Use DNS (Yes, No) [Yes]:
  1. выбрать метод для политики DNS:
  • для варианта 1 серверы DNS, перечисленные в /etc/resolv.conf, используются для разрешения IP-адреса; убедиться в том, что файл /etc/resolv.conf обновлен до корректных значений серверов DNS;
  • для варианта 2 ввести полное доменное имя (FQDN) или IP-адрес сервера LDAP. Для обнаружения имени домена можно использовать команду dig и запись SRV. Запись SRV имеет следующий формат: 
    _service._protocol.domain_name
    Пример: 
    dig _ldap._tcp.example.ru SRV.
  • для варианта 3 ввести список серверов LDAP, разделенных пробелами; использовать либо полные доменные имена серверов, либо их IP-адреса. Данная политика предоставляет балансировку нагрузки между серверами LDAP. Запросы распределяются между всеми серверами LDWP согласно алгоритму циклического перебора;
  • для варианта 4 указать список серверов LDAP, разделенных пробелами; использовать либо полное доменное имя серверов, либо их IP-адреса. Данная политика настраивает первый сервер LDAP в качестве сервера по умолчанию, отвечающего на запросы. Если первый сервер недоступен, запрос переходит следующему серверу в списке. 
    - Single server
- DNS domain LDAP SRV record
- Round-robin between multiple hosts
- Failover between multiple hosts Please select:
  1. выбрать метод защищенного соединения, поддерживаемый имеющимся сервером LDAP, и указать этот метод для получения сертификата ЦС в формате PEM:
  • File ‒ дает возможность указать полный путь до сертификата;
  • URL ‒ дает возможность указать адрес URL сертификата;
  • Inline ‒ дает возможность вставить содержимое сертификата в терминал;
  • System ‒ дает возможность указать местоположение по умолчанию для всех файлов ЦС;
  • Insecure ‒ пропускает проверку сертификата, но подключение по-прежнему шифруется с использованием TLS; 
    NOTE:
It is highly recommended to use secure protocol to access the LDAP server. Protocol startTLS is the standard recommended method to do so.
Only in cases in which the startTLS is not supported, fallback to non standard ldaps protocol.
Use plain for test environments only.
Please select protocol to use (startTLS, ldaps, plain) [startTLS]: startTLS
Please select method to obtain PEM encoded CA certificate (File, URL, Inline, System, Insecure):
Please enter the password:

Примечание — LDAPS — это защищенный протокол LDAP (Lightweight Directory Access Protocol Over Secure Socket Links). Для подключений SSL следует выбирать параметр "ldaps".

  1. ввести отличительное имя (DN) пользователя поиска. Этот пользователь должен иметь полномочия для просмотра всех пользователей и групп на сервер каталогов и должен быть указан в примечаниях LDAP. Если разрешается анонимный поиск, просто нажать клавишу Enter.
Enter search user DN (for example uid=username,dc=example,dc=com or leave empty for anonymous): uid=user1,ou=Users,ou=department-1,dc=example,dc=com
Enter search user password:
  1. ввести отличительное имя базы:
Please enter base DN (dc=example,dc=ru) [dc=example,dc=ru]: ou=department- 1,dc=example,dc=ru
  1. если для ВМ планируется настроить единый вход, выбрать "Yes". Следует обратить внимание, что этот вариант не может быть использован параллельно с единым входом на Портал администрирования. Сценарий напомнит, что имя профиля должно совпадать с именем домена. И далее потребуется следовать инструкциям п. Резервные копии и миграция .
Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:
  1. указать имя профиля. "Имя" профиля является видимым для пользователей на странице входа в Систему. В данном примере используется example.ru.

Примечание — Чтобы переименовать профиль после завершения настройки домена, нужно отредактировать атрибут ovirt.engine.aaa.authn.profile.name в файле /etc/ovirt-engine/extensions.d/example.ru.-authn.properties. Для применения изменений перезапустить службу ovirt-engine.

Please specify profile name that will be visible to users: example.ru

Важно — Пользователь, впервые выполняющий вход в Систему, должен выбрать профиль в выпадающем списке "Профиль" (рисунок 242). Эта информация сохранится в файлах cookie браузера и будет автоматически указана в следующий раз.

Рисунок 242 ‒ Страница входа в Систему на Портале администрирования

  1. протестировать возможность входа в Систему, чтобы убедиться в том, что сервер LDAP корректно подключен к РОСА Виртуализация. В запросе на вход указать имя пользователя и пароль:
NOTE:
It is highly recommended to test drive the configuration before applying it into engine. Login sequence is executed automatically, but it is recommended to also execute Search sequence manually after successful Login sequence.
Please provide credentials to test login flow: Enter user name:
Enter user password:
[ INFO ] Executing login sequence…
…
[ INFO ] Login sequence executed successfully
  1. проверить корректность информации пользователя. Если она неверна, выбрать "Abort":
Please make sure that user details are correct and group membership meets expectations (search for PrincipalRecord and GroupRecord titles).
Abort if output is incorrect.
Select test sequence to execute (Done, Abort, Login, Search) [Abort]:
  1. рекомендуется вручную протестировать функционал поиска. Для создания запроса выбрать "Principal" для учетных записей пользователей или "Group" ‒ для учетных записей групп. Если также должна выводиться информация об учетной записи группы пользователя, выбрать значение "Yes" для пункта "Resolve Groups". Будет создано и выведено на экран три конфигурационных файла.
Select test sequence to execute (Done, Abort, Login, Search) [Search]: Search
Select entity to search (Principal, Group) [Principal]: Term to search, trailing '*' is allowed: testuser1 Resolve Groups (Yes, No) [No]:
  1. для завершения настройки выбрать "Done":
Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Done
[ INFO ] Stage: Transaction setup [ INFO ] Stage: Misc configuration
[ INFO ] Stage: Package installation [ INFO ] Stage: Misc configuration
[ INFO ] Stage: Transaction commit [ INFO ] Stage: Closing up CONFIGURATION SUMMARY
Profile name is: example.ru
The following files were created:
/etc/ovirt-engine/aaa/example.ru.properties
/etc/ovirt-engine/extensions.d/example.ru.properties
/etc/ovirt-engine/extensions.d/example.ru-authn.properties  [ INFO ] Stage: Clean up
Log file is available at /tmp/ovirt-engine-extension-aaa-ldap-setup-20171004101225- mmneib.log:
[ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination
  1. перезапустить службу ovirt-engine:
systemctl restart ovirt-engine.service

Созданный профиль теперь доступен на страницах входа в Систему Портала администрирования и Портала ВМ. Чтобы присвоить пользовательской учетной записи на сервере LDAP соответствующие роли и полномочия, например, для входа в Систему на Портале ВМ, следует обратиться к сведениям в п. Администрирование задач пользователей на Портале администрирования.

Примечание — Дополнительную информацию см. в файле README расширения для аутентификации и авторизации в LDAP по пути /usr/share/doc/ovirt-engine-extension-aaa-ldap-версия.

Присоединение Active Directory

Предварительные условия для присоединения к Active Directory:

  • Администратору должно быть известно имя Active Directory.

Примечание — Примеры часто встречающихся конфигураций Active Directory, которые нельзя создать с помощью утилиты ovirt-engine-extension-aaa-ldap-setup, можно найти в файле /usr/share/ovirt-engine-extension-aaa-ldap/examples/README.md.

  • Необходимо либо добавить сервер DNS, который может разрешать имя леса Active Directory в файл /etc/resolv.conf на машине диспетчера виртуализации, либо записать серверы DNS Active Directory и затем указать их по запросу сценария интерактивной установки.
  • Для настройки защищенного соединения между сервером LDAP и машиной диспетчера необходимо убедиться в том, что был подготовлен сертификат ЦС в формате PEM. Подробности см. в п. Настройка единого входа для LDAP и Kerberos.
  • В случае если анонимный поиск не поддерживается, в Active Directory должен быть доступен пользователь с полномочиями на просмотр всех пользователей и групп для выполнения поиска. Следует записать отличительное имя (DN) этого пользователя. Не рекомендуется использовать пользователя Active Directory с административными полномочиями.
  • Для выполнения поисковых запросов и запросов по входам в Систему в Active Directory необходимо иметь как минимум одну пару "имя учетной записи ‒ пароль".
  • Если при развертывании Active Directory охватывается несколько доменов, нужно ознакомиться с ограничениями, указанными в файле /usr/share/ovirt-engine-extension-aaa-ldap/profiles/ad.properties.

Последовательность действий по присоединению к серверу Active Directory:

  1. для начала интерактивной установки запустить команду:
ovirt-engine-extension-aaa-ldap-setup
  1. выбрать тип LDAP, введя соответствующий номер. Вопросы, касающиеся LDAP и выводимые сценарием после этого шага, зависят от типа LDAP.
Available LDAP implementations:
- 389ds
- 389ds RFC-2307 Schema
- Active Directory
- IBM Security Directory Server
- IBM Security Directory Server RFC-2307 Schema
- IPA
- Novell eDirectory RFC-2307 Schema
- OpenLDAP RFC-2307 Schema
- OpenLDAP Standard Schema
- Oracle Unified Directory RFC-2307 Schema
- RFC-2307 Schema (Generic)
- RHDS
- RHDS RFC-2307 Schema
- iPlanet
Please select: 3
  1. указать имя леса Active Directory. Если DNS диспетчера виртуализации не разрешает имя леса, сценарий предложит указать список имен серверов DNS для Active Directory через пробел:
Please enter Active Directory Forest name: ad-example.test.ru
[ INFO ] Resolving Global Catalog SRV record for ad-example.test.ru
[ INFO ] Resolving LDAP SRV record for ad-example.test.ru
  1. выбрать метод защиты соединения, поддерживаемый сервером LDAP, а также указать способ получения сертификата центра сертификации в формате PEM. Вариант "File" дает возможность указать полный путь до сертификата. Вариант "URL" дает возможность указать адрес URL сертификата. Вариант "Inline" используется для вставки содержимого сертификата в консольную строку. Вариант "System" дает возможность указать путь до местоположения всех файлов центра сертификации. Вариант "Insecure" дает возможность использовать startTLS в незащищенном режиме.
NOTE:
It is highly recommended to use secure protocol to access the LDAP server. Protocol startTLS is the standard recommended method to do so.
Only in cases in which the startTLS is not supported, fallback to non standard ldaps protocol. Use plain for test environments only.
Please select protocol to use (startTLS, ldaps, plain) [startTLS]: startTLS
Please select method to obtain PEM encoded CA certificate (File, URL, Inline, System, Insecure): File
Please enter the password:

Примечание — LDAPS — это защищенный протокол LDAP (Lightweight Directory Access Protocol Over Secure Socket Links). Для подключений SSL следует выбирать параметр "ldaps".

  1. ввести отличительное имя (DN) пользователя поиска. Этот пользователь должен иметь полномочия для просмотра всех пользователей и групп на сервер каталогов и должен быть указан в примечаниях LDAP. Если разрешается анонимный поиск, просто нажать клавишу Enter:
Enter search user DN (empty for anonymous): cn=user1,ou=Users,dc=test,dc=ru
Enter search user password:
  1. указать, нужно ли использовать единый вход для ВМ. Эта возможность используется по умолчанию, но ее невозможно использовать параллельно с настроенным единым входом на Портал администрирования. Сценарий напомнит, что имя профиля должно совпадать с именем домена. И далее потребуется следовать инструкциям п. Резервные копии и миграция "Настройка единого входа для ВМ" документа .
Are you going to use Single Sign-On for Virtual Machines (Yes, No) [Yes]:
  1. указать имя профиля. "Имя" профиля является видимым для пользователей на странице входа в Систему. В данном примере используется test.ru.
Please specify profile name that will be visible to users:test.ru

Важно — Пользователь, впервые выполняющий вход в Систему, должен выбрать профиль в выпадающем списке "Профиль" (рисунок 243). Эта информация сохранится в файлах cookie браузера и будет автоматически указана в следующий раз.

Рисунок 243 ‒ Страница входа в Систему на Портале администрирования

  1. протестировать возможность входа в Систему и поиск, чтобы убедиться в том, что сервер LDAP корректно подключен к окружению РОСА Виртуализация. В запросе на вход в Систему указать имя пользователя и пароль. Для создания запроса выбрать "Principal" для учетных записей пользователей или "Group" ‒ для учетных записей групп. Если также должна выводиться информация об учетной записи группы пользователя, выбрать значение "Yes" для пункта "Resolve Groups". Для завершения настройки выбрать "Done". Будет создано и выведено на экран три конфигурационных файла.
NOTE:
It is highly recommended to test drive the configuration before applying it into engine. Login sequence is executed automatically, but it is recommended to also execute Search sequence manually after successful Login sequence.
Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Login Enter search user name: testuser1
Enter search user password:
[ INFO ] Executing login sequence...
...
Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Search Select entity to search (Principal, Group) [Principal]:
Term to search, trailing '*' is allowed: testuser1
Resolve Groups (Yes, No) [No]:
[ INFO ] Executing login sequence...
...
Select test sequence to execute (Done, Abort, Login, Search) [Abort]: Done [ INFO ] Stage: Transaction setup
[ INFO ] Stage: Misc configuration
[ INFO ] Stage: Package installation [ INFO ] Stage: Misc configuration
[ INFO ] Stage: Transaction commit
[ INFO ] Stage: Closing up CONFIGURATION SUMMARY
Profile name is: test.ru
The following files were created:
/etc/ovirt-engine/aaa/test.ru.properties
/etc/ovirt-engine/extensions.d/test.ru-authz.properties
/etc/ovirt-engine/extensions.d/test.ru-authn.properties  [ INFO ] Stage: Clean up
Log file is available at /tmp/ovirt-engine-extension-aaa-ldap-setup-20160114064955- 1yar9i.log:
[ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination
  1. созданный профиль теперь доступен на страницах входа в Систему Портала администрирования и Портала ВМ. Чтобы присвоить пользовательской учетной записи на сервере LDAP соответствующие роли и полномочия, например, для входа в Систему на Портале ВМ, следует обратиться к сведениям в п. Администрирование задач пользователей на Портале администрирования.

Примечание — Дополнительные сведения см. в файле README расширения аутентификации и авторизации LDAP по пути /usr/share/doc/ovirt-engine-extension-aaa-ldap-версия.

Настройка внешнего поставщика LDAP (вручную)

Расширение ovirt-engine-extension-aaa-ldap использует протокол LDAP для получения доступа к серверам каталогов и является полностью настраиваемым. Если не планируется настройка одноразового входа на Портал ВМ или Портал администрирования, то аутентификация Kerberos не требуется.

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

Последовательность действий по настройке внешнего поставщика LDAP:

  1. установить пакет расширения LDAP на диспетчере РОСА Виртуализация:
dnf install ovirt-engine-extension-aaa-ldap
  1. скопировать файл шаблона конфигурации LDAP в каталог /etc/ovirt-engine. Файлы шаблонов доступны для Active Directory (ad) и других типов каталогов (simple). В данном примере используется шаблон simple:
cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/. \
/etc/ovirt-engine
  1. переименовать файлы конфигурации для соответствия имени профиля, который должен быть видимым для пользователей на страницах входа в Систему Порталов ВМ и администрирования:
mv /etc/ovirt-engine/aaa/profile1.properties \
/etc/ovirt-engine/aaa/example.properties
mv /etc/ovirt-engine/extensions.d/profile1-authn.properties \
/etc/ovirt- engine/extensions.d/example-authn.properties
mv /etc/ovirt-engine/extensions.d/profile1-authz.properties  \
/etc/ovirt- engine/extensions.d/example-authz.properties
  1. изменить файл конфигурации LDAP property, раскомментировав строки с типом сервера LDAP и обновив информацию в полях домена и пароля:
vi /etc/ovirt-engine/aaa/example.properties

Пример профиля ‒ раздел server LDAP:

Select one #
include = <openldap.properties> #include = <389ds.properties> #include = <rhds.properties> #include = <ipa.properties> #include = <iplanet.properties>
#include = <rfc2307-389ds.properties> #include = <rfc2307-rhds.properties> #include = <rfc2307-openldap.properties> #include = <rfc2307-edir.properties> #include = <rfc2307-generic.properties>
Server #
vars.server = ldap1.company.com
Search user and its password. #
vars.user = uid=search,cn=users,cn=accounts,dc=company,dc=com vars.password = 123456
pool.default.serverset.single.server = ${global:vars.server} pool.default.auth.simple.bindDN = ${global:vars.user} pool.default.auth.simple.password = ${global:vars.password}

При использовании протоколов TLS или SSL для обмена информацией с сервером LDAP нужно получить сертификат ЦС для сервера LDAP и с его помощью создать файл открытого ключа. Затем следует раскомментировать строки, указанные ниже, и указать полный путь к открытому ключу и паролю доступа к файлу.

Пример профиля ‒ раздел keystore:

Create keystore, import certificate chain and uncomment
if using tls.
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = /full/path/to/myrootca.jks
pool.default.ssl.truststore.password = password
  1. просмотреть файл параметров аутентификации. "Имя" профиля, видимое пользователям на страницах входа в Систему на Портале администрирования и на Портале ВМ, определяется файлом ovirt.engine.aaa.authn.profile.name. Местоположение профиля конфигурации должно совпадать с местоположением файла конфигурации LDAP. Для всех полей можно оставить значения по умолчанию.
vi /etc/ovirt-engine/extensions.d/example-authn.properties

Пример файла конфигурации аутентификации:

ovirt.engine.extension.name = example-authn ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = example ovirt.engine.aaa.authn.authz.plugin = example-authz
config.profile.file.1 = ../aaa/example.properties
  1. местоположение профиля конфигурации должно совпадать с местоположением файла конфигурации LDAP. Для всех полей можно оставить значения по умолчанию:
vi /etc/ovirt-engine/extensions.d/example-authz.properties

Пример файла конфигурации авторизации:

ovirt.engine.extension.name = example-authz ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz config.profile.file.1 = ../aaa/example.properties
  1. установить соответствующие права доступа и указать владельца файла профиля:
chown ovirt:ovirt /etc/ovirt-engine/aaa/example.properties
chmod 600 /etc/ovirt-engine/aaa/example.properties
  1. перезапустить службу engine:
systemctl restart ovirt-engine.service
  1. созданный профиль example теперь доступен на страницах входа в Систему Портала администрирования и Портала ВМ. Чтобы присвоить пользовательской учетной записи на сервере LDAP соответствующие роли и полномочия, например, для входа в Систему на Портале ВМ, обратиться к сведениям в п. Администрирование задач пользователей на Портале администрирования.

Примечание — Дополнительную информацию см. в файле README расширения для аутентификации и авторизации в LDAP по пути /usr/share/doc/ovirt-engine-extension-aaa-ldap-версия.

Удаление внешнего поставщика LDAP

В данной последовательности показывается процесс удаления настроенного внешнего поставщика LDAP и его пользователей.

Последовательность действий по удалению внешнего поставщика LDAP:

  1. удалить файлы конфигурации поставщика LDAP, заменив имя по умолчанию profile1:
rm /etc/ovirt-engine/extensions.d/profile1-authn.properties
rm /etc/ovirt-engine/extensions.d/profile1-authz.properties
rm /etc/ovirt-engine/aaa/profile1.properties
  1. перезапустить службу ovirt-engine:
systemctl restart ovirt-engine
  1. во вкладке "Пользователи" Портала администрирования выбрать пользователей этого поставщика (пользователи со значением "profile1-authz" для параметра "Поставщик авторизации") и нажать кнопку Удалить.

Настройка единого входа для LDAP и Kerberos

Механизм единого входа дает возможность пользователям войти в Систему на Портале ВМ или Портале администрирования без повторного ввода пароля. Данные учетной записи для аутентификации получаются с сервера Kerberos. Для настройки единого входа на Портале администрирования необходимо настроить два расширения: ovirt-engine-extension-aaa-misc и ovirt-engine-extension-aaa-ldap, а также два модуля Apache: mod_auth_gssapi и mod_session. Есть возможность настроить единый вход без использования Kerberos, но ее описание выходит за рамки данного руководства.

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

В данном примере предполагается, что:

  • на существующем центре распределения ключей (KDC) используется версия MIT Kerberos 5;
  • для сервера KDC имеются полномочия администратора;
  • клиент Kerberos установлен на СУСВ и на ВМ пользователя;
  • для создания принципалов служб Kerberos и файлов таблиц ключей использовалась утилита kadmin.

Последовательность действий для настройки единого входа для LDAP и Kerberos:

  1. на сервере KDC на машине диспетчера РОСА Виртуализация создать принципала службы и файл keytab для службы Apache;
  2. на диспетчере РОСА Виртуализация установить пакеты расширений аутентификации и авторизации, а также модуль аутентификации Kerberos для Apache;
  3. настроить файлы расширений.

Настройка Kerberos для службы Apache

Для настройки Kerberos для службы Apache нужно выполнить следующие действия:

  1. на сервере KDC использовать утилиту kadmin для создания принципала для службы Apache на машине диспетчера виртуализации (принципал службы — это ссылочный идентификатор службы Apache):
kadmin
kadmin> addprinc -randkey HTTP/fqdn-of-rhevm@REALM.COM
  1. создать файл keytab для службы Apache, в котором хранится общий секретный ключ:

Примечание — Во время создания и восстановления резервных копий команде engine-backup указывается файл /etc/httpd/http.keytab. Если файлу keytab было дано другое имя, следует убедиться, что для него была создана и восстановлена резервная копия.

kadmin> ktadd -k /tmp/http.keytab HTTP/fqdn-of-rhevm@REALM.COM
kadmin> quit
  1. скопировать файл keytab с сервера KDC на машину диспетчера виртуализации:
scp /tmp/http.keytab root@rhevm.example.com:/etc/httpd

Настройка единого входа для Портала ВМ или Портала администрирования

Для настройки единого входа для Портала ВМ или Портала администрирования нужно выполнить следующие действия:

  1. на машине диспетчера виртуализации установить соответствующие права доступа и указать владельца файла таблицы ключей:
chown apache /etc/httpd/http.keytab
chmod 400 /etc/httpd/http.keytab
  1. установить пакет расширения для аутентификации, пакет расширения для LDAP, а также модули Apache mod_auth_gssapi и mod_session:
dnf install ovirt-engine-extension-aaa-misc \
ovirt-engine-extension-aaa-ldap mod_auth_gssapi mod_session
  1. скопировать файл шаблона конфигурации SSO в каталог /etc/ovirt-engine. Файлы шаблонов доступны для Active Directory (ad-sso) и для других типов каталогов (simple-sso). В данном примере используется шаблон конфигурации simple-sso:
cp -r /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple-sso/. \
/etc/ovirt-engine
  1. переместить файл ovirt-sso.conf в каталог настройки Apache:

Примечание — Во время создания и восстановления резервных копий команде engine-backup указывается файл /etc/httpd/conf.d/ovirt-sso.conf. Если этому файлу было дано другое имя, следует убедиться, что для него была создана и восстановлена резервная копия.

mv /etc/ovirt-engine/aaa/ovirt-sso.conf /etc/httpd/conf.d
  1. просмотреть файл метода аутентификации. Этот файл не нужно редактировать, поскольку данные области автоматически получаются из файла keytab.
vi /etc/httpd/conf.d/ovirt-sso.conf

Пример файла метода аутентификации:

<LocationMatch ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http- auth)|^/ovirt-engine/api>
<If "req('Authorization') !~ /^(Bearer|Basic)/i"> RewriteEngine on
RewriteCond %{LA-U:REMOTE_USER} ^(.*)$ RewriteRule ^(.*)$ ‒ [L,NS,P,E=REMOTE_USER:%1] RequestHeader set X-Remote-User %{REMOTE_USER}s
AuthType GSSAPI AuthName "Kerberos Login"
Modify to match installation GssapiCredStore keytab:/etc/httpd/http.keytab GssapiUseSessions On
Session On
SessionCookieName ovirt_gssapi_session path=/private;httponly;secure;
Require valid-user
ErrorDocument 401 "<html><meta http-equiv=\"refresh\" content=\"0; url=/ovirt- engine/sso/login-unauthorized\"/><body><a href=\"/ovirt-engine/sso/login- unauthorized\">Here</a></body></html>"
</If>
</LocationMatch>
  1. переименовать файлы конфигурации для соответствия с именем профиля, который должен быть видимым для пользователей на страницах входа в Систему Порталов ВМ и администрирования:
mv /etc/ovirt-engine/aaa/profile1.properties \
/etc/ovirt-engine/aaa/example.properties
mv /etc/ovirt-engine/extensions.d/profile1-http-authn.properties \
/etc/ovirt-engine/extensions.d/example-http-authn.properties
mv /etc/ovirt-engine/extensions.d/profile1-http-mapping.properties \
/etc/ovirt-engine/extensions.d/example-http-mapping.properties
mv /etc/ovirt-engine/extensions.d/profile1-authz.properties \
/etc/ovirt- engine/extensions.d/example-authz.properties
  1. изменить файл конфигурации LDAP property, убрав комментарии со строк с типом сервера LDAP и обновив информацию в полях домена и пароля:
vi /etc/ovirt-engine/aaa/example.properties

Пример профиля ‒ раздел сервера LDAP:

Select one
include = <openldap.properties>
#include = <389ds.properties>
#include = <rhds.properties>
#include = <ipa.properties>
#include = <iplanet.properties>
#include = <rfc2307-389ds.properties>
#include = <rfc2307-rhds.properties>
#include = <rfc2307-openldap.properties>
#include = <rfc2307-edir.properties>
#include = <rfc2307-generic.properties>
Server
#vars.server = ldap1.company.com
Search user and its password. #
vars.user = uid=search,cn=users,cn=accounts,dc=company,dc=com vars.password = 123456
pool.default.serverset.single.server = ${global:vars.server} pool.default.auth.simple.bindDN = ${global:vars.user} pool.default.auth.simple.password = ${global:vars.password}

Если для обмена информацией с сервером LDAP используются протоколы TLS или SSL, необходимо получить сертификат корневого центра сертификации для сервера LDAP и с его помощью создать файл открытого ключа. Cледует раскомментировать строки, указанные ниже, и указать полный путь к открытому ключу и паролю доступа к файлу.

Пример профиля ‒ раздел keystore:

Create keystore, import certificate chain and uncomment
if using ssl/tls.
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = /full/path/to/myrootca.jks
pool.default.ssl.truststore.password = password
  1. просмотреть файл параметров аутентификации. "Имя" профиля, видимое пользователям на страницах входа в Систему на Портале администрирования и на Портале ВМ, определяется файлом ovirt.engine.aaa.authn.profile.name. Местоположение профиля конфигурации должно совпадать с местоположением файла конфигурации LDAP. Для всех полей можно оставить значения по умолчанию.
vi /etc/ovirt-engine/extensions.d/example-http-authn.properties

Пример файла параметров аутентификации:

ovirt.engine.extension.name = example-http-authn ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.misc ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.misc.http.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = example-http ovirt.engine.aaa.authn.authz.plugin = example-authz ovirt.engine.aaa.authn.mapping.plugin = example-http-mapping config.artifact.name = HEADER
config.artifact.arg = X-Remote-User
  1. просмотреть файл параметров авторизации. Местоположение профиля конфигурации должно совпадать с местоположением файла конфигурации LDAP. Для всех полей можно оставить значения по умолчанию.
vi /etc/ovirt-engine/extensions.d/example-authz.properties

Пример файла параметров авторизации:

ovirt.engine.extension.name = example-authz ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz config.profile.file.1 = ../aaa/example.properties
  1. просмотреть файл конфигурации отображения аутентификации. Местоположение профиля конфигурации должно совпадать с местоположением файла конфигурации LDAP. Расширение имени профиля конфигурации должно совпадать со значением "ovirt.engine.aaa.authn.mapping.plugin" в файле конфигурации аутентификации. Для всех полей можно оставить значения по умолчанию.
vi /etc/ovirt-engine/extensions.d/example-http-mapping.properties

Пример файла параметров отображения аутентификации:

ovirt.engine.extension.name = example-http-mapping ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine.extension.aaa.misc ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engine.extension.aaa.misc.mapping.MappingExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Mapping config.mapAuthRecord.type = regex
config.mapAuthRecord.regex.mustMatch = true
config.mapAuthRecord.regex.pattern  =  ^(?<user>.*?)((\\\\(?<at>@)(?<suffix>.*?)@.*)|(?
<realm>@.*))$
config.mapAuthRecord.regex.replacement = ${user}${at}${suffix}
  1. установить соответствующие права доступа и указать владельца файла конфигурации:
chown ovirt:ovirt /etc/ovirt-engine/aaa/example.properties
chown ovirt:ovirt \
/etc/ovirt-engine/extensions.d/example-http-authn.properties
chown ovirt:ovirt \
/etc/ovirt-engine/extensions.d/example-http-mapping.properties
chown ovirt:ovirt /etc/ovirt-engine/extensions.d/example-authz.properties
chmod 600 /etc/ovirt-engine/aaa/example.properties
chmod 640 /etc/ovirt-engine/extensions.d/example-http-authn.properties
chmod 640 /etc/ovirt-engine/extensions.d/example-http-mapping.properties
chmod 640 /etc/ovirt-engine/extensions.d/example-authz.properties
  1. перезапустить службу Apache и службу ovirt-engine:
systemctl restart httpd.service
systemctl restart ovirt-engine.service

Авторизация пользователей

Модель авторизации пользователей

Управление авторизацией в РОСА Виртуализация базируется на сочетании трех составляющих:

  • Пользователь, выполняющий действие.
  • Тип этого выполняемого действия.
  • Объект, над которым выполняется это действие.

Действия пользователей

Чтобы действие выполнилось успешно, у пользователя должны быть соответствующие полномочия на объект, над которым выполняется действие. У каждого типа действий есть соответствующие полномочия.

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

Администрирование задач пользователей на Портале администрирования

Интерфейс Системы предназначен для управления локальными пользователями. Управление пользователями происходит посредством использования утилиты ovirt-aaa-jdbc-tool.

Система представляет собой веб-приложение и состоит из фронтенд-части и бэкенд-части. Данные хранятся в СУБД.

Для работы веб-приложения необходимо обеспечить следующие системные требования:

  • CPU – не менее 2;
  • оперативная память – не менее 1 ГБ;
  • диск – не меньше 1 ГБ.

Для установки с диска РОСА Виртуализация, выбрав в наборе программ "Минимальная установка", выполнить команду:

dnf install rv-aaa-users

Для работы необходимо открыть интерфейс Портала администратора и перейти в раздел "Дополнения → Пользователи". Интерфейс состоит из двух вкладок "Пользователи" и "Группы" (рисунок 244).

Рисунок 244 ‒ Пользователи

Во вкладке "Пользователи" в таблице постранично показаны все пользователи (по умолчанию по 10 пользователей на странице). Для каждого пользователя показано имя, дата последнего входа, дата создания учетной записи, срок действия учетной записи, срок действия пароля (если он есть). Для каждого пользователя в строке расположены пиктограммы для редактирования, удаления, разблокировки и деактивации пользователя.

Добавление пользователя

Для добавления нового пользователя нужно нажать кнопку Добавить пользователя, после чего откроется окно (рисунок 245).

Рисунок 245 ‒ Добавление пользователя

В форме обязательным полем является только поле "Системное имя". После заполнения требуемых полей следует нажать кнопку "Сохранить". Окно закроется, появится крутящийся элемент, по исчезновении которого пользователь будет создан. Хотя в таблице новый пользователь может не присутствовать, но его уже можно найти через поисковую строку (рисунок 246).

Рисунок 246 ‒ Поисковая строка

Редактирование пользователя

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

Удаление пользователя

Для удаления пользователя нужно нажать на кнопку (корзина), появится диалоговое окно для подтверждения, в котором требуется нажать кнопку Да.

Выключение пользователя

В Системе возможно выключение (disable) пользователя. После выключения пользователь не сможет войти в Систему.

Включение осуществляется нажатием пиктограммы (зачеркнутый человечек).

После выключения пиктограмму изменится на (человечек), которая, в свою очередь, служит для включения пользователя.

Блокировка пользователя

Пользователь блокируется автоматически после нескольких попыток ввода неправильного пароля. Количество попыток, после которых учетная запись блокируется, зависит от настроек. Для разблокирования нужно нажать на пиктограмму (замочек).

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

Настройка

Для настройки параметров работы с пользователями нужно нажать на кнопку Настройки", после чего появится окно (рисунок 247).

Рисунок 247 ‒ Параметры паролей

Все поля для настройки снабжены коротким пояснением.

Работа с группами пользователей

Группы пользователей в интерфейсе Портала администрирования показаны в виде дерева на вкладке "Группы" (рисунок 248).

Рисунок 248 ‒ Группы пользователей

Узлами дерева являются группы, при этом группа может иметь в своем составе другие группы и пользователей.

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

Рисунок 249 ‒ Добавление группы

После заполнение требуемых полей следует нажать кнопку Сохранить.

Редактирование и удаление групп реализовано аналогично интерфейсу работы с пользователями с теми же пиктограммами и функциями.

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

Рисунок 250 ‒ Редактирование состава группы

Администрирование задач пользователей в консольном режиме

С помощью утилиты ovirt-aaa-jdbc-tool можно управлять учетными записями пользователей во внутреннем домене. Изменения, внесенные при помощи этой утилиты, применяются мгновенно и не требуют перезапуска службы ovirt-engine. Полный список параметров для работы с пользователями можно просмотреть в выводе команды:

ovirt-aaa-jdbc-tool user —help

Примеры наиболее часто встречающихся случаев использования описаны в данном разделе.

Важно — Администратор должен выполнить вход в Систему на машине СУСВ.

Создание нового пользователя

Администратор может создавать учетные записи новых пользователей. Дополнительный параметр --attribute передает подробности.

ovirt-aaa-jdbc-tool user add test1 \
--attribute=firstName=John --attribute=lastName=Doe
adding user test1...
user added successfully

Теперь только что созданного пользователя можно добавить на Портал администрирования и присвоить ему подходящие роли и полномочия.

Чтобы просмотреть полный список параметров, нужно выполнить команду:

ovirt-aaa-jdbc-tool user add --help.

Настройка пароля пользователя

Администратор может создавать пароли, при этом необходимо указать значение параметра --password-valid-to, в противном случае время истечения действия пароля по умолчанию равно текущему времени.

Формат значения по умолчанию: "гггг-ММ-дд ЧЧ:мм:ссX", где "X" — значение смещения часового пояса от UTC. В данном примере значение "0800" означает время по Гринвичу (GMT) минус 8 часов. Для нулевого смещения используют значение "Z".

ovirt-aaa-jdbc-tool user password-reset test1 \
--password-valid-to="2025-08-01 12:00:00-0800"
Password:
updating user test1... user updated successfully

Дополнительные параметры см. в выводе команды:

ovirt-aaa-jdbc-tool user password-reset --help.

Примечание — По умолчанию политика паролей для учетных записей пользователей во внутренних доменах имеет следующие ограничения:

  • Минимум 6 символов.
  • При смене пароля нельзя снова назначить три предыдущих пароля.
  • Чтобы получить дополнительные сведения о политике паролей и других значениях по умолчанию, следует выполнить команду: 
    ovirt-aaa- jdbc-tool settings show.

Сразу после обновления пароля необходимо вручную распространить изменения в ovirt-provider-ovn. В противном случае пользователь admin будет заблокирован, т. к. для синхронизации сетей из ovirt-provider-ovn диспетчер РОСА Виртуализация продолжит использовать старый пароль. Для внесения нового пароля в ovirt-provider-ovn необходимо выполнить следующие действия:

  1. на Портале администрирования выбрать "Администрирование → Поставщики";
  2. выбрать ovirt-provider-ovn;
  3. нажать кнопку Изменить и ввести новый пароль в поле "Пароль";
  4. нажать кнопку Проверить, чтобы протестировать успешность аутентификации с предоставленными данными учетной записи;
  5. в случае успешности проверки нажать кнопку OK.

Настройка интервала истечения времени ожидания сеанса пользователя

Администратор может настроить интервал истечения времени ожидания сеанса пользователя следующей командой:

engine-config --set UserSessionTimeOutInterval=integer

Предварительное шифрование паролей пользователей

С помощью сценария ovirt-engine-crypto-tool администратор может создавать предварительно зашифрованные пароли пользователей. Эта возможность удобна, если пользователи и пароли добавляются в базу данных с помощью сценариев.

Примечание — Пароли хранятся в базе данных диспетчера виртуализации в зашифрованном виде. Сценарий ovirt-engine-crypto-tool используется потому, что все пароли должны быть зашифрованы с использованием одного и того же алгоритма.

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

Для шифрования пароля нужно выполнить следующие действия:

  1. выполнить команду:
/usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode

Сценарий предложит ввести пароль.

Как вариант, чтобы зашифровать один пароль, указанный в первой строке файла, можно использовать параметр --password=file:файл. Эта возможность удобна для автоматизации. В примере ниже файл — это текстовый файл с паролем, который нужно зашифровать:

/usr/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode \
--password=file:file
  1. с помощью сценария ovirt-aaa-jdbc-tool с параметром --encrypted указать новый пароль:
ovirt-aaa-jdbc-tool user password-reset test1 \
--password-valid-to="2025-08-01 12:00:00- 0800" --encrypted
  1. ввести и подтвердить зашифрованный пароль:
Password:
Reenter password:
updating user test1...
user updated successfully

Просмотр информации о пользователях

Администратор может просматривать подробные сведения об учетных записях пользователей:

ovirt-aaa-jdbc-tool user show test1

Указанная команда выводит больше сведений, чем можно получить на экране "Администрирование → Пользователи" на Портале администрирования.

Изменение информации о пользователях

Администратор может обновлять информацию о пользователях, например почтовый адрес:

ovirt-aaa-jdbc-tool user edit test1 --attribute=email=jdoe@example.com

Удаление пользователей

Администратор может удалять учетные записи пользователей:

ovirt-aaa-jdbc-tool user delete test1

Удаление пользователя с Портала администрирования описано в п. Удаление пользователя.

Отключение внутреннего пользователя-администратора

Администратор может отключать пользователей в локальных доменах, включая пользователя admin@internal, создаваемого во время выполнения engine-setup. Перед отключением изначального пользователя admin следует убедиться в том, что в окружении имеется еще как минимум один пользователь с полными административными полномочиями.

Последовательность действий по отключению внутреннего пользователя-администратора:

  1. выполнить вход в Систему на машине с установленным диспетчером виртуализации;
  2. убедиться в том, что в окружение был добавлен еще один пользователь с ролью SuperUser (подробности см. в п. Изменение параметров роли);
  3. отключить изначального пользователя admin:
ovirt-aaa-jdbc-tool user edit admin --flag=+disabled

Примечание — Чтобы включить отключенного пользователя, выполняют команду:

ovirt-aaa-jdbc-tool user edit username --flag=-disabled

Управление группами

С помощью утилиты ovirt-aaa-jdbc-tool можно управлять учетными записями групп во внутреннем домене. Управление учетными записями групп аналогично управлению учетными записями пользователей. Полный список возможностей для групп см. в выводе команды:

ovirt-aaa-jdbc-tool group —help

В данном разделе приводятся общие примеры.

Создание группы пользователей

Данная последовательность действий позволяет создать группу пользователей, добавить пользователей в группу и просматривать сведения о группе:

  1. выполнить вход в Систему на машине с установленным диспетчером виртуализации;
  2. создать новую группу:
ovirt-aaa-jdbc-tool group add group1
  1. добавить пользователей, которые должны уже быть созданы ранее, в группу:
ovirt-aaa-jdbc-tool group-manage useradd group1 --user=test1

Примечание — Полный список параметров управления группами см. в выводе команды:

ovirt-aaa-jdbc-tool group- manage --help
  1. просмотреть сведения об учетной записи группы:
ovirt-aaa-jdbc-tool group show group1
  1. добавить только что созданную группу на Портале администрирования и выделить группе необходимые роли и полномочия.

Пользователи-участники группы наследуют роли и полномочия группы.

Создание вложенных групп

Данная процедура позволяет создать группу внутри группы:

  1. выполнить вход в Систему на машине с установленным диспетчером виртуализации;
  2. создать новую группу:
ovirt-aaa-jdbc-tool group add group1
  1. создать вторую группу:
ovirt-aaa-jdbc-tool group add group1-1
  1. добавить вторую группу к первой:
ovirt-aaa-jdbc-tool group-manage groupadd group1 --group=group1-1
  1. добавить первую группу на Портале администрирования и присвоить группе необходимые роли и полномочия.

Запрос сведений о группах и пользователях

Модуль query дает возможность запросить сведения о пользователях и группах. Полный список параметров можно посмотреть в выводе команды:

ovirt-aaa-jdbc-tool query --help

Просмотр сведений об учетных записях всех пользователей или групп

Данная последовательность действий позволяет просмотреть информацию обо всех учетных записях:

  1. выполнить вход в Систему на машине с установленным диспетчером виртуализации;
  2. получить список сведений об учетных записях:
  • учетные записи всех пользователей: 
    ovirt-aaa-jdbc-tool query --what=user
  • учетные записи всех групп: 
    ovirt-aaa-jdbc-tool query --what=group

Получение списка учетных записей с применением фильтра

Данная процедура показывает, как применять фильтры при получении списка сведений об учетных записях:

  1. выполнить вход в Систему на машине с установленным диспетчером виртуализации;
  2. применить фильтр к информации об учетной записи с помощью параметра —pattern.

Например, чтобы получить список учетных записей с именами, начинающимися с символа "j", выполняют команду:

ovirt-aaa-jdbc-tool query --what=user --pattern="name=j*"

Чтобы получить список групп со значением "marketing" атрибута department, выполняю команду:

ovirt-aaa-jdbc-tool query --what=group --pattern="department=marketing"

Управление параметрами учетных записей

Для изменения исходных параметров учетной записи используется модуль ovirt-aaa-jdbc-tool settings.

Обновление информации о параметрах учетной записи

Данная последовательность действий показывает, как изменить изначальные параметры учетной записи:

  1. выполнить вход в Систему на машине с установленным диспетчером виртуализации;
  2. для просмотра всех доступных параметров выполнить следующую команду:
ovirt-aaa-jdbc-tool settings show
  1. изменить необходимые параметры:
  • в данном примере изначальное значение длительности сеанса пользователя (10080 минут) изменяется на 60 минут для всех учетных записей пользователей: 
    ovirt-aaa-jdbc-tool settings set --name=MAX_LOGIN_MINUTES --value=60
  • в данном примере изменяется значение числа неудачных попыток входа в Систему, которые может выполнить пользователь до того, как его учетная запись будет заблокирована (значение по умолчанию ‒ "5"): 
    ovirt-aaa-jdbc-tool settings set --name=MAX_FAILURES_SINCE_SUCCESS \
--value=3

Примечание — Для разблокирования учетной записи пользователя нужно выполнить команду:

ovirt-aaa-jdbc-tool user unlock test1
```

## Настройка дополнительных локальных доменов

Создание дополнительных локальных доменов, помимо изначального домена internal, также поддерживается. Это выполняется с помощью расширения ovirt-engine-extension-aaa-jdbc, дающего возможность создания более одного домена без присоединения внешних серверов каталогов, хотя такой сценарий использования не очень часто встречается в корпоративных окружениях.

Дополнительно созданные локальные домены не будут обновляться автоматически во время стандартных обновлений версий РОСА Виртуализация: после выходов следующих версий эти домены необходимо будет обновлять вручную. Дополнительные сведения о создании дополнительных локальных доменов и об обновлении версий этих доменов см. в файле README, расположенном по пути /usr/share/doc/ovirt-engine-extension-aaa-jdbc-версия/README.admin.