talking to eduroam federation

Phil Mayers p.mayers at imperial.ac.uk
Fri Jan 6 10:51:04 CET 2012


On 01/05/2012 09:24 PM, Rui Ribeiro wrote:
> Cheers,
>
> I´m in the testing phase of a freeradius for the EDUROAM federation;
local users are working ok authenticated against an AD, but when I proxy
for the federation, users loose attributes, like Service-Type =
"Framed-User", and is all zeros like "Message-Authenticator =

In the debug you show below, no Service-Type attribute is in the 
original packet. So it's not being lost - it's not there, at all.

0x00000000000000000000000000000000". Obviously the request is denied by
the federation, while a radtest works fine.

Message-Authenticator in outgoing packets always appears as all-zeros; 
it's only "filled in" when the server finally converts the packets to 
bytes. Ignore it, or use radsniff / tcpdump / wireshark to see the 
"real" value.

>
> In proxy.conf I have:
>
> realm DEFAULT {
> type = radius
> authhost = federation_server:1812
> accthost =federation_server:1813
> secret = xxxxxxxx
> nostrip
> }

A few eduroam-specific notes...

As Alan has suggested, you don't want to do it like that (or rather, we 
don't want you to!)

The "right" thing to do is:

  1. Define a realm "eduroam"
  2. Check the syntax of the username is valid
  3. If and only if it's valid and a non-local realm, manually set 
Proxy-To-Realm

e.g. like so:

authorize {
   # check for NAI format
   if (User-Name !~ /^([^@]*)@(.+)$/) {
     reject
   }
   # username is valid, set stripped & realm values
   update request {
     Stripped-User-Name := "%{1}"
     Realm := "%{toupper:%{2}}"
   }
   # check if it's your local realm
   if (Realm =~ /^(ISCTE\.PT|TEST\.ISCTE\.PT)$/) {

     # do normal local auth e.g.
     update control {
       Virtual-Server := eduroam-inner
     }
     eap

   }
   else {
     update control {
       Proxy-To-Realm := EDUROAM
     }
     # be friendly, tell sites who is calling
     update request {
       Operator-Name := YOUR.REALM.PT
     }
   }
}

...and the same for accounting. You can define a lot of this in 
policy.conf and re-use the "code".

> rad_recv: Access-Request packet from host 10.10.65.135 port 46611, id=93, length=184
> 	User-Name = "iscte at roam.fccn.pt"
> 	NAS-IP-Address = 10.10.65.135
> 	NAS-Port = 400
> 	Called-Station-Id = "00-0F-7D-39-2A-12:eduroam2"
> 	Calling-Station-Id = "60-C5-47-8B-FF-46"
> 	Framed-MTU = 1400
> 	NAS-Port-Type = Wireless-802.11
> 	Connect-Info = "CONNECT 13Mbps/6Mbps 802.11n"
> 	EAP-Message = 0x020f001701697363746540726f616d2e6663636e2e7074
> 	Message-Authenticator = 0x2012955096623bb33854fc25a46b8cde

> Sending Access-Request of id 4 to 193.136.192.43 port 1812
> 	User-Name = "iscte at roam.fccn.pt"
> 	NAS-IP-Address = 10.10.65.135
> 	NAS-Port = 400
> 	Called-Station-Id = "00-0F-7D-39-2A-12:eduroam2"
> 	Calling-Station-Id = "60-C5-47-8B-FF-46"
> 	Framed-MTU = 1400
> 	NAS-Port-Type = Wireless-802.11
> 	Connect-Info = "CONNECT 13Mbps/6Mbps 802.11n"
> 	EAP-Message = 0x020f001701697363746540726f616d2e6663636e2e7074
> 	Message-Authenticator = 0x00000000000000000000000000000000
> 	Proxy-State = 0x3933

As above: ignoring Message-Authenticator, these packets are identical. 
No attributes have been lost, so what's wrong?

> Thu Jan  5 21:14:12 2012 : Error: ASSERT FAILED event.c[1181]: "We do not have threads, but the request is marked as queued or running in a child thread" == NULL
> Aborted

This is a bug. Upgrade to 2.1.12



More information about the Freeradius-Users mailing list