[Freeipa-users] replica creation problems

Fri Apr 14 07:04:43 UTC 2017

On 04/13/2017 07:50 PM, Josh wrote:
> Scenario:
>
> RHEL7 IPA with DNS and without CA. Initial installation was done using
> --http-cert-file, --dirsrv-cert-file with certificates from an issuer A.
>
> For a number of reasons replica must be created with certificates from
> an issuer B.
>
> A bundle consisting of key, server certificate and a full certificate
> chain provided by the issuer B is prepared as replica.crt
>
> IPA Replica file created as
>
> ipa-replica-prepare --dirsrv-cert-file=replica.crt
> --http-cert-file=replica.crt --dirsrv-pin=key_pass --http-pin=key_pass
> --ip-address=n.n.n.n --password=manager_pass replica_host_name
>
> no errors/warnings during above process.
>
> Resulting file transferred to a new clean system and launched as
>
> # ipa-replica-install --setup-dns --auto-forwarders --mkhomedir
> /var/lib/ipa/replica-replica_host_name.gpg
> Directory Manager (existing master) password:
>
> Checking DNS forwarders, please wait ...
> Run connection check to master
> admin at REALM password:
> Connection check OK
> Adding [n.n.n.n replica_host_name] to your /etc/hosts file
> Configuring NTP daemon (ntpd)
>   [1/4]: stopping ntpd
>   [2/4]: writing configuration
>   [3/4]: configuring ntpd to start on boot
>   [4/4]: starting ntpd
> Done configuring NTP daemon (ntpd).
> Configuring directory server (dirsrv). Estimated time: 1 minute
>   [1/42]: creating directory server user
>   [2/42]: creating directory server instance
>   [3/42]: updating configuration in dse.ldif
>   [4/42]: restarting directory server
>   [5/42]: adding default schema
>   [6/42]: enabling memberof plugin
>   [7/42]: enabling winsync plugin
>   [8/42]: configuring replication version plugin
>   [9/42]: enabling IPA enrollment plugin
>   [10/42]: enabling ldapi
>   [11/42]: configuring uniqueness plugin
>   [12/42]: configuring uuid plugin
>   [13/42]: configuring modrdn plugin
>   [14/42]: configuring DNS plugin
>   [15/42]: enabling entryUSN plugin
>   [16/42]: configuring lockout plugin
>   [17/42]: configuring topology plugin
>   [18/42]: creating indices
>   [19/42]: enabling referential integrity plugin
>   [20/42]: configuring ssl for ds instance
>   [21/42]: configuring certmap.conf
>   [22/42]: configure autobind for root
>   [23/42]: configure new location for managed entries
>   [24/42]: configure dirsrv ccache
>   [25/42]: enabling SASL mapping fallback
>   [26/42]: restarting directory server
>   [27/42]: setting up initial replication
> Starting replication, please wait until this has completed.
> Update in progress, 15 seconds elapsed
> [master_host_name] reports: Update failed! Status: [-11  - LDAP error:
> Connect error]
>
>   [error] RuntimeError: Failed to start replication
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> ipa.ipapython.install.cli.install_tool(Replica): ERROR    Failed to
> start replication
> ipa.ipapython.install.cli.install_tool(Replica): ERROR    The
> ipa-replica-install command failed. See /var/log/ipareplica-install.log
> for more information
>
> Log file does not list any obvious errors other then full call stack
> which tell  me nothing, I can post it here if helps.
> Both machines run no firewall and are on the same subnet.
>
> Additional problems noticed during cleanup attempt:
>
> # /usr/sbin/ipa-server-install --uninstall
>
> This is a NON REVERSIBLE operation and will delete all data and
> configuration!
>
> Are you sure you want to continue with the uninstall procedure? [no]: yes
>
> Replication agreements with the following IPA masters found:
> master_host_name. Removing any replication agreements before
> uninstalling the server is strongly recommended. You can remove replication
> agreements by running the following command on any other IPA master:
> $ ipa-replica-manage del replica_host_name
>
> Are you sure you want to continue with the uninstall procedure? [no]:
>
> Aborting uninstall operation.
>
>
>
> Going to master and running
>
> $ ipa-replica-manage del replica_host_name
>
> fails with
>
> Connection to 'replica_host_name' failed: cannot connect to
> 'ldaps://replica_host_name:636': TLS error -8172:Peer's certificate
> issuer has been marked as not trusted by the user.
> Unable to delete replica 'replica_host_name'
>
> I attempted to provide --cacert=full_path_to_issuer_B_bundle option but
> nothing changed. As a matter of fact providing invalid file name to
> --cacert does not raise any error. Strace output confirm that file
> listed in --cacert is not Only appending the bundle to /etc/ipa/ca.crt
> resolved TLS errors.
>
>
> Please advise how I can find root cause of LDAP error: Connect error.
> I have a suspicion that master LDAP can't connect to replica LDAP for
> above mentioned TLS reason.
>
> Josh.
>
Hi Josh,

I did not try this type of setup myself, but I think the issue comes 
from missing root certificates. I would try to run
$ ipa-cacert-manage --install <issuer B certfile>
$ ipa-certupdate
on the master. This command will install issuer B certificate as a 
trusted CA on the master, thus allowing communications with services (eg 
LDAP on replica) using certificates delivered by issuer B.

You may find more information in /var/log/dirsrv/slapd-DOMAINNAME/access 
and errors files. You can also check if the root certificates are 
installed in each LDAP server's NSS DB:
$ certutil -L -d /etc/dirsrv/slapd-DOMAINNAME
You should find issuer A and issuer B certs with CT,C,C trust flags on 
each machine.

HTH,
Flo.