Bug 1218029

Please provide information mentioned on page https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting + IPA package versions ($ rpm -qa | grep 'ipa')

Thank you!

bind-dyndb-ldap-6.0-2.el7.x86_64
ipa-server-4.1.0-18.el7.centos.3.x86_64

What does not work?
* Bind is unable to load or utilise and LDAP / IPA provided zone due to inability to connect to ldap.

How to reproduce?
Not tested, but these are the steps I took:
 Install ipa on EL7.0
 Upgrade to 7.1 with yum upgrade
 Everything breaks.

Error messages in logs:

As per previous ticket comment.

Is the problem zone or record?
  It is all zones. No data is loaded at all into bind-dyndb.

Can I export the DNS database?
  Yes, but I won't do much because the issue is connectivity between bind and ldap, not the data in the ldap database.

bind-dyndb-ldap as part of IPA installation?
  yes

Which version of bind?
  bind-9.9.4-18.el7_1.1.x86_64

Dynamic-db component of /etc/named.conf:

dynamic-db "ipa" {
	library "ldap.so";
	arg "uri ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket";
	arg "base cn=dns, dc=ipa,dc=example,dc=com";
	arg "fake_mname alina.ipa.example.com.";
	arg "auth_method sasl";
	arg "sasl_mech GSSAPI";
	arg "sasl_user DNS/alina.ipa.example.com";
	arg "serial_autoincrement yes";
};

Do I have other zones configured?
 No

Do you have global forwarders?
  Yes:

        forward first;
        forwarders {
                X.X.203.132;
                X.X.203.3;

        };

Do you have some settings in global configuration object in LDAP? 
  Probably, but as bind cannot connect to ldap, this is irrelevant.


No configuration change has been made by me after this issue started or before. The sequence of events was:

Working IPA and DNS on 7.0
yum upgrade (to 7.1); reboot
DNS no longer works.

The issue is quite firmly in the inability of bind to connect to the ldap server. According to the 389 logs as provided, it looks like there is a malformed request from bind.

It seems that named.conf contains correct values so the problem is likely in Directory server configuration.

Martin, do you remember this problem? I'm not able to find the bug we had some time back during RHEL 7.1 development.

William, it seems that you are hitting bug 1195295 (cloned from bug 1189154). Could you please verify what was you 389-ds-base version before the upgrade and verify if logs indicate the same problem as desribed in bug 1189154? Thank you!

Martin, could you advise William how to re-run directory server config upgrade? Thanks!

Hello William,

can check you /var/log/ipaupgrade.log for errors?

You can run upgrade manually, by executing following commands (please keep order, ipa-ldap-updater must go first)

# ipa-ldap-updater --upgrade
# ipa-upgradeconfig

