Bug 2231995

Summary:	IdM password policy Min lifetime is not enforced when high minlife is set
Product:	Red Hat Enterprise Linux 8	Reporter:	Sunny Wu <suwu>
Component:	ipa	Assignee:	Florence Blanc-Renaud <frenaud>
Status:	NEW ---	QA Contact:	ipa-qe
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	8.8	CC:	rcritten, tscherf
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Sunny Wu 2023-08-15 00:03:52 UTC

Description of problem:
IdM does not check Minimum life of password when performing password changing, if a very high minlife value is set.

==========

$ ipa pwpolicy-show --user=bob
  Group: non_expired_passwd_group
  Min lifetime (hours): 99999
  Grace login limit: -1

[bob@node-0 ~]$ passwd
Changing password for user bob.
Current Password: 
New password: 
Retype new password: 
Password change failed. Server message: Current password's minimum life has not expired

Password not changed.
passwd: Authentication token manipulation error

==========
Change lifetime to 10x larger to previous run:
==========

[bob@node-0 ~]$ ipa pwpolicy-show --user=bob
  Group: non_expired_passwd_group
  Min lifetime (hours): 999999
  Grace login limit: -1

[bob@node-0 ~]$ passwd
Changing password for user bob.
Current Password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.

Version-Release number of selected component (if applicable):


How reproducible:
100%

Actual results:
Password changing is allowed even if age of password is within minlife.

Expected results:
1. IdM checks acceptable range of integer when adding/modifying a password policy, and  rejects ridiculously high values, or
2. IdM enforces password policy for whatever minlife value saved in policy.

Additional info:

Comment 1 Rob Crittenden 2023-08-15 01:35:43 UTC

Sounds like an integer overflow. What is the use-case for using a huge case for minimum lifetime? Is it to disallow users from changing their own passwords?

Comment 2 Sunny Wu 2023-08-15 01:41:42 UTC

> What is the use-case for using a huge case for minimum lifetime? Is it to disallow users from changing their own passwords?

Yes, initially I was testing if it would be a possible option.

Regardless what the use-case is, validation should be performed when either: (1) value is set in pwpolicy, or (2) user is changing password.