- Freeradius-Devel - lists.freeradius.org

Re: PEAP/MSCHAP doesn't run post-auth in inner-tunnel for reject?
by Phil Mayers 20 May '12

20 May '12

On 05/18/2012 10:23 PM, Alan DeKok wrote: > Phil Mayers wrote: >> Am I being dumb / getting something wrong or does the post-auth session >> not get called if PEAP/MSCHAP returns a reject? >> >> It seems to run for successful auths, but not failures. > > That is the case. > >> This is in the context of us not seeing log messages for EAP auth >> failures; I suspect that the client may just "hang up" and let the EAP >> session expire, and since the inner post-auth doesn't run, and the outer >> session expires, I have no logs. > > There was talk about getting it to do Post-Auth-Type Reject in the > inner tunnel. No code yet, tho. Ok, so after a bit (well, a lot) of digging, the cause seems to be that "Post-Auth-Type REJECT" is actually implemented in event.c:request_post_handler as opposed to auth.c:rad_authenticate - the latter handles successful post-auth, but the former rejects. The post handler doesn't seem to be called for the PEAP (and presumably TTLS) fake requests, but I gave up trying to track down which code path invokes request_post_handler - the socket or thread code? The comments in rad_authenticate initially suggested this is probably not the intention: /* * Result should be >= 0 here - if not, it means the user * is rejected, so we just process post-auth and return. */ if (result < 0) { return RLM_MODULE_REJECT; } ...and of course the code doesn't process post-auth, it just returns. But it looks like this changed here, so in fact it's just an out-of-date comment: https://github.com/alandekok/freeradius-server/commit/1b26bbb7576fabed84c47… What's the appropriate way to fix this? Presumably, if "rad_authenticate" doesn't call post-auth for reject, then ANY caller of rad_authenticate must take responsibility for doing so, but also somehow ensure that request_post_handler doesn't call it a 2nd time?

1 1

Compilation issues on freeradius-server v2.1.x for rlm_eap2
by JustinP 19 May '12

19 May '12

I am trying to configure EAP-FAST on freeradius-server v2.1.x Once I download the source. There is no issue if I do:- ./configure make make install But I get compilation issue on rlm_eap2 if I follow the below steps:- ./configure --with-experimental-modules --with-rlm_eap2 make Its giving error for not able to include header files. For some reason the include paths specified in CFLAGS and RLM_CFLAGS are not getting picked up. I am using 32 bit Ubuntu lucid Release 10.04 running on Intel Pentium 4. Is anybody else seeing this issue? Any help on this will be appreciated. -- View this message in context: http://freeradius.1045715.n5.nabble.com/Compilation-issues-on-freeradius-se… Sent from the FreeRadius - Dev mailing list archive at Nabble.com.

3 8

radclient and Message-Authenticator validation
by Jouni Malinen 07 May '12

07 May '12

It looks like the Message-Authenticator validation done by radclient for Disconnect-ACK/NAK and CoA-ACK/NAK messages does not match with the mechanism described in RFC 5176. Message-Authenticator is generated correctly for Disconnect-Request and CoA-Request, but I needed to modify rad_verify() to get this matching with the code I'm writing for hostapd. RFC 5176, 3.4: When a Message-Authenticator Attribute is included within a CoA- ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it is calculated as follows: Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) When the HMAC-MD5 message integrity check is calculated, the Message-Authenticator Attribute MUST be considered to be sixteen octets of zero. The Request Authenticator is taken from the corresponding CoA/Disconnect-Request. The Message-Authenticator is calculated and inserted in the packet before the Response Authenticator is calculated. It is that "The Request Authenticator is taken from the corresponding CoA/Disconnect-Request" part that does not seem to be followed by the current rad_verify() implementation. It clears the Authenticator field to all zeros (which is the mechanism used for the Request message) instead of using the Authenticator field from the Request message when validating the ACK/NAK message. Is this a workaround for some deployed NAS implementations or can this be fixed to match with RFC 5176? The following change was enough to make this interoperate with my hostapd implementation. diff --git a/src/lib/radius.c b/src/lib/radius.c index 7025573..dec3849 100644 --- a/src/lib/radius.c +++ b/src/lib/radius.c @@ -2619,11 +2619,7 @@ int rad_verify(RADIUS_PACKET *packet, RADIUS_PACKET *original, case PW_ACCOUNTING_REQUEST: case PW_DISCONNECT_REQUEST: - case PW_DISCONNECT_ACK: - case PW_DISCONNECT_NAK: case PW_COA_REQUEST: - case PW_COA_ACK: - case PW_COA_NAK: memset(packet->data + 4, 0, AUTH_VECTOR_LEN); break; @@ -2631,6 +2627,10 @@ int rad_verify(RADIUS_PACKET *packet, RADIUS_PACKET *original, case PW_AUTHENTICATION_ACK: case PW_AUTHENTICATION_REJECT: case PW_ACCESS_CHALLENGE: + case PW_DISCONNECT_ACK: + case PW_DISCONNECT_NAK: + case PW_COA_ACK: + case PW_COA_NAK: if (!original) { fr_strerror_printf("ERROR: Cannot validate Message-Authenticator in response packet without a request packet."); return -1; -- Jouni Malinen PGP id EFC895FA

