Old OpenLDAP server and ProFTPD - "bad password" problem
Hi all, My colleagues and I are scratching our heads to figure out what goes wrong when we are setting up a new ProFTPd server and connecting to an older LDAP server (CentOS 5 - we want all refurbished at the end). The new ProFTPd is on Ubuntu 20.04 and uses mod_ldap. We can connect to the LDAP server, getting uid etc., but then it says: 2020-10-22 12:27:22,998 mod_ldap/2.9.4[1510]: bad password for user ftptest It works if we use the "old fashioned way" as our old server had: using nsswitch.conf. Interestingly, the LDAP server gives back, using ldapsearch userPassword:: e0NSWVBUfUFDOTl5RjBhWVNZNmM= When using a system user, I have this: # getent shadow|grep -i ftptest ftptest:ACJJox72N4DZQ:14740::99999:7::: I wonder what the password hash above is, they all start with "e0NSWVBUf" , and whether we are missing anything in the ProFTPd configuration so it 'understands' it. As said, the OpenLDAP server runs on CentOS5, so it is old, very old.. (openldap-2.3.43-3.el5), don't ask me why it's still there ;-) Do you have any ideas what I can do to get ProFTPd working with it? Thank you Peter
On Thu, Oct 22, 2020 at 11:00:10AM +1100, Peter Ross wrote:
ftptest:ACJJox72N4DZQ:14740::99999:7:::
that's a really ancient looking crypted password, probably hasn't been changed in decades. It doesn't even start with "$1$", so it was created before even MD5 hashing became standard (let alone $5$ for sha256 or $6$ for sha512), and I can't even remember when that happened, late 1990s perhaps. Centos 5 was released in 2007, so a) I guess this server was migrated from something even older and b) should be capable of more modern passwd hashing.
Do you have any ideas what I can do to get ProFTPd working with it?
Two ideas: 1. change the password to itself (might require changing it to something else, then back to whatever it was originally) so that it gets hashed again. this should be easy to test with minimal work required. who knows, it may even work :-) remember to test that any old clients still work with the newly hashed passwd, as well as the new proftpd server. changing the password to itself **should** be harmless, but you'll probably want to make a backup of the ldap config & auth data, just in case you have to revert. 2. set up a VM with either a modern ldap proxy or a clone ldap server using a modern version of the ldap daemon. If the new VM works with both old and new clients, then congrats - you're well on the way to migrating your ldap infrastructure to something modern. craig -- craig sanders <cas@taz.net.au>
On 22/10/20 11:00 am, Peter Ross via luv-main wrote:
Interestingly, the LDAP server gives back, using ldapsearch
userPassword:: e0NSWVBUfUFDOTl5RjBhWVNZNmM
This is a base64 representation of a old crypt hash "AC99yF0aYSY6c" (which is a hash of the password 'sftptest')
When using a system user, I have this:
# getent shadow|grep -i ftptest ftptest:ACJJox72N4DZQ:14740::99999:7:::
This is also an old crypt hash (which is a hash of the password 'ftptest') Presumably both test passwords match their username, so they are for different usernames. Not sure why both have the same salt? regards, Glenn
Hi Craig and Glenn, Thanks for answers. On Sun, Oct 25, 2020 at 11:02 AM Glenn McIntosh via luv-main <luv-main@luv.asn.au> wrote:
"Not sure why both have the same salt?"
They are the same from the same LDAP server. I was probably a bit confusing in describing it: I get the "e0NSWVBUfUFDOTl5RjBhWVNZNmM" when querying the LDAP server using ldapsearch, while "ACJJox72N4DZQ" was the getent shadow answer after I enabled LDAP to be used to authorise system users (via nsswitch.conf).
This is a base64 representation of a old crypt hash "AC99yF0aYSY6c" (which is a hash of the password 'sftptest')
Ah, I did not know that ldapsearch would give me a base64 representation. I expected the hash "ACJJox72N4DZQ". (ftptest is a test user only, btw) On Sun, Oct 25, 2020 at 10:17 AM Craig Sanders via luv-main <luv-main@luv.asn.au> wrote:
It doesn't even start with "$1$"
Yes, that confused me. I have no idea about the history of that LDAP server, I just know that it precedes me by a long long time here.
"2. set up a VM with either a modern ldap proxy or a clone ldap server using a modern version of the ldap daemon.'
We are on that but I am not sure whether the old password representation may bite us. The problem is that it may contain passwords we do not know so we cannot just retype it. Will see how that works.
congrats - you're well on the way to migrating your ldap infrastructure to something modern.
That is what I want.. Regards Peter
Hi all, I just wanted to let you know how it ends: I was surprised when we did a LDIF export/import from the lhe LDAP CentOS5 server to a new one on Ubuntu 20.04. Afterwards the new ProFTPD server could talk to the new LDAP, so the password representation was not the problem, despite the "bad password" message when connecting to the old LDAP server. We tried the other way around, let the old FTP server (also on CentOS 5) talk to the new LDAP server but that didn't work either. Instead of spending more time debugging it, I have a script which keeps the two LDAP servers in sync, and we are replacing the old FTP servers with new ones talking to the new LDAP server. When finished, we switch off the old LDAP server, planned in a month's time (BTW please do mention FTP and security. We have to make customers happy but put some efforts in to have more security around it.) Thanks to Craig and Glenn and all who spent some time and thoughts on this. Regards Peter On Mon, Oct 26, 2020 at 2:52 PM Peter Ross <petrosssit@gmail.com> wrote:
Hi Craig and Glenn,
Thanks for answers.
On Sun, Oct 25, 2020 at 11:02 AM Glenn McIntosh via luv-main <luv-main@luv.asn.au> wrote:
"Not sure why both have the same salt?"
They are the same from the same LDAP server. I was probably a bit confusing in describing it:
I get the "e0NSWVBUfUFDOTl5RjBhWVNZNmM" when querying the LDAP server using ldapsearch, while "ACJJox72N4DZQ" was the getent shadow answer after I enabled LDAP to be used to authorise system users (via nsswitch.conf).
This is a base64 representation of a old crypt hash "AC99yF0aYSY6c" (which is a hash of the password 'sftptest')
Ah, I did not know that ldapsearch would give me a base64 representation. I expected the hash "ACJJox72N4DZQ".
(ftptest is a test user only, btw)
On Sun, Oct 25, 2020 at 10:17 AM Craig Sanders via luv-main <luv-main@luv.asn.au> wrote:
It doesn't even start with "$1$"
Yes, that confused me. I have no idea about the history of that LDAP server, I just know that it precedes me by a long long time here.
"2. set up a VM with either a modern ldap proxy or a clone ldap server using a modern version of the ldap daemon.'
We are on that but I am not sure whether the old password representation may bite us. The problem is that it may contain passwords we do not know so we cannot just retype it. Will see how that works.
congrats - you're well on the way to migrating your ldap infrastructure to something modern.
That is what I want..
Regards Peter
participants (3)
-
Craig Sanders -
Glenn McIntosh -
Peter Ross