On 19/08/2014 9:09 a.m., Mike wrote:
> Question, when we copy the /etc/squid/passwd file itself from "server 1"
> to "server 2", and when using the same squid authentication, why does
> server 2 not accept the username and passwords in the file that works on
> server 1?
> Is that file encrypted by server 1?
> Do we need to create a new passwd file from scratch on server 2, and use
> a script to "import" it into that new passwd file from server 1?
>
> The main differences:
> Server 1 is 64 bit OS Fedora 8 using squid Version 2.6.STABLE19
> Server 2 is recently installed OS with 32 bit CentOS 6.5 i686 (due to
> hardware being 32bit), squid 3.4.5.
>
> Does that 64 versus 32 bit file setup and creation make an impact? Or
> how about the 2.6.x versus 3.4.x?
Two possibilities:
1) long passwords encrypted with DES.
The current releases Squid NCSA helper checks length of DES passwords
and rejects if they are more than 8 charecters long instead of silently
truncating and accepting bad input.
If your users have long passwords and you encrypted them into the
original file with DES then they need to be upgraded. Logging in with
only the first 8 characters of their password should still work with DES.
2) OS-specific hash algorithm was used to encrypt.
Blowfish and SHA1 algorithms are not universally available. The NCSA
helper which is built against a library missing one of these algorithms
cannot login users with a password file generated using them.
You may have to migrate users via MD5, or ensure libcrypt is used to
build the new Squid helper.
HTH
Amos
Received on Mon Aug 18 2014 - 23:56:53 MDT
This archive was generated by hypermail 2.2.0 : Tue Aug 19 2014 - 12:00:05 MDT