What is the nature and description of the request? RHEV refreshes all group membership for a user when logging in via LDAP/AD. If an organization has many LDAP/AD groups, users experience a very large lag time (~30 seconds) as group membership is analyzed. Why does the customer need this? * Large scale deployment using AD auth * Large AD/LDAP group memberships How would the customer like to achieve this? Any implementation that would speed up the login process. Maybe a background thread that does group membership validation asynchronous to the login process? For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Logging in as an AD user with many groups (~150) will be quick. Is there already an existing RFE upstream or in Red Hat Bugzilla? No. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? ASAP (RHEV 3.3.X) Is the sales team involved in this request and do they have any additional input? Not that I am aware. List any affected packages or components. ovirt-engine-backend, specifically adbroker.DirectorySearcher Would the customer be able to assist in testing this functionality if implemented? Possibly
Yair/Juan please specify what can be done (if available) to improve performance in this case
IMHO we should try to parallelize the code of the group retrieval and introduce other performance issues to the following area in the code - LdapBrokerCommandBase.populateGroup
(In reply to Yair Zaslavsky from comment #3) > IMHO we should try to parallelize the code of the group retrieval and > introduce other performance issues to the following area in the code - > > LdapBrokerCommandBase.populateGroup As the group membership may influence the permissions to that user, Shouldn't we rely on previously retrieved groups and after login refresh ? I'm not sure about the expectations here, but assuming these membership are rarely changed this may be a good enough solution. Alon what do you think ?
(In reply to Barak from comment #4) > (In reply to Yair Zaslavsky from comment #3) > > IMHO we should try to parallelize the code of the group retrieval and > > introduce other performance issues to the following area in the code - > > > > LdapBrokerCommandBase.populateGroup > > As the group membership may influence the permissions to that user, > Shouldn't we rely on previously retrieved groups and after login refresh ? > > I'm not sure about the expectations here, but assuming these membership are > rarely changed this may be a good enough solution. > > Alon what do you think ? I do not fully understand current implementation nor the question... However, if you refer to the ldap synchronization we do, we should not relay on it when constructing user profile on login, as the authoritative information is within the ldap. After we implement the new ldap provider we will be able to benchmark individual queries better, analyzing what should be optimized. During logon we should not update database with results, I think the current implementation does that.
(In reply to Alon Bar-Lev from comment #5) > (In reply to Barak from comment #4) > > (In reply to Yair Zaslavsky from comment #3) > > > IMHO we should try to parallelize the code of the group retrieval and > > > introduce other performance issues to the following area in the code - > > > > > > LdapBrokerCommandBase.populateGroup > > > > As the group membership may influence the permissions to that user, > > Shouldn't we rely on previously retrieved groups and after login refresh ? > > > > I'm not sure about the expectations here, but assuming these membership are > > rarely changed this may be a good enough solution. > > > > Alon what do you think ? > > I do not fully understand current implementation nor the question... > > However, if you refer to the ldap synchronization we do, we should not relay > on it when constructing user profile on login, as the authoritative > information is within the ldap. > > After we implement the new ldap provider we will be able to benchmark > individual queries better, analyzing what should be optimized. > > During logon we should not update database with results, I think the current > implementation does that. It does, as the current login flow also performs the MLA check (whether user is authorized to perform login to the system).
Actions taken: 1. there is no way to escape query all groups in LDAP as the output is group DN while in order to determine actual group membership the group unique id is required. 2. the new ldap implementation will not query same group twice in same query. 3. the engine synchronization was modified to avoid recursive queries, resolve and cache groups and only query these that are not resolved.
Notes: 1. query groups at login cannot be done async - as fully functional user within application requires all privileges. 2. query groups of user/groups must be done using individual query based on DN, so N groups derives N queries. 3. optimizing implementation to use X connections in parallel is doable at client side, however: a. in a sequence of several users at once, we load the server in many connections. b. the server has its own limitation, and it does not serve only ovirt application.
Adjusting priority/severity per work on generic ldap provider, bug#1063095.
Not sure why I missed this bug, we done our best within the new ldap implementation. I consider this fixed within 3.5 as we have no way to assign component version within the way we manage our product.
Alon, That's good to hear as our customer is very keen to get this functionality as it's blocking their wider adoption of RHEV. They will definitely be testing 3.5 and if they hit any issues with the ldap implementation, they will let us know and we will file appropriate bzs. Is there anything we should do specifically to keep you from missing bugs related to the LDAP implementation in RHEV? Cheers, Karl
I did not ignore this bug, just did not move it into the proper milestone and status... :) You should use the new ovirt-engine-extension-aaa-ldap component, there is no automatic migration sequence from legacy. Instructions are available[1][2]. I suggest you install upstream ovirt-engine within the same environment and start testing this even before the downstream version, there is no different in that regard. [1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=HEAD [2] http://www.ovirt.org/Features/AAA
I've got ~14s for legacy ad and ~6s for new provider which used ad ldap simple. For user with 160groups.
(In reply to Ondra Machacek from comment #15) > I've got ~14s for legacy ad and ~6s for new provider which used ad ldap > simple. > For user with 160groups. you should also try concurrent :)
you mean concurrent login ?
(In reply to Ondra Machacek from comment #17) > you mean concurrent login ? yes and also sequential, the new provider use connection pool that can be adjusted to balance the load, not to mention that it can communicate with several ldap servers based on various serverset settings. but at minimum see "POOL OPTIONS" within README.profile so you can optimize the # of connections. you can also in most cases enable auth-check.default.reuse-connections and gain even better response times.
I tested with rest api and new provider performance is significant. I used 4 users and set up 4 connection to ldap. Concurennt login of all 4 users was about ~2 sec. For the legacy it was ~18sec. Sequential login for new provider with same config was about +2sec. For legacy about +10sec.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0174.html