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