Bug 51684 – Serverpasswordchange fails on all server roles in case ppolicy is enabled

Bug 51684 - Serverpasswordchange fails on all server roles in case ppolicy is enabled


Summary:	Serverpasswordchange fails on all server roles in case ppolicy is enabled

Status:	RESOLVED DUPLICATE of bug 51676

Product:	UCS
Classification:	Unclassified
Component:	Password changes
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:	31907 51676 52059
Blocks:
	Show dependency tree / graph

Reported:	2020-07-17 12:11 CEST by Dirk Ahrnke
Modified:	2020-09-18 13:58 CEST (History)
CC List:	6 users (show)

See Also:
What kind of report is it?:	Bug Report
What type of bug is this?:	5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?:	2: Will only affect a few installed domains
How will those affected feel about the bug?:	2: A Pain – users won’t like this once they notice it
User Pain:	0.114
Enterprise Customer affected?:
School Customer affected?:	Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:	2020071621000523
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 Ahrnke

2020-07-17 12:11:24 CEST

+++ This bug was initially created as a clone of Bug #51676 +++

although the symptoms are comparable to Bug #51676 (permision denied when changing the password using udm-cli) it appears as if there is no relation in the root cause.

possible steps to reproduce:

- activate ppolicy as documented in https://docs.software-univention.de/handbuch-4.4.html#users:faillog-openldap
- trigger server_password_change

observation: 
- changing the password using udm-cli fails by using valid machine credentials
- changing the password as root using udm-cli is possible

Comment 1 Dirk Ahrnke

2020-07-17 12:40:03 CEST

I have observed the behaviour on all system roles (Master, Backup, Slave, there is no Member in the customer environment).
There are no traces that ppolicy has ever triggered on a machine account. Both "pwdFailureTime" and "pwdAccountLockedTime" are only logged for user accounts but not for machine accounts. This was checked on LDAP on the Master as well as on the local LDAP of the Slave.
In addition I tried "univention-ldapsearch" successfully on my personal enviroment where I can reproduce the behaviour. If a lock would ever had happened, a successful bind should have reset it.

Comment 2 Arvid Requate

2020-07-20 16:58:39 CEST


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