Bug 1224418

Thank you Anitha,
Logs looks good!

I guess you forgot to add new pkg of aaa-ldap.
There is currently - ovirt-engine-extension-aaa-ldap-1.0.2-1.el6ev.noarch

(In reply to Ondra Machacek from comment #19)
> I guess you forgot to add new pkg of aaa-ldap.
> There is currently - ovirt-engine-extension-aaa-ldap-1.0.2-1.el6ev.noarch

it is not onqa... :)

I will probably won't support this in 3.5 as customer has a solution and I have not gotten any more requests

It was ON_QA, I've changed the status, see comment 19.
Anyway, should I close as won't fix, then?

(In reply to Ondra Machacek from comment #22)
> It was ON_QA, I've changed the status, see comment 19.
> Anyway, should I close as won't fix, then?

sorry, it was my mistake. yes, I will close it for now.

On second thought this to make it clear it is fixed in 3.6, closing it for 3.6.

Created attachment 1075886 [details]
Error adding user to RHEV from eDirectory LDAP

Full error in engine.log

As said above, it's not supported in 3.5. You can workaround if you add this[1] to directory: /usr/share/ovirt-engine-extension-aaa-ldap/profiles/ and name it 'rfc2307-edir.properties'. Then in your properties use 'include = <rfc2307-edir.properties>'

[1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob_plain;f=profiles/rfc2307-edir.properties;hb=ovirt-engine-extension-aaa-ldap-1.0

Thanks, I do know it is not supported in 3.5 but the customer is willing to try anything even unsupported to see if it works. Without this patch the namespace is blank, but we can find his user in the search. However, we cannot add it as we get the error I posted above.

With this new profile in place, the namespace is now populated, though it is unknown where this came from. It is a different ou= than we specified in the profile. So, the search cannot find his username, or anything else really so we still cannot move forward.

Would you like logs from this failure or should we not spend time on this testing and wait for 3.6?

(In reply to Vinny Valdez from comment #28) 
> With this new profile in place, the namespace is now populated, though it is
> unknown where this came from. It is a different ou= than we specified in the
> profile. So, the search cannot find his username, or anything else really so
> we still cannot move forward.

The namespace should be the namingContext, which you can find as follows:
$ ldapsearch -x -LLL -H ldap://edirectory-fqdn.org -s base namingContexts

I am not sure what do you mean by ou=? The user you used is in different namespace then the namespace which is shown in UI?

> 
> Would you like logs from this failure or should we not spend time on this
> testing and wait for 3.6?

Should work the same for 3.6 and 3.5 with the properties you downloaded.
So believe it worth to test. The logs would be very helpfull, also the configuration files. Thank you.

(In reply to Vinny Valdez from comment #28)
>
> With this new profile in place, the namespace is now populated, though it is
> unknown where this came from. It is a different ou= than we specified in the
> profile. So, the search cannot find his username, or anything else really so
> we still cannot move forward.
> 

Also please note some facts about edir. By default AFAIK, it has set up ACL, you have to use startTLS to be able to view some attributes needed by oVirt. 

Also please note, that the filter oVirt use is:
'&(objectClass=posixAccount)(uid=*)(|(givenName=*)(sn=*)(displayName=*)(uid=*))'

That means your users have to have objectClass posixAccount.