RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1404443 - incompatible nsEncryptionConfig object definition prevents RHEL 7->6 schema replication
Summary: incompatible nsEncryptionConfig object definition prevents RHEL 7->6 schema r...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.3
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: 7.4
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks: 1410080
TreeView+ depends on / blocked
 
Reported: 2016-12-13 21:27 UTC by Scott Poore
Modified: 2020-09-13 21:54 UTC (History)
8 users (show)

Fixed In Version: 389-ds-base-1.3.6.1-3.el7
Doc Type: Known Issue
Doc Text:
IdM schema replications from Red Hat Enterprise Linux 7 to 6.9 fail Identity Management (IdM) in Red Hat Enterprise Linux 6.9 uses a different schema definition in the `nsEncryptionConfig` object class than IdM on Red Hat Enterprise Linux 7.3. Because the schema learning mechanism is unable to merge definitions, schema replications between servers fail. As a consequence, mechanisms relying on the schema can fail. For example, schema violations and plug-in failures can occur, replication can fail, and access control instructions (ACI) can be ignored. In an upcoming Red Hat Enterprise Linux 7.3 update, the `nsTLS10`, `nsTLS11`, and `nsTLS12` attributes will be added to the list of allowed attributes in the `nsEncryptionConfig` object class, and as a consequence, mechanisms relying on the schema no longer fails in the described scenario.
Clone Of:
: 1410080 (view as bug list)
Environment:
Last Closed: 2017-08-01 21:12:24 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
var log from master (4.00 MB, application/x-gzip)
2016-12-13 21:48 UTC, Scott Poore 		no flags Details
var log from replica (878.55 KB, application/x-gzip)
2016-12-13 21:49 UTC, Scott Poore 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 2133 0 None closed incompatible nsEncryptionConfig object definition prevents RHEL 7->6 schema replication 2020-09-29 12:24:36 UTC
Red Hat Product Errata RHBA-2017:2086 0 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2017-08-01 18:37:38 UTC

Description Scott Poore 2016-12-13 21:27:30 UTC 
Description of problem:

After doing an ipa-replica-install on a RHEL7 host, I can no longer see DNS entries in IPA from my RHEL6 IPA Master.

After what appears to be a successful ipa-replica-install, I see this:

[root@rhel6-1 yum.repos.d]# ipa dnsrecord-find testrelm.test
----------------------------
Number of entries returned 0
----------------------------

But, on the RHEL7 Replica, I see:

[root@rhel7-1 ~]# ipa dnsrecord-find testrelm.test
  Record name: @
  NS record: rhel7-1.testrelm.test., rhel6-1.testrelm.test.

  Record name: _kerberos
  TXT record: "TESTRELM.TEST"

  Record name: _kerberos._tcp
  SRV record: 0 100 88 rhel7-1.testrelm.test., 0 100 88 rhel6-1.testrelm.test.

  Record name: _kerberos-master._tcp
  SRV record: 0 100 88 rhel7-1.testrelm.test., 0 100 88 rhel6-1.testrelm.test.

  Record name: _kpasswd._tcp
  SRV record: 0 100 464 rhel6-1.testrelm.test., 0 100 464 rhel7-1.testrelm.test.

  Record name: _ldap._tcp
  SRV record: 0 100 389 rhel6-1.testrelm.test., 0 100 389 rhel7-1.testrelm.test.

  Record name: _kerberos._udp
  SRV record: 0 100 88 rhel7-1.testrelm.test., 0 100 88 rhel6-1.testrelm.test.

  Record name: _kerberos-master._udp
  SRV record: 0 100 88 rhel7-1.testrelm.test., 0 100 88 rhel6-1.testrelm.test.

  Record name: _kpasswd._udp
  SRV record: 0 100 464 rhel6-1.testrelm.test., 0 100 464 rhel7-1.testrelm.test.

  Record name: _ntp._udp
  SRV record: 0 100 123 rhel7-1.testrelm.test.

  Record name: ipa-ca
  A record: 192.168.122.71, 192.168.122.61

  Record name: rhel6-1
  A record: 192.168.122.61
  SSHFP record: 2 1 25E56BD64B1AF74DAD7EF1602764370E5EBF7768, 1 1
                079868C7C370853AE500D5AC51DA09DE298C3A71

  Record name: rhel7-1
  A record: 192.168.122.71
  SSHFP record: 4 2 FDB4EC53A9852259A7B4C7683F2E732E5F22159A2FEFCC56EC4C6EDF 1E802778, 3 2
                C16330C457DB62F57E354C3B5AB691D3971E2541BA3D35CE2B94D602 40633F14, 1 1
                5ECFC03B91EAC1BA899EFEC96FE4D5907335AE02, 3 1 38624BD4358FC5875C0A5AA33F18AFCD21C1BBF3,
                4 1 0DEE9239A41FFF1343A29EEAD195AA9F84B6FE2A, 1 2
                68A7A65399233DD0A01A6D6CFBF57DFCE351EE143657FD4D86FF6F9E 9CCBC0C6