2015-05-03T06:01:20Z DEBUG nsSSL3Ciphers:
2015-05-03T06:01:20Z DEBUG      +all
2015-05-03T06:01:20Z DEBUG [(0, u'nsSSL3Ciphers', ['+all']), (1, u'nsSSL3Ciphers', ['-rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_s
ha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha']), (2, u'allowWeakCipher', ['off'])]
2015-05-03T06:01:20Z DEBUG Live 1, updated 1
2015-05-03T06:01:20Z ERROR Upgrade failed with attribute "allowWeakCipher" not allowed
2015-05-03T06:01:20Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 152, in __upgrade
    self.modified = (ld.update(self.files, ordered=True) or
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 854, in update
    self._run_updates(all_updates)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 799, in _run_updates
    self._update_record(update)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 720, in _update_record
    self.conn.update_entry(entry)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1628, in update_entry
    self.conn.modify_s(entry.dn, modlist)
  File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1191, in error_handler
    raise errors.ObjectclassViolation(info=info)
ObjectclassViolation: attribute "allowWeakCipher" not allowed

2015-05-03T06:01:20Z DEBUG   duration: 2 seconds
2015-05-03T06:01:20Z DEBUG   [8/10]: stopping directory server
2015-05-03T06:01:20Z DEBUG Starting external process
2015-05-03T06:01:20Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv'
2015-05-03T06:01:22Z DEBUG Process finished, return code=0
2015-05-03T06:01:22Z DEBUG stdout=
2015-05-03T06:01:22Z DEBUG stderr=
2015-05-03T06:01:22Z DEBUG   duration: 1 seconds
2015-05-03T06:01:22Z DEBUG   [9/10]: restoring configuration
2015-05-03T06:01:22Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2015-05-03T06:01:22Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state'
2015-05-03T06:01:22Z DEBUG   duration: 0 seconds

Reruning the update gives me:

Done
Updating existing entry: cn=tasks,cn=config
Done
Updating existing entry: cn=encryption,cn=config
Upgrade failed with attribute "allowWeakCipher" not allowed
  [8/10]: stopping directory server
  [9/10]: restoring configuration
  [10/10]: starting directory server
Done.
IPA upgrade failed.


I removed the duplicate from the schema. Before: 

schema/99user.ldif:12:objectClasses: ( nsEncryptionConfig-oid NAME 'nsEncryptionConfig' DESC 'Netsca
schema/01core389.ldif:322:objectClasses: ( nsEncryptionConfig-oid NAME 'nsEncryptionConfig' DESC 'Netscape defined objectclass' SUP top MUST ( cn ) MAY ( nsCertfile $ nsKeyfile $ nsSSL2 $ nsSSL3 $ nsTLS1 $ sslVersionMin $ sslVersionMax $ nsSSLSessionTimeout $ nsSSL3SessionTimeout $ nsSSLClientAuth $ nsSSL2Ciphers $ nsSSL3Ciphers $ nsSSLSupportedCiphers $ allowWeakCipher) X-ORIGIN 'Netscape' )

After:

schema/01core389.ldif:322:objectClasses: ( nsEncryptionConfig-oid NAME 'nsEncryptionConfig' DESC 'Netscape defined objectclass' SUP top MUST ( cn ) MAY ( nsCertfile $ nsKeyfile $ nsSSL2 $ nsSSL3 $ nsTLS1 $ sslVersionMin $ sslVersionMax $ nsSSLSessionTimeout $ nsSSL3SessionTimeout $ nsSSLClientAuth $ nsSSL2Ciphers $ nsSSL3Ciphers $ nsSSLSupportedCiphers $ allowWeakCipher) X-ORIGIN 'Netscape' )

This appears to have worked to allow the update to complete, and both commands completed successfully. Now my DNS is working once more.

So summary:

The issue was failure to upgrade, due to nsEncryptionConfig in 99user.ldif.

Good to know, William.

It seems that 389 DS upgrade somehow did not manage to properly upgrade nsEncryptionConfig object class or something like that. Re-assigning the bug to 389 component for further investigation.

Hi, 

Can have some more details about the issue?

The upgrade was successful if it was done manually.  Is it correct?
If so, upgrading it as part of the IPA upgrade was the problem?
Can we have the steps to reproduce?
1) old system info -- versions, configuration, etc?
2) upgrade method.

And could there be any failed upgrade logs left?

Thanks,
--noriko

Old system was EL7.0

Previous versions were:

    Dep-Install 389-ds-base-1.3.1.6-26.el7_0.x86_64                         @updates
    Dep-Install 389-ds-base-libs-1.3.1.6-26.el7_0.x86_64                    @updates


Upgrade method was yum upgrade to new versions, followed by reboot. Manually running ipa-ldap-updater didn't work.

However, I suspect now in hindsight the reason was because I can't contact LDAPI due to being a confined SELinux used. So setting permissive followed by then manually fixing the schema worked. Sadly, because of this I can't now see what caused the issue. 

I have all logs including:
 ipa-upgradelog
 access
 errors

I can provide these to you if you want.

Thank you for your response, William!

Now, I'm wondering why you had nsEncryptionConfig in 99user.ldif.
> schema/99user.ldif:12:objectClasses: ( nsEncryptionConfig-oid NAME 'nsEncryptionConfig' DESC 'Netsca

Do you have nsEncryptionConfig-oid in the current upgraded 99user.ldif?

Do you see any modify operation in the access log?
$ grep "cn=encryption,cn=config" /path/to/access

I'm a bit worried you hit a bug in the schema replication...

Hi William,

Do you think you could reproduce this problem in house?

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

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

Replying to [comment:6 firstyear]:
> 
> I don't think that this will occur in the wild. It may be as a result of my specific environment setup.
> 
> First, my IPA domain started on Fedora. I believe it was on F20 / F21 at the time. I then moved it to EL7.0 when it came out, but this was a "minor version" downgrade of ipa version. I believe 3.3 to 3.1. Given my F21 likely had newer schema, this is probably how I ended up with nsEncryptionConfig in 99user.ldif.
> 
> Then, I have gone to upgrade 7.0 -> 7.1, and that's when I hit the issue.
> 
> So, I think it's a low likely hood people will hit this in the wild, but maybe we need some way of handling when system schema is put into 99user.ldif, and is then changed during an upgrade.
> 

Thanks to William Brown for his input on the ticket 48320.

We are pushing this bug out to 7.4.0.

This is believed to be the same issue as bug#1410080.  Closing as a duplicate.

*** This bug has been marked as a duplicate of bug 1410080 ***