Bug 1538184
| Summary: | IDM replica install failing with "ldap_modify: Insufficient access (50)" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | aheverle |
| Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | ipa-qe <ipa-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.4 | CC: | aheverle, cheimes, lkrispen, pvoborni, rcritten, tbordaz, tscherf |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-03-20 16:36: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: | |||
Note that I see the same bind even on a successful installation: 2018-01-24T18:51:40Z DEBUG stderr=ldap_initialize( ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE-COM.socket/??base ) SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 Before adding the new sasl mapping installer also deleted the previous mapping
[23/Jan/2018:10:07:06.641219650 -0500] conn=2 op=3 DEL dn="cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config"
[23/Jan/2018:10:07:06.643693427 -0500] conn=2 op=3 RESULT err=0 tag=107 nentries=0 etime=0
[23/Jan/2018:10:07:06.643852904 -0500] conn=2 op=4 DEL dn="cn=Peer Master,cn=mapping,cn=sasl,cn=config"
[23/Jan/2018:10:07:06.646315724 -0500] conn=2 op=4 RESULT err=0 tag=107 nentries=0 etime=0
[23/Jan/2018:10:07:06.646473424 -0500] conn=2 op=5 DEL dn="cn=rfc 2829 dn syntax,cn=mapping,cn=sasl,cn=config"
[23/Jan/2018:10:07:06.648993236 -0500] conn=2 op=5 RESULT err=0 tag=107 nentries=0 etime=0
[23/Jan/2018:10:07:06.649144789 -0500] conn=2 op=6 DEL dn="cn=rfc 2829 u syntax,cn=mapping,cn=sasl,cn=config"
[23/Jan/2018:10:07:06.651591998 -0500] conn=2 op=6 RESULT err=0 tag=107 nentries=0 etime=0
[23/Jan/2018:10:07:06.651745071 -0500] conn=2 op=7 DEL dn="cn=uid mapping,cn=mapping,cn=sasl,cn=config"
[23/Jan/2018:10:07:06.654147130 -0500] conn=2 op=7 RESULT err=0 tag=107 nentries=0 etime=0
[23/Jan/2018:10:07:06.654708862 -0500] conn=2 op=8 ADD dn="cn=Full Principal,cn=mapping,cn=sasl,cn=config"
[23/Jan/2018:10:07:06.657004209 -0500] conn=2 op=8 RESULT err=0 tag=105 nentries=0 etime=0
[23/Jan/2018:10:07:06.657564254 -0500] conn=2 op=9 ADD dn="cn=Name Only,cn=mapping,cn=sasl,cn=config"
[23/Jan/2018:10:07:06.659911039 -0500] conn=2 op=9 RESULT err=0 tag=105 nentries=0 etime=0
But this looks intentional
def __configure_sasl_mappings(self):
# we need to remove any existing SASL mappings in the directory as otherwise they
# they may conflict.
The entry "uid=root,cn=users,cn=accounts,dc=ipa,dc=campllc,dc=org" matches one of the new mapping. Is it an entry added by the customer ?
Could we have a dump of this entry ?
Indeed if for any reason, uid=root has gidNumber=uidNumber=0 it could take authentication in place of 'cn=directory manager'. It could be a silent behavior if uid=root has enough rights on the main suffix. But during install, if you update schema you need to be DM. It is failing with:
2018-01-25T18:19:03Z DEBUG The ipa-replica-install command failed, exception: HTTPError: 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Decryption failed.',)]"]
2018-01-25T18:19:03Z ERROR 406 Client Error: Failed to validate message: No recipient matched the provided key["Failed: [ValueError('Decryption failed.',)]"]
2018-01-25T18:19:03Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
Which sounds very much like https://pagure.io/freeipa/issue/7006 and was fixed by modifying the HBAC rules.
I think I'd start with a new upstream tool to check the custodia keys:
https://raw.githubusercontent.com/freeipa/freeipa/master/install/tools/ipa-custodia-check
# wget https://raw.githubusercontent.com/freeipa/freeipa/master/install/tools/ipa-custodia-check
# python ipa-custodia-check `hostname` --verbose
|
Description of problem: Attempting to install IDM replicas and they are failing with the error: ldap_modify: Insufficient access (50) additional info: Insufficient 'write' privilege to the 'objectClasses' attribute of entry 'cn=schema'. Version-Release number of selected component (if applicable): ipa-server-4.5.0-22.el7_4.x86_64 How reproducible: Steps to Reproduce: 1. # ipa-replica-install --principal admin --admin-password ********* --setup-ca Actual results: Install fails Expected results: Install successful Additional info: Tried setting SELinux to permissive. umask is set to 0022 on the master and attempted replica [root@idm1 ~]# ll -lZ /usr/share/ipa/schema-update.ldif -rw-r--r--. root root system_u:object_r:usr_t:s0 /usr/share/ipa/schema-update.ldif