-----------------------------
Number of entries returned 13
-----------------------------
[root@rhel7-1 ~]# 



Version-Release number of selected component (if applicable):
on RHEL6 IPA Master:
ipa-server-3.0.0-51.el6.x86_64
pki-ca-9.0.3-51.el6.noarch

on RHEL7 IPA Replica:
ipa-server-4.4.0-14.el7_3.1.x86_64
pki-ca-10.3.3-14.el7_3.noarch


How reproducible:
always

Steps to Reproduce:
On IPA Master:
1.  ipa-server-install --setup-dns --forwarder=192.168.122.1 --hostname=rhel6-1.testrelm.test --ip-address=192.168.122.61 -r TESTRELM.TEST -n testrelm.test -p Secret123 -a Secret123 -U

On IPA Replica:
2.  scp /usr/share/ipa/copy-schema-to-ca.py root@rhel6-1:/root
3.  ssh root@rhel6-1 "python /root/copy-schema-to-ca.py"

On IPA Master:
4.  ipa-replica-prepare -p Secret123 --ip-address=192.168.122.71 --reverse-zone=122.168.192.in-addr.arpa. rhel7-1.testrelm.test

On IPA Replica:
5.  ipa-replica-install --setup-ca --setup-dns --forwarder=192.168.122.1 -p Secret123 -w Secret123 /root/replica-info-rhel7-1.testrelm.test.gpg -U

note, firewall was disabled on both hosts to test.

Actual results:

Cannot see DNS records from IPA commands after installing newer replica.

Expected results:

Can still see DNS records as expected.

Additional info:
Comment 1 Scott Poore 2016-12-13 21:36:05 UTC 
Also, note to prevent NetworkManager from overwriting /etc/resolv.conf I added dns=none to /etc/NetworkManager/NetworkManager.conf.
Comment 2 Scott Poore 2016-12-13 21:48:44 UTC 
Created attachment 1231338 [details]
var log from master

