This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

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

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.

   

  • 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.
  • 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.
  •  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.

  • 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.

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

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

  • Thank 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.

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

  • Ok, 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.

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

    Thank you for your comments, appreciate it.