Bug 1148797

(In reply to Ondra Machacek from comment #0)
> Description of problem:
> currenty when there is backslash in name of any object it's not found.
> 
> Version-Release number of selected component (if applicable):
> rhevm-backend-3.5.0-0.13.beta.el6ev.noarch
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. Add user with backslash in username like AD-domain\userx@authz
> 2. Search for this user in UI or in REST
> UI: Users: usrname=AD-domain\userx@authz
> REST = /api/users?search=usrname%3DAD-domain%5Cuserx%40authz
> 
> Actual results:
> no results returned
> 
> Expected results:
> user is returned
> 
> Additional info:

new implementation supports only upn style, so backslashes will not appear any more.

but wroth checking with other special characters, now it is '@'.

please retest with latest implementations if that is at high priority.
yair has more import tasks for now.
thanks!

It's working for /api/users, but it doesn't work for /api/domains/id/users.

(In reply to Ondra Machacek from comment #3)
> It's working for /api/users, but it doesn't work for /api/domains/id/users.

can you please provide user and exact query (I prefer curl), so I can test.

Please note that different usernames I use below are due to bug 1147900.

1)
curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -H "Filter: False"
    -u $U $URL/users?search=usrname%3Du1%40qa.qumranet.com%40ldap-authz-test_digest_ad

2)
curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -H "Filter: False"
    -u $U $URL/domains/6c646170-2d61-7574-687a-2d746573745f/users?search=usrname%3Duser1+testgrp%40ldap-authz-test_digest_ad

First command return user. Second command return empty <users/> tag.

in api/domains is:
<user href="/api/domains/6c646170-2d61-7574-687a-2d746573745f/users/6E616A6E452B5973506B366D4F5645465737616571513D3D" id="6E616A6E452B5973506B366D4F5645465737616571513D3D"><name>user1</name><domain href="/api/domains/6c646170-2d61-7574-687a-2d746573745f" id="6c646170-2d61-7574-687a-2d746573745f"/><namespace>DC=qa,DC=lab,DC=tlv,DC=redhat,DC=com</namespace><last_name>testgrp</last_name><user_name>user1 testgrp@ldap-authz-test_digest_ad</user_name><principal>u1.com</principal><groups/></user>

in api/users is:
<user href="/api/users/44939603-b9a4-411a-a32e-8ed509f423a0" id="44939603-b9a4-411a-a32e-8ed509f423a0"><name>user1</name><link href="/api/users/44939603-b9a4-411a-a32e-8ed509f423a0/permissions" rel="permissions"/><link href="/api/users/44939603-b9a4-411a-a32e-8ed509f423a0/roles" rel="roles"/><link href="/api/users/44939603-b9a4-411a-a32e-8ed509f423a0/tags" rel="tags"/><domain href="/api/domains/6c646170-2d61-7574-687a-2d746573745f" id="6c646170-2d61-7574-687a-2d746573745f"/><domain_entry_id>6E616A6E452B5973506B366D4F5645465737616571513D3D</domain_entry_id><namespace>DC=qa,DC=lab,DC=tlv,DC=redhat,DC=com</namespace><last_name>testgrp</last_name><user_name>u1.com@ldap-authz-test_digest_ad</user_name><principal>u1.com</principal></user>

Bare in mind in engine code /api/users and /api/domains/xxxx/users get translated to SQL queries, and LDAP queries.
The fact "Users" are used both for engine (db) users and authz providers principals is misleading.

Please notice that the additions of @authz should not be included in search term as they are added for output only due to backward compatibility. We need user, actual user, with special characters, not sure such available.

My findings:

For:
---
    <user href="/ovirt-engine/api/domains/6c646170-2d61-7574-687a-2d61645f6164/users/312B7454613546726F6B572B364C71784A42457957773D3D" id="312B7454613546726F6B572B364C71784A42457957773D3D">
        <name>user3FirstName</name>
        <domain href="/ovirt-engine/api/domains/6c646170-2d61-7574-687a-2d61645f6164" id="6c646170-2d61-7574-687a-2d61645f6164"/>
        <namespace>DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com</namespace>
        <last_name>user3LastName</last_name>
        <user_name>user3FirstName user3LastName@ldap-authz-ad_ad-w2k12r2</user_name>
        <principal>user3.lab.eng.brq.redhat.com</principal>
        <groups/>
    </user>
