Could you please share the perl scripts and the corresponding
configuration in radiusd.conf like authorize and post-auth section
related to these logs?
Unfortunately, I would need to get a release from my company as the code
belongs to them. I cannot post it at this time. You may want to
Thanks.
Could you please share the perl scripts and the corresponding
configuration in radiusd.conf like authorize and post-auth section
related to these logs?
Schilling
On Wed, Nov 10, 2010 at 10:04 PM, Garber, Neal
neal.gar...@iberdrolausa.com wrote:
Could you please summarize what you
Could you please summarize what you did to log the output from
ntlm_auth and MS_CHAP-Error?
Sure. I should mention that other options are available now that didn't exist
when I created the solution below...
I have a PERL script that runs during authorize that obtains user/group or
Hi,
Could you please summarize what you did to log the output from
ntlm_auth and MS_CHAP-Error? Even with configuration snippet will be
greatly appreciated!
Thanks,
Schilling
On Wed, Sep 8, 2010 at 5:02 PM, Garber, Neal
neal.gar...@iberdrolausa.com wrote:
Hmm... OK. The issue appears to be
Garber, Neal wrote:
You are a gentleman and a scholar! I have made the changes as you suggested
for PEAP and tested PEAP-MSCHAPv2. It works! I am now able to log the
output from ntlm_auth and MS-CHAP-Error. I'm also excited about the improved
TLS logging in 2.1.10.
:)
I will add
On Tue, 2010-09-07 at 22:26 +0200, Alan DeKok wrote:
John Horne wrote:
We have been running 3 servers with 2.1.10 (taken from git a while ago)
The proxy change went in August 4.
for some time with no problems. They act as a proxy, receiving requests
from wireless lan controllers and
John Horne wrote:
We don't have that exact scenario, but, for whatever reason, we were
seeing the home servers being marked dead/zombie extremely frequently -
usually every few minutes.
Network packet loss, etc. ...
With the later git version (dated 1 September in the changelog file) we
Uh... eapol-test supports TTLS. See the FreeRADIUS source:
src/tests/eap-ttls-*.conf
Ugh.. I should have checked the doc. I should be able to do the TTLS change
independently (i.e., you can ignore the post to the devel list related to
this). Thanks for enlightening me :-)
-
List
Garber, Neal wrote:
I just cloned and built the latest 2.1.10 to do some testing. I did a
PEAP-MSCHAPv2 authentication, with bad credentials, using eapol_test. What I
found seems to indicate the problem I was referring to still exists in 2.1.10
(probably because I wasn't clear enough in
Hmm... OK. The issue appears to be that the tunneled reply is saved
for Access-Accept, but not Access-Reject.
See accept_vps in rlm_eap_peap/*. Something similar needs to be
done for reject, and for TTLS.
You are a gentleman and a scholar! I have made the changes as you suggested
for PEAP
Sion wrote:
On Mon, Sep 6, 2010 at 12:54 PM, Alan DeKok al...@deployingradius.com wrote:
Sion wrote:
I've also tried outer.reply, but I'm still not seeing it show up in my logs.
sigh And the debug log says... ?
Just set use_tunneled_reply = yes
Alan DeKok.
-
List
On Tue, Sep 7, 2010 at 8:45 AM, Alan DeKok al...@deployingradius.com wrote:
Sion wrote:
On Mon, Sep 6, 2010 at 12:54 PM, Alan DeKok al...@deployingradius.com
wrote:
Sion wrote:
I've also tried outer.reply, but I'm still not seeing it show up in my
logs.
sigh And the debug log says... ?
--On Tuesday, September 07, 2010 14:11:42 +0100 Sion mle...@gmail.com
wrote:
On Tue, Sep 7, 2010 at 8:45 AM, Alan DeKok al...@deployingradius.com
wrote:
Sion wrote:
On Mon, Sep 6, 2010 at 12:54 PM, Alan DeKok al...@deployingradius.com
wrote:
Sion wrote:
I've also tried outer.reply, but
but it seems the next packet sent is a Challenge, not reject/accept.
Therefore the message does not persist until reject/accept time.
Hmm.. It seems I've heard that before:
http://lists.cistron.nl/pipermail/freeradius-users/2009-August/msg00326.html
-
List info/subscribe/unsubscribe? See
Garber, Neal wrote:
but it seems the next packet sent is a Challenge, not reject/accept.
Therefore the message does not persist until reject/accept time.
Hmm.. It seems I've heard that before:
http://lists.cistron.nl/pipermail/freeradius-users/2009-August/msg00326.html
Fixed in 2.1.9.
Fixed in 2.1.9.
Great (I guess missed that in the change log). Was the change to eliminate the
extra round trip? If so, would you accept a patch to set
Module-Failure-Message upon failure of ntlm_auth in rlm_mschap (as was
originally implemented in the fix for bug 398 in v1.1.4)?
Thanks
Garber, Neal wrote:
Fixed in 2.1.9.
Great (I guess missed that in the change log). Was the change to eliminate
the extra round trip?
IIRC, it was to remember replies better. When the inner tunnel
returns accept and the outer sends a challenge... remember the accept
for later.
If so,
On Tue, 2010-09-07 at 21:19 +0200, Alan DeKok wrote:
I'd like to get some feedback on the pre-release of 2.1.10, especially
the changes to the proxy code.
We have been running 3 servers with 2.1.10 (taken from git a while ago)
for some time with no problems. They act as a proxy, receiving
John Horne wrote:
We have been running 3 servers with 2.1.10 (taken from git a while ago)
The proxy change went in August 4.
for some time with no problems. They act as a proxy, receiving requests
from wireless lan controllers and (mostly) proxying them on to MS IAS.
Is there any
On Tue, 2010-09-07 at 22:26 +0200, Alan DeKok wrote:
John Horne wrote:
We have been running 3 servers with 2.1.10 (taken from git a while ago)
The proxy change went in August 4.
Ah. Our versions date back to June. I'll see about upgrading them to a
later 2.1.10 version. (Hopefully that
I'll take a look...
Thanks.
I'd like to get some feedback on the pre-release of 2.1.10,
especially the changes to the proxy code.
I'll download the latest 2.1.10 tomorrow; unfortunately, I won't have a chance
to test it until next week. Also, we don't use proxying, at the moment, but I
IIRC, it was to remember replies better. When the inner tunnel
returns accept and the outer sends a challenge... remember the
accept for later.
I just cloned and built the latest 2.1.10 to do some testing. I did a
PEAP-MSCHAPv2 authentication, with bad credentials, using eapol_test. What
On Fri, Sep 3, 2010 at 10:30 PM, Alan DeKok al...@deployingradius.com wrote:
Sion wrote:
This had actually crossed my mind but I had tried testing this in the
post-auth section as well.
What section should I do this in? Would something like this work?
update outer {
Sion wrote:
I've also tried outer.reply, but I'm still not seeing it show up in my logs.
sigh And the debug log says... ?
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Mon, Sep 6, 2010 at 12:54 PM, Alan DeKok al...@deployingradius.com wrote:
Sion wrote:
I've also tried outer.reply, but I'm still not seeing it show up in my logs.
sigh And the debug log says... ?
rad_recv: Access-Request packet from host 192.168.196.13 port 32768,
id=113, length=175
Sion wrote:
I've got freeradius 2.1.7 setup on a CentOS system working as an AAA
server for our WPA Enterprise based wireless network with clients
successfully authenticating using PEAP and TTLS. Now to my question,
I've configured linelog to log certain attributes but I also want it to
log
On Fri, Sep 3, 2010 at 11:47 AM, Alan DeKok al...@deployingradius.com wrote:
Sion wrote:
I've got freeradius 2.1.7 setup on a CentOS system working as an AAA
server for our WPA Enterprise based wireless network with clients
successfully authenticating using PEAP and TTLS. Now to my
Sion wrote:
That's what I thought, but it my linelog log it shows it being empty.
The MS-CHAP-Error is in the reply.
I've tried putting 'linelog' in the post-auth sections of both the
default and inner-tunnel virtual servers but no joy. Am I missing
something obvious here?
See the
On Fri, Sep 3, 2010 at 12:58 PM, Alan DeKok al...@deployingradius.com wrote:
Sion wrote:
That's what I thought, but it my linelog log it shows it being empty.
The MS-CHAP-Error is in the reply.
I've tried putting 'linelog' in the post-auth sections of both the
default and inner-tunnel
Sion wrote:
Still no luck I'm afraid. Here's the output of radiusd -X in case it helps:
Reading it helps.
The MS-CHAP-Error is in the inner-tunnel virtual server. You are
trying to log it in the default virtual server.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
On Fri, Sep 3, 2010 at 3:32 PM, Alan DeKok al...@deployingradius.com wrote:
Sion wrote:
Still no luck I'm afraid. Here's the output of radiusd -X in case it helps:
Reading it helps.
The MS-CHAP-Error is in the inner-tunnel virtual server. You are
trying to log it in the default virtual
Sion wrote:
That was one of the first things I did after reading the debug output
originally - I've got 'linelog' in the post-auth section of the
inner-tunnel in addition to the default virtual server.
The post-auth section of inner-tunnel isn't used, unfortunately.
If I take
linelog
On Fri, Sep 3, 2010 at 4:25 PM, Alan DeKok al...@deployingradius.com wrote:
Sion wrote:
That was one of the first things I did after reading the debug output
originally - I've got 'linelog' in the post-auth section of the
inner-tunnel in addition to the default virtual server.
The post-auth
Sion wrote:
This had actually crossed my mind but I had tried testing this in the
post-auth section as well.
What section should I do this in? Would something like this work?
update outer {
MS-CHAP-Error = %{reply:MS-CHAP-Error}
}
You need to refer to a *list*:
34 matches
Mail list logo
