On 08/15/2014 11:25 AM, Michael Lasevich wrote:
Sorry, I did not intend to belittle your efforts - just misread the
code (saw you pass in $admin and $password and made wrong assumption
that $admin was admin username) as well as trying to avoid puppet as I
find Salt much quicker and much simpler (and already established in my
setup)
I sat down tonight and threw together a quick salt reactor that does
same thing as your module - creates the host account in IPA with a
generated OTP password and joins the host to the domain using that
generated OTP (and while at it, validates the host against AWS and
populates the metadata into IPA) Ended up having to join the salt
master to the domain, which I was avoiding doing for security reasons,
but I can just disable IPA logins in PAM and call it a day. The nice
bit is that it is using the host's keytab for authentication, so I do
not need any extra credentials sitting around. Seems to be working
just fine. :-). I ended up granting the salt-master host the "Host
Administrators" privilege. It seems that "Host Enrollment" privilege
is not sufficient to enroll hosts - go figure.
The only thing that bugs me is that I am calling IPA python code from
my salt reactor python code via subprocess - there has got to be a
better, more direct way - but I found documentation too confusing to
follow at 1 am - will be a project for another day.
Thanks for your help.
Great that it is working for you! Would you mind may be putting together
a howto page based on your setup for others to benefit from your
sleepless night?
http://www.freeipa.org/page/HowTos
Thanks
Dmitri
-M
On Thu, Aug 14, 2014 at 6:50 PM, James <[email protected]
<mailto:[email protected]>> wrote:
On Thu, Aug 14, 2014 at 8:29 PM, Michael Lasevich
<[email protected] <mailto:[email protected]>> wrote:
> I appreciate it. Maybe I did not read it close enough, but it
seemed to send
> the admin password to every client, which is what I am trying to
avoid.
Oh no!! Definitely not :) I went to great pains to specifically avoid
this actually. If you're interested in how the DM and admin passwords
are managed, read:
https://ttboj.wordpress.com/2014/06/06/securely-managing-secrets-for-freeipa-with-puppet/
If you're interested in how the clients auth, they do so via
getkeytab, and in order for that to work, puppet passes a temporary
one-time password to the client, uses it, and verifies that _that_
client auth-ed. If the password isn't used by that client, then a new
OTP is generated, and the original is discarded (as it was probably
used by the wrong client, or maliciously in that rare scenario).
All of this to say, that this was quite complex to write, so I would
consider using the module as is (and even extending it as needed!).
Secondly, I'd like to point out that I'm not doing any orchestration,
only config management. Which means this can actually scale!
>
> I will take a closer look, maybe I can bite the bullet and
implement the few
> lines of code that are required to make this work in Salt (it
would take way
> too much work and be generally counterproductive to switch to
Puppet).
Of course I can only help with the puppet case, but if you don't
switch (this module is a winning module, in the same way that rails
saved ruby, so I would take a closer look) you can at least use it as
a reference architecture when writing a salt module. That;s the beauty
of Free Software!
Good luck! HTH,
James
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
