Description of problem: Currently, when creating virtual machine pools, the RHEV admin portal pool creation screen prompts for a Windows Active Directory domain name and OU. But it does not prompt for credentials to join that domain. Instead, the RHEV administrator must launch an ssh session to RHEVM and issue a series of commands: engine-config -s "SysPrepDefaultPassword=interactive" engine-config -s "SysPrepDefaultUser=example\administrator" Or execute this command from RHEV-M as root: engine-manage-domains add --domain=example.local --provider=ad or, since engine-manage-domains is being deprecated, configure ovirt-engine-extension-aaa-ldap by hand-editing a series of configuration files and issuing the engine-config commands above. This scheme has an architectural problem because it assumes the organization has only one Windows Active Directory domain. To handle multiple domains, the RHEV Administrator must work around this assumption by setting up another file in /etc/ovirt-engine/osinfo.conf.d describing multiple copies of the same Windows operating system. Each copy points to a customized sysprep XML auto-answer file with credential information in clear text edited in by hand. We can do better. The pool creation screen needs GUI improvements. Credentials for joining the Active Directory domain should be in the GUI and should be stored in the database in some kind of safe form. The domain credentials should be part of each pool, not part of an overall OS default, because different pools with the same OS may join different Active Directory (or other LDAP) domains. If the ovirt-engine-aaa-ldap module is to replace engine-manage-domains, and since pool creation indirectly depends on ovirt-engine-aaa-ldap, this new module also needs a usable and documented interface so less experienced system administrators can use it. Version-Release number of selected component (if applicable): 3.5.n How reproducible: At will Steps to Reproduce: 1. Go through the steps to manually edit several properties files in multiple directories by hand. 2. Spend days or weeks debugging. 3. Actual results: Eventually, after weeks of hand tuning and editing and help from developers, it may be possible to get a sophisticated system up and running properly. But with sensitive authentication info stored in clear text files in various directory trees. Expected results: This should all be in an easy to use GUI; the database model should accommodate a 1:1 relationship between pools and domains and not be centered on one domain for the whole organization. The credentials for joining the domain should be part of the GUI and should be stored in a safe manner in the RHEVM database. Additional info:
seems like a combination of 'virt' (pools) and infra (ovirt-engine-aaa-ldap/engine-manage-domains); currently marking 'infra', please change if necessary.
Yaniv Dary asked to move this bug to oVirt. I just re-entered it there at: https://bugzilla.redhat.com/show_bug.cgi?id=1273940 - Greg
It was decided to keep this bug here after all. We've had some subsequent conversations on this. Instead of putting domain credentials in the pool setup GUI, it may make more sense and be more secure to approach it differently. Every LDAP domain has a set of attributes that depend on the domain. These include: - credentials to join. - Possible site name close to RHEVM for Active Directory domains. - Other fields as appropriate. What about setting up another top level menu item, "Domains" and filling in the appropriate fields there? If not enough room for another top level menu item, perhaps put in a subsection, "Domains" in the RHEVM "User" menu. Fill in the appropriate fields in the GUI and RHEVM would populate the database and build the appropriate .properties files. And then with pool creation, the "Domain" field could become a dropdown list. Select the domain during pool creation and RHEVM already has what it needs about that domain. This also eliminates the problem where the RHEVM admin needs to know AD Domain credentials to create a pool.
I'm linking support case number 01521092 with this BZ. And more feedback from the customer on this: The customer uses a password management system named Cloakware and has a security requirement that admins do not enter passwords by hand once they're stored inside Cloakware. So in addition to the GUI for creating domains, the system also needs a CLI to replace engine-manage-domains and build/edit the approprieate .properties files for ovirt-engine-aaa-ldap. With the CLI, the RHEV admin can set up scripts for domain creation to export a copy of the credentials from Cloakware and copy them into the RHEV, for storage in the engine database. So RHEV needs both a GUI and CLI for this purpose. Note that the join-the-domain credentials need to be stored in the database in an obfuscated manner, not easily readable in clear text. Everyone understands that files such as unattend.xml, which drives the mini-setup program when PCs firstboot, use clear text passwords. This is the way Microsoft Windows works and Red Hat has no ability to redesign Windows. But with pool creation, unattend.xml is a temporary file that RHEV generates and then destroys when finished. So temporarily putting that password in clear text in unattend.xml seems to be the best available compromise. But the permanent RHEV location for these credentials is the engine database and the copy in the database needs to be protected. *********** <jwoods> gscott: one thing to consider for any GUI management of AAA LDAP domains (which I am a fan of), there needs to also be a CLI option for setting the password, else it won't fly for {customer}. not only do they not want password in config files, they also don't want anyone to see passwords to manually type them into a GUI <jwoods> need to be able to set options requiring passwords via something like engine-config as it can have the cloakware pipe to it and all reqs will be met
The domains/profile used to authenticate with engine and the credentials used for sysprep are two separate subjects, we should stop mix these two. Even if I have only admin@local I should be able to deploy sysprep for example.com domain or company.com domain without having user authenticate against these domains. We should focus in this distinction to avoid creating more application errors and incorrect dependencies between components. Each pool should have a set of key/value attached, user should be able to add keys and value as he wishes, selecting type "sensitive" of a key will also encrypt the value using engine standard encryption (obfuscation). The sysprep file will be transformed by replacing each $key$ with its value before used. In this configuration user may set: JoinDomain DomainAdminPassword [sensitive] DomainAdmin MachineObjectOU And be able to join the specific domain in the pool.
BZ<2>Jira Resync