Bug 1442413

Summary:	IPA password policy has no password difference checking
Product:	Red Hat Enterprise Linux 8	Reporter:	David Jones <david.jones74>
Component:	ipa	Assignee:	IPA Maintainers <ipa-maint>
Status:	CLOSED DUPLICATE	QA Contact:	ipa-qe <ipa-qe>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	8.0	CC:	frenaud, pasik, pvoborni, rcritten, ssorce, tscherf
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-10-27 12:59:17 UTC	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 David Jones 2017-04-14 16:02:37 UTC

Description of problem:

There's no way to configure IPA's password policy to required a new password to be sufficiently different from the old one. 

By next year, this will make IPA unusable on all Redhat systems that need to meet U.S. DoD hardening requirements. 

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


How reproducible:
always

Steps to Reproduce:
1. try to configure password policy to check for difference
2.
3.

Actual results:
Can't configure

Expected results:
Can configure IPA password policy to have at least identical functionality to the PAM difok option. 

Additional info:

A workaround is to somehow disable the web interface, and uninstall IPA CLI tools from all systems. Then users have to go through PAM to change their passwords. However, I'm not sure if this will apply to kinit. 

A complicated workaround is to launch a program when a user logs in that tries to match the hash of the previous password by generating permutations of the current one. This would either have to be run at every login, or every few logins, and would require the ability to retrieve the password history from the IPA server. Yes, this is a terrible workaround.

Comment 3 Simo Sorce 2017-04-21 13:44:52 UTC

A dif is possib le only if you have both the old and the new password.
We do not always have the old password available (for example we do not when usin kpasswd) so this functionality is not simple to implement.

We could have some strict mode that will require any password change to go thorugh the LDAP server and there have a falg to enforce the requirement that a client sends both old and new password.
this will require developing new code so needs to be scopped and prioritized if needed.

Is there a way to get exceptions from this policy ?

Comment 4 David Jones 2017-04-21 14:13:16 UTC

I doubt the requirement can simply be waived. The best workaround is to force everything to go through PAM, but I'm not sure how to disable all the other ways a password can be changed. 

I looked through the source code, but didn't manage to track down the point at which the password is actually changed, and the policies are applied. 

So, you're saying that there is no single convergence point for password changes? How are the existing policies applied?

I was thinking that there was a particular place in the code where password policy is applied to the new password, and LDAP could simply be queried there to determine if there's an existing password. If there's none, then, the diff policy would be skipped. But it sounds like it's a lot more complex than that. 

So then, is there a way to change passwords that bypasses the password policy?

Comment 5 Petr Vobornik 2017-05-19 16:13:47 UTC

Upstream ticket:
https://pagure.io/freeipa/issue/6964

Comment 8 Florence Blanc-Renaud 2018-06-27 18:44:24 UTC

*** Bug 1595069 has been marked as a duplicate of this bug. ***

Comment 12 Rob Crittenden 2020-10-23 13:50:45 UTC

Fixed upstream
master:
https://pagure.io/freeipa/c/41021c278ae572ff5b1b3dea828a7dd93fe1ffff
https://pagure.io/freeipa/c/6b452e54045bb957e6f787209b4498eefc5df779
https://pagure.io/freeipa/c/c03b4862b84d52ddc91c5a3fb885b0ebf753d8f2
https://pagure.io/freeipa/c/3fc2eda4e15e9592132062036d70acad3bab401c
https://pagure.io/freeipa/c/c4cca53e88e78bfe512ebe59898ede0f94ec24ff
https://pagure.io/freeipa/c/46d0096218488a961125b6d97a9210b68e5434e5
https://pagure.io/freeipa/c/6da070e655c5d084a825607ed3be604c809b12f0
https://pagure.io/freeipa/c/be2efc12d37018794200fee874f27d83e0442ea4
https://pagure.io/freeipa/c/fe44835970eca197543eb3c908c51a240204d846
https://pagure.io/freeipa/c/68aa7c05542422aca05bec4967133be09a32496e
https://pagure.io/freeipa/c/f602da4b28fcf8822225b80df241eed6b624bf8e
https://pagure.io/freeipa/c/5155280bb4a92eb3dfdee5ca3f3a332f0159d568

Comment 13 Rob Crittenden 2020-10-26 19:52:43 UTC

Fixed upstream
ipa-4-8:
https://pagure.io/freeipa/c/04c34dcb33fa2e1ed6103250257c00e03ad93a22
https://pagure.io/freeipa/c/e8232dd0846963b1af7dc96ddbc99c75ef8333d5
https://pagure.io/freeipa/c/4dcb8d98e100d1fad89600b312b301e87d79f704
https://pagure.io/freeipa/c/734afe3896896a5633a926a4af08a58bceb966fd
https://pagure.io/freeipa/c/43cdcad24082bdb8356c44de78bfa69162e0ca6a
https://pagure.io/freeipa/c/cba86e814d44169b0275f908a389b67ddc462ce7
https://pagure.io/freeipa/c/d6a8fc290aa93fc5d53025f4400a9736366175eb
https://pagure.io/freeipa/c/676979eb510f71639ae0ccb16a44b75e3c084245
https://pagure.io/freeipa/c/9627ac4496cd3631250ed21e20157d41d27d6052
https://pagure.io/freeipa/c/60768b7344fcd0ad991ed1dc78c7a8f9784dc031
https://pagure.io/freeipa/c/48801cba3ffb76ba01fa908b13a8ff400423793f

Comment 14 Rob Crittenden 2020-10-27 12:59:17 UTC

I'm marking this as a duplicate of BZ 1340463 because the RFE is satisfied by the use of libpwquality.

*** This bug has been marked as a duplicate of bug 1340463 ***