Re: talking to eduroam federation

6 Jan 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@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@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

Re: talking to eduroam federation

Phil Mayers