User Password Updated After First Login - Moodle 3.1

User Password Updated After First Login - Moodle 3.1

by Clement Li -
Number of replies: 2

Hello. I am using Moodle version 3.1 on a server with Linux 4.9.51, and our users are reporting that after setting their password and logging in for the first time, upon the next login their password has changed and they are unable to log in. When I check the report logs, I can see the following message for each user after their first login:


"The user with id X changed the password of the user with id Y"


The origin for this log entry is "cli", and these entries tend to occur in bulk at the same time, always on times ending on some multiple of "15", leading me to believe that it is a scheduled task that is updating user passwords after their first login, preventing them from logging in again. We upload users in bulk and create password and send via email, but do not force password change. I am wondering how to disable the user password update after their first login? I am having trouble narrowing it down to what is causing this, even if I suspect it is caused by a scheduled task.

Average of ratings: -
In reply to Clement Li

Re: User Password Updated After First Login - Moodle 3.1

by Ken Task -
Picture of Particularly helpful Moodlers

Find out who is user 'X' first.  Is that user assigned an Admin level or is that user in a custom role that has related capabilities.

You can check all task ... yoursite/admin/tool/task/scheduledtasks.php

Check the ones related to users/accounts.

They show a time to run/how often ... do those setting match what you see in logs?

'spirit of sharing', Ken


Average of ratings: -
In reply to Ken Task

Re: User Password Updated After First Login - Moodle 3.1

by Clement Li -
User 'X' in this case is user with id '19', one of our admin users. I see them as not only performing user password updates, but sending out the automated emails about Moodle updates when I review the logs.


I have checked our scheduled tasks, but the last run time for the ones related to the users/accounts and passwords all match the logs, or else are more recent than the logs, for last runtime, and their Next Run is scheduled as "ASAP", even though it has been over four days since the last run for all of them. For reference, the last incident I see in my logs of a user password update is 2/4 at 12:00 am, which is the last run time for about half of my scheduled tasks. I also do not know if a scheduled task could have run more recently than that time and simply not found any new users to update the passwords of, in which case it would not register in the logs.


Checking those that are scheduled to run on 15 minute increments, the only one that matches the criteria of both having run at or more recently than the last incident of password reset and acting on 15 minute intervals is "Global search index optimization", which does not sound like the likely culprit from the name alone.


For reference, these are the scheduled tasks that sound relevant to users/accounts that I see that have run at, or more recently than the last incident of a user password update:

- Send New user Passwords

- Send Failed Login Notifications

- Cleanup Password Reset Attempts

The full list is much longer and includes scheduled tasks that from their descriptions don't sound like they are the cause of the problem, such as "Background processing for caches". Poking through the back end, I have also begun to try to follow instances where user_password_updated.php is called, which is the source of the message that appears in the logs, to try to see if I can find out what might be calling it for this particular issue, though I haven't had success with this so far.

Average of ratings: -