Re: Old OpenLDAP server and ProFTPD - "bad password" problem

2020-10-24 Thread Glenn McIntosh via luv-main
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::9: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



signature.asc
Description: OpenPGP digital signature
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main


Re: Old OpenLDAP server and ProFTPD - "bad password" problem

2020-10-24 Thread Craig Sanders via luv-main
On Thu, Oct 22, 2020 at 11:00:10AM +1100, Peter Ross wrote:

> ftptest:ACJJox72N4DZQ:14740::9: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 
___
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main