Background: 'Add User' lets the client select an existing user from a configured domain in the system (e.g: active-directory, ldap, internal domain) and add it to the ovirt configuration. To specify the user, the client supplies user-id. In 'internal' domain there is only one, pre-defined, user, which is: 'admin'. The bug: If client adds a user to 'internal' domains, then, since there is only one possible user in this domain ('admin'), the id which the client has supplied is ignored, and the engine assumes that the client meant 'admin'. But this can lead to confusing behaviour. If the client gave a different ID - perhaps thinking that he's creating a new user in 'internal' domain, the result will be adding the user 'admin' (which almost always exists already). The correct behaviour is - if client adds a user to 'internal' domain, and the ID of this user is not equal to the ID for 'admin', fail the action and supply a meaningful validation message.
Going forward we'll have an internal JDBC provider, Based on the the AAA work done for 3.5, Hence moving to 3.5, as this is low priority and even when called this API does not do any damage.
The problem is that InternalDirectory-->queryUsers(String query) always returns admin@internal, ignoring the query string. Since refactoring is expected this area in 3.5, it did not seem worth it to fix now and risk 'noise' (considering also the low priority of the bug). Another possibility was to add a hard-coded validation in the API, but that would be a wrong approach - after engine changes we would be stuck with a redundant - if not wrong, by then, validation.
*** This bug has been marked as a duplicate of bug 1100321 ***