freeipa

#9212 Nightly test failure in test_user.py::test_user::test_password_expiration_notification
Closed: fixed by frenaud. Opened by frenaud.

Closed: fixed
Reopen Issue

The nightly test test_user.py::test_user::test_password_expiration_notification is failing, see PR #1917 with the following logs and report.

Test scenario (all the steps are done using the Gui):

  • Modify ipa config through the Gui (IPA Server > Configuration) with Password Expiration Notification = 15 days
  • Create a user
  • Create a group
  • Add the user to the group
  • Create a password policy for the group
  • Set Password Max life = 7 days, Password Min Life = 0
  • As admin, reset the user password. Logout.
  • Login to the Gui as the new user. As the password was administratively reset, the user is prompted to reset his password

reset_pwd.png

  • Enter a new password

The user should be able to login but the reset pwd operation fails:

invalid_pwd.png

The expected result would be a successful reset + successful login + a notification of close password expiration in the top right corner of the browser:

notification.png

The defaults are tricky

For grace -1 means disabled and this is the default in the global policy.
0 means no grace logins are allowed.

A group policy defaults to being empty. Empty values are treated as 0.

So a new group policy will not allow grace logins.

group policies have never inherited values from the global policy.

Maybe in this case it should. I could argue both ways though.

Metadata Update from @rcritten:
- Issue assigned to rcritten

Using Carla's PR https://github.com/freeipa/freeipa/pull/6388 which adds gracelimit to the UI I updated the group policy to set grace to -1 and now the test user login succeeds.

Metadata Update from @frenaud:
- Issue tagged with: webui

The decision is to set all group policies to match the global policy on creation.

Any existing group policy with no grace policy set will get the global policy during upgrades.

PR https://github.com/freeipa/freeipa/pull/6397

Metadata Update from @rcritten:
- Issue untagged with: webui

Metadata Update from @rcritten:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=2115475 https://bugzilla.redhat.com/show_bug.cgi?id=2115495

Reproducible in testing_master_latest PR 1927 Report

Reproducible in testing_master_latest PR 1937Report

We identified 4 possible solutions:

Option A: When creating new pwpolicy use the global pwpolicy value. Also on upgrades if no gracelimit is set, use global policy value.

Option B: -1 for new policies, ignoring “global_policy”. If grace is not already set, set existing group policies to -1 on upgrade

Option C: switch meaning of “-1” and “0” (?) to “-1 (no bind allowed)”
“0 (unlimited)”

Option D: Different default? 5? ….

The team has chosen option B.

master:

  • b6587d3361391b15b0a3ef9b08a2f21bedcdeff7 doc: Update LDAP grace period design with default values
  • c8955a4d0a10aa8b86e1af4361245d7f71da68c8 Set default gracelimit on group password policies to -1
  • 0468cc6085b92d91bebc0fa8ff0a5b1384759af5 Set default on group pwpolicy with no grace limit in upgrade

ipa-4-9:

  • 434620ee342ac4767beccec647a318bfa7743dfa doc: Update LDAP grace period design with default values
  • 497a57e7a6872fa30d1855a1d91a455bfdbf9300 Set default gracelimit on group password policies to -1
  • a4ddaaf3048c4e8d78a1807af7266ee40ab3a30b Set default on group pwpolicy with no grace limit in upgrade

ipa-4-10:

  • 1aa39529cda4ab9620539dbad705cedd23c21b42 doc: Update LDAP grace period design with default values
  • 45e6d49b94da78cd82eb016b3266a17a1359a087 Set default gracelimit on group password policies to -1
  • de6f074538f6641fd9d84bed204a3d4d50eccbe5 Set default on group pwpolicy with no grace limit in upgrade

Metadata Update from @frenaud:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)
Metadata

test-failure

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.