Description of problem: Version-Release number of selected component (if applicable): rhevm-restapi-3.5.0-0.13.beta.el6ev.noarch How reproducible: always Actual results: At /domains/id/users url user_name element is: <user_name>user3@ldap-authz-ad_ad-w2k12r2</user_name> At /users url user_name element is: <user_name>AD-W2K12R2\user3@ldap-authz-ad_ad-w2k12r2</user_name> Expected results: Both should be same.
Do you see the differentiation in names after upgrade from 3.4.x to 3.5, or is it on clean env? On cleanenv, with the ldap-authz-ad1 it works well, unfortunately, there is some issue with the profile you tested with (I wonder if some setup issue) so I'll need to check it out, but for the meanwhile answering my question can help thanks!
I tested with clean env. now(vt6) it's: <user_name>user1FirstName user1LastName@ldap-authz-test_tls</user_name> vs <user_name>user1.lab.eng.brq.redhat.com@ldap-authz-test_tls</user_name>
(In reply to Ondra Machacek from comment #0) > Description of problem: > > > Version-Release number of selected component (if applicable): > rhevm-restapi-3.5.0-0.13.beta.el6ev.noarch > > How reproducible: > always > > Actual results: > At /domains/id/users url user_name element is: > <user_name>user3@ldap-authz-ad_ad-w2k12r2</user_name> > > At /users url user_name element is: > <user_name>AD-W2K12R2\user3@ldap-authz-ad_ad-w2k12r2</user_name> > > > Expected results: > Both should be same. This is correct behavior. Due to backward compatibility the user name of user at /users should be something that can be used in restapi to perform login for the legacy providers. This is why it contains the principal name and not the user name. The current behavior is what we expect.
Alon, based on your comment, should this one be closed as notabug/wontfix?
(In reply to Oved Ourfali from comment #4) > Alon, based on your comment, should this one be closed as notabug/wontfix? yes, unless anyone think otherwise.
(In reply to Alon Bar-Lev from comment #5) > (In reply to Oved Ourfali from comment #4) > > Alon, based on your comment, should this one be closed as notabug/wontfix? > > yes, unless anyone think otherwise. Hmm, I had additional thought about it - are you ok with Ondra's comment that it happens on clean envvironment as well, not just upgrade from 3.4?
(In reply to Yair Zaslavsky from comment #6) > (In reply to Alon Bar-Lev from comment #5) > > (In reply to Oved Ourfali from comment #4) > > > Alon, based on your comment, should this one be closed as notabug/wontfix? > > > > yes, unless anyone think otherwise. > > Hmm, I had additional thought about it - are you ok with Ondra's comment > that it happens on clean envvironment as well, not just upgrade from 3.4? it is not matter if it is clean or not... the behavior and we had bug against that is that the user name should be able to login into restapi when using legacy providers (and if also required the new provider if the authz is the profile name).
(In reply to Alon Bar-Lev from comment #7) > (In reply to Yair Zaslavsky from comment #6) > > (In reply to Alon Bar-Lev from comment #5) > > > (In reply to Oved Ourfali from comment #4) > > > > Alon, based on your comment, should this one be closed as notabug/wontfix? > > > > > > yes, unless anyone think otherwise. > > > > Hmm, I had additional thought about it - are you ok with Ondra's comment > > that it happens on clean envvironment as well, not just upgrade from 3.4? > > it is not matter if it is clean or not... the behavior and we had bug > against that is that the user name should be able to login into restapi when > using legacy providers (and if also required the new provider if the authz > is the profile name). On clean envirionment with paches that were suggested by me: 1. added IPA "domain" using manage-domains 2. searched the domains using /domains/<domain_id>/users 3. found a user I would like to add. 4. added the user to the system, gave system permissions 5. used rest-api to login, worked fine. So I guess I'm missing here something.
(In reply to Yair Zaslavsky from comment #8) > So I guess I'm missing here something. I do not think you are missing anything as the principal == user name in the legacy provider. In new provider and active directory you have difference hence this bug was opened. At least this is what I understand.
(In reply to Alon Bar-Lev from comment #9) > (In reply to Yair Zaslavsky from comment #8) > > So I guess I'm missing here something. > > I do not think you are missing anything as the principal == user name in the > legacy provider. > > In new provider and active directory you have difference hence this bug was > opened. > > At least this is what I understand. But I did test the patches with the new provider as well and they work. So what compatbility issue do we have?
(In reply to Yair Zaslavsky from comment #10) > (In reply to Alon Bar-Lev from comment #9) > > (In reply to Yair Zaslavsky from comment #8) > > > So I guess I'm missing here something. > > > > I do not think you are missing anything as the principal == user name in the > > legacy provider. > > > > In new provider and active directory you have difference hence this bug was > > opened. > > > > At least this is what I understand. > > But I did test the patches with the new provider as well and they work. > So what compatbility issue do we have? not sure how it can work if the @xxx is expected by restapi to be profile name while the @xxx we get is authz name, and if there are two user name user1 within domain and you do not have leading component.
I am re-opening just to reconsider since we don't have legacy provider in 4.0 anymore.
Closing again, we will create a new bug to track the change.