Hi, I searched the interwebs but didn't find definite answer.
We are enrolling clients with ansible like this: shell: ipa-client-install -U {{ ipa_extra_params }} --domain={{ ipa_domain }} --principal={{ ipa_admin_user }} --password={{ ipa_admin_password }} --mkhomedir --force-join --hostname={{ instance_hostname.stdout }}.{{ ipa_domain }} This works fine.
After enrolling we want to edit the attributes of the newly enrolled host. We do that like this: shell: echo {{ ipa_admin_password }} | kinit enroller@{{ ipa_domain|upper }} && ipa host-mod --setattr=userclass="{{ host_user_class }}" {{ instance_hostname.stdout }}.{{ ipa_domain }} This also works fine but we don't love the fact that we echo the password to kinit. I know that there is the keytab route but that would require moving the keytab file to the host first. While this is not in any way impossible, we would like to "see all the cards".
What would be the best practice(tm) for this?
I don't know whether this is good practice, but:
* You can run the action locally instead of in the target host; if the user running Ansible has a ticket, it should work * If you use ssh to connect to the IPA client host using an IPA user, you should get a ticket and it should work * Another option would be to use an Ansible module to do the operation, but I don't see the existing ipa_* modules doing what you need.
Cheers,
Álex
On Wed, Mar 18, 2020 at 8:44 AM Kimmo Rantala via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hi, I searched the interwebs but didn't find definite answer.
We are enrolling clients with ansible like this: shell: ipa-client-install -U {{ ipa_extra_params }} --domain={{ ipa_domain }} --principal={{ ipa_admin_user }} --password={{ ipa_admin_password }} --mkhomedir --force-join --hostname={{ instance_hostname.stdout }}.{{ ipa_domain }} This works fine.
After enrolling we want to edit the attributes of the newly enrolled host. We do that like this: shell: echo {{ ipa_admin_password }} | kinit enroller@{{ ipa_domain|upper }} && ipa host-mod --setattr=userclass="{{ host_user_class }}" {{ instance_hostname.stdout }}.{{ ipa_domain }} This also works fine but we don't love the fact that we echo the password to kinit. I know that there is the keytab route but that would require moving the keytab file to the host first. While this is not in any way impossible, we would like to "see all the cards".
What would be the best practice(tm) for this? _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Yeah. Ansible Tower would solve this neatly but alas, we don't run one (although I wish we were). We will go with the currect set up for the time being. After all, it is not that huge of a deal.
If anyone has a suggestion how to do this better, please feel free to share it.
On ke, 18 maalis 2020, Kimmo Rantala via FreeIPA-users wrote:
Yeah. Ansible Tower would solve this neatly but alas, we don't run one (although I wish we were). We will go with the currect set up for the time being. After all, it is not that huge of a deal.
If anyone has a suggestion how to do this better, please feel free to share it.
Please look into using ansible-freeipa. It natively supports python3-gssapi-based Kerberos authentication for tasks performed from the controller against IPA API, so it can do keytab-based auth and is able to use in-memory ccaches.
There was a question from Angus that he did not CC here but I think he kind of asked what I/we are trying to do and told that Foreman is a bit like ansible.
I thought it would be fair to tell what is the goal here.
We are enrolling clients and we set the userclass attribute to a certain value to then assign the host to host groups with automember rules. This host group is for the environment, customer etc. so the correct users get the correct privileges to the hosts.
We have the ansible playbooks in bitbucket but currently the playbooks are ran on peoples' workstations that may or may not be enrolled to the same IPA domain. Yes, I know this is sub-optimal but this is the current situation. I, myself, want some kind of centralized solution to this in the (preferably near) future.
I know that people could use kinit on their workstations to obtain a ticket. That would require that me and my team would need to teach the various actors (who sometimes have surprising lack of knowledge in basic IT stuff) the basic operations of Kerberos.
The current style works and we are refining it. Gonna take a look at ansible-freeipa again. Looked at it ages ago.
for what it’s worth, you can use ansible’s ldap module with GSSAPI if you make a one-line patch. In this case we’re only concerned with issuing the ldap command locally. Ansible defaults SASL to using external rather than GSSAPI. You’d think they’d make it an option, but it’s hardcoded. I was unable to find a way to override it.
It’s more complex than you’re expect because I’m worried that ansible might choose a different version of python than the default, so I’m trying to figure out the location of the file that it’s actually using.
- name: Find correct ldap module to patch local_action: command "{{ ansible_playbook_python }}" -c "import ansible.module_utils.ldap; print(ansible.module_utils.ldap.__file__)" register: ldapfile
- debug: var: ldapfile
- name: patch ldap.py become: true local_action: replace path="{{ ldapfile.stdout }}" regexp="ldap.sasl.external" replace="ldap.sasl.gssapi"
On Mar 18, 2020, at 11:05:15 AM, Kimmo Rantala via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
There was a question from Angus that he did not CC here but I think he kind of asked what I/we are trying to do and told that Foreman is a bit like ansible.
I thought it would be fair to tell what is the goal here.
We are enrolling clients and we set the userclass attribute to a certain value to then assign the host to host groups with automember rules. This host group is for the environment, customer etc. so the correct users get the correct privileges to the hosts.
We have the ansible playbooks in bitbucket but currently the playbooks are ran on peoples' workstations that may or may not be enrolled to the same IPA domain. Yes, I know this is sub-optimal but this is the current situation. I, myself, want some kind of centralized solution to this in the (preferably near) future.
I know that people could use kinit on their workstations to obtain a ticket. That would require that me and my team would need to teach the various actors (who sometimes have surprising lack of knowledge in basic IT stuff) the basic operations of Kerberos.
The current style works and we are refining it. Gonna take a look at ansible-freeipa again. Looked at it ages ago. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
freeipa-users@lists.fedorahosted.org
-
Alex Corcoles -
Alexander Bokovoy -
Charles Hedrick -
Kimmo Rantala