Hi all, Currently when users connect to our WLAN they enter their username thus:- firstname.lastname@mydomain.ox.ac.uk Is there a way I can strip everything after the @ out (ie the domain) - so they are forced to authenticate against the domain I specify. At the moment in my test environment, as long as I DONT specify the domain it works - so I'm looking to strip out the domain name if they DO specify it. Cheers, Mark
Hi,
Hi all,
Currently when users connect to our WLAN they enter their username thus:- firstname.lastname@mydomain.ox.ac.uk
Is there a way I can strip everything after the @ out (ie the domain) - so they are forced to authenticate against the domain I specify.
At the moment in my test environment, as long as I DONT specify the domain it works - so I'm looking to strip out the domain name if they DO specify it.
deal with the realm and/or use stripped-user-name rather than rely on User-Name or MSCHAP:User-Name alan
On 12/10/10 16:06, Mark Holmes wrote:
Hi all,
Currently when users connect to our WLAN they enter their username thus:- firstname.lastname@mydomain.ox.ac.uk
Is there a way I can strip everything after the @ out (ie the domain) - so they are forced to authenticate against the domain I specify.
Sure, a couple of different ways: 1. Define "mydomain.ox.ac.uk" as a realm in proxy.conf, enable "strip", add the "suffix" module to authorize, update any config to try the Stripped-User-Name attribute first: authorize { ... strip } modules { mschap { ntlm_auth = "... username=%{%{Stripped-User-Name}:-%{mschap:User-Name}}" } } 2. Write an unlang expression: authorize { if (User-Name =~ /^(.*)@(.*)/) { update request { User-Name := "%{1}" Realm := "%{2}" } if (Realm !~ /mydomain\.ox\.ac\.uk/i) { # invalid reject } } } Which is "better" will depend on exactly what you're trying to do. I use the former, but mostly for historical reasons. The latter may be somewhat more flexible.
Hi,
authorize { if (User-Name =~ /^(.*)@(.*)/) { update request { User-Name := "%{1}" Realm := "%{2}" } if (Realm !~ /mydomain\.ox\.ac\.uk/i) { # invalid reject } } }
beware of blank outerid as per the RFC - ie @mydomain.ox.ac.uk is 100% legit. you need to ensure that the unlang and regex handles this.
Which is "better" will depend on exactly what you're trying to do. I use the former, but mostly for historical reasons. The latter may be somewhat more flexible.
I've moved to the latter because of the flexibility - especially if you have 3rd party realms to deal with that wont be sent off to a default external proxy farm. alan
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Currently when users connect to our WLAN they enter their username thus:- firstname.lastname@mydomain.ox.ac.uk
Is there a way I can strip everything after the @ out (ie the domain) - so they are forced to authenticate against the domain I specify.
Sure, a couple of different ways:
1. Define "mydomain.ox.ac.uk" as a realm in proxy.conf, enable "strip", add the "suffix" module to authorize, update any config to try the Stripped-User-Name attribute first:
authorize { ... strip }
modules { mschap { ntlm_auth = "... username=%{%{Stripped-User-Name}:-%{mschap:User-Name}}" } }
2. Write an unlang expression:
authorize { if (User-Name =~ /^(.*)@(.*)/) { update request { User-Name := "%{1}" Realm := "%{2}" } if (Realm !~ /mydomain\.ox\.ac\.uk/i) { # invalid reject } } }
3. slight spin on option 1... ---- authorize { suffix if (Realm == "DEFAULT") { reject } ... } ---- In your proxy.conf have something like: ---- realm NULL { } realm LOCAL { } realm soas.ac.uk { } realm DEFAULT { pool = eduroam nostrip } ---- One you are ready for roaming (if that is the direction you are going in) just comment out the reject for DEFAULT in authorize. Later you can do cunning things like add to proxy.conf: ---- # blackhole routing realm myabc.com { nostrip } realm "~\\.3gppnetwork\\.org$" { nostrip } ---- and then in authorize have: ---- # handle blackhole'd realms if (Realm != "NULL" && Realm != "DEFAULT" && Realm != "soas.ac.uk") { update reply { Reply-Message := "Realm Blackholed" } reject } ---- Cheers -- Alexander Clouter .sigmonster says: This Fortune Examined By INSPECTOR NO. 2-14
Thanks Phil. Final question: At the moment, I can authenticate with username, but not with username@mydomain.ox.ac.uk How do I tell freeradius to accept username@mydomain.ox.ac.uk (I don't mind if authenticating with just username without the domain fails) Thanks, Mark
On 13/10/10 11:55, Mark Holmes wrote:
Thanks Phil.
Final question: At the moment, I can authenticate with username, but not with username@mydomain.ox.ac.uk
How do I tell freeradius to accept username@mydomain.ox.ac.uk (I don't mind if authenticating with just username without the domain fails)
Sorry, I don't follow: isn't that just the same question you asked previously? FreeRadius itself doesn't care what the username is. The key is that the modules doing the authentication can recognise and authenticate that username. I believe from your earlier posts you are using "mschap" and the "ntlm_auth" helper? If you look in the default configs, the commented out (but suggested) config is: #ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{User-Name:-None}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" Note the use of the conditional expansion "Stripped-User-Name" Anyway, as always - if it's failing, please post the full debug output i.e.: radiusd -X | tee log ...so we can see why and help you. In all probability, you are passing the unstripped username a@b to "ntlm_auth" and it's choking on it.
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Anyway, as always - if it's failing, please post the full debug output i.e.:
radiusd -X | tee log
...I am pretty sure that is meant to be: radiusd -X 2>&1 | tee log I thought freeradius printed to STDERR? If not that probably should be fixed, in my honest opinion. :) Cheers -- Alexander Clouter .sigmonster says: Drive defensively. Buy a tank.
On 13/10/10 13:27, Alexander Clouter wrote:
Phil Mayers<p.mayers@imperial.ac.uk> wrote:
Anyway, as always - if it's failing, please post the full debug output i.e.:
radiusd -X | tee log
...I am pretty sure that is meant to be:
radiusd -X 2>&1 | tee log
I thought freeradius printed to STDERR?
Nope.
Mark Holmes <mark.holmes@nuffield.ox.ac.uk> wrote:
At the moment in my test environment, as long as I DONT specify the domain it works - so I'm looking to strip out the domain name if they DO specify it.
As a hint for the record, in production for 'eduroam, you must reject when there is no domain otherwise: a) your helpdesk get sloppy b) your users will be unable to roam Just advice from someone who already walked that path of pain a few years back. :) Cheers -- Alexander Clouter .sigmonster says: Tact, n.: The unsaid part of what you're thinking.
On Oct 12, 2010, at 10:29 AM, Alexander Clouter wrote:
Mark Holmes <mark.holmes@nuffield.ox.ac.uk> wrote:
At the moment in my test environment, as long as I DONT specify the domain it works - so I'm looking to strip out the domain name if they DO specify it.
As a hint for the record, in production for 'eduroam, you must reject when there is no domain otherwise: a) your helpdesk get sloppy b) your users will be unable to roam
Just advice from someone who already walked that path of pain a few years back. :)
Mmm same. Fond memories of the lines of students complaining that their internet had suddenly stopped working after we turned off automatic insertion of sussex.ac.uk when domain component was null. The documentation of course explicitly stated that the username must be user@domain, but since when do students read documentation... -Arran
Cheers
-- Alexander Clouter .sigmonster says: Tact, n.: The unsaid part of what you're thinking.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
Alan Buxey -
Alexander Clouter -
Arran Cudbard-Bell -
Mark Holmes -
Phil Mayers