I was recently changing the password for the root - for the system, for the mysql and... also for the admin user in ISPConfig. I generated a random password for all three and set them up. While SSH and MySQL worked nicely there was a problem with ISPConfig - I changed the password and lost the ability to log in back. So I run mysql from SSH selected the ispconfig database, got to sys_user and copied the encrypted password from one of my sites to the admin entry. I was able to log in with my accounts password. So I tried changing the password again (to the same one I generated early) - I got the same result - there was no way to login. So I did the same again and finally it came to me. My password had this: Code: ' sign inside. ISPConfigs' script didn't interpret that char correctly hence causing a bad password encrypted and written out to the SQL.
Recently i realized that i have something strange with how ISPConfig handle passwords. In my configuration i;'ve changed default setup to use md5 - longer passwords: Code: $go_info["server"]["password_hash"] = 'md5'; // 'crypt' = crypt; 'md5' = crypt-md5 Unfortunately sometimes it produce incorrect hashes - user can not login. Re-entering same password in ispconfig interface gives ma different hash. Sometime i have to reenter it two or three times to login (different hash value every time - i've double checked this). This seems not to happen if i setup user accounts from ispconfig admin account (ispconfig clients logins gives me this behaviour) - but i do not work like this on a daily basis. P.S. I use also user@domain mod but hashes in userdb file are always same as in /etc/shadow - so synchronized correctly. EDIT: it happens despite user i choose (admin or not). I' ve always to check if password is ok - with mailuser or webmail login to be sure. This bug stopps me from giving their own admin panel for my users
Facing the same problem here. Any password with a is accepted during creation but rejected during login. I've confirmed that the md5 hash stored in database is correct. Something is wrong with the password string that gets parsed during login.
ISPConfig had a problem with the correct escaping of special characters in login and password. I've fixed the bug in the SVN trunk and 2.2.-stable repository. For each version there's a different bugfix because of different versions of ispconfig_auth.lib.php and login.php. @jbravo: Please recheck with the bugfix. http://bugtracker.ispconfig.org/index.php?do=details&task_id=22 cheers, flip
Does it mean that i can download "ISPConfig 2.x stable branch" from http://www.ispconfig.org/downloads/ISPConfig-svn-stable.tar.gz and check if it works as expected? Does it also mean that all i have to do on production is to overwrite these two mentioned files from above archive with latest ISPConfig official release (2.2.23)?
Hi jbravo, exactly. Almost. At the moment the bugfix is only available through ISPConfig-svn-stable.tar.gz or SVN. It will be available in the next official release (2.2.24 i guess). But yes, you may copy only lib/classes/ispconfig_auth.lib.php and web/login/login.php from the current ISPConfig-svn-stable.tar.gz to your production system to fix this bug. cheers, flip
I've checked this with my vmware ispconfig 2.2.23 machine and it works! All keepass random generated passwords works as expected. Ispconfig time for rewriting config files when changing password could be confusing - checked in ispconfig.log that system finished rewriting files before trying to login with new password. Thanks and hope to see it asap in official release.
