HTTP Bad Request on login with ipa modules #43091
Comments
|
Files identified in the description:
If these files are inaccurate, please update the |
ansibot
added
affects_2.6
Akasurde
removed
the
needs_triage
|
@Guampa Thanks for reporting this issue. Could you please check if |
|
Hello @Akasurde , thank you for your prompt response. Yes, I did check and it is reachable. I've also verified with a small shell snippet that the server is authenticating correctly: testipaauth.sh |
|
resolved_by_pr #43133 |
* Only assume GET if no data, otherwise POST. Fixes ansible#42876 ansible#43091 ansible#42750
|
Thanks a lot guys, waiting for the backport and in the meantime I'll resort to a custom module to talk to FreeIPA. |
|
@Akasurde the patch won't apply at the same line in 2.6 but it's a single line so I added it manually. The error still persists, both with and without the patch. |
|
bot_skip |
|
@Guampa I see you are using short name as hostname in your invocation - I can reproduce this using 2.6 with playbook - ---
- name: Error 43091
hosts: localhost
tasks:
- name: Add user
ipa_user:
ipa_pass: Secret1234
ipa_host: master
ipa_user: admin
validate_certs: false
name: pinky5
state: present
givenname: Pinky5
sn: pinky5but if I provide FQDN of IPA Master server then I can proceed - with playbook ---
- name: Error 43091
hosts: localhost
tasks:
- name: Add user
ipa_user:
ipa_pass: Secret1234
ipa_host: master.ipa.test
ipa_user: admin
validate_certs: false
name: pinky5
state: present
givenname: Pinky5
sn: pinky5This brings me to conclusion that this is related to FQDN and nothing to do with #43133 patch. Could you please provide full FQDN for IPA server and retry ? |
|
@Akasurde, you hit the nail. I was indeed using a FQDN, but the name was only resolvable at the host where the task was to be run (set in /etc/hosts). When I changed ipa_host to the "real" FQDN of the ipa server (resolvable recursively over public DNS), it did work. What prevented me from finding this was the fact the "testipaauth" shell script was succeeding with the "fake" FQDN. Maybe it's some sort of constraint? However the detail above it does look like it has nothing to do with the HTTP method, and that the correct POST is being used, so #43133 probably isn't needed here. |
|
@Guampa Cool. I am glad this worked for you. I will mark this issue as resolved as this is more related to environment rather than Ansible module issue. Thanks for debugging and providing feedback. |
SUMMARY
I'm getting the following error when using ipa_*:
fatal: [vm1.ipatest001.net]: FAILED! => {"changed": false, "msg": "login: HTTP Error 400: Bad Request"}
Verified with curl that the FreeIPA password endpoint authenticates correctly and returns the session data.
ISSUE TYPE
COMPONENT NAME
ipa_group
ipa_user
module_utils/ipa
(probably the other ipa user modules are affected, but haven't tested)
ANSIBLE VERSION
CONFIGURATION
DEFAULT_ACTION_PLUGIN_PATH(/home/testcase/ansible.cfg) = [u'/home/testcase/external/ansible-freeipa/action_plugins']
DEFAULT_HOST_LIST(/home/testcase/ansible.cfg) = [u'/home/testcase/hosts.yml']
DEFAULT_ROLES_PATH(/home/testcase/ansible.cfg) = [u'/home/testcase/roles', u'/hometestcase/external/ansible-freeipa/roles']
DEFAULT_VAULT_PASSWORD_FILE(/home/testcase/ansible.cfg) = /home/testcase/.vaultpass
HOST_KEY_CHECKING(/home/testcase/ansible.cfg) = True
OS / ENVIRONMENT
Ansible host: Debian Stretch
Managed host: Centos 7.6
STEPS TO REPRODUCE
ansible-playbook playbooks/testgroup.yml
EXPECTED RESULTS
The group would be created
ACTUAL RESULTS
The login fails with the following error:
fatal: [vm1.ipasrvtest001.net]: FAILED! => {"changed": false, "msg": "login: HTTP Error 400: Bad Request"}
to retry, use: --limit @/home/testcase/playbooks/fixture.retry
The text was updated successfully, but these errors were encountered: