Bug 53230 – ppolicy password lockout doesn't trigger PAM (faillog) password lockout

Bug 53230 - ppolicy password lockout doesn't trigger PAM (faillog) password lockout


Summary:	ppolicy password lockout doesn't trigger PAM (faillog) password lockout

Status:	NEW

Product:	UCS
Classification:	Unclassified
Component:	LDAP
Version:	UCS 4.4
Hardware:	Other Linux

Importance:	P5 normal (vote)
Target Milestone:	---
Assigned To:	UCS maintainers
QA Contact:	UCS maintainers

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2021-05-06 10:54 CEST by Dirk Schnick
Modified:	2023-04-27 19:08 CEST (History)
CC List:	6 users (show)

See Also:
What kind of report is it?:	Feature Request
What type of bug is this?:	---
Who will be affected by this bug?:	---
How will those affected feel about the bug?:	---
User Pain:
Enterprise Customer affected?:	Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:	2021042621000384, 2021121421000141, 2023020821000444
Bug group (optional):
Max CVSS v3 score:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Dirk Schnick

2021-05-06 10:54:22 CEST

A lockout via ppolicy will not (f.e. by wrong passwords via ldapbind) will not lead to lockout the PAM stack.
I'm not sure if this is expected in actual implementation, but this would be consistently and was expected by the customer.
Maybe the patch of bug 52892 would already fix that and if this bug is a (kind of) duplicate to 52892 or 52893. The topic is different as these two bugs treats other directions.

I was able to verify the problem in my test environment. Ppolicy lockout was triggered by ldapbind with wrong password, kinit and ldap access were locked but via ssh or local su was still possible.

Comment 4 Stefan Gohmann

2022-12-19 07:58:15 CET

I set the "Waiting Support" flag because of Ticket #2021121421000141.

Comment 5 Mirac Erdemiroglu

2023-02-09 16:37:25 CET

Another customer is effected Ticket #2023020821000444

Comment 6 Stefan Gohmann

2023-04-27 19:08:32 CEST

Yes, it would be nice if this is overall synchronized but it is currently not documented and not implemented. So, I change it to a feature request.

The main goal is to prevent brute force attacks.