RE: Logging ntlm authentication
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 look at the linelog module (depending upon what version of FR you are running). If you're not familiar with perl, that might be easier for you to implement. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 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 machine/container permissions for the NAS in question from XML files to determine whether the entity is authorized and it creates a Log-Data reply attribute containing all non-sensitive request attributes. This is then written to syslog during post-auth by another PERL script. Our help desk and others use a .Net application that I wrote to display/filter the data from the current or past log files in a grid control. The log contains specifics of the request, authorization and authentication results/messages and reply attributes. Does that answer your question? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Logging ntlm authentication
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 machine/container permissions for the NAS in question from XML files to determine whether the entity is authorized and it creates a Log-Data reply attribute containing all non-sensitive request attributes. This is then written to syslog during post-auth by another PERL script. Our help desk and others use a .Net application that I wrote to display/filter the data from the current or past log files in a grid control. The log contains specifics of the request, authorization and authentication results/messages and reply attributes. Does that answer your question? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 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 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 the code for TTLS now. Unfortunately, I don't have a way to test that as I don't believe eapol_test supports TTLS and we don't use it. I suppose someone else can test it once I upload the patch (which I will do after I make the TTLS changes). Thanks again Alan. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 the code for TTLS now. Unfortunately, I don't have a way to test that as I don't believe eapol_test supports TTLS and we don't use it. I suppose someone else can test it once I upload the patch (which I will do after I make the TTLS changes). Uh... eapol-test supports TTLS. See the FreeRADIUS source: src/tests/eap-ttls-*.conf Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 (mostly) proxying them on to MS IAS. Is there any particular change that you wanted feedback on? What happens when a home server is marked zombie / dead. Previously, if *one* request didn't get a response, the home server was marked zombie. If the proxy then received a response, the home server was marked alive. i.e. if a proxy was sending packets for realm A B to a home server, and the home server was responding only for realm A and not B... then the home server could be marked zombie / alive / zombie / alive in quick sequence. It now keeps track of recent replies. If the home server is responding for realm A, then it will always be marked alive, even if it's not responding for realm B. The home server is marked as zombie only when it receives *no* replies for a period of time. I hope that explanation makes sense... 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. With the later git version (dated 1 September in the changelog file) we are seeing much fewer changes of the home servers being marked dead/zombie. From your description above I suspect this is what you were aiming for. A simple count of messages in our (daily) log files shows: grep -c dead radius.log.1(yesterday, 24 hours) 416 grep -c Proxy: radius.log.1 1859 grep -c dead radius.log (today, 12 hours) 34 grep -c Proxy: radius.log 154 Unless we have had a sudden change in our home servers, and/or network, (we haven't) the numbers do indicate that the freeradius code is now less 'aggressive' in marking a home server dead/zombie. (Our numbers are still probably high compared to other sites; we are still investigating the cause of the problem.) John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 are seeing much fewer changes of the home servers being marked dead/zombie. From your description above I suspect this is what you were aiming for. A simple count of messages in our (daily) log files shows: Nice. Unless we have had a sudden change in our home servers, and/or network, (we haven't) the numbers do indicate that the freeradius code is now less 'aggressive' in marking a home server dead/zombie. That's good to hear, thanks. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Logging ntlm authentication
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 info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 describing the issue). OK. It seems that after ntlm_auth fails, it sends the EAP failure via an Access-Challenge. Then, after it receives the response in the next Access-Request, it sends Access-Reject. This is how it behaved prior to 2.1.9 also (this is what I meant by extra round trip in a previous post). The problem is that any information stored in an attribute, after the ntlm_auth failure, will not survive the subsequent Access-Challenge, Access-Request. I can post the debug output if you'd like to see it. Hmm... OK. The issue appears to be that the tunneled reply is saved for Access-Accept, but not Access-Reject. When I originally discovered this, I suggested storing the ntlm_auth output in the eap handler so it could be saved in Module-Failure-Message when the response to the EAP failure is received. Is there a better approach? If you tell me your preference, I'd be willing to create a patch.. See accept_vps in rlm_eap_peap/*. Something similar needs to be done for reject, and for TTLS. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Logging ntlm authentication
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 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 the code for TTLS now. Unfortunately, I don't have a way to test that as I don't believe eapol_test supports TTLS and we don't use it. I suppose someone else can test it once I upload the patch (which I will do after I make the TTLS changes). Thanks again Alan. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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... ?
Just set use_tunneled_reply = yes
That had already been set, this is my peap config:
peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = yes
proxy_tunneled_request_as_eap = yes
virtual_server = inner-tunnel
}
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
--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 I'm still not seeing it show up in
my logs.
sigh And the debug log says... ?
Just set use_tunneled_reply = yes
That had already been set, this is my peap config:
peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = yes
proxy_tunneled_request_as_eap = yes
virtual_server = inner-tunnel
}
Hi,
Something like the below should copy the messge to the outer tunnel, but
it seems the next packet sent is a Challenge, not reject/accept. Therefore
the message does not persist until reject/accept time.
authenticate {
Auth-Type MS-CHAP {
eduroamlocalmschap {
reject = 1
}
if (reject) {
update outer.reply {
MS-CHAP-Error := %{reply:MS-CHAP-Error}
}
reject = return
}
}
...
}
-James
--
James J J Hooper
University of Bristol
http://www.wireless.bristol.ac.uk
--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Logging ntlm authentication
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 http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Logging ntlm authentication
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 Alan. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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, 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)? I'll take a look... I'd like to get some feedback on the pre-release of 2.1.10, especially the changes to the proxy code. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 requests from wireless lan controllers and (mostly) proxying them on to MS IAS. Is there any particular change that you wanted feedback on? John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 particular change that you wanted feedback on? What happens when a home server is marked zombie / dead. Previously, if *one* request didn't get a response, the home server was marked zombie. If the proxy then received a response, the home server was marked alive. i.e. if a proxy was sending packets for realm A B to a home server, and the home server was responding only for realm A and not B... then the home server could be marked zombie / alive / zombie / alive in quick sequence. It now keeps track of recent replies. If the home server is responding for realm A, then it will always be marked alive, even if it's not responding for realm B. The home server is marked as zombie only when it receives *no* replies for a period of time. I hope that explanation makes sense... Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 will be tomorrow.) John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287Fax: +44 (0)1752 587001 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Logging ntlm authentication
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 will report any issues I find with other areas. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Logging ntlm authentication
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 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 describing the issue). It seems that after ntlm_auth fails, it sends the EAP failure via an Access-Challenge. Then, after it receives the response in the next Access-Request, it sends Access-Reject. This is how it behaved prior to 2.1.9 also (this is what I meant by extra round trip in a previous post). The problem is that any information stored in an attribute, after the ntlm_auth failure, will not survive the subsequent Access-Challenge, Access-Request. I can post the debug output if you'd like to see it. When I originally discovered this, I suggested storing the ntlm_auth output in the eap handler so it could be saved in Module-Failure-Message when the response to the EAP failure is received. Is there a better approach? If you tell me your preference, I'd be willing to create a patch.. Thanks for your time Alan. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 {
MS-CHAP-Error = %{reply:MS-CHAP-Error}
}
You need to refer to a *list*: outer.reply, or outer.control. See
man unlang, which has examples.
Thanks for the pointers, in the inner-tunnel virtual server I've
changed the 'eap' line in the authenticate section to the following:
Auth-Type EAP {
eap
update outer.control {
MS-CHAP-Error = %{reply:MS-CHAP-Error}
}
}
I've also tried outer.reply, but I'm still not seeing it show up in my logs.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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
Re: Logging ntlm authentication
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
User-Name = cc0086
Calling-Station-Id = 00-1B-77-94-57-72
Called-Station-Id = 00-0B-85-6D-BA-C0:eduroam
NAS-Port = 29
NAS-IP-Address = 192.168.196.13
NAS-Identifier = llwacA105
Airespace-Wlan-Id = 2
Service-Type = Framed-User
Framed-MTU = 1300
NAS-Port-Type = Wireless-802.11
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 115
EAP-Message = 0x0203000b01636330303836
Message-Authenticator = 0xfad76efcaaae1711153d00e8b66be682
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = cc0086, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] EAP packet type response id 3 length 11
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
++[unix] returns notfound
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No known good password found for the user.
Authentication may fail because of this.
++[pap] returns noop
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] EAP Identity
[eap] processing type tls
[tls] Initiate
[tls] Start returned 1
++[eap] returns handled
Sending Access-Challenge of id 113 to 192.168.196.13 port 32768
EAP-Message = 0x010400061920
Message-Authenticator = 0x
State = 0xcd901d8ccd9404e11d6b7c064faf8b1f
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host 192.168.196.13 port 32768,
id=114, length=297
User-Name = cc0086
Calling-Station-Id = 00-1B-77-94-57-72
Called-Station-Id = 00-0B-85-6D-BA-C0:eduroam
NAS-Port = 29
NAS-IP-Address = 192.168.196.13
NAS-Identifier = llwacA105
Airespace-Wlan-Id = 2
Service-Type = Framed-User
Framed-MTU = 1300
NAS-Port-Type = Wireless-802.11
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 115
EAP-Message =
0x02040073198000691603010064016003014c84aaed46f925dbf010684571f2a65f8665099d1535eb4dafd7b34ccf5c382c18002f00350005000ac013c014c009c00a0032003800130004011f000b000906636330303836000a0006000400170018000b00020100
State = 0xcd901d8ccd9404e11d6b7c064faf8b1f
Message-Authenticator = 0x723f90602e22add50d84204eb9c29fbb
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = cc0086, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] EAP packet type response id 4 length 115
[eap] Continuing tunnel setup.
++[eap] returns ok
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
TLS Length 105
[peap] Length Included
[peap] eaptls_verify returned 11
[peap] (other): before/accept initialization
[peap] TLS_accept: before/accept initialization
[peap] TLS 1.0 Handshake [length 0064], ClientHello
[peap] TLS_accept: SSLv3 read client hello A
[peap] TLS 1.0 Handshake [length 002a], ServerHello
[peap] TLS_accept: SSLv3 write server hello A
[peap] TLS 1.0 Handshake [length 06e5], Certificate
[peap] TLS_accept: SSLv3 write certificate A
[peap] TLS 1.0 Handshake [length 0004], ServerHelloDone
[peap] TLS_accept: SSLv3 write server done A
[peap] TLS_accept: SSLv3 flush data
[peap] TLS_accept: Need to read more data: SSLv3 read client certificate A
In SSL Handshake Phase
In SSL Accept mode
[peap] eaptls_process returned 13
[peap] EAPTLS_HANDLED
++[eap] returns handled
Sending Access-Challenge of id 114 to 192.168.196.13 port 32768
EAP-Message =
0x0105040019c00722160301002a022603014c84aaeabbefb79f979e0bc448a7508f277b89b07cd68280544ad5af8234c25d2f0016030106e50b0006e10006de0003c1308203bd30820326a0030201020210571735f114d0297747dec8e1dc855028300d06092a864886f70d01010505003081c4310b3009060355040613025a41311530130603550408130c5765737465726e204361706531123010060355040713094361706520546f776e311d301b060355040a131454686177746520436f6e73756c74696e6720636331283026060355040b131f43657274696669636174696f6e205365727669636573204469766973696f6e311930
EAP-Message =
Re: Logging ntlm authentication
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 either the Exec-Program output of ntlm_auth or the peap reply value for the MS-CHAP-Error attribute but so far I've been unsuccessful in doing this. Is this possible? if so can anybody give me any pointers? You can't log the ntlm_auth output. If it's important for you, write a shell script wrapper around the problem. For MS-CHAP-Error, it's just an attribute. You can log it, just like any other attribute. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 question,
I've configured linelog to log certain attributes but I also want it to
log either the Exec-Program output of ntlm_auth or the peap reply value
for the MS-CHAP-Error attribute but so far I've been unsuccessful in
doing this. Is this possible? if so can anybody give me any pointers?
You can't log the ntlm_auth output. If it's important for you, write
a shell script wrapper around the problem.
For MS-CHAP-Error, it's just an attribute. You can log it, just like
any other attribute.
That's what I thought, but it my linelog log it shows it being empty.
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?
If it helps, my linelog config is as follows
linelog {
filename = ${logdir}/linelog
format =
%S\t%{reply:Packet-Type}\t%{User-Name}\t%{Calling-Station-Id}\t%{Called-Station-Id}\t%{NAS-Identifier}\t%{Packet-Src-IP-Address}\t%{reply:Reply-Message}\t%{MS-CHAP-Error}\t%{reply:Tunnel-Type}
%{reply:Tunnel-Private-Group-Id}
}
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 Post-Auth-Type Reject block, too. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 virtual servers but no joy. Am I missing
something obvious here?
See the Post-Auth-Type Reject block, too.
Still no luck I'm afraid. Here's the output of radiusd -X in case it helps:
rad_recv: Access-Request packet from host 192.168.196.13 port 32768,
id=9, length=181
User-Name = anonymous
Calling-Station-Id = 00-1B-77-94-57-72
Called-Station-Id = 00-0B-85-6D-BA-C0:eduroam
NAS-Port = 29
NAS-IP-Address = 192.168.196.13
NAS-Identifier = llwacA105
Airespace-Wlan-Id = 2
Service-Type = Framed-User
Framed-MTU = 1300
NAS-Port-Type = Wireless-802.11
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 115
EAP-Message = 0x0205000e01616e6f6e796d6f7573
Message-Authenticator = 0xe0aee197f906702cbcedda8c6fce7ab1
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = anonymous, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] EAP packet type response id 5 length 14
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
++[unix] returns notfound
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No known good password found for the user.
Authentication may fail because of this.
++[pap] returns noop
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] EAP Identity
[eap] processing type tls
[tls] Initiate
[tls] Start returned 1
++[eap] returns handled
Sending Access-Challenge of id 9 to 192.168.196.13 port 32768
EAP-Message = 0x010600061920
Message-Authenticator = 0x
State = 0x70163a6b70102318926cb2671448dd5c
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host 192.168.196.13 port 32768,
id=10, length=312
User-Name = anonymous
Calling-Station-Id = 00-1B-77-94-57-72
Called-Station-Id = 00-0B-85-6D-BA-C0:eduroam
NAS-Port = 29
NAS-IP-Address = 192.168.196.13
NAS-Identifier = llwacA105
Airespace-Wlan-Id = 2
Service-Type = Framed-User
Framed-MTU = 1300
NAS-Port-Type = Wireless-802.11
Tunnel-Type:0 = VLAN
Tunnel-Medium-Type:0 = IEEE-802
Tunnel-Private-Group-Id:0 = 115
EAP-Message =
0x0206007f198000751603010070016c03014c80fc7750fabd6450dcb77c4605cbaab73a3c1e43bf175cfcee437c8275d0e118002f00350005000ac013c014c009c00a0032003800130004012b001700151264617573657268656c706465736b74657374000a0006000400170018000b00020100
State = 0x70163a6b70102318926cb2671448dd5c
Message-Authenticator = 0x1b3669861698384d471a2c44b8a9fda0
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = anonymous, looking up realm NULL
[suffix] No such realm NULL
++[suffix] returns noop
[eap] EAP packet type response id 6 length 127
[eap] Continuing tunnel setup.
++[eap] returns ok
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
TLS Length 117
[peap] Length Included
[peap] eaptls_verify returned 11
[peap] (other): before/accept initialization
[peap] TLS_accept: before/accept initialization
[peap] TLS 1.0 Handshake [length 0070], ClientHello
[peap] TLS_accept: SSLv3 read client hello A
[peap] TLS 1.0 Handshake [length 002a], ServerHello
[peap] TLS_accept: SSLv3 write server hello A
[peap] TLS 1.0 Handshake [length 06e5], Certificate
[peap] TLS_accept: SSLv3 write certificate A
[peap] TLS 1.0 Handshake [length 0004], ServerHelloDone
[peap] TLS_accept: SSLv3 write server done A
[peap] TLS_accept: SSLv3 flush data
[peap] TLS_accept: Need to read more data: SSLv3 read client certificate A
In SSL Handshake Phase
In SSL Accept mode
[peap] eaptls_process returned 13
[peap] EAPTLS_HANDLED
++[eap] returns handled
Sending Access-Challenge of id 10 to 192.168.196.13 port 32768
EAP-Message =
Re: Logging ntlm authentication
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 http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 server. 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. If I take linelog completely out of the default virtual server so that it's only defined in the post-auth of the inner-tunnel no log is generated at all. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 completely out of the default virtual server so that it's only defined in the post-auth of the inner-tunnel no log is generated at all. $ man unlang You can use the inner-tunnel config to update the outer attributes, and then log them in the outer virtual server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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 section of inner-tunnel isn't used, unfortunately.
Ahh ok, that explains it.
If I take
linelog completely out of the default virtual server so that it's only
defined in the post-auth of the inner-tunnel no log is generated at
all.
$ man unlang
You can use the inner-tunnel config to update the outer attributes,
and then log them in the outer virtual server.
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}
}
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Logging ntlm authentication
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*: outer.reply, or outer.control. See
man unlang, which has examples.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
