Bug 1352109

Summary:	Replication stops working only when fips mode is set to true
Product:	Red Hat Enterprise Linux 6	Reporter:	Jean Figarella <jfigarel>
Component:	389-ds-base	Assignee:	mreynolds
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:	Marc Muehlfeld <mmuehlfe>
Priority:	unspecified
Version:	6.7	CC:	amsharma, hkario, jfigarel, mreynolds, nhosoi, nkinder, rmeggins, rrelyea, vashirov
Target Milestone:	pre-dev-freeze
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.2.11.15-84.el6	Doc Type:	Bug Fix
Doc Text:	In FIPS mode, the "slapd_pk11_getInternalKeySlot()" function is now used to retrieve the key slot for a token The Red Hat Directory Server previously tried to retrieve the key slot from a fixed token name, when FIPS mode was enabled on the security database. However, the token name can change. If the key slot is not found, Directory Server is unable to decode the replication manager's password and replication sessions fail. To fix the problem, the "slapd_pk11_getInternalKeySlot()" function now uses FIPS mode to retrieve the current key slot. As a result, replication sessions using SSL or STTARTTLS no longer fail in the described situation.	Story Points:	---
Clone Of:
Clones:	1425841 (view as bug list)		Environment:
Last Closed:	2017-03-21 10:21:50 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:
Bug Depends On:	1387811, 1387812, 1390154
Bug Blocks:	1425841, 1425952

Description Jean Figarella 2016-07-01 15:46:42 UTC

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>
3.

Actual results:

[01/Jul/2016:11:42:33 -0400] NSMMReplicationPlugin - agmt="cn=ReplAgrmt_ds-clone1" (ds-clone1:636): Decoding of the credentials failed.
[01/Jul/2016:11:42:39 -0400] NSMMReplicationPlugin - agmt="cn=ReplAgrmt_ds-clone1" (ds-clone1:636): Decoding of the credentials failed.
[01/Jul/2016:11:42:51 -0400] NSMMReplicationPlugin - agmt="cn=ReplAgrmt_ds-clone1" (ds-clone1:636): Decoding of the credentials failed.
[01/Jul/2016:11:43:15 -0400] NSMMReplicationPlugin - agmt="cn=ReplAgrmt_ds-clone1" (ds-clone1:636): Decoding of the credentials failed.
[01/Jul/2016:11:44:03 -0400] NSMMReplicationPlugin - agmt="cn=ReplAgrmt_ds-clone1" (ds-clone1:636): Decoding of the credentials failed.

Comment 1 Noriko Hosoi 2016-07-01 17:33:30 UTC

Upstream ticket:
https://fedorahosted.org/389/ticket/48909

Comment 2 Jean Figarella 2016-07-01 17:46:41 UTC

I got around the issue by refreshing the password via an ldapmodify.

Example:

dn: cn=ReplAgrmt_name,cn=replica,cn=dc\3Dca-33,cn=mapping tree,cn=config
changetype: modify
replace: nsDS5ReplicaCredentials
nsDS5ReplicaCredentials: passwordgoeshere

Comment 26 errata-xmlrpc 2017-03-21 10:21:50 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0667.html