Problem with crypt passwords matching
I am running Freeradius 2.1.12 on a Centos box. I am able to authenticate from the server command line, and from a Cisco ASR1k BRAS via the command line. However, when I attempt to authenticate customers from the DSL network, I get a reject, even though the crypt'd passwords match! Here is a sample from a trace: rad_recv: Access-Request packet from host 204.111.5.9 port 1645, id=235, length=89 Framed-Protocol = PPP User-Name = "k143rott" User-Password = "k*****" NAS-Port-Type = Virtual NAS-Port = 0 NAS-Port-Id = "0/0/0/304" Service-Type = Framed-User NAS-IP-Address = 204.111.5.9 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "k143rott", looking up realm NULL [suffix] Found realm "NULL" [suffix] Adding Stripped-User-Name = "k143rott" [suffix] Adding Realm = "NULL" [suffix] Authentication realm is LOCAL. ++[suffix] returns ok [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns updated [files] users: Matched entry DEFAULT at line 169 [files] users: Matched entry DEFAULT at line 172 [files] users: Matched entry DEFAULT at line 186 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group PAP {...} [pap] login attempt with password "krt444" [pap] Using CRYPT password "*3u.3LS/VKTOVc" [pap] Passwords don't match ++[pap] returns reject Failed to authenticate the user. Login incorrect (rlm_pap: CRYPT password check failed): [k143rott/k*****] (from client va-edbg-bras-1 port 0) Using Post-Auth-Type Reject # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> k143rott attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 30 for 1 seconds Going to the next request Sending delayed reject for request 21 Sending Access-Reject of id 227 to 204.111.5.9 port 1645 The crypt'd password ("*3u.3LS/VKTOVc") is exactly what is in the /etc/shadow file. So I am confident the shared secret is correct. What am I doing wrong? -- Haskins Family Farm Middletown, VA web: http://www.haskinsfamilyfarm.com FB: http://www.facebook.com/pages/Middletown-VA/Haskins-Family-Farm/114984971161
Hi,
++[unix] returns updated
okay...so I assume you have edited the passwd module to read thew shadow file?
[files] users: Matched entry DEFAULT at line 169 [files] users: Matched entry DEFAULT at line 172 [files] users: Matched entry DEFAULT at line 186
what do these lines have/say? alan
What do you mean by editing the passwd module? As for the users lines, here is what is in that file (first line is 169 and the last one is 186): DEFAULT Auth-Type == System Fall-Through == 1 DEFAULT Service-Type == Framed-User Framed-IP-Address == 255.255.255.254, Framed-Netmask == 255.255.255.255, Framed-MTU == 1500, Service-Type == Framed-User, Framed-Routing == None, Fall-Through == Yes # # Default for PPP: dynamic IP address, PPP mode, VJ-compression. # NOTE: we do not use Hint = "PPP", since PPP might also be auto-detected # by the terminal server in which case there may not be a "P" suffix. # The terminal server sends "Framed-Protocol = PPP" for auto PPP. # DEFAULT Framed-Protocol == PPP On Wed, Aug 15, 2012 at 4:52 PM, alan buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
++[unix] returns updated
okay...so I assume you have edited the passwd module to read thew shadow file?
[files] users: Matched entry DEFAULT at line 169 [files] users: Matched entry DEFAULT at line 172 [files] users: Matched entry DEFAULT at line 186
what do these lines have/say?
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Haskins Family Farm Middletown, VA web: http://www.haskinsfamilyfarm.com FB: http://www.facebook.com/pages/Middletown-VA/Haskins-Family-Farm/114984971161
On Thu, Aug 16, 2012 at 3:40 AM, Robert Haskins <robert.haskins@gmail.com> wrote:
I get a reject, even though the crypt'd passwords match!
That's not how crypt works. You don't compare the crypted password.
[pap] login attempt with password "krt444"
that is what the user sends
[pap] Using CRYPT password "*3u.3LS/VKTOVc"
that is what FR reads from whatever backend which stores user information (in your case, should be the unix module)
The crypt'd password ("*3u.3LS/VKTOVc") is exactly what is in the /etc/shadow file.
because that's where FR reads it from, of course it's the same.
So I am confident the shared secret is correct.
Shared secret has nothing to do with your problem.
What am I doing wrong?
Simple. Is "krt444" the correct password? FR says it's not. -- Fajar
On 15 August 2012, at 14:23, Fajar A. Nugraha wrote:
On Thu, Aug 16, 2012 at 3:40 AM, Robert Haskins <robert.haskins@gmail.com> wrote:
I get a reject, even though the crypt'd passwords match!
That's not how crypt works. You don't compare the crypted password.
[pap] login attempt with password "krt444"
that is what the user sends
[pap] Using CRYPT password "*3u.3LS/VKTOVc"
that is what FR reads from whatever backend which stores user information (in your case, should be the unix module)
The crypt'd password ("*3u.3LS/VKTOVc") is exactly what is in the /etc/shadow file.
because that's where FR reads it from, of course it's the same.
So I am confident the shared secret is correct.
Shared secret has nothing to do with your problem.
What am I doing wrong?
Simple. Is "krt444" the correct password? FR says it's not.
I don't know for sure about your system, but most Unix based systems will not generate a * in the encrypted password. Normally that is used to indicate a locked or disabled account. From the FreeBSD man pages: A password of `*' indicates that password authentication is disabled for that account (logins through other forms of authentication, e.g., using ssh(1) keys, will still work). The field only contains encrypted pass- words, and `*' can never be the result of encrypting a password. You might want to try reentering that password or check your man pages.
On Wed, Aug 15, 2012 at 04:46:09PM -0700, Doug Hardie wrote:
[pap] login attempt with password "krt444"
...
[pap] Using CRYPT password "*3u.3LS/VKTOVc"
I don't know for sure about your system, but most Unix based systems will not generate a * in the encrypted password. Normally that is used to indicate a locked or disabled account.
Agreed - the crypted password is fine except for the *. $ perl -e 'print crypt("krt444", "3u") . "\n";' 3u.3LS/VKTOVc Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (5)
-
alan buxey -
Doug Hardie -
Fajar A. Nugraha -
Matthew Newton -
Robert Haskins