Bug 2165605
| Summary: | RHDS 12 Performance notably worse than RHDS 10 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Directory Server | Reporter: | George Srutkowski <gsrutkow> | ||||||
| Component: | 389-ds-base | Assignee: | LDAP Maintainers <idm-ds-dev-bugs> | ||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | LDAP QA Team <idm-ds-qe-bugs> | ||||||
| Severity: | medium | Docs Contact: | Evgenia Martynyuk <emartyny> | ||||||
| Priority: | unspecified | ||||||||
| Version: | 12.0 | CC: | czinda, dchen, idm-ds-dev-bugs, jyoung, mharmsen, mreynolds, msauton, musoni, tbordaz, tmihinto, vashirov, vvanhaft | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2023-08-16 16:12:55 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
George Srutkowski
2023-01-30 14:26:26 UTC
*** Copied from Support Ticket 03420041 ***
(replying to Srutkowski, George)
> I apologize for not providing an update sooner; I've been communicating with the engineering team to come up with a better solution than what they've provided; currently, the only solution they've been able to provide is to switch the password hash for all users to the less secure solution. We're continuing to examine the data you've provided while methodically testing and recording results. I understand that the safety and security of the users in your database are of the utmost importance; Will this be a feasible solution for you?
George,
Thank you for the update. Switching password storage scheme to SSHA512 is not an option we will be considering. We will wait for other options from engineering.
(In reply to George Srutkowski from comment #10) > *** Copied from Support Ticket 03420041 *** > > (replying to Srutkowski, George) > > I apologize for not providing an update sooner; I've been communicating with the engineering team to come up with a better solution than what they've provided; currently, the only solution they've been able to provide is to switch the password hash for all users to the less secure solution. We're continuing to examine the data you've provided while methodically testing and recording results. I understand that the safety and security of the users in your database are of the utmost importance; Will this be a feasible solution for you? > George, > Thank you for the update. Switching password storage scheme to SSHA512 is > not an option we will be considering. We will wait for other options from > engineering. There are no other options if they want to compare RHDS 10 to RHDS 12. The config and password storage scheme must be the same between the versions of RHDS as the password storage scheme PBKDF2-SHA512 is designed to be slower (but more secure) than SSHA512. No idea why they are refusing to make this simple change, because from the engineering standpoint what they are seeing (this perf drop on binds) is expected with the default password scheme used in RHDS 12. If they want the binds to be more performant then they need to change the password storage scheme to what is used in RHDS 10 "before" loading the entries into RHDS 12. Or, don't change the storage scheme and remove the "binds" from the slamd configuration and rerun the tests on both RHDS 10 and 12. Customer has followed steps and provided SLAMD testing results. Latest round (Round 2) has been uploaded to bugzilla. Comment from customer: Steps followed: 1. Verified that the password storage scheme is PBKDF2-SHA512 and this is reflected as such on the slamd accounts, those paasswords show up as PBKDF2-SHA512. 2. All RHDS 12 servers have the password storage scheme changed to SSHA512. Restarted. 3. Verified that slamd accounts still have the password storage scheme as PBKDF2-SHA512. 4. First round of slamd test performed. This is the first bind for slamd acccounts since the change to the password storage scheme. Verified that they now reflect the change to SSHA512. 5. Another round of slamd test performed. This has slightly better results, presumably because the passwords have already been changed to SSHA512. But still very much lower than RHDS 10. > 1. Verified that the password storage scheme is PBKDF2-SHA512 and this is reflected as such on the slamd accounts, those paasswords show up as PBKDF2-SHA512.
> 2. All RHDS 12 servers have the password storage scheme changed to SSHA512. Restarted.
> 3. Verified that slamd accounts still have the password storage scheme as PBKDF2-SHA512.
Changing the default password storage scheme won't change the password store scheme of existing password.
You will need to change passwords to use the new default password storage scheme.
Created attachment 1955349 [details]
Internal Red Hat Testing Results
Red Hat Internal Testing Update
Using the same slamd job I ran tests against RHDS 10, 12.1, and 12.3. I made sure all the user entry passwords were hashed using SSHA512.
RHDS 12.3 is 32%-37% faster than RHDS 10. All RHDS 12 versions were faster than RHDS 10. I suspect in the customer tests they still did not have passwords hashed using the same algorithm. The attached document has all the testing steps, data, and results.
|