Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 8

Beware of v15.2 - Password Expiry Bug

Just a heads up for the bold updaters our there We just performed an upgrade from 15.1.7u5 to 15.2.0 and had to revert back to the old version with the hour... Had dozen of customers calling, because they could no longer sign in, because apparently their password was expired and they were forced to set a new one. We could also verify that behavior with accounts of our own. This of course despite the fact that the password expire option was and is disabled on all levels. (user, domain, global) We did not have time to perform extensive tests, but the problem seems to only happen for web bases logons. (would make sense, as FTP/SCP does not know any method to force a password change)
6 Replies
Level 10

For anyone following, this was resolved in 15.2.1, thanks to @ivodlouhy 

Released here:

0 Kudos
Level 10

@chrisrowWould also be interested to know if FTP/SFTP accounts could still successfully log in using their current password or were they just disconnected/denied access? Would be a nightmare for automated processed for example.

You raised an important point - what happens if they have to change their password but the setting for ability to change password is not enabled on their account?

Appreciate your input!

0 Kudos

Thank you for these comments. As described in different thread we are aware about the problem and working on resolution with aim to publish it soon. Solution has been identified and it is being implemented and verified now.
This Serv-U version 15.2 shouldn't be applied for installations with automated users or generally users who don't have access to Serv-U web ftp client as they are prompted to change password and it is not possible without login via web ftp client so their access will not work. In case Serv-U 15.2 is applied for this type of implementation current workaround is to revert version 15.2. We will inform about new version without this limitation soon.

0 Kudos

@ivodlouhyThanks for the update, it is very very important that this is a seamless transition to the new password encryption method, as descbied in my post here..


For it to work for your customers it must migrate the password to the new method without requiring intervention from the user or admin - as many of us have literally thousands of accounts and it would be impossible to manage this process for both user or automated accounts.

We look forward to the update.

0 Kudos

Sorry, did not have time to investigate to much, as in our case it's a production system with thousands of user accounts across many different domains. (managed by the customers themselves) For the time we were running with v15.2 (~1 hour) I remember seeing quite a bunch of logged in users doing some file uploads/download. So I just assumed that FTP/SCP still works, as I can not imagine that all these customers/users already re-set their password. I did also not check or play around with the option of allowing/disallowing a password reset. But I assume they cannot do that, if they don't have this permission - even in this current case.
0 Kudos
Level 10

Thanks for posting this @chrisrow

I have just made a detailed post to Solarwinds because apparently this is intentional! Here is my post about why it is entirely unworkable..

Please share your thoughts too as this has to be reversed.


0 Kudos