[Freeipa-users] Minimal permissions for "joiner" account?

[Michael Lasevich]

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.

-M


On Thu, Aug 14, 2014 at 6:50 PM, James <purpleidea at gmail.com> wrote:

> On Thu, Aug 14, 2014 at 8:29 PM, Michael Lasevich
> <mlasevich at lasevich.net> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140815/f407b081/attachment.htm>