Description Fabian Schneider 2025-05-28 12:14:31 CEST

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

> 1. You set pwdChangeNext=1 for a user in UDM
> 2. If the user was already logged in the last minutes, dovecot will "Cache" that behavior for some seconds, still serving the directory index. That's no problem so far, but important to remember
> 3. If the dovecot cache has been invalidated or dovecot is restarted, the "state" is as follows:
> 
> ```
> # udm users/user list --filter uid=lehrer.s401 | grep -E "DN:|pwdChangeNext"                                                                                                                                                                                        
> DN: uid=lehrer.s401,cn=lehrer,cn=users,ou=S40,dc=…
>   pwdChangeNextLogin: 0
> ```
> 
> -> The user tries to login by IMAP and gets rejected from the PAM Stack, as a password change is required:
> 
> ```
> ~ # curl imaps://$(hostname -f) --user 'lehrer.s401:nixda' -k                                                                                                                                                                                                           root@ucs-ox
> curl: (67) Login denied
> ```
> 
> 4. This failed Login attempt causes the pwdChangeNextLogin to be changed back to 0 -> removes the requirement to change the password for the user, if you try the same commands 1 second later:
> 
> ```
> 
> ~ # udm users/user list --filter uid=lehrer.s401 | grep -E "DN:|pwdChangeNext"                                                                                                                                                                                       
> DN: uid=lehrer.s401,cn=lehrer,cn=users,ou=S40,…
>   pwdChangeNextLogin: 0
> 
> ~ # curl imaps://$(hostname -f) --user 'lehrer.s401:nixda' -k                                                                                                                                                                                                           root@ucs-ox
> * LIST (\HasNoChildren \UnMarked \Sent) "/" "Gesendete Objekte"
> * LIST (\HasNoChildren \UnMarked \Trash) "/" Papierkorb
> * LIST (\HasNoChildren \UnMarked \Drafts) "/" Entw&APw-rfe
> * LIST (\HasNoChildren) "/" confirmed-ham
> * LIST (\HasNoChildren \Junk) "/" confirmed-spam
> * LIST (\HasNoChildren \Junk) "/" Spam
> * LIST (\HasNoChildren) "/" INBOX
> ```
> 
> I had the same issue like a week ago on my test environment but couldn't reproduce it on fresh installed servers, causing me to think about a error in my environment. The clients tellings they had actual wars going on in their office because they suspected team members to not set the pwdChangeNext flag as mail accounts got hijacked over and over again without actual password changes made me pretty certain about a product bug.