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!
revision 0001-Ticket-48909-Replication-stops-working-in-FIPS-mode.patch
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 61c72f9 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 9982033
fba9d48..48ed4c8 389-ds-base-1.3.4 -> 389-ds-base-1.3.4 commit 48ed4c8
509b296..96c8765 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 96c8765
c567c7c..c55e708 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit c55e708
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.
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.