<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 06/06/2014 03:57 PM, James wrote:<br>
</div>
<blockquote cite="mid:1402091847.10825.40.camel@freed" type="cite">
<pre wrap="">On Fri, 2014-06-06 at 14:43 -0400, Simo Sorce wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Fri, 2014-06-06 at 14:06 -0400, James wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Fri, 2014-06-06 at 08:51 -0400, Simo Sorce wrote:
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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 ?
</pre>
</blockquote>
<pre wrap="">Yes. That is one approach.
</pre>
</blockquote>
<pre wrap="">
What did you have in mind ?
</pre>
</blockquote>
<pre wrap="">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...
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">This is what I was thinking... I'll need to know how to extract this,
send it (encrypted), and use it instead of --password
</pre>
</blockquote>
<pre wrap="">
It might be greppable out of the dse.ldif file I think.
</pre>
</blockquote>
<pre wrap="">Can you help me with the specific commands for a Proof Of Concept?
I have found /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif
(attached)</pre>
</blockquote>
<br>
grep nsslapd-rootpw /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif<br>
<br>
The pwdhash command can be used to create a hashed password.<br>
<br>
<blockquote cite="mid:1402091847.10825.40.camel@freed" type="cite">
<pre wrap="">
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?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I don't think there is any other need for the dm_password in
ipa-replica-install. Did I miss something?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">Which I understand we could get around by passing around the (salted?)
hashed password, correct?
</pre>
</blockquote>
<pre wrap="">
Not for the CA, unfortunately the CA requires the DM password in the
clear.
</pre>
</blockquote>
<pre wrap="">I'll skip over doing the CA part for now... Sounds like I need to break
this into smaller challenges ;)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Use the DM password to do everything as usual AND create the asymmetric
keys in the replicas and *securely* transmit them to the master.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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!
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">*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.
</pre>
</blockquote>
<pre wrap="">
This is intrinsically not possible.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
It is not about being inelegant, it is about being useless to me.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Yeah, chicken-egg issues of bootstrapping infrastructures. I currently
do not see any way around this.
</pre>
</blockquote>
<pre wrap="">
See my above idea for a dirty hack. (--uninstall)
</pre>
</blockquote>
<pre wrap="">
install; uninstall; replica-install ... the first 2 steps are a no-op.
</pre>
</blockquote>
<pre wrap="">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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Freeipa-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Freeipa-devel@redhat.com">Freeipa-devel@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-devel">https://www.redhat.com/mailman/listinfo/freeipa-devel</a></pre>
</blockquote>
<br>
</body>
</html>