I see a lot of errors in dirsrv logs.  maybe corruption there?
Comment 3 Scott Poore 2016-12-13 21:49:15 UTC 
Created attachment 1231339 [details]
var log from replica
Comment 4 Petr Spacek 2016-12-14 07:58:09 UTC 
There is some ACI problem:
$ grep NSACLPlugin /var/log/dirsrv/slapd-TESTRELM-TEST/error*
[06/Dec/2016:21:53:27 -0500] NSACLPlugin - __aclp__init_targetattr: targetattr "ipaProtectedOperation" does not exist in schema. Please add attributeTypes "ipaProtectedOpera
tion" to schema if necessary. 
[06/Dec/2016:21:53:27 -0500] NSACLPlugin - ACL PARSE ERR(rv=-5): (targetattr  = "userPassword
[06/Dec/2016:21:53:27 -0500] NSACLPlugin - __aclp__init_targetattr: targetattr "ipaProtectedOperation" does not exist in schema. Please add attributeTypes "ipaProtectedOpera
tion" to schema if necessary. 
[06/Dec/2016:21:53:27 -0500] NSACLPlugin - ACL PARSE ERR(rv=-5): (targetattr  = "userPassword
[06/Dec/2016:21:53:27 -0500] NSACLPlugin - Error: This  ((targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey 
|| krbPrincipalName || krbCanonicalName || krbPasswordExpiration || krbPwdHistory || krbLastPwdChange || krbExtraData || krbLastSuccessfulAuth || krbLastFailedAuth || ipaUni
queId || memberOf || enrolledBy || ipaNTHash || ipaProtectedOperation")(version 3.0; acl "Admin can manage any entry"; allow (all) groupdn = "ldap:///cn=admins,cn=groups,cn=
accounts,dc=testrelm,dc=test";)) ACL will not be considered for evaluation because of syntax errors.
[06/Dec/2016:21:53:27 -0500] NSACLPlugin -  Can't add the rest of the acls for entry:dc=testrelm,dc=test after delete
[06/Dec/2016:21:53:27 -0500] NSACLPlugin - __aclp__init_targetattr: targetattr "ipaProtectedOperation" does not exist in schema. Please add attributeTypes "ipaProtectedOpera
tion" to schema if necessary. 
[06/Dec/2016:21:53:27 -0500] NSACLPlugin - ACL PARSE ERR(rv=-5): (targetattr  = "userPassword


and so on.
Comment 5 thierry bordaz 2016-12-14 10:54:56 UTC 
There is a problem of replication of the schema RHEL7 to RHEL6. The side effect is that aci definitions that rely on attributes only defined in RHEL7, will be ignore during access control evaluations.

Some data
The update of the domain schema (from RHEL7 to RHEL6) relies on replication of the schema that did not occur because

    [06/Dec/2016:21:53:29.320981372 -0500] NSMMReplicationPlugin - [S] Schema agmt="cn=meToqe-blade-14.testrelm.test" (qe-blade-14:389) must not be overwritten (set replication log for additional info)


The problem is that RHEL7 defines new acis with RHEL7 schema specific definitions
For example:
# update on RHEL7 that added

    aci;vucsn-584779e4002c00030000: (targetattr="ipaProtectedOperati
     on;write_keys")(version 3.0; acl "Allow trust agents to set keys for cross re
     alm principals"; allow(write) groupdn="ldap:///cn=adtrust agents,cn=sysaccoun
     ts,cn=etc,dc=testrelm,dc=test";)


Then RHEL7 replicates those aci

    [06/Dec/2016:21:53:25 -0500] conn=35 fd=75 slot=75 connection from 10.19.34.9 to 10.19.34.84
    [06/Dec/2016:21:53:25 -0500] conn=35 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
    [06/Dec/2016:21:53:25 -0500] conn=35 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
    [06/Dec/2016:21:53:25 -0500] conn=35 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
    [06/Dec/2016:21:53:25 -0500] conn=35 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
    [06/Dec/2016:21:53:25 -0500] conn=35 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
    [06/Dec/2016:21:53:25 -0500] conn=35 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=ldap/auto-hv-02-guest04.testrelm.test,cn=services,cn=accounts,dc=testrelm,dc=test"
    ..
    [06/Dec/2016:21:54:31 -0500] conn=35 op=133 MOD dn="cn=trusts,dc=testrelm,dc=test"
    [06/Dec/2016:21:54:31 -0500] conn=35 op=133 RESULT err=0 tag=103 nentries=0 etime=0 csn=584779e4002c00030000


But they can not be parsed/evaluated on RHEL6

    [06/Dec/2016:21:53:27 -0500] NSACLPlugin - __aclp__init_targetattr: targetattr "ipaProtectedOperation" does not exist in schema. Please add attributeTypes "ipaProtectedOperation" to schema if necessary.
Comment 6 thierry bordaz 2016-12-14 11:08:21 UTC 
Problems are
nsEncryptionConfig allowed attribute
    RHEL7 specific: sslVersionMin, sslVersionMax
    RHEL6 specific: nsTLS10, nsTLS11, nsTLS12

    --> RHEL7 definition should support nsTLS10, nsTLS11, nsTLS12

nsViewFilter syntax change:
    RHEL7: 1.3.6.1.4.1.1466.115.121.1.15
    RHEL6: 1.3.6.1.4.1.1466.115.121.1.26

mgrpRFC822MailMember
    RHEL7
        15rfc2307bis.ldif:  1.3.6.1.4.1.1466.115.121.1.26
        50ns-mail.ldif:     1.3.6.1.4.1.1466.115.121.1.15  <-- selected                                                             

    RHEL6:
        50ns-mail.ldif: 1.3.6.1.4.1.1466.115.121.1.15
        99user.ldif:    1.3.6.1.4.1.1466.115.121.1.26  <-- selected
Comment 10 thierry bordaz 2016-12-14 16:14:07 UTC 
The problems comes from the nsEncryptionConfig objectclass definition that differs in RHEL6 and RHEL7.
Both versions have specific attributes. RHEL 7 allows sslVersionMin, sslVersionMax but not nsTLS10, nsTLS11, nsTLS12.
This is the opposite for RHEL6.

There is in RHEL7 a schema learning mechanism that should address this.
It does not because it does not implement a merge, where the final result would be: allows sslVersionMin, sslVersionMax , nsTLS10, nsTLS11, nsTLS12.

So the problematic objectclass is not learned/merged and RHEL7 is unable to push its schema.

A possible workaround (needs to be confirmed) is to stop RHEL7, edit nsEncryptionConfig definition to add nsTLS10, nsTLS11, nsTLS12. So that it will be a true superset of RHEL6 definition.
Comment 11 thierry bordaz 2016-12-14 18:07:46 UTC 
The workaround is verified:

 RHEL7: stop ipa, edit 99user.ldif to add the definition
objectclasses: ( nsEncryptionConfig-oid NAME 'nsEncryptionConfig' DESC 'Netsca
 pe defined objectclass' SUP top STRUCTURAL MUST cn MAY ( nsCertfile $ nsKeyfi
 le $ nsSSL2 $ nsSSL3 $ nsTLS1 $ nsTLS10 $ nsTLS11 $ nsTLS12 $ sslVersionMin $
  sslVersionMax $ nsSSLSessionTimeout $ nsSSL3SessionTimeout $ nsSSLClientAuth
  $ nsSSL2Ciphers $ nsSSL3Ciphers $ nsSSLSupportedCiphers $ allowWeakCipher $
 CACertExtractFile $ allowWeakDHParam ) X-ORIGIN ( 'Netscape' 'user defined' )
  )
       It basically adds 'nsTLS10 $ nsTLS11 $ nsTLS12'
         start ipa

   Then the schema is replicated RHEL7 to RHEL6 (ldapsearch -D "cn=directory manager" -W -b "cn=schema" nsSchemaCSN)

 RHEL6: ipa restart (to reread the aci definitions that were ignored)

Then the command ipa dnsrecord-find testrelm.test gives the same result on RHEL6 and RHEL7
Comment 12 Petr Vobornik 2016-12-15 14:13:57 UTC 
It is bit unclear to me. Should it be fixed on RHEL6 side or RHEL7? In ipa or 389-ds?
Comment 13 thierry bordaz 2016-12-15 15:20:56 UTC 
My understanding is that starting https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=522309 RHEL6 standard DS schema contains a nsEncryptionConfig definition that diverge from RHEL7.

This prevents replication of the schema RHEL6 to/from RHEL7 (and creates the aci/dns issue).

A workaround exists https://bugzilla.redhat.com/show_bug.cgi?id=1404443#c11

A fix for this is needed in 389-ds (improve schema learning mechanism to support diverging defintions, enhance RHEL7 nsEncryptionConfig defintion, others ...)
Comment 14 Nathan Kinder 2016-12-15 16:36:59 UTC 
Moving to the proper component.
Comment 19 Noriko Hosoi 2016-12-20 18:31:03 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/49074
Comment 20 thierry bordaz 2016-12-22 16:52:45 UTC 
Fix pushed upstream. Moving BZ to POST.
Comment 21 Noriko Hosoi 2016-12-26 01:43:29 UTC 
Justification: this is a test stopper.  Without this fix, the QE team cannot test the rhel-7.3 -> rhel-6.8 replication.
Comment 24 thierry bordaz 2017-01-10 15:54:34 UTC 
IMHO the description looks really good but the possible consequences aspect may be more precise:

"...schema replications from Red Hat Enterprise Linux 7 to 6.9 fail, and schema violation errors are logged."

with something like

"...schema replication between the servers fails. The consequence is that mechanisms relying on schema may fails: operation logged in schema violations, operation failing because of plugin failures, replication breakage, ACI being ignored, ..."
Comment 29 errata-xmlrpc 2017-08-01 21:12:24 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://access.redhat.com/errata/RHBA-2017:2086
Note You need to log in before you can comment on or make changes to this bug.