I am really sorry Ivan. I am very new to radius and have not gone in depth.
Thanks a lot. I can see the expected behavior after commenting unix in
authorize :)
Regards,
Dhandapani
Ivan Kalik wrote:
And I couldn't find the 'authorize' config file anywhere in my server.
Oh, dear. How are
Hi,
I still suggest:
abcUser-Password == test
that is wrong. wrong and wrong
Elias, please put your entry at the top of the users file - or remove
the
DEFAULT Auth-Type == System
from your config (this forces the server to always use 'system' auth
- which you really dont
I have setup a custom module to do auth and acct. In debug mode
everything appears correct, and responses appear correct. When I
don't have radius running in debug mode, responses still appear
correct, but if auth fails due to simultaneous use, radius is logging
'Auth: Login OK'.
I have searched through the maillinglist archive regarding this matter.
There was one thread similar to the problem I'm facing with: Have the
outer-tunnel reply with the user-name specified in the inner-tunnel;
thus instead of anonym...@some.realm
From this thread:
I have searched through the maillinglist archive regarding this matter.
There was one thread similar to the problem I'm facing with: Have the
outer-tunnel reply with the user-name specified in the inner-tunnel;
thus instead of anonym...@some.realm
From this thread:
Ok i have done what you guys have said, which is to not use sql for nas's.
I
deleted the table and changed the readclient line in sql.conf to 'no'. I
have checked radiusd.conf and it has the line $INCLUDE sites-enabled at
the
end of the file. I have also checked in sites-enabled in the
Hi,
have checked radiusd.conf and it has the line $INCLUDE sites-enabled at the
wrong.
$INCLUDE ${confdir}/sites-enabled/
and then make sure you have some files in there (usually
symlinks to the files in sites-available directory)
alan
-
List info/subscribe/unsubscribe? See
On Wed, Jun 17, 2009 at 10:48:07AM +0100, Ivan Kalik wrote:
This is already present in post-auth in latest version (after a lengthy
explanation):
#update outer.reply {
# User-Name = %{request:User-Name}
#}
After uncommenting that in inner-tunnel, I see local users authenticated
by
ok added that new line to radiusd.conf, seems to go through the first stages
of the authorize section, when it comes to the sql part it errors again.
Radiusd -X Debug:
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on proxy address * port
ok added that new line to radiusd.conf, seems to go through the first
stages
of the authorize section, when it comes to the sql part it errors again.
Post the debug of the server startup as well.
Radiusd -X Debug:
Listening on authentication address * port 1812
Listening on accounting
linux-6pfg:/home/james # radiusd -X
FreeRADIUS Version 2.1.1, for host i686-suse-linux-gnu, built on Dec 3 2008
at 10:47:13
Copyright (C) 1999-2008 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may
JamesWhetherly wrote:
linux-6pfg:/home/james # radiusd -X
...
Module: Linked to module rlm_sql
Module: Instantiating sql
Ok, it's there...
sql {
...
authorize_check_query =
authorize_group_check_query =
authorize_group_reply_query =
accounting_onoff_query
Alan Ivan,
I can confirm that the change made to the event.c file fixed the problem
with the robust proxy accounting.
Many thanks for you help.
Chris
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
After uncommenting that in inner-tunnel, I see local users authenticated
by the LOCAL auth called outer.reply. But this is not the case for
external users(Realm handled by external proxy).
The latter is what I really want: being able to see which external user
is authenticating.
The
Chris Howley wrote:
I can confirm that the change made to the event.c file fixed the problem
with the robust proxy accounting.
That's great news!
Many thanks for you help.
And thanks for spending the time to not only debug it, but provide
useful feedback.
Alan DeKok.
-
List
...
including configuration file /etc/raddb/sql.conf
including configuration file /etc/raddb/sql/mysql/counter.conf
...
You have done something to sql.conf. It didn't include dialup.conf.
Ivan Kalik
Kalik Informatika ISP
-
List info/subscribe/unsubscribe? See
Hi
Please could someone help a newbe ...
I'm using the following stack FreeRADIUS Version 2.1.3 with coova-chilli-1.0.13
with Daloradius .
I'm having issues with sending POD from Daloradius and radclient via the
command line
[r...@localhost ~]# echo User-Name='TC-Demo' | radclient -c '1'
On Wed, Jun 17, 2009 at 01:23:57PM +0200, Stefan Winter wrote:
The whole concept of inner tunneling and protecting it via TLS is
*because* you are *not* supposed to see the actual authentication
credentials. For your local users, you terminate the tunnel yourself and
can decide to expose the
Am 17.06.2009 um 13:43 schrieb Gregory Machin:
Hi
Please could someone help a newbe ...
I'm using the following stack FreeRADIUS Version 2.1.3 with coova-
chilli-1.0.13 with Daloradius .
I'm having issues with sending POD from Daloradius and radclient via
the command line
I'm using the following stack FreeRADIUS Version 2.1.3 with
coova-chilli-1.0.13 with Daloradius .
I'm having issues with sending POD from Daloradius and radclient via the
command line
Send it to NAS (coova-chilli), not radius server.
Ivan Kalik
Kalik Informatika ISP
-
List
Hi,
I thought the outer-tunnel is set up to secure the connection between the
user and the authentication server. So the Authentication has access to
the unencrypted data which it in turn queries proxies to verify the
received credentials; this data is encrypted using the home-server shared
From: freeradius-users-bounces+gregorym=techconcepts.co...@lists.freeradius.org
[freeradius-users-bounces+gregorym=techconcepts.co...@lists.freeradius.org] On
Behalf Of Ivan Kalik [...@kalik.net]
Sent: Wednesday, June 17, 2009 1:57 PM
To: FreeRadius users mailing list
Subject: Re: radclient: no
I thought that the dialup.conf was linked to the 'nas' table . . . .
I've re-added it and it just brings up errors to do with the nas table
again, which i deleted and told not to look at with readclients.
radiusd -X debug:
linux-6pfg:/home/james # radiusd -X
FreeRADIUS Version 2.1.1, for host
Alan,
It worked after I put my user entry before DEFAULT Auth-Type == System.
Thanks for your help,
Elias
-Original Message-
From:
freeradius-users-bounces+elias.abou.zeid=ericsson@lists.freeradius.o
rg
[mailto:freeradius-users-bounces+elias.abou.zeid=ericsson@lists.free
JamesWhetherly wrote:
I thought that the dialup.conf was linked to the 'nas' table . . . .
No.
I've re-added it and it just brings up errors to do with the nas table
again, which i deleted and told not to look at with readclients.
Could you *please* stop breaking the configuration?
create nas table and leave it empty. add client in clients.conf
you have all you will need inside clients.conf... just delete comments and
enter your own IP address(es) and secret.
On Wed, Jun 17, 2009 at 3:19 PM, JamesWhetherly
jameswhethe...@hotmail.comwrote:
I thought that the
I thought that the dialup.conf was linked to the 'nas' table . . . .
I've re-added it and it just brings up errors to do with the nas table
again, which i deleted and told not to look at with readclients.
Don't delete things from sql.conf. Put back:
# Table to keep radius client info
Hi,
I am trying to authenticate ssh login using radius server running in another
linux machine.
I added a new user in /usr/local/etc/raddb/users of radius server.
Now when I do ssh to the radius client, the radius server denies request and
says 'Password doesn't match. But I gave right
So it looks like the radius client is not sending the password to radius
server if the user does not exist in local machine.
Yes, that's how PAM works. It can't authenticate users that don't exist
locally (think about it - if user/group is not defined locally what will
user be able to access on
Hi,
Just out for sake of completeness. On FreeRADIUS Version 1.1.7
I tried both User-Password == test and Cleartext-Password := test.
They both work fine when the user entry is before default setting in
users file.
Just to let you know.
Elias
-Original Message-
From:
On Wed, 17 Jun 2009, a.l.m.bu...@lboro.ac.uk wrote:
abcUser-Password == test
that is wrong. wrong and wrong
Okay, this isn't just my favorite quibbler jumping on me. So I have to
ask, even if there is a 'better' syntax, or a 'preferred' way of doing
things, why is this
Elias Abou Zeid wrote:
Just out for sake of completeness. On FreeRADIUS Version 1.1.7
I tried both User-Password == test and Cleartext-Password := test.
They both work fine when the user entry is before default setting in
users file.
Yes. Because *old* versions of the server accepted
Well, in debugging mode, it doesn't log anything to the file, but the
debug output shows it being rejected. When I am not running in debug,
I only get 'Login OK: [zdls02/p2182111] (from client allowed_clients
port 536936642)' logged by the radius server, I am logging my own
simultaneous use
Charles Gregory wrote:
Okay, this isn't just my favorite quibbler jumping on me. So I have to
ask, even if there is a 'better' syntax, or a 'preferred' way of doing
things, why is this 'standard' old radius check item so 'wrong'?
The '==' operator should be *comparing* attributes. There
Just out for sake of completeness. On FreeRADIUS Version 1.1.7
I tried both User-Password == test and Cleartext-Password := test.
They both work fine when the user entry is before default setting in
users file.
For a pap request. Try sending chap or mschap request and see what
happens.
On Wed, 17 Jun 2009, Elias Abou Zeid wrote:
Just out for sake of completeness. On FreeRADIUS Version 1.1.7
I tried both User-Password == test and Cleartext-Password := test.
They both work fine when the user entry is before default setting in
users file.
Just to let you know.
Elias
Thank you,
Well, in debugging mode, it doesn't log anything to the file, but the
debug output shows it being rejected. When I am not running in debug,
I only get 'Login OK: [zdls02/p2182111] (from client allowed_clients
port 536936642)' logged by the radius server, I am logging my own
simultaneous use
Thanks a lot Ivan for the clarification. I am feeling like working with you.
Do you mean the radius server can be only used for password authentication
in case of ssh/telnet? Can't we login using the centralized
username/password?
Regards,
Dhandapani
Ivan Kalik wrote:
So it looks like the
Do you mean the radius server can be only used for password authentication
in case of ssh/telnet?
Yes.
Can't we login using the centralized
username/password?
No, that can't work. Let's say that you were authenticated and reached the
shell as a nonexistant local user. How is he suposed to
preprocess returns ok for request 0
radius_xlat:
'/usr/local/var/log/radius/radacct/10.205.1.1/auth-detail-20090617'
rlm_detail:
/usr/local/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%
d expands to
/usr/local/var/log/radius/radacct/10.205.1.1/auth-detail-20090617
modcall[authorize
The authentication portion of the module returns ok, the session
portion returns reject, as it should.
On Wed, Jun 17, 2009 at 9:18 AM, Ivan Kalikt...@kalik.net wrote:
Well, in debugging mode, it doesn't log anything to the file, but the
debug output shows it being rejected. When I am not
James Devine wrote:
The authentication portion of the module returns ok, the session
portion returns reject, as it should.
No.
The session portion should return ok, and increment
request-simul_count. See rlm_radutmp for examples.
This is because users may be tracked in multiple places
Yes. Got it. Thanks Ivan.
Regards,
Dhandapani
Ivan Kalik wrote:
Do you mean the radius server can be only used for password
authentication
in case of ssh/telnet?
Yes.
Can't we login using the centralized
username/password?
No, that can't work. Let's say that you were
Hello Ivan.
Forcing Auth-Type in users file should work.
Thanks for this advice. I changed my users file to use MOTP as the
DEFAULT-Auth-Type (first entry of the users file).
/etc/freeradius/users
-
DEFAULT Auth-Type = MOTP
Exec-Program-Wait =
On Wed, 17 Jun 2009, Stefan Kuegler wrote:
/etc/freeradius/users
-
DEFAULT Auth-Type = MOTP
Exec-Program-Wait = /usr/local/bin/otpverify.sh '%{User-Name}'
'%{User-Password}' '%{Secret}' '%{PIN}' '%{Offset}',
Fall-Through = yes
user1
Hi,
I'm new to FreeRadius, and I'm having some hard time to put it to
work. Simply talking: I can authenticate from my linux (Suse 11.1)
using radtest, directly linked to the server (LAN). Here is the
answer:
protagoras:~ # radtest teste teste 192.168.10.113:1812 1812 testing123
Sending
I notice it matching multiple 'DEFAULT' entries in your 'users' file.
Make sure that one of them doesn't enforce an 'auth-type' other than
the one you want to use here.
- Charles
On Wed, 17 Jun 2009, Filipe Scalioni wrote:
I'm new to FreeRadius, and I'm having some hard time to put it
So, it works... But then I put the AP to work (Linksys wrt54g),
configured like this:
It nevers authenticates... No matter what I do. I tried everything I
could find on the list or FAQ before registering. Here goes the log
This is a very old version. You shouldn't be using 1.x with EAP for a
Ah yes, I was doing that wrong, that seems to work much better now. Thank you.
On Wed, Jun 17, 2009 at 10:28 AM, Alan DeKokal...@deployingradius.com wrote:
James Devine wrote:
The authentication portion of the module returns ok, the session
portion returns reject, as it should.
No.
49 matches
Mail list logo
