Please help me make sense of inconsistent results. Using either raddest
(local) or NTRadPing (remote) the tests are successful if I login as a
user in /etc/passwd. In NTRadPing I must make sure CHAP is *not* selected.
Using NTRadPing with CHAP selected I can login as a user in
raddb/users. If
Running radiusd -X produces the following during a failed radtest test:
rad_recv: Access-Request packet from host 127.0.0.1:32782, id=58, length=55
User-Name = mao
User-Password = testing
NAS-IP-Address = 255.255.255.255
NAS-Port = 10
Processing the authorize
Paul [EMAIL PROTECTED] wrote:
A failed test against a username in raddb/users looks like this:
radtest -d /usr/local/etc/raddb/ kiko testing 127.0.0.1 10 testing123
...
Why are you looking at the output from radclient when the README,
FAQ, man pages, and other places say to run the server in
Paul [EMAIL PROTECTED] wrote:
rad_check_password: Found Auth-Type System
auth: type System
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 2
modcall[authenticate]: module unix returns notfound for request 2
Ok... what part of
Alan DeKok wrote:
Paul [EMAIL PROTECTED] wrote:
rad_check_password: Found Auth-Type System
auth: type System
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 2
modcall[authenticate]: module unix returns notfound for request 2
Paul [EMAIL PROTECTED] wrote:
Well, that seems to indicate that radtest is not sending the password in
the form of CHAP. As a result, it looks like the server is trying to
use /etc/passwd to validate a user that is actually in raddb/users.
So edit raddb/users to set Auth-Type := Local, or
Alan DeKok wrote:
Paul [EMAIL PROTECTED] wrote:
Well, that seems to indicate that radtest is not sending the password in
the form of CHAP. As a result, it looks like the server is trying to
use /etc/passwd to validate a user that is actually in raddb/users.
So edit raddb/users to set
7 matches
Mail list logo
