Hi, Whilst trawling my logs to see what new interesting ways in which our userbase has gone and borked their workstations, I noticed that we are proxying realms upstream (to eduroam) that we should not be.....in this case it seems to be realms with spaces in them.
If anyone reads the guff I dump out onto this mailing list you might have stumbled onto a policy definition I use to catch completely broken realms: ---- # only needs to be close enough to catch unroutable guff validate_username { if (User-Name !~ /@/ \ || ( \ User-Name !~ /@.*@/ \ && User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/ \ ) \ ) { ok } else { update reply { Reply-Message := "Invalid User-Name Syntax" } reject } } ---- This pretty such deals with 'double' realms, and badly formed usernames (the NULL realm condition is blocked elsewhere). It is then used as so: ---- authorize { preprocess rewrite.called_station_id <---- sanitiser rewrite.calling_station_id <---- sanitiser rewrite.quirk.wlc <---- sanitiser validate_username suffix .... } ---- The sanitising entries to not touch the User-Name field at all. Now if I fake some of the cruft I see I get: ---- rad_recv: Access-Request packet from host 172.31.3.41 port 1645, id=85, length=242 User-Name = "dsadada...@globalsign Root CA" Service-Type = Framed-User Framed-MTU = 1500 Called-Station-Id = "00-19-30-78-60-A5" Calling-Station-Id = "00-12-3F-E5-55-3C" EAP-Message = 0x02010022016473616461646173646140476c6f62616c7369676e20526f6f74204341 Message-Authenticator = 0x1f4ef372e5c3cb6ab4c2354ac9ce36d0 Cisco-AVPair = "audit-session-id=AC1F04BD000019806FAB0F27" NAS-Port-Type = Ethernet NAS-Port = 50133 NAS-Port-Id = "FastEthernet1/0/33" NAS-IP-Address = 172.31.3.41 server dot1x { +- entering group authorize {...} ++[preprocess] returns ok ++- entering policy rewrite.called_station_id {...} [RFCise the Called-Station-ID] ++- policy rewrite.called_station_id returns ok ++- entering policy rewrite.calling_station_id {...} [RFCise the Calling-Station-ID] ++- policy rewrite.calling_station_id returns ok ++- entering policy rewrite.quirk.wlc {...} [RFCise the crap Cisco's WLC 4400 returns] ++- policy rewrite.quirk.wlc returns noop ++- entering policy validate_username {...} +++? if (User-Name !~ /@/ || ( User-Name !~ /@.*@/ && User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/ ) ) ? Evaluating (User-Name !~ /@/) -> FALSE ?? Evaluating (User-Name !~ /@.*@/) -> TRUE ?? Evaluating (User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/) -> TRUE +++? if (User-Name !~ /@/ || ( User-Name !~ /@.*@/ && User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/ ) ) -> TRUE +++- entering if (User-Name !~ /@/ || ( User-Name !~ /@.*@/ && User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/ ) ) {...} ++++[ok] returns ok +++- if (User-Name !~ /@/ || ( User-Name !~ /@.*@/ && User-Name =~ /^[[:graph:]]*@([-[:alnum:]]+\.)+[[:alpha:]]{2,}$/ ) ) returns ok +++ ... skipping else for request 103: Preceding "if" was taken ++- policy validate_username returns ok [suffix] Looking up realm "Globalsign Root CA" for User-Name = "dsadada...@globalsign Root CA" [suffix] Found realm "DEFAULT" [suffix] Adding Realm = "DEFAULT" [suffix] Proxying request from user dsadadasda to realm DEFAULT [suffix] Preparing to proxy authentication request to realm "DEFAULT" ++[suffix] returns updated ---- Okay, maybe my regex is bad...so I tested it: ---- a...@berk:~$ cat moo xwfmnc02qnabzlq9wi9...@globalsignrootca.test xwfmnc02qnabzlq9wi9...@globalsign Root CA wob...@example.com wib...@example.co.uk a...@berk:~$ grep '[[:graph:]...@\([-[:alnum:]]\+\.\)\+[[:alpha:]]\{2,\}' moo xwfmnc02qnabzlq9wi9...@globalsignrootca.test wob...@example.com wib...@example.co.uk ---- Any ideas? Bug? Feature? Cheers -- Alexander Clouter .sigmonster says: They're only trying to make me LOOK paranoid! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html