Bug 2072826

Summary:	Support preventing password use for specified accounts
Product:	[Community] Bugzilla	Reporter:	Jeff Fearn 🐞 <jfearn>
Component:	Extensions	Assignee:	Jeff Fearn 🐞 <jfearn>
Extensions sub component:	RedHat	QA Contact:	Jeff Fearn 🐞 <jfearn>
Status:	CLOSED CURRENTRELEASE	Docs Contact:
Severity:	unspecified
Priority:	unspecified
Version:	5.0
Target Milestone:	---
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:	2022-05-09 00:14:59 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 Jeff Fearn 🐞 2022-04-07 03:54:13 UTC

Description of problem:
Some accounts should are not permitted to use passwords and must use external authentication.

Currently Bugzilla supports this to some degree.

1. If the password is set to '*' the user must use external authentication

2. The existing parameter rh_radius_groups forces users in specified groups to use external auth.


#1 doesn't have any UI changes so the UX is poor. There is no way to get in to this state without an admin setting the password to '*'. the user can use the forgot password process to change the password.

#2 requires a user to be in one of the groups specified first, thus can't be in effect when the account is created.


Changes required:

1: Add can_use_password function[s?] to flag if a user is allowed to use a password.

2: Modify Bugzilla::Auth::Verify::RedHat->check_credentials to use can_use_password.

3: Modify User->create to set password to '*' if can_use_password is false.

4: Modify account creation pages to hide password text and field if can_use_password is false.

5: Modify preferences tab to hide password fields if can_use_password is false.

6: Modify password update function to throw an error if can_use_password is false and password isn't '*'.

7: Modify forgot password form and process to error if can_use_password is false.

8: Modify User->update to set password to '*' if can_use_password is false and password isn't '*'.

Comment 1 Jeff Fearn 🐞 2022-04-29 04:14:37 UTC

Tested on both Dev & QA servers.

Dev server is set to block password auth for selected users.
QA server is set to allow password auth for all users.

1. Login in to QA server using password with an associate account in no groups.

User is logged in.

2. Login in to QA server using password with an associate account in a sensitive group.

User is prevented logging in and told to use 2FA.

3. Login in to QA server using 2FA with an associate account in a sensitive group.

User is logged in.

4. Login in to Dev server using password with an associate account in no groups.

User is prevented logging in and told to use 2FA.

5. Login in to Dev server using 2FA with an associate account in a sensitive group.

User is logged in.

6. Login in to Dev server using password with an associate account in a sensitive group.

User is prevented logging in and told to use 2FA.

7. Login in to Dev server using 2FA with an associate account in a sensitive group.

User is logged in.

8. On QA server login in as an associate and view the "Account Information" user preferences tab.

Password field is present and can be updated.

9. On Dev server login in as an associate and view the "Account Information" user preferences tab.

Password field is not present and cannot be updated.

10. Use the API to update password for an associate on the QA server.

Password is updated.

11. Use the API to update password for an associate on the DEV server.

Attempt to change password fails with message "RPC Fault: This account cannot use a password so the password must be set to '*'"

Comment 2 Jeff Fearn 🐞 2022-05-05 00:10:46 UTC

The fix for this bug has been deployed to the stage server for public testing.

https://bugzilla.stage.redhat.com/

Comment 3 Jeff Fearn 🐞 2022-05-09 00:14:59 UTC

This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.