On 08/15/2014 06:02 PM, James wrote:
On Fri, Aug 15, 2014 at 5:25 AM, Michael Lasevich
<mlasev...@lasevich.net> wrote:
Sorry, I did not intend to belittle your efforts - just misread the code
Didn't take it that way, no worries :)

(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.
There is the python ipa API, not sure how stable or official it is,
but if you look in my code I use it occasionally.

The RPC API is not official (i.e. documented), but since IPA needs to keep backwards compatibility with its own client, it's very stable.

Just be sure to send the API version with each call. (The server will send a warning if you don't.)


Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to