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.
Solved! Go to Solution.
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.
@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.
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.
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.
@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.
@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.
@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!
I think there may be a bug in this patch (18.104.22.1686) 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?
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.