3 2

slow recovery from SIGHUP
by Bruce Bauman 07 May '12

07 May '12

We are running freeradius 2.1.10 in a moderately busy environment. We send our server a SIGHUP daily to rotate our logfiles. The server seems to sometimes take > 15 minutes to recover from the SIGHUP and start responding to requests again. Our monitoring software then generates alerts because it thinks the server is dead. I quickly perused the code and nothing obvious jumped out at me. Any suggestions as to how to "fix" this? Thanks. -- Bruce

3 2

FR Developer for hire: Adding Accounting support to the rlm_ldap module?
by Peter Lambrechtsen 04 May '12

04 May '12

Hello I was wanting to know if someone would be interested in being paid to add "accounting" support into the RLM_LDAP module. For this I am wanting when calling the ldap module during the "accounting" section so it can update/delete records in the LDAP directory based on the Acct-Status-Type and using a new field type into the ldap.attrmap. Ideally I would be looking for when you get an accounting Start it adds or updates an attribute, for an Interim-Update also add/update and for a Stop then removes the attribute. In the ldap.attrmap the following ItemType should be extended to support both accounting start / interim update and stop verbs over and above the current checkItem/replyItem. checkItem NAS-IP-Address radiusNASIpAddress replyItem Framed-IP-Address radiusIpAddress acctStartItem NAS-Port-Id radiusNASPortId acctIntUpdItem NAS-Port-Id radiusNASPortId acctStopItem NAS-Port-Id radiusNASPortId This would mean that when an accounting start packet came through the same LDAP Filter lookup used for the authenticate & authorize would be done for the customer record and query for the acctStartItem attributes if the accounting request had the matching VSA then the LDAP Module would do a LDAP replace attribute or if the attribute didn't exist do a ldap add attribute. The same applies for an Interim-Update and subsequently for a stop packet remove the attribute from the directory if it exists. The wrinkle with LDAP is you can't always do a LDAP add, you need to use replace if the attribute exists. I've written this in Perl and it works reasonably well but it would be ideal to have this working inside ldap as then the custom perl code I wrote wouldn't be needed. Below is the perl i've written. my $ldap = Net::LDAP->new ( "127.0.0.1" ) or die "$@"; my $mesg = $ldap->bind ( "cn=admin,o=admin", password => "password", version => 3 ); my $attrs = [ 'radiusNASPortId' ]; my $result = $ldap->search ( base => "o=Identities", scope => "sub", filter => "(radiusRemoteID=$RAD_REQUEST{'ADSL-Agent-Remote-Id'})", attrs => $attrs ); my $attrcount = $result->count; if ($result->count > 0) { my @entries = $result->entries; my $userdn = @entries[0]->dn; my $sessionfound = @entries[0]->exists('radiusNASPortId'); if ( $RAD_REQUEST{'Acct-Status-Type'} =~ "Start" ) { if ( @entries[0]->exists('radiusNASPortId') ) { my $newresult = $ldap->modify($userdn , replace => { 'radiusNASPortId' => "$RAD_REQUEST{'NAS-Port-Id'}" } ); } else { my $newresult = $ldap->modify($userdn , add => { 'radiusNASPortId' => "$RAD_REQUEST{'NAS-Port-Id'}" } ); } } if ( $RAD_REQUEST{'Acct-Status-Type'} =~ "Stop" ) { if ( @entries[0]->exists('radiusNASPortId') ) { my $newresult = $ldap->modify($userdn , delete => { 'radiusNASPortId' => [] } ); } } } To get someone who is familiar with the freeradius code base and can write code which would be acceptable to be committed back into the mainline FR codebase as this should be code contributed back to the community. How much development effort would be required (x days?) and who would be interested in being paid (and how much) to do the work? Feel free to email me directly off list if you're interested. Cheers Peter

7 8

Re: LDAP module
by Alan Buxey 04 May '12

04 May '12

I'd contact the Novell guys I seem to recall who wrote/submitted that code asking for thev required work to be done...discussion on this list is fine but contributers may not be reading it.... alan

3 2

LDAP module
by Alan DeKok 04 May '12

04 May '12

I'm taking a look at the LDAP module. It's rather more complicated than I like. I'm thinking of moving it to use the new connection pools. I have a first draft which uses the connection pool to open the sockets. But... the behavior of the module is hard to understand. I'll start off with my thoughts: 1) connection pool is working. They don't *do* anything, but they connect 2) authentication. The "bind as user" code is simple. But what's with the "perform_search" and "filter" stuff? Why not use have a statically configured user DN? I'd like to avoid some of the complexity of the current code. So is the user DN really some arbitrarily changing value? Do you really have to search over the entire DB for "uid=username" in order to find the user? Alan DeKok.

6 7

small patch for detail.log module (2.x or 3.x)
by alan buxey 02 May '12

02 May '12

