Users and Groups Randomly Disabled - Bug related to password encryption method

We have had a very strange issues related to the most recent Serv-U update in June ( which started yesterday 26th September out of nowhere, no changes were made..

See this thread for the details relating to the password encryption method change in the update from, we've had this update in place for months with no issues but now...

Accounts using Public Key authentication to connect to Serv-U suddently were not able to connect AND their accounts were becoming disabled. Users do not have automatic disabling set on their account, Serv-U is doing this all by itself.

After lots of testing, it appears that when an account has been connecting using a key, Serv-U still has the old password format/encryption method associated with that user's account (in the user's Archive file), even though they are not using a password to connect. Something in the Serv-U code seems to have enforced that accounts with this get DISABLED when they try to connect, even with a key (specifically on 26th September). The administrator when has to manually reactivate the account but as soon as they try to login again, it gets disabled. We also saw one instance where the GROUP that the user belonged to also go disabled, which disables all other users in that group.

The only way to fix this is to set a new password on the account but I have hundreds of accounts this could have happened to and it is near impossible to work out which accounts are affected.

Please can you let us know if there is something in Serv-U for this specific date and how we can fix this issue, is there a patch?

@ivodlouhy @bshopp @peter.kruty 

Thank you for your help.

You may get this issue too based on our previous discussions on the other thread linked above.

Parents Reply
  • We are affected by this problem as well...

    We have dozens of domains configured with up to several hundred users each and so many of them get/got disabled in the last couple weeks/months
    Nobody (we and the customers) knows all the passwords of these accounts and most users only use the plain old FTP service - so they never see the web interface and thus the passwords will remain MD5.

    Just today I had to re-enable a couple hundred accounts....lucky me, this was on a domain that uses an SQL database for storing the users, so I could complete that task somewhat quick with some T-SQL commands.
    On the downside I've enabled ALL the users of this domain, even the ones that were disabled on purpose.
    But currently there is no way to distinguish if user is disabled because of old password scheme or other reasons...

No Data