I seek your support and advice to resolve this incidence relating to the
Radius server used for authentification.
There is a user created on the Radius that is used by Netcool for the synch
with the SAM server.
The user authenticates successfully but there is failure of connection on
the JMS and
Dear all,
I have rebuild freeradius on debian 7.0. I have added rlm_raw and have a
working dynamic client configuration where I use Called_Station_ID to
authenticate / validate that a NAS is allowed to use this radius server.
I test using the following command on client A
echo
George Innocent wrote:
I seek your support and advice to resolve this incidence relating to the
Radius server used for authentification.
There is a user created on the Radius that is used by Netcool for the
synch with the SAM server.
The user authenticates successfully but there is
st...@comitcon.be wrote:
I have rebuild freeradius on debian 7.0. I have added rlm_raw and have a
working dynamic client configuration where I use Called_Station_ID to
authenticate / validate that a NAS is allowed to use this radius server.
That's not a recommended configuration.
I wait
Hi!
We're proxying auth requests to another RADIUS service and encounter the
following problem:
The password seems to get changed somewhere along the way.
In our case, a 9 character password arrives as 16 character garbage at the home
server, which then -of course- rejects the access request.
Are you sure the RADIUS secret is the right one?
On Wed, Oct 2, 2013 at 12:14 PM, JB list.freerad...@me.com wrote:
Hi!
We're proxying auth requests to another RADIUS service and encounter the
following problem:
The password seems to get changed somewhere along the way.
In our case, a 9
On 02/10/13 17:14, JB wrote:
Hi!
We're proxying auth requests to another RADIUS service and encounter the
following problem:
The password seems to get changed somewhere along the way.
In our case, a 9 character password arrives as 16 character garbage at the home
server, which then -of
Has anyone encountered a similar situation?
Yes, it's called getting the shared secret wrong between two of your servers.
To prove this, enable Message-Authenticator validation on the home server.
I believe recent versions of FreeRADIUS will include the Message-Authenticator
attribute by
Yes, we double checked the secret.
Am 02.10.2013 um 18:20 schrieb Francois Gaudreault fgaudrea...@cloudops.com:
Are you sure the RADIUS secret is the right one?
On Wed, Oct 2, 2013 at 12:14 PM, JB list.freerad...@me.com wrote:
Hi!
We're proxying auth requests to another RADIUS service
Dear Alan
see my comments below
st...@comitcon.be wrote:
I have rebuild freeradius on debian 7.0. I have added rlm_raw and have a
working dynamic client configuration where I use Called_Station_ID to
authenticate / validate that a NAS is allowed to use this radius server.
That's not a
On 02/10/13 17:30, JB wrote:
Yes, we double checked the secret.
Well, you missed something.
There is no other reasonable explanation for the behaviour you're
seeing. In *theory* it could be broken MD5 libraries at one end, but
that's so unlikely that the possibility can be discarded.
You
1. FreeRadius lacks the ability to actually run Nas's behind a link with a
dynamic IP. Although not recommended, this software does not support a
proper way of dealing with this.
Nonsense. This is a fundamental limitation of the RADIUS protocol.
If you want to use dynamic IPs, use a
For those interested:
Information gotten from
http://sourceforge.net/apps/trac/hotcakes/wiki/YfiTechDynamicClients
In regards to the usage of Called_Station_Id, rlm_raw and SQL checks.
Kind regards
Steve
1. FreeRadius lacks the ability to actually run Nas's behind a link with
a
dynamic
Alan
first of all thank you for replying although I must sense quite some
hostility in your replies. On the other hand, I have read previous emails
coming from your end and this appears to be the way you respond.
Secondly I have read the documentation, but RTFM still appears to be the
common way
I'm trying to do what might be an odd configuration.
I'm attempting to digest auth users without caring about their User-name
attribute.
So in other words I want to auth on the Digest-User-Name = testuser
that comes in as part of the Digest-Attributes and a password.
So in the users file I have
I changed all instances of the password testing123, to a random password on
both the StrongSwan server and the Radius server, and restarted the strongswan
and radiusd services. However, this broke the connection to authenticate to
the LDAP server, so I had to put it back to testing123 to get
Clint Petty wrote:
How can I change the radius default testing123 password? Is there a
command I need to run to do this?
Edit raddb/clients.conf. Look for testing123.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
st...@comitcon.be wrote:
For those interested:
Information gotten from
http://sourceforge.net/apps/trac/hotcakes/wiki/YfiTechDynamicClients
In regards to the usage of Called_Station_Id, rlm_raw and SQL checks.
Which notes that rlm_raw doesn't come with the server. The reason is
st...@comitcon.be wrote:
first of all thank you for replying although I must sense quite some
hostility in your replies. On the other hand, I have read previous emails
coming from your end and this appears to be the way you respond.
Perhaps you could read the *content* of my messages,
Philip Walenta wrote:
I'm trying to do what might be an odd configuration.
I'm attempting to digest auth users without caring about their
User-name attribute.
That should work.
So in other words I want to auth on the Digest-User-Name = testuser
that comes in as part of the
On 2 Oct 2013, at 19:06, st...@comitcon.be wrote:
Alan
first of all thank you for replying although I must sense quite some
hostility in your replies. On the other hand, I have read previous emails
coming from your end and this appears to be the way you respond.
Firstly, you ignored what
Hi Alan,
Thanks for your reply. However, I have already changed the instances of the
password testing123 in the following files:
StrongSwan:/etc/strongswan/strongswan.conf
Radius:/etc/raddb/proxy.conf
Radius:/etc/raddb/sites-available/dynamic-clients
Replied in between
st...@comitcon.be wrote:
first of all thank you for replying although I must sense quite some
hostility in your replies. On the other hand, I have read previous
emails
coming from your end and this appears to be the way you respond.
Perhaps you could read the *content*
On 2 Oct 2013, at 19:06, st...@comitcon.be wrote:
Alan
first of all thank you for replying although I must sense quite some
hostility in your replies. On the other hand, I have read previous
emails
coming from your end and this appears to be the way you respond.
Firstly, you ignored
Clint Petty wrote:
Hi Alan,
Thanks for your reply. However, I have already changed the instances of the
password testing123 in the following files:
StrongSwan:/etc/strongswan/strongswan.conf
That's good.
Radius:/etc/raddb/proxy.conf
That's not good. The secret there is for home
We are getting unexpected behavior from FreeRADIUS 2.2.x (built from current
git).
We want to check if a user is BLOCKED first, and only then do we want to
perform some other checks.
Our current config looks like this:
authorize {
#auth_log # uncomment for debugging
st...@comitcon.be wrote:
It is fairly clear that the experts claim they have the knowledge , but
are guarding it.
Ah, yes. That's why I've wrote tons of documentation for the server,
and have answered questions daily for 15 years. I'm trying to hide
RADIUS knowledge.
I am secondly not
Bruce Bauman wrote:
We want to stop executing the BUNCH OF UNLANG CODE in the first two
cases (infected and tempsus), effectively doing something like a return.
There is a return code. See doc/configurable_failover.rst:
ok {
ok = return
}
That may work. The issue is that
We want to stop executing the BUNCH OF UNLANG CODE in the first two cases
(infected and tempsus), effectively doing something like a return.
Where you have ok in the case stanzas, put
ok {
ok = return
}
-Arran
Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team
Hi Alan,
Ok, I just changed the StrongSwan:/etc/strongswan/strongswan.conf the
Radius:/etc/raddb/clients.conf files, and left the other files with reference
to testing123 alone. Restarted the strongswan radiusd services, and get
the same error from my iphone, VPN Connection - User
Hi,
A simple thing:
infected case
update control {
Tmp-String-0 := stop
}
...
if (Tmp-String-0 != stop) {
BUNCH OF UNLANG CODE
}
That should work. Ugly, but functional.
this is pretty much what I was
Hi,
Thanks for your reply. However, I have already changed the instances of the
password testing123 in the following files:
if you are dealing with a shared secret between a NAS and the FreeRADIUS
server, there are only
2 thigns to configure
1) the shared secret on the NAS - I would guess
Hi Alan,
Ok, I figured out why I wasn't able to change the testing123 password. I was
surrounding the new random password in quotes. Once I removed the quotes, it
worked.
Clint
-Original Message-
From: freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org
hi,
pretty definitive. incorrect shared secret - are you SURE that you havent got
any white spaces
etc lurking around? keep the shared secret in quotes if in doubt
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I would like to display the active Radius connections. When I run radwho I get
the following results (showing nothing but the titles) even though I know I
have an active connection:
# radwho
Login Name What TTY When FromLocation
#
-
List
On 2 Oct 2013, at 22:57, a.l.m.bu...@lboro.ac.uk wrote:
Hi,
A simple thing:
infected case
update control {
Tmp-String-0 := stop
}
...
if (Tmp-String-0 != stop) {
BUNCH OF UNLANG CODE
}
That should work. Ugly,
Alan,
That was actually the problem. I surrounded the new password in quotes, and
didn't like that. Once I removed the quotes, it worked!
Clint
-Original Message-
From: freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org
37 matches
Mail list logo