hi, small patch for the detail.log in freeRADIUS - this aligns it with the detail module - and ensures that people with IPv6 clients get their directories/files sorted properly rather than all stuff from IPv6 clients going into the same single files --- detail.log 2012-02-27 13:54:12.000000000 +0000 +++ /tmp/detail.log 2012-05-02 10:17:24.000000000 +0100 @@ -15,7 +15,7 @@ # in the 'authorize' section, below. # detail auth_log { - detailfile = ${radacctdir}/%{Client-IP-Address}/auth-detail-%Y%m%d + detailfile = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d # # This MUST be 0600, otherwise anyone can read @@ -37,7 +37,7 @@ # in the 'post-auth' section, below. # detail reply_log { - detailfile = ${radacctdir}/%{Client-IP-Address}/reply-detail-%Y%m%d + detailfile = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d detailperm = 0600 } @@ -49,7 +49,7 @@ # in the 'pre-proxy' section, below. # detail pre_proxy_log { - detailfile = ${radacctdir}/%{Client-IP-Address}/pre-proxy-detail-%Y%m%d + detailfile = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/pre-proxy-detail-%Y%m%d # # This MUST be 0600, otherwise anyone can read @@ -69,7 +69,7 @@ # in the 'post-proxy' section, below. # detail post_proxy_log { - detailfile = ${radacctdir}/%{Client-IP-Address}/post-proxy-detail-%Y%m%d + detailfile = ${radacctdir}/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/post-proxy-detail-%Y%m%d detailperm = 0600 } alan

1 0

Apache2 mod-auth-radius - include client IP address
by Matthew Newton 01 May '12

01 May '12

Hi, Not sure if this is the correct list - if not, apologies. I've set up mod_auth_radius, which is working great, but it doesn't include the user's IP address in the radius query. It would be nice to be able to check against this in certain circumstances. Of course, proxies and other things can mess with this, so it can't always be trusted for authorization purposes, but on corporate LANs where the network is known it should be safe to use, and is always good to log. The following mini patch adds the Calling-Station-Id attribute to the RADIUS request, with apache's remote_ip as the value. Cheers, Matthew >From 08cbb6eb5df3246c602fbce54c61ae3f124ca415 Mon Sep 17 00:00:00 2001 From: Matthew Newton <mcn4(a)leicester.ac.uk> Date: Tue, 1 May 2012 15:08:52 +0100 Subject: [PATCH] add calling-station-id = client ip to radius request --- mod_auth_radius-2.0.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/mod_auth_radius-2.0.c b/mod_auth_radius-2.0.c index 8b659f4..08671ef 100644 --- a/mod_auth_radius-2.0.c +++ b/mod_auth_radius-2.0.c @@ -348,6 +348,7 @@ typedef struct radius_packet_t { #define RADIUS_REPLY_MESSAGE 18 #define RADIUS_STATE 24 #define RADIUS_SESSION_TIMEOUT 27 +#define RADIUS_CALLING_STATION_ID 31 #define RADIUS_NAS_IDENTIFIER 32 /* service types : authenticate only for now */ @@ -883,6 +884,10 @@ radius_authenticate(request_rec *r, radius_server_config_rec *scr, /* ************************************************************ */ + /* add client IP address */ + add_attribute(packet, RADIUS_CALLING_STATION_ID, r->connection->remote_ip, strlen(r->connection->remote_ip)); + + /* ************************************************************ */ /* add state, if requested */ if (state != NULL) { add_attribute(packet, RADIUS_STATE, state, strlen(state)); -- 1.7.2.5 -- Matthew Newton, Ph.D. <mcn4(a)le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp(a)le.ac.uk>

1 0

packet dump module for debugging
by Matthew Newton 24 Apr '12

24 Apr '12

Hi, I was wondering a while ago exactly what AVPs were going through freeradius at a particular point, and it wasn't easy (that I could find) to just dump the lot out - detail or linelog will write certain AVPs, but not everything that's currently known. Maybe there's a way to do it, but I missed it :) So I hacked up a really quick module to do it. Whenever it's called in the server, it just dumps out all pairs in request, reply, control, and proxy lists as well if available. Made it much easier for me to see what state the packet was in at a particular point. Not submitting this necessarily for inclusion in the main tree, but just thought I'd tidy it up and push it out in case it's of any use to anyone else. https://github.com/mcnewton/freeradius-server/tree/rlm_debugpacket Example - include 'debugpacket' in post-auth, you might get debug output containing something like the following (obviously, you can call it as many times as you like, but after a couple or so it gets a bit confusing!): ... (0) debugpacket : ---------------------------------------------------- PACKET DEBUG -----v-v-v-v-v (0) debugpacket : Request: User-Name = "bob" User-Password = "Test" NAS-IP-Address = 127.0.0.1 NAS-Port = 0 Message-Authenticator = 0x57c4fc026b2c741303aa0931f21b81f1 (0) debugpacket : Reply: Reply-Message = "Hi, come on in." (0) debugpacket : Control: Cleartext-Password := "Test" Auth-Type = PAP (0) debugpacket : -----------------------------------------------------------------------^-^-^-^-^ (0) [debugpacket] = noop ... I'm fully expecting there to already exist a better way - in which case I'd be pleased to be informed :) Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4(a)le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp(a)le.ac.uk>

3 2