---

Working: (search for "username=user3FirstName*")
$ curl -k -X GET -H "Content-Type: application/xml" "http://admin%40internal:engine@localhost:8080/ovirt-engine/api/domains/6c646170-2d61-7574-687a-2d61645f6164/users?search=username%3Duser3FirstName%2A"

Not working: (search for "username=user3FirstName *")
$ curl -k -X GET -H "Content-Type: application/xml" "http://admin%40internal:engine@localhost:8080/ovirt-engine/api/domains/6c646170-2d61-7574-687a-2d61645f6164/users?search=username%3Duser3FirstName%20%2A"

So there is a problem with at least space when specifying search.

see 1096175 for documentation which special characters are supported

*** This bug has been marked as a duplicate of bug 1096175 ***

I cannot search for user with * in name. I used ** for search. (within kerbldap, RHDS)
2015-09-11 14:53:50,530 DEBUG [org.ovirt.engine.extensions.aaa.builtin.kerberosldap.DirectorySearcher] (ajp-/127.0.0.1:8702-7) [] find() : LDAP filter='(&(&(objectClass=person))(|(givenname=special**)(sn=special**)(uid=special**)(uid=special**)))', baseDN='', explicitBaseDN='null', domain='brq-ldap.rhev.lab.eng.brq.redhat.com'



I cannot search for user with space in name. Used just a space for search (within AAA, ADw2k12)
2015-09-11 14:45:50,711 INFO  [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-1) [] ResourceManager::searchBusinessObjects - erroneous search text - ''ADUSER: allnames=with space''

Am I doing anything wrong? If yes, please tell me and change doc text.

I failed to add group with spaces in name. So moving back to assigned, but please read also comment 10 , thanks.

Command:

$ curl -k -X POST -H "Accept: application/xml" -H "Content-Type: application/xml" \
     -d "<group><name>Group with space</name><domain><name>ad-w2k12r2.rhev.lab.eng.brq.redhat.com-authz</name></domain></group>" \
     -u $U $URL/groups

=============================================================
Output:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<fault>
    <reason>Operation Failed</reason>
    <detail>Entity not found: ADGROUP.lab.eng.brq.redhat.com-authz:: name=Group with space</detail>
</fault>

=============================================================
Log:

2015-09-14 19:57:30,890 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp-/127.0.0.1:8702-2) [] Operation Failed: Entity not found: ADGROUP.lab.eng.brq.redhat.com-authz:: name=Group with space

As we discussed before, to make this happen, we must escape all special characters when provided with a query and unescape these at backend when parsing. It won't work any other way, as '=', ' ' and might be other characters have dual meaning when parsing. URIEncode/URIDecode will be fine, having done for each component.

Sitting with Eli it seems like it won't be a small change to escape everything.
Looking at the customer tickets on that, I saw that the only ones open are ones in which there is a "#" in the username, and " " in the domain.
As far as I understand, both these use-cases were covered as part of Eli's fix.

Ondra - can you verify those use-cases are now working properly?
Anand - can you confirm these are the only cases you know of?

If that's the case, we will move it to 4.0 (we consider re-writing the search mechanism anyway, so it will be one of the requirements there).

Created attachment 1075472 [details]
webadmin users

Works fine with AAA

Here is a list of special characters that can't be searched for(tested with new generic ldap nad RHDS):

!, ^, &, ), =, ', ", <, >, space

Anand - that means that if using the generic LDAP provider, you can add domains with spaces.
Also, generally, you'll be able to search for users and groups with "#".

Would that be enough for the pending tickets?
If so, we'll open another bug on the general use-case.

Verified with Anand that it is enough.

Eli/Ondra - please verify also the doc-text provided here, and correct it to suit what we support, if needed.

(In reply to Oved Ourfali from comment #17)
> Verified with Anand that it is enough.
> 
> Eli/Ondra - please verify also the doc-text provided here, and correct it to
> suit what we support, if needed.

Verified

Just few notes to doc text.

1) "Cause: unsupported characters in AD search." -> It's not related only to AD search

2) "space - supported only for the domain name" -> It's actually supported for namespace in context of oVirt and new generic ldap. In context of ldap it's namingContext.

same applies to bug 1096175

oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue.
If problems still persist, please open a new BZ and reference this one.