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

Serv-U 15.2 Forced Password change for ALL accounts - entirely unworkable in production.

Jump to solution

I am aware of a change in v15.2 that means ALL passwords will expire after installation and must be reset manually so they can be re-hashed - meaning all accounts are offline until this takes place.

This is completly unworkable for your customers and I would like to share some real world scenarios to explain why.

We have 100's of accounts for sensors and equipment around the world in remote locations that report in data every 15 mins. These are pre-programmed with a host, username and password. It is impossible to change the details on these units, many are unmanned remote locations. These user accounts connect by FTP and SFTP so they have no interface to change the passwords.

All user accounts would be cut off at the point of installation until all passwords had been reset. Furthermore it would take days and days to manually change these in the admin panel directly and there is room for error. Not only this but the latest announcement says that the existing password cannot be used.

Another example would be systems using the service to pick up orders, or instructions for manufacturing - these systems would all go down until all passwords were reset manually both on the account and on the system (which could take days to organise and may not even be physically possible), the distruption would be huge and unworkable. Solarwinds must remember that Serv-U is used in environments where there are hundreds or thousands of user accounts, this is why we pay so much for this software and maintenance - it is business critical.

My suggestion for the fix is simple..

After the upgrade to v15.2, when a user account logs in successfully, the current password is rehashed and stored. A flag can be stored on the account to identify it uses the new algorythm and the next time they login it uses that to validate the password. This is normal practice for password algorythm migration.

This is an URGENT issue that needs to be addressed as it affects every single Serv-U customer.

Please give us an update and your plan to address this as soon as possible.

@ivodlouhy @bshopp @peter.kruty 

1 Solution

Serv-U version 15.2.1 resolving this problem is now available - announcement

View solution in original post

23 Replies
Product Manager
Product Manager

Thank you for raising this concern. 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.
I will inform about final approach in next few days, meanwhile workaround for impacted use cases is to revert Serv-U 15.2.

0 Kudos
Level 8
WTF, I am baffled.... Do you guys realize that some may use big installations with dozens of separate domains, each with up to 100+ accounts and all of them managed by different customers? And like anyone still remembers all these passwords to set them anew.... Configuring a different password may not be feasible, despite it being a time consuming task and a big pita, if it has to be done for more than a handful of accounts. I really don't get it why you enforce a password change/reset, just to get away from the old md5 hashes.

Serv-U version 15.2.1 resolving this problem is now available - announcement

0 Kudos

We work on solution right now, we will give an update today asap.

0 Kudos

@chrisrow 100% agree, there is literally no way this be left like this - it has to be changed. If we're responding to this within hours of the release, imagine the millions of user accounts that are affected across all Serv-U installations.

It is simply not workable.

Solarwinds, we need an urgent fix.

0 Kudos

Appreciate your post, and we work on solution right now, we will give an update today.

0 Kudos
Level 10

Here is the official information from the release that shows how unworkable this is...

Serv-U version 15.2 will be using a stronger encryption for the user password. This will affect the Domain and Database users. Windows Authentication and LDAP Authentication accounts will use the same password. 
After upgrading to version 15.2, Serv-U will treat all Domain and Database user passwords as expired. This will cause the accounts to fail the authentication process. Once the password is changed, it will now be encrypted using a stronger hashing algorithm.

Here are the suggested Resolution:
1. Update and change the user account password through the Management Console
- Launch the Serv-U Management Console
- Go to Domains > Users > Domain Users or Database Users tab
- Edit each account and manually set the password (this can be the same password as the old one)

2. End-users will have the ability to change their password if they are connecting to ServU through Web Client. Once they enter their credentials, they will be prompted to enter their old and new password. The need to use a different password. FTP and SFTP connections will not have the option to change passwords.
0 Kudos

Thank you for this info, we are aware about this potential problem for automated users or users without access to web client. We work on solution right now and will be giving update today. Current quick workaround for impacted users is to revert Serv-U 15.2. for now before it is fully resolved.

What is the new encryption method for creating the manual password for scripting? The documentation is not up to date.

Thank you.

0 Kudos

@ivodlouhyThank you for the info and look forward to the update.

This also impacts users who access via the web client but do not have "Allow user to change password" limit/setting set. By default in Serv-U this was not on in previous versions so this apply to nearly all users.

The other consideration with the above is that many admins do not want specific accounts to be able to change their password vian the web panel as they may be a service account and have to be managed by the admin. Some serv-u installations have hundreds or thousands of such service accounts.

We look forward to hearing from you.

0 Kudos

This is not an issue as "Allow user change password" is ignored in this particular case. Serv-U requires the change unconditionally.

0 Kudos

@ivodlouhyOk, however in many many cases it is policy not to allow many users to change the password of accounts to avoid them taking control of an account that may be used for a process, automated or otherwise. This is why the limit/setting settings in Serv-U to give admins that control to stop users breaking things.

We look forward to hearing the resolution and thank you for your quick responses to this.

0 Kudos

Yes, understood and we have proper solution on the way.

Thank you for your comments, appreciate it.

@ivodlouhyThanks, we appreciate your help with this and look forward to the update over the next few days.

I'd just like to be really clear about how important it is that the password migration is seamless when the user logs in either by web client or automated means such as SFTP/FTP/FTPS. Please see my original post above for the suggested solution. It is impossible for administrators like me or @chrisrow for example to manage any change of process that includes manual intervention by the user or admin for thousands of user accounts and the disruption would be massive and unworkable, many passwords simply cannot be changed and/or shouldnt be by the end users for security and continuous operation reasons.

I know you're working on the update and we appreciate that, I just want to make sure it is right when it is released. Thanks!

0 Kudos

@calc2014 , @chrisrow yes we are working on and testing solution with no need for password change so no need for user intervention.

Thats great @ivodlouhy  - much appreciated. We look forward to hearing from you.

0 Kudos

Serv-U version 15.2.1 resolving this problem is now available - announcement

View solution in original post

I think there may be a bug in this patch ( that has started as of 26th September to disable accounts that use Public Key authentication as the password encryption method is not being updated by Serv-U. Even though the accounts do not use a password, Serv-U is disabling the account and groups it is associated with, every time the user tries to connect.

More details on this new thread:

Please help @ivodlouhy 

@chrisrowAre you having the same issue?

0 Kudos

Thanks @ivodlouhy from some initial testing it seems to be working fine. I will do more testing over the next couple of days before putting into production.

@chrisrowis this working for you now with 15.2.1?

0 Kudos

Installed 15.2.1 this morning and so far everything looks OK

No customer complaints and we ourself did also not encounter any problems.

0 Kudos