(First logged against RHEV. See:
https://bugzilla.redhat.com/show_bug.cgi?id=1273634

Re-entered here per request from Yaniv Dary.)

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: