389-ds-base

#48909 Replication stops working only when fips mode is set to true
Closed: wontfix Opened by nhosoi.

Closed: wontfix
Reopen Issue 
Description of problem:
After turning fips mode true, on the dirsrv nss, replication stops working,
getting error like:
NSMMReplicationPlugin - agmt="cn=ReplAgrmt_ds-clone1" (ds-clone1:636): Decoding
of the credentials failed.
Replication stops working only when fips mode is set to true
Version-Release number of selected component (if applicable):
rpm -qa | grep 389
389-admin-1.1.43-2.el6dsrv.x86_64
389-ds-console-1.2.12-2.el6dsrv.noarch
389-console-1.1.16-1.el6dsrv.noarch
389-ds-base-libs-1.2.11.15-74.el6.x86_64
389-admin-console-1.1.11-1.el6dsrv.noarch
389-ds-console-doc-1.2.12-2.el6dsrv.noarch
389-adminutil-1.1.22-1.el6dsrv.x86_64
389-admin-console-doc-1.1.11-1.el6dsrv.noarch
389-ds-base-1.2.11.15-74.el6.x86_64
rpm -qa | grep redhat-ds
redhat-ds-console-9.1.2-1.el6dsrv.noarch
redhat-ds-admin-9.1.2-1.el6dsrv.x86_64
redhat-ds-9.1.2-1.el6dsrv.x86_64
redhat-ds-base-9.1.2-1.el6dsrv.x86_64
redhat-ds-console-doc-9.1.2-1.el6dsrv.noarch
rpm -q nss
nss-3.21.0-8.el6.x86_64
How reproducible:
Looks like this only affects if replication has been setup and confirmed
working before fips mode is turn on.
Steps to Reproduce:
1. modutil -dbdir . -fips true
2. service dirsrv restart ds-<name>
Actual results:
[..] NSMMReplicationPlugin - agmt="cn=ReplAgrmt_ds-clone1" (ds-clone1:636): Decoding of the credentials failed.

Reproduced problem on master branch. The problem is that the security database gets modified when enabling FIPS, and pre-existing PBE(reversible passwords) can no longer be decoded. If the passwords are recreated/replaced then they can be decoded. Still trying to determine if this is the expected behavior when enabling FIPS...

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1378209

Note - this patch fixes the issue with the credentials, but there is another problem when replication tries to connect to the consumer. An "nss" bug has been identified as the cause of our server failing to establish a client connection while in FIPS mode. More on this as it develops.

Your fix looks good to me with this one question.

In migrateCredentials, you set "Internal (Software) Token " to the 7th arg fslotdes, which is FIPSSlotDescription. What is the purpose of passing the value? Is that to enforce not to change the token name, for instance?
{{{
… … migrateCredentials(char oldpath, char newpath, char *oldcred)
554 slapd_pk11_configurePKCS11(NULL, NULL, tokPBE, ptokPBE, NULL, NULL, NULL, NULL, 0, 0 );
553 slapd_pk11_configurePKCS11(NULL, NULL, tokPBE, ptokPBE, NULL, NULL, ptokPBE, NULL, 0, 0 );
^^^^^^^
}}}
Thanks!

Replying to [comment:5 nhosoi]:

Your fix looks good to me with this one question.

In migrateCredentials, you set "Internal (Software) Token " to the 7th arg fslotdes, which is FIPSSlotDescription. What is the purpose of passing the value? Is that to enforce not to change the token name, for instance?
{{{
… … migrateCredentials(char oldpath, char newpath, char *oldcred)
554 slapd_pk11_configurePKCS11(NULL, NULL, tokPBE, ptokPBE, NULL, NULL, NULL, NULL, 0, 0 );
553 slapd_pk11_configurePKCS11(NULL, NULL, tokPBE, ptokPBE, NULL, NULL, ptokPBE, NULL, 0, 0 );
^^^^^^^
}}}
Thanks!

Actually it's not needed. New patch attached.

Thanks, Mark!! Acked.

83a7705..61c72f9 master -> master
commit 61c72f966bda17993f483e8f79d97dff20b7cc93
Author: Mark Reynolds mreynolds@redhat.com
Date: Fri Oct 14 16:17:46 2016 -0400

70c7d2a..9982033 389-ds-base-1.3.5 -> 389-ds-base-1.3.5
commit 9982033b7cd888bd30400001e10158a9bbf9b863

fba9d48..48ed4c8 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit 48ed4c8137e4bc931b8fcc5ff24371984b764da5

509b296..96c8765 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit 96c87653b6f121592924ff30ed684f5c753bb12d

c567c7c..c55e708 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit c55e70835b4896ca178f6db2e9efe3545617357e

This still requires two fixes to NSS to truly work:

NSS - https://bugzilla.redhat.com/show_bug.cgi?id=1387811
NSS Softoken - https://bugzilla.redhat.com/show_bug.cgi?id=1387812

Mozilla upstream:

https://bugzilla.mozilla.org/show_bug.cgi?id=1312141
https://bugzilla.mozilla.org/show_bug.cgi?id=1312142

DS work is done, so closing ticket.

Metadata Update from @nhosoi:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.11.33

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/1968

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
None
None
None
Normal
Community
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.