freeipa

#9452 newly created users via ansible module cannot login to freshly installed freeipa 4.10 containers
Opened by ykuksenko. Modified

Open
Close Issue

Issue

newly created users via ansible module cannot login to freeipa web ui on a freshly installed freeipa 4.10 container. This works as expected in freeipa 4.9 and lower containers.

I reset the password as the admin user via the UI and the problem remains.

I copy/pasted the password as well as tried enter it by hand many times to make sure I did not make a mistake - I also tried redeploying a fresh freeipa container with a new /data mount between attempts.

If I create a new user via the freeipa UI the user works correctly. I am not sure why this would be the case. Both users show up as active users as expected.

Please let me know if you need more information. I am not sure what else would be helpful.

Steps to Reproduce

  1. Deploy a 4.10 freeipa container
  2. Create a user via ansible module (supply the password here)
  3. Try to login

Actual behavior

The web ui prints The password or username you entered is incorrect

Expected behavior

The login should work and allow the user to update their own credentials.

Version/Release/Distribution

$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server

freeipa-server-4.10.2-1.fc38.x86_64
freeipa-client-4.10.2-1.fc38.x86_64
package ipa-server is not installed
package ipa-client is not installed
389-ds-base-2.3.7-1.fc38.x86_64
package pki-ca is not installed
krb5-server-1.21-3.fc38.x86_64
  • The docker image that failed is freeipa/freeipa-server:fedora-38-4.10.2 from dockerhub.
  • I also tested freeipa/freeipa-server:fedora-rawhide-4.11.0 from dockerhub (it has the same issue as 4.10.2)
  • The 4.10.0 image failed to deploy for me so I am ignoring that one.
  • freeipa-server:fedora-36-4.9.11 is the latest docker image that worked as expected.

Additional info:

Any additional information, configuration, data or log snippets that is needed for reproduction or investigation of the issue.

The options provided to the ansible module are:

- community.general.ipa_user:
    uid: tratcoez
    uidnumber: 20003
    gidnumber: 20003
    update_password: on_create
    sn: tester
    mail: ["test@test.example.com"]
    givename: test
    password: testtest
    state: enabled
    ipa_host: "{{ host_url }}"
    ipa_user: "{{ ipa_admin_user }}"
    ipa_pass: "{{ ipa_admin_pass }}"

The broken user info shows up as:

#ipa user-show tratcoez --all
  dn: uid=tratcoez,cn=users,cn=accounts,dc=ipa,dc=test,dc=example,dc=com
  User login: tratcoez
  First name: test
  Last name: tester
  Full name: test tester
  Display name: test tester
  Initials: tt
  Home directory: /home/tratcoez
  GECOS: test tester
  Login shell: /bin/sh
  Principal name: tratcoez@IPA.TEST.example.com
  Principal alias: tratcoez@IPA.TEST.example.com
  User password expiration: 20230919235319Z
  Email address: test@test.example.com
  UID: 20003
  GID: 20003
  Account disabled: False
  Preserved user: False
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True
  ipauniqueid: b64ccf76-5747-11ee-bf4a-a6f7a00dcfe9
  krbextradata: AAJvNAplcm9vdC9hZG1pbkBJUEEuVEVTVC5ERUZSQVkuT1JHAA==
  krblastpwdchange: 20230919235319Z
  mepmanagedentry: cn=tratcoez,cn=groups,cn=accounts,dc=ipa,dc=test,dc=example,dc=com
  objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry

The only difference between this broken one and a working one created via the UI that I can see is that the UI variant has objectclass: ipantuserattrs and ipantsecurityidentifier in it's info.

I also compared this to freeipa 4.9. It is the same, ie in 4.9 the UI created user also has the ipantsecurityidentifier attribute, but not the ansible created one. So this attribute should not be the issue.

The absence of ipantsecurityidentifier shouldn't break logins to the freeipa UI in 4.10 should it? (This looks like a windows SID iirc. I do not have any windows machines in this system.)

I also see the following error in the /var/log/krb5kdc.log log for the broken user:

Sep 19 23:56:29 freeipa-01.ipa.test.example.com krb5kdc[215](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 10.10.12.66: CLIENT KEY EXPIRED: tratcoez@IPA.TEST.example.com for krbtgt/IPA.TEST.example.com@IPA.TEST.example.com, Password has expired
Sep 19 23:56:29 freeipa-01.ipa.test.example.com krb5kdc[215](info): closing down fd 11
Sep 19 23:56:29 freeipa-01.ipa.test.example.com krb5kdc[215](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 10.10.12.66: NEEDED_PREAUTH: tratcoez@IPA.TEST.example.com for kadmin/changepw@IPA.TEST.example.com, Additional pre-authentication required
Sep 19 23:56:29 freeipa-01.ipa.test.example.com krb5kdc[215](info): closing down fd 11
Sep 19 23:56:29 freeipa-01.ipa.test.example.com krb5kdc[215](info): AS_REQ : handle_authdata (2)
Sep 19 23:56:29 freeipa-01.ipa.test.example.com krb5kdc[215](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 10.10.12.66: HANDLE_AUTHDATA: tratcoez@IPA.TEST.example.com for kadmin/changepw@IPA.TEST.example.com, No such file or directory
Sep 19 23:56:29 freeipa-01.ipa.test.example.com krb5kdc[215](info): closing down fd 11

For a working user created via the freeipa UI the part at issue looks like (the rest is the same):

Sep 20 00:14:42 freeipa-01.ipa.test.example.com krb5kdc[215](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 10.10.12.66: ISSUE: authtime 1695168882, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2@IPA.TEST.example.com for kadmin/changepw@IPA.TEST.example.com

Log file locations: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-files-logs.html
Troubleshooting guide: https://www.freeipa.org/page/Troubleshooting

Thank you.

The Ansible community plugin is not maintained by the FreeIPA team. Can you test your playbook using ansible-freeipa plugin (upstream and Galaxy) to manage users?

I tested with the freeipa.ansible_freeipa.ipauser module and got the same results. I cannot login with an IPA server version 4.10.2. It worked with 4.9.x

- name: add idm users
  freeipa.ansible_freeipa.ipauser:
    ipaadmin_principal: admin
    ipaadmin_password: "{{ ipa_admin_pass }}"
    update_password: on_create
    state: present
    users:
    - name: tratcoez
      first: test
      last: tester
      uid: 20003
      gid: 20003
      email: ["test@test.example.com"]
      password: testtest

the collection version is:

$ ansible-galaxy collection list|grep ipa
freeipa.ansible_freeipa       1.11.1

edit: Clarifying an implied factor: Ansible is connecting to the host running the container. The host is freshly joined to the new IPA domain deployed inside the container. The command used to remove the host from the domain before redeploying the container is ipa-client-install --uninstall. I think this may be relevant to how the freeipa managed ansible modules work, as you do not get to specify the ipa host for them.
Edited by ykuksenko
Metadata
None
None
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.