On Fri, 2014-06-06 at 14:43 -0400, Simo Sorce wrote: > On Fri, 2014-06-06 at 14:06 -0400, James wrote: > > On Fri, 2014-06-06 at 08:51 -0400, Simo Sorce wrote: > > > But let me ask a more important question, how do you distribute the > > > public keys securely ? Is it puppet fetching them from each > > > replica-to-be server and sending them to the first master server ? > > Yes. That is one approach. > > What did you have in mind ? Actually, I'm good with this. If someone is unnecessarily paranoid I could probably mangle this over SSH, but I'd like to avoid it. It still requires distributing the SSH fingerprints over puppet...
> > > > It is also needed to actually store the DM password on the replica > > > server itself in it's own cn=Directory Manager super user entry. > > > Although I think we could send the hash for that. > > This is what I was thinking... I'll need to know how to extract this, > > send it (encrypted), and use it instead of --password > > It might be greppable out of the dse.ldif file I think. Can you help me with the specific commands for a Proof Of Concept? I have found /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif (attached) How do I find a password in there? ( I couldn't see any ) How do I get that back in on the destination replica side once I find it? > > > > > > The simplest way to handle this (which I wanted to do for a while) is to > > > pre-create the replica's LDAP principal and keys at replica-prepare time > > > so we can start right away with GSSAPI authentication for the first > > > replication and create agreements directly using GSSAPI auth. This would > > > in turn simplify replication agreements creation as we won't need > > > anymore to do the dance where we create the agreement with a plain text > > > bind and then we need to convert the agreement to use GSSAPI. > > > > This of course sounds fine to me. As long as it meets my criteria of not > > needing the password, it should work. Is this an easy patch? IOW > > something that I could test a build of within the next month at the > > latest? > > Well, you may not need a password (you do because you need to be DM on > the replica to create replication agreements, but we can do some magic > there and use ldapi as root I guess) but you'll need a keytab, which is > a secret, just like a password and must not be exposed to anyone and > anything just like the DM password. But that wouldn't be a problem, the > keytab would be in the encrypted prepared file. Great! Can you show to me how to do this part please? * Generate this specific keytab * Use it to complete the ipa-replica-install process > > > > > I don't think there is any other need for the dm_password in > > > > ipa-replica-install. Did I miss something? > > > > > > See above, it needs the password to actually create the DM account at DS > > > setup time. *also* the DM password is used to setup some parts of the > > > dogtag CA so if any of your replica is also a CA clone you go straight > > > back to needing the DM password. > > Which I understand we could get around by passing around the (salted?) > > hashed password, correct? > > Not for the CA, unfortunately the CA requires the DM password in the > clear. I'll skip over doing the CA part for now... Sounds like I need to break this into smaller challenges ;) > > > Use the DM password to do everything as usual AND create the asymmetric > > > keys in the replicas and *securely* transmit them to the master. > > Keep in mind I'm only transmitting public keys, so it doesn't have to be > > secure as long as I know verify the identity. > > Bzzzzzzzzt. How do I know that "these are the public key I am looking > for" if they are not transmitted securely ? > If someone can sneak in an additional key or replace a public key in > transit now it gets access to everything as soon you transmit the > encrypted package! Agreed. As discussed, I'm assuming that Puppet master has securely authenticated it's individual puppet clients, and I am relying on that trust to pass the public keys around. > > > > Now wrap the current replica file (yes it is already encrypted, who > > > cares), AND the DM password into a new envelope encrypted with your > > > public keys. > > > > > > Presto! Now you transfer the blob back to the replicas, and each replica > > > can be scripted, and puppet has no passwords in its manifest. > > > > This approach won't work because the first axiom is incorrect. To do > > this, I would have to keep the dm_password around on each host with a > > key that could be read and used by anyone with root. So effectively I > > might as well store the password in puppet. > > Look, at the moment there is no way around that, you have to have the DM > password *or* an equivalent secret to install replicas, there is simply > no way around that. You need to transport some form of credentials from > the master ipa server to the replicas because the replicas need to > authenticate to the master in order to be allowed to become replicas. > It is as simple as that, whether it is the DM password, or a keytab, or > something else. I'd like to learn how to do this keytab solution for this scenario, or perhaps use an OTP to authenticate... The OTP would be carried in the pseudo-secure puppet channel. > > > > > *symmetry* > > > > > > > > It would be especially elegant and beneficial to FreeIPA and the > > > > puppet module if the process of "peering" was symmetrical, that is to > > > > say, similar for any host. If I could use ipa-server-install to setup > > > > N hosts, and then run a secondary command to cause certain ones to > > > > "join" this would make the process much more natural for puppet. > > > > > > This is intrinsically not possible. > > That is unfortunate. I could hack a version of this where by each host > > runs the installer, but the ones that need to peer start by running: > > > > ipa-server-install --uninstall && ipa-replica-install > > > > but that is less elegant that the solution existing natively. > > It is not about being inelegant, it is about being useless to me. hehe, fair enough. I'll try and think if I can come up with a POC of why it's needed. If it turns out to be a requirement, we can revisit it. > > > > > In addition, this would ensure that the configuration management itself > > > > is HA. Without this type of functionality, then if the first ipa > > > > server isn't available, then config management will be blocked. > > > > > > Yeah, chicken-egg issues of bootstrapping infrastructures. I currently > > > do not see any way around this. > > > > See my above idea for a dirty hack. (--uninstall) > > install; uninstall; replica-install ... the first 2 steps are a no-op. Agreed. It wasn't about trying to simplify down to a no-op, it was about having a path in the state graph of going from installed => replica. Currently you can do: uninstalled => installed. installed => uninstalled. uninstalled => replica-ed. But no: installed => replica-ed. So until that pathway is is possible, I will have to "fake it" by doing an installed => uninstalled, so that I can turn an installed machine into a replica. Cheers, James
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
