I was just wondering if the bug from this post has been fixed since 1.1.6:
Re: EAP-TTLS outer identity accounting
After alot of experimenting researching, I still haven't found a solution
to the TTL anonymous outer identity being used for accounting.
I have set a DEFAULT entry that sets the
] On Behalf Of
Sam Schultz
Sent: Wednesday, March 14, 2007 7:14 PM
To: freeradius-users@lists.freeradius.org
Subject: Re: RE : EAP-TTLS outer identity accounting
An entry like:
DEFAULT Realm == test, Autz-Type := sql-test
User-Name = %{User-Name}
does add a new User
I have implement freeradius with LDAP + cisco VPDN my
problem
is my authentication working with PAP but when i try for
authentication
from CHAP it is not working error is password not clear text so
i have
read many document about it and ppl talking about store passwd
in
I can also vouch for freeradius 1.0.5 after building retro-fitting
my configuration to it. I'll probably just downgrade to an earlier
1.1.x build, since I haven't seen any major security
vulnerabilities/
fixes since the early 1.0.x builds.
On Tue, 20 Mar 2007 16:53:26 -0500 [EMAIL PROTECTED]
On Tue, 20 Mar 2007 09:38:25 -0500 Alan DeKok
[EMAIL PROTECTED] wrote:
Sam Schultz wrote:
I have set a DEFAULT entry that sets the User-Name attribute via
':=', but I still end up with two User-Name attributes
(anonymous
identity real identity). This is especially strange, since
After alot of experimenting researching, I still haven't found
a solution to the TTL anonymous outer identity being used for
accounting.
I have set a DEFAULT entry that sets the User-Name attribute via
':=', but I still end up with two User-Name attributes (anonymous
identity real identity).
On Thu, 15 Mar 2007 12:17:11 -0500 Chris Moody [EMAIL PROTECTED]
tech.net wrote:
Greetings all,
I am trying to create an RPM of Freeradius 1.1.5 for a Fedora Core
6
install, and following the instructions in the Wiki, the build
process
dies with this at the end:
c/include -Ilibeap -c
An entry like this in your 'users' file should work:
DEFAULT NASIPAddress =~ 192.168.100.*
Auth-Type := Reject
I'm not sure '*' is the appropriate regular expression character
for freeradius, but you should be able to verify that pretty quickly
from the documentation. Operator
DEFAULT check_items (ex: Realm == 'your_domain')
Autz-Type := your_ldap_instance (ex: ldap),
Auth-Type := module_instance_for_authentication
so i did what you recommended, which makes sense to do... i have
Autz-type := eap, and in debug mode i get this clearly an
you an option to specify this, all
would
be well. But... since they don't, I have to figure out how to
break
RADIUS for one subnet and yet allow it to function for the rest.
-Original Message-
From: Sam Schultz [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 12:46 PM
reference the initial thread where i said i was authenticating off
of
active directories, using eap-peap. which i had previously
working just
fine.
Since i didn't specify an instance name in my eap.conf, it is
referenced
as 'eap' (which i did read, but was following your advice).
Once you
On Thu, 15 Mar 2007 10:16:14 -0500 joe vieira [EMAIL PROTECTED]
wrote:
Hi all,
I'm using the RHEL build of freeradius 1.0.1. I'm trying to do
You really should upgrade that. If I recall correctly, there were
some nasty bugs in the early 1.0.x builds.
something that might seem totally
On Thu, 15 Mar 2007 10:51:17 -0500 Alan DeKok
[EMAIL PROTECTED] wrote:
Sam Schultz wrote:
An entry like:
DEFAULT Realm == test, Autz-Type := sql-test
User-Name = %{User-Name}
Please read man users for the definition and meaning of
operators.
You want:
DEFAULT
On Thu, 15 Mar 2007 10:57:29 -0500 joe vieira [EMAIL PROTECTED]
wrote:
Alan DeKok wrote:
joe vieira wrote:
i have eap-peap authentication working against our ad domain.
peachy
keen. what i would like to be able to do is, in our openldap
environment, store attributes for retrieval
On Tue, 13 Mar 2007 13:15:52 -0500 Alan DeKok
[EMAIL PROTECTED] wrote:
Sam Schultz wrote:
This should be solvable by adding something like
'User-Name = %{User-Name}' to the DEFAULT entries in the users
file,
correct?
Yes.
One of my users file DEFAULT entries look like this:
DEFAULT
On Wed, 14 Mar 2007 11:25:20 -0500 Thibault Le Meur
[EMAIL PROTECTED] wrote:
-Message d'origine-
De :
[EMAIL PROTECTED]
radius.org
[mailto:[EMAIL PROTECTED]
sts.freeradius.org] De la part de Sam Schultz
Envoyé : mercredi 14 mars 2007 17:13
À : freeradius-users
Sam Schultz
[EMAIL PROTECTED] wrote:
On Wed, 14 Mar 2007 11:25:20 -0500 Thibault Le Meur
[EMAIL PROTECTED] wrote:
-Message d'origine-
De :
[EMAIL PROTECTED]
radius.org
[mailto:[EMAIL PROTECTED]
sts.freeradius.org] De la part de Sam Schultz
Envoyé : mercredi 14 mars 2007 17:13
À
On Tue, 13 Mar 2007 11:58:51 -0500 Alan DeKok
[EMAIL PROTECTED] wrote:
Sam Schultz wrote:
I'm currently using EAP-TTLS PAP (via SecureW2) to authorize
authenticate wireless clients against specific realms. Users are
able to authorize authenticate properly, but the username in
incoming
I'm currently using EAP-TTLS PAP (via SecureW2) to authorize
authenticate wireless clients against specific realms. Users are
able to authorize authenticate properly, but the username in
incoming accounting replies come in as 'anonymous@realmname'.
I had this spitting out proper accounting
You could add an entry like User-Password == your_password_here
to a default entry in freeradius' users file (/etc/raddb/users,
usually), or do something similar using a group if you have some
user accounts that will need to have different passwords. In that
case, you'd need to use Group ==
According to my research, FreeRADIUS supposedly does work from
behind
an LVS load balancer. My current configuration works perfectly
outside of the LVS, but once it is put behind the LVS it ceases
to work. Connections seem to succeed even behind the LVS, until
they get to an access
According to my research, FreeRADIUS supposedly does work from
behind an LVS load balancer. My current configuration works
perfectly outside of the LVS, but once it is put behind the LVS it
ceases to work. Connections seem to succeed even behind the LVS,
until they get to an access
Unfortunately, it isn't possible to use direct routing on this
network. I was thinking there may be some way to coerce FR into
thinking the load balancer is another radius server sending over
proxied requests, or something like that.
Sam Schultz wrote:
From what little information I could
I've been trying to set up FR in a realm-based configuration using
only LOCAL realms that are passed to different MySQL tables via
different instances. This setup, like several previous questions
posted to this list for similar setups, requires conditional
branching. The solution as
24 matches
Mail list logo
