#50099 In FIPS mode, the server can select an unsupported password storage scheme
Closed: wontfix by mreynolds. Opened by tbordaz.

Issue Description

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

Package Version and Platform

All versions

Steps to reproduce

  1. Enable a server in fips mode
  2. install IPA server

Actual results

It fails during 'creating default Sudo bind user' where it stores a password

Expected results

It should not fail


Metadata Update from @tbordaz:
- Issue assigned to tbordaz

PR https://pagure.io/389-ds-base/pull-request/50100

00c3b7a94..76847e82a 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

76847e82a..ecdf6d8df 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)

826682eb6..baadc1c64 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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

Metadata