Bug 1224418 – [RFE] Support eDirectory / rfc2307

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 1224418 - [RFE] Support eDirectory / rfc2307

Summary:	[RFE] Support eDirectory / rfc2307

Status:	CLOSED CURRENTRELEASE

Aliases:	None

Product:	Red Hat Enterprise Virtualization Manager
Classification:	Red Hat
Component:	ovirt-engine-extension-aaa-ldap (Show other bugs)
Sub Component:
Version:	3.5.0
Hardware:	Unspecified Unspecified

Priority	unspecified Severity unspecified
Target Milestone:	ovirt-3.6.0-rc2
Target Release:	3.6.0
Assigned To:	Yaniv Kaul
QA Contact:	Ondra Machacek
Docs Contact:

URL:
Whiteboard:
Keywords:	FutureFeature, Improvement, Reopened, ZStream

Depends On:	1224722
Blocks:
	Show dependency tree / graph

Reported:	2015-05-22 17:35 EDT by Anitha Udgiri
Modified:	2016-03-27 02:50 EDT (History)
CC List:	15 users (show)

See Also:
Fixed In Version:
Doc Type:	Enhancement
Doc Text:	Red Hat Enterprise Virtualization Manager now supports Novell eDirectory with the RFC-2307 schema extension.
Story Points:	---
Clone Of:
Environment:
Last Closed:	2016-03-27 02:50:02 EDT
Type:	Bug
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Error adding user to RHEV from eDirectory LDAP (20.47 KB, text/plain) 2015-09-22 11:34 EDT, Vinny Valdez	no flags	Details
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Anitha Udgiri 2015-05-22 17:35:31 EDT

Description of problem:openldap rfc2307

Customer is using the NetIQ/edir product that conforms to openldap rfc2307. 
After configuring for it, he was unable to add a user.

Comment 6 Alon Bar-Lev 2015-05-25 08:35:59 EDT

Thank you Anitha,
Logs looks good!

Comment 19 Ondra Machacek 2015-09-18 04:45:35 EDT

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

Comment 21 Alon Bar-Lev 2015-09-18 05:21:19 EDT

(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

Comment 22 Ondra Machacek 2015-09-18 05:24:33 EDT

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

Comment 23 Alon Bar-Lev 2015-09-18 05:28:26 EDT

(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.

Comment 24 Alon Bar-Lev 2015-09-18 05:31:55 EDT

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

Comment 26 Vinny Valdez 2015-09-22 11:34 EDT

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

Full error in engine.log

Comment 27 Ondra Machacek 2015-09-22 13:08:48 EDT

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

Comment 28 Vinny Valdez 2015-09-22 13:53:39 EDT

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?

Comment 29 Ondra Machacek 2015-09-23 03:08:53 EDT

(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.

Comment 30 Ondra Machacek 2015-09-23 04:08:49 EDT

(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.

Note You need to log in before you can comment on or make changes to this bug.