Problem: Users Unable to Change Password After Reset

[fdavid]

Problem

Users who are forced to change their password after a password reset are unable to successfully set a new password during login.
The issue occurs when a password reset is performed via the UMC with the option enabled that requires the user to change their password upon next login.

Steps to Reproduce

1. Log in as a test teacher.
2. Open the Passwords (Students) portal tile in the UMC.
3. Reset a user’s password and enable the option “User must change password at next login”.
4. Log in as the affected user.
5. Enter the initial password and set a new password.
6. The password change fails.

---

Analysis

It was observed that the password change is reliably accepted on the fourth attempt, which already indicated an underlying infrastructure issue rather than a frontend or policy problem.

Keycloak Logs

Relevant warnings were found in the Keycloak logs (univention-app logs keycloak), showing repeated UPDATE_PASSWORD_ERROR events with the error:

• password_rejected
• gensec_update failed - NT_STATUS_LOGON_FAILURE
• The new password could not be set

This pointed towards an authentication or backend directory service issue.

Samba / Kerberos Logs

Further investigation in the Samba logs revealed Kerberos authentication failures with the status:

• NT_STATUS_PROTOCOL_UNREACHABLE

This suggested that Kerberos requests were being sent to an endpoint that could not properly handle them.

Directory Replication (DRS)

A check using samba-tool drs showrepl revealed an unexpected replication connection:

• A school slave server (school01) was listed as a replication partner, even though it should not act as a replicating domain controller.
• The object had been created months earlier and could not be traced back reliably.

DNS and Kerberos SRV Records

On the backup servers running Keycloak, no Samba was installed. However, Kerberos was configured to discover KDCs via DNS SRV records.

DNS showed the following SRV entries:

• _kerberos._tcp.schule.domain → master.schule.domain
• _kerberos._tcp.schule.domain → dc-backup02.schule.domain

The problem:
dc-backup02 runs Heimdal Kerberos (not Samba Kerberos), which cannot process the Samba-specific Kerberos requests required for password changes. As a result, some authentication attempts were routed to an incompatible KDC, causing intermittent failures.

---

Solution

1. Remove the Invalid Replication Partner

The school slave was removed from DRS using:

samba-tool domain demote --remove-other-dead-server school01

2. Clean Up Kerberos DNS SRV Records

Identify SRV records pointing to the backup DC:

udm dns/srv_record list --filter location=*dc-backup02.schule.domain*

The following entries were found and must be edited to remove dc-backup02:

• _kerberos._tcp.schule.domain
• _kerberos._udp.schule.domain

This can be done either via command line or directly in the UMC.

3. Verify DNS Resolution

On a backup server, verify that Kerberos SRV records now only point to valid Samba DCs:

host -t SRV _kerberos._tcp.schule.domain

4. Repeat Cleanup for the School Slave

Check for DNS entries referencing the former school slave:

udm dns/srv_record list --filter location=*school01*

Any SRV records listing both the master and school01 should be reviewed and corrected accordingly.