When setting up replication, it should not be necessary to cache any
passwords, anywhere, until the replication agreemsnts are set up, and
then, all caching should be using known secure mechanisms.
The two main repositories we care about are the Directory Server
instances managed by IPA and the Certificate Authority. Currently,
these are not in the same Dir Srv isntance (although they could be) due
to the fact that we expect to replicate them seperately. Specifically,
we expect to have more IPA instances than CA instances, and we will not
have a CA instance without a co-located IPA instance.
During normal operations, the IPA instance should not need to talk to
the directory server instance of the CA. All communication between IPA
and the CA should happen via the HTTPS secured via Certificates issued
by the CA.
Once the replication process starts, the file generated by ipa-prepare
replicate should not need an passwords. Instead, when the replicated
server is installed, the user performing the install should get a ticket
as an administrative user. All authentication for the replication
should be based on that ticket.
The very first step is to install an new Directory server for IPA. For
this, the replication process can generate a single use password and use
it as the Directory server password for the local instance. Next, the
ticket for the adminiustrative user should be used to download a keytab
for the Directory Server to use when communicating back to the original
IPA directory server.With these keytab in place, the replicated IPA DS
should be able to talk to the original IPA DS and establish the
replication agreement. At this point, the single use password should be
Once the IPA Directory server has been replicated, we can either use the
original keytab or download a second keytab to establish a replication
agreement between the replicated CA directory server and the original CA
directory server. The process would look the same as setting up the
keytab for the IPA directory server.
Why don't we do this now?
Freeipa-devel mailing list