Description of problem: The aaa-ldap extension don't parses the space in baseDN correctly and characters after space is ignored . If the base DN is "My Company" only My is considered as baseDN in Search Request Version-Release number of selected component (if applicable): ovirt-engine-extension-aaa-ldap-1.0.2-1.el6ev.noarch How reproducible: 100% Steps to Reproduce: 1. Configure a base DN along with space . In my case pool.default.auth.simple.bindDN = cn=manager,dc=My Company,dc=com 2. Restart the ovirt-engine service and the profile will be created successfully . Here "space" is taken correctly. ========== 2015-05-13 21:43:24,387 DEBUG [org.ovirt.engineextensions.aaa.ldap.Framework] (ServerService Thread Pool -- 41) createBindRequest Return SimpleBindRequest(dn='cn=manager,o=My Company,dc=com') 2015-05-13 21:43:24,387 DEBUG [org.ovirt.engineextensions.aaa.ldap.Framework] (ServerService Thread Pool -- 41) BindRequest: SimpleBindRequest(dn='cn=manager,o=My Company,dc=com') ====== 3. Go to RHEV-M admin portal => Users => Add and search the user in this namespace. Here all characters after "space" will be ignored. My logs engine 2015-05-13 21:49:14,485 DEBUG [org.ovirt.engineextensions.aaa.ldap.Framework] (ajp-/127.0.0.1:8702-8) SearchRequest: SearchRequest(baseDN='cn=manager,o=My', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=0, filter='&(objectClass=groupOfNames)(|(cn=*))', attrs={entryUUID, cn, description}) ldap log May 13 21:52:57 dhcp234-33 slapd[16826]: connection_get(24) May 13 21:52:57 dhcp234-33 slapd[16826]: connection_get(24) May 13 21:52:57 dhcp234-33 slapd[16826]: SRCH "cn=manager,o=My" 2 0 Only 'cn=manager,o=My' is considered as baseDN . Characters after that has been ignored. Actual results: Characters after "space" in baseDN is ignored Expected results: Extension should consider space in baseDN correctly Additional info:
It is not ldap extension issue, cause is bug#1096175. I keep it open for visibility.
Martin - that will be fixed by Bug 1096175, right?
Yes, patch for BZ1096175 should fix also this bug.
*** This bug has been marked as a duplicate of bug 1096175 ***