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