Bug 35011 – Password change in a s4 environment requires a second login on the ucc client

Bug 35011 - Password change in a s4 environment requires a second login on the ucc client


Summary:	Password change in a s4 environment requires a second login on the ucc client

Status:	CLOSED WONTFIX

Product:	Z_Univention Corporate Client (UCC)
Classification:	Unclassified
Component:	User logins
Version:	unspecified
Hardware:	Other Linux

Importance:	P5 normal
Target Milestone:	UCC 2.x
Assigned To:	UCC maintainers
QA Contact:

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2014-05-28 17:39 CEST by Felix Botner
Modified:	2023-06-28 10:33 CEST (History)
CC List:	6 users (show)

See Also:
What kind of report is it?:	---
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?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
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 Felix Botner

2014-05-28 17:39:38 CEST

UCS Master with samba4 and UCC 2.0 and an UCC client. 

Created a user with "Change password on next login". Login on the UCC client works, password change is triggered and successful but than i get 

"You are required to change your LDAP password"

and have to login a second time.

Maybe the problem is that the password change is done via kerberos (thus samba in a s4 environment) and the pam account check vi pam_ldap. The samba password change triggers the connector which does the password change in openldap. But this takes some time and maybe too long for a proper login on UCC.

Comment 1 Tim Petersen

2014-09-25 15:21:56 CEST

Reuested at 2014092221000243

Comment 2 Arvid Requate

2014-11-10 15:35:11 CET

> Maybe the problem is that the password change is done via kerberos
> (thus samba in a s4 environment) and the pam account check vi pam_ldap.

Yes, I had a similar same effect when fixing change of expired passwords during UMC logon. I had to avoid the pam_acct_mgmt call directy after the change, otherwise the authentication would fail directly after the change.

Comment 3 Jens Thorp-Hansen

2016-01-22 11:09:37 CET

happened eventually again at: Ticket#2015040721000485 (message 57)

Regarding password-change:
Could be reproduced on 2 clients. It seems that UCC authenticates alternating between LDAP and AD or that the sychronisation between LDAP and AD is slower then the password entry action of a user at on the UCC Client.

Workaround: 
the UCC Client has to be restarted between the steps of the password-change, then all seems to work.

Comment 4 Erik Damrose

2016-01-22 11:20:28 CET

UCCs pam config has a fallback to LDAP auth in case kerberos is not available. Maybe the kerberos pam module behaves differently in terms of return values after changing the password.

We should also check if the local password cache is updated correctly.

Comment 5 Arvid Requate

2016-01-22 13:03:56 CET

"second login" vs "UCC Client has to be restarted"?

Comment 6 Jens Thorp-Hansen

2016-01-27 09:35:05 CET

additional information from the customer Ticket#2015040721000485
additional workaround:

User in the UMC -> UNSET checkbox "change password on next login" -> save -> SET checkbox "change password on next login" -> save

password change works without restart

Comment 7 Philipp Hahn

2023-06-28 10:30:40 CEST

UCC is EoL