Re: [Freeipa-devel] Keytab for talking to PKI CA from IPA
Adam Young wrote: 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. Not really. I created two instances to provide logical separation and prevent us from having to deal with multiple naming contexts. There was some serious investigation over the summer to see if we could consolidate into a single instance. It was determined to be too much too late in the cycle. 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. Right, this has never been in question AFAIK. 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 disabled. I think you mean the first step is to create a 389-ds instance for the CA, right? Why not simply pre-create the keytab and ship it in the prepared file? There is no need to disable the random DM password. Once the installation is complete it will be unknown so effectively disabled. 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? Because of permission issues writing the relevant entries to cn=config. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Keytab for talking to PKI CA from IPA
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 disabled. 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 Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Keytab for talking to PKI CA from IPA
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 disabled. 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 Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
