Routing new RFC7542-style realms
Sooo, I'm looking at how to configure FreeRADIUS to be able to handle RFC7542-style usernames (i.e. "realhome.realm!username@intermediate.realm"). At the same time, that same FreeRADIUS server must be able to handle the standard RFC4282 NAI, and authenticate NAIs that are local to it. The inner identity obviously remains the standard NAI for the real home realm, unless someone else has a better idea: Scenario 1: Outer = username@intermediate.realm. Authenticate locally at 'intermediate.realm'. Scenario 2: Outer = realhome.realm!username@intermediate.realm. Route on to 'realhome.realm'. Authenticate locally at 'realhome.realm'. Scenario 1 works just fine... But Scenario 2? I can define a prefix/suffix that works on the bang (!), so I can handle one or the other... But not both? Alan D, since RFC7542 is your baby, how do we do this? I'd love to know this. :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On Oct 2, 2016, at 7:32 AM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
I'm looking at how to configure FreeRADIUS to be able to handle RFC7542-style usernames (i.e. "realhome.realm!username@intermediate.realm").
Those were defined long before RFC 7542. It just tried to fix some long-standing issues.
At the same time, that same FreeRADIUS server must be able to handle the standard RFC4282 NAI, and authenticate NAIs that are local to it. The inner identity obviously remains the standard NAI for the real home realm, unless someone else has a better idea:
The inner user-name is always either unqualified ("bob'), or qualified with a local domain name.
Scenario 1: Outer = username@intermediate.realm. Authenticate locally at 'intermediate.realm'.
Yes.
Scenario 2: Outer = realhome.realm!username@intermediate.realm. Route on to 'realhome.realm'. Authenticate locally at 'realhome.realm'.
The key here is *who does this*. If you have "realm1!user@realm2", then the packet MUST be routed by third parties to "realm2". Because it is the domain name which appears after the "@". "realm2" then notices that the user portion is in a special format. A format which it understands. The AAA server for "realm2" can then decompose the "realm1!user" string into "realm1" and "user". And then re-compose it into "user@realm1". At which point the AAA server for "realm2" can forward the packet to "user@realm1".
Scenario 1 works just fine... But Scenario 2?
Magic... lots of magic. :)
I can define a prefix/suffix that works on the bang (!), so I can handle one or the other... But not both?
The existing "realm" module isn't smart enough to do this kind of double lookup. Though I suppose it shouldn't be too hard to add (hint hint). Just have it check for a realm, and if the realm is local, do *another* check for realm on the user portion. It can be done manually in "unlang". But it means replicating the logic in rlm_realm, and re-writing it unlang statements. Alan DeKok.
If you have "realm1!user@realm2", then the packet MUST be routed by third parties to "realm2". Because it is the domain name which appears after the "@".
Yep. That's all fine.
The existing "realm" module isn't smart enough to do this kind of double lookup. Though I suppose it shouldn't be too hard to add (hint hint). Just have it check for a realm, and if the realm is local, do *another* check for realm on the user portion.
It can be done manually in "unlang". But it means replicating the logic in rlm_realm, and re-writing it unlang statements.
OK, I simply rewrite the User-Name *before* calling suffix? Because if I do it after and then try to do something else like trying to get FR to proxy it, I get 'Request already has destination realm set. Ignoring' (at this point that's the realm to the right of the '@'). How do I reset that? :-/ I have this in my authorize (after suffix): if (&Stripped-User-Name ~= /[a-zA-Z0-9\-.]+)!(.+)/) { update request { User-Name := "%{2}@%{1}" Realm !* ANY } } But then... Because it previously identified this as a local realm, it then tries to do authentication locally... Any suggestions are helpful. :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On Oct 2, 2016, at 11:28 AM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
It can be done manually in "unlang". But it means replicating the logic in rlm_realm, and re-writing it unlang statements.
OK, I simply rewrite the User-Name *before* calling suffix?
No, I mean *all* of the logic has to be in unlang. Don't use the realm module at all. if (User-Name =~ /^([^@]+)@([^@]+)$/) { update request { Stripped-User-Name := "%{1}" Realm := "%{2}" } if (Realm == /my.realm.name) { # ... more checks on Stripped-User-Name... } update control { Proxy-To-Realm := &Realm } } Alan DeKok.
No, I mean *all* of the logic has to be in unlang. Don't use the realm module at all.
Ohhhhhhh, I see! Yeah, that can be done... Not quite ideal, but short of adding support for that format into rlm_realm, it'll do :-) Thanks again, Alan. As always, much appreciated! :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
No, I mean *all* of the logic has to be in unlang. Don't use the realm module at all.
Hmmm, to follow up on this... I've gotten it to route correctly, but on the ultimate destination (i.e. at "realhome.realm"), I now get a message saying that the EAP Identity does not match User-Name, which then subsequently leads to failure. It's not quite unexpected since EAP keeps track of what User-Name *should* be. Well, the final bit that I came up with (using suffix) was this: if (&User-Name =~ /([a-zA-Z0-9\-.]+)!(.+)/) { update control { Tmp-String-1 := "%{1}" Tmp-String-2 = &User-Name } if ("%{2}" =~ /([a-zA-Z0-9\-.]*)@(.+)/) { update request { User-Name := "%{1}@%{control:Tmp-String-1}" } } } suffix { updated = 1 noop = reject } if (&control:Tmp-String-2) { update request { User-Name := &control:Tmp-String-2 } update control { Tmp-String-1 !* ANY Tmp-String-2 !* ANY } } It works on both the sending as well as the receiving end. :-) With Regards Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Hi,
Hmmm, to follow up on this... I've gotten it to route correctly, but on the ultimate destination (i.e. at "realhome.realm"), I now get a message saying that the EAP Identity does not match User-Name, which then subsequently leads to failure. It's not quite unexpected since EAP keeps track of what User-Name *should* be.
expected - as you've messed with the User-Name - you need to keep the user-name the same, and just use unlang to make the proxy decision. the END host needs to receive the packet as is....and have the smarts to deal with it. alan
On Oct 2, 2016, at 2:55 PM, Stefan Paetow <Stefan.Paetow@JISC.AC.UK> wrote:
No, I mean *all* of the logic has to be in unlang. Don't use the realm module at all.
Hmmm, to follow up on this... I've gotten it to route correctly, but on the ultimate destination (i.e. at "realhome.realm"), I now get a message saying that the EAP Identity does not match User-Name, which then subsequently leads to failure. It's not quite unexpected since EAP keeps track of what User-Name *should* be.
Yes. The solution is to not mangle the User-Name. Which means that the home server *must* have the following logic: if Realm == "example.com" && Packet-Src-IP-Address == ip.for.example.com { look for "realm2|user@..." } I'll put this into my ongoing "RADIUS proxy issues" document. Alan DeKok.
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Stefan Paetow