When running in FIPS mode, DS selects SSHA512 as password storage schema else it selects PBKDF2_SHA256. The problem is that in FIPS mode it selects PBKDF2_SHA256 that is currently not supported by NSS. So DS fails to hash password
All versions
It fails during 'creating default Sudo bind user' where it stores a password
It should not fail
Metadata Update from @tbordaz: - Issue assigned to tbordaz
PR https://pagure.io/389-ds-base/pull-request/50100
00c3b7a..76847e8 master
Metadata Update from @tbordaz: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None
Metadata Update from @tbordaz: - Custom field origin adjusted to IPA (was: None) - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1656418
Extending error message
76847e8..ecdf6d8 master
Metadata Update from @mreynolds: - Issue set to the milestone: 1.3.9
Metadata Update from @tbordaz: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
826682e..baadc1c 389-ds-base-1.3.9
Metadata Update from @mreynolds: - Issue status updated to: Open (was: Closed)
We still get these errors if FIPS mode is enabled directly on the NSS database:
modutil -dbdir /etc/dirsrv/slapd-instance_name/ -fips true
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
we are seeing this problem . Do you have any docs/workaround for fixing this problem.,
[27/Aug/2019:09:15:40.674966260 -0400] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 3389 for LDAP requests [27/Aug/2019:09:16:27.671469052 -0400] - ERR - PBKDF2_SHA256 - Unable to retrieve slot from NSS. [27/Aug/2019:09:16:28.076190359 -0400] - ERR - PBKDF2_SHA256 - Unable to hash userpwd value [27/Aug/2019:09:16:28.350559528 -0400] - ERR - PBKDF2_SHA256 - Unable to retrieve slot from NSS. [27/Aug/2019:09:16:28.384578660 -0400] - ERR - PBKDF2_SHA256 - Unable to hash userpwd value [27/Aug/2019:09:16:37.423132237 -0400] - ERR - PBKDF2_SHA256 - Unable to retrieve slot from NSS. [27/Aug/2019:09:16:37.495669939 -0400] - ERR - PBKDF2_SHA256 - Unable to hash userpwd value [27/Aug/2019:09:16:37.776703296 -0400] - ERR - PBKDF2_SHA256 - Unable to retrieve slot from NSS. [27/Aug/2019:09:16:37.803930088 -0400] - ERR - PBKDF2_SHA256 - Unable to hash userpwd value [27/Aug/2019:09:16:38.082306270 -0400] - ERR - PBKDF2_SHA256 - Unable to retrieve slot from NSS
Above issue is seen on: 389-ds-base-1.4.1.3-5
We still get these errors if FIPS mode is enabled directly on the NSS database: modutil -dbdir /etc/dirsrv/slapd-instance_name/ -fips true
If NSS is in fips mode but not the system then I think the fix will select PBKDF2_SHA256 that is unsupported by NSS. @mreynolds, is this kind of deployment valid (NSS in FIPS and system not in FIPS) ?
Thanks @gkapoor for this testing/update. I am unsure if it is related to this ticket. The RC of the failing test looks independent of the selection of the appropriate password storage schema. It looks more a general issue, how to prevent/fix a deployment with data already containing unsupported storage schema. I fully agree it needs to be documented.
@tbordaz This could probably be fixed with an "if fips()" in libglobs.c when we do the default pw hash selection as we setup the frontend config I think. But I'm not able to configure a fips machine so I can't really test this :(
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/3158
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.