In case anyone else has the same problem, let me document what I did today with our IPA
installation (Centos 7.3)
We started out by installing a primary with a default install, and doing
ipa-replica-install with no parameters. That worked fine. We then install a commercial
certificate, because I wanted people to be able to use the web tool without having to
click through warnings.
That used
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP.
That worked fine. However it created a time bomb.
The first attempt at doing “yum update” failed to update the primary. There was a recent
email on this. It can be fixed by changing the nicknames for the certificate to
“Server-Cert,” using a process describe in email. That allows update and reboot to work.
However I just tried installing a third replica. I ran into two issues:
1) It blew up at varying points, but most consistently when trying to talk to the CA
system. I’m guessing that using the commercial cert confused it, though I didn’t actually
diagnose the problem.
To work around this, I did ldapmodify on
dn: cn=CA,cn=krb1.cs.rutgers.edu,cn=masters,cn=ipa,cn=etc,dc=cs,dc=rutgers,dc=edu
changetype:modify
delete:ipaConfigString
ipaConfigString: enabledService
ipaConfigString: caRenewalMaster
That makes the primary appear not to be a CA, after which ipa-replica-install works, when
specifying --dirsrv-cert-file --http-cert-file --no-pkinit.
2) The resulting system looked OK, but ipa-replica-manage -v list XXX showed that it
didn’t sync from one of the servers. It looks like a remnant of the failed installs. I had
done “ipa server-del” after the failure, but maybe no after all of them. Anyway, I ended
up with two entries for the ldap service. On one of the servers the current entry had the
wrong dn. I had to do modrdn to fix it.
But I still got permission failures. I had to add the dn manually to cn=replication
managers,cn=sysaccounts,cn=etc,dc=cs,dc=rutgers,dc=edu. At that point after doing a
reinitialize and restarting ipa, things look good.
The upshot is that doing this kind of thing requires pretty good skills at reverse
engineering and doing LDAP configuration. Perhaps it’s reasonable to assume such skills
are available anywhere that’s using this in production.