Hello all, i do have a problem with our freeradius configuration and i have no idea how to solve it. we do have one realm configured domainname.com which works perfectly. every user who wants to authenticate with a different realm is proxied to an outside radius. server. the setup works fine. we do have some mobile devices who send something like: username@company.com@wlan.mnc003.mc username@company.com@Verisign... . . we send these requests to our proxy and the proxy sends it back to us,.... from my understanding i cant solve it with a regex in the proxy.conf, right? since the "realm" is just the string after the last @? anyone has an idea how i can process such request in my company.com realm? inside the realm i strip everything out, so it should work then. any ideas?kind regards -euroreg
Hi,
we do have one realm configured domainname.com <http://domainname.com> which works perfectly. every user who wants to authenticate with a different realm is proxied to an outside radius. server. the setup works fine.
we do have some mobile devices who send something like: username@company.com <mailto:username@company.com>@wlan.mnc003.mc <http://wlan.mnc003.mc> username@company.com <mailto:username@company.com>@Verisign...
Ah. Nokia cell phones with Symbian by any chance? Recent firmwares behave less rude, but of course you may not have control over these clients.
we send these requests to our proxy and the proxy sends it back to us,....
from my understanding i cant solve it with a regex in the proxy.conf, right? since the "realm" is just the string after the last @?
A regex on the User-Name should do nicely. If it contains multiple @'s Auth-Type := Reject.
anyone has an idea how i can process such request in my company.com <http://company.com> realm? inside the realm i strip everything out, so it should work then.
Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Hi,
we do have one realm configured domainname.com which works perfectly. every user who wants to authenticate with a different realm is proxied to an outside radius. server. the setup works fine.
we do have some mobile devices who send something like: username@company.com@wlan.mnc003.mc username@company.com@Verisign...
as Stefan says - this looks suspiciously like Nokia Symbian clients. if the client hasnt been configured correctly it will send the CN of the certificate as the realm details...and other things - so you get that double realm issue... which might get to you via external proxy.. or might not. reject if you see more than one @ - or, if these are your people, find them and fix their client. (in case of Nokia, its ensure that the realm is specified rather than left to default setting. alan
problem is, that we are a university, so they are "our" people. tousands of students and teachers. if we deny those users, our helpdesk will get more work. is there a way to remove the double entries or do i have to block those? -euroreg On Wed, Oct 7, 2009 at 1:50 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
we do have one realm configured domainname.com which works perfectly. every user who wants to authenticate with a different realm is proxied to an outside radius. server. the setup works fine.
we do have some mobile devices who send something like: username@company.com@wlan.mnc003.mc username@company.com@Verisign...
as Stefan says - this looks suspiciously like Nokia Symbian clients. if the client hasnt been configured correctly it will send the CN of the certificate as the realm details...and other things - so you get that double realm issue... which might get to you via external proxy.. or might not.
reject if you see more than one @ - or, if these are your people, find them and fix their client. (in case of Nokia, its ensure that the realm is specified rather than left to default setting.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
problem is, that we are a university, so they are "our" people. tousands of students and teachers. if we deny those users, our helpdesk will get more work. is there a way to remove the double entries or do i have to block those?
Any chance we are talking about eduroam? In this case: doing something locally to make it work for these users even with misconfigured devices is *not* going to do any good, and you will have helpdesk trouble as soon as your users roam. The rationale being straightforward: you "fix" your local realm stripping, misconfigured clients are happy on your campus. Then they go to other hotspots without your magic fixes, and roaming will break. At some point they come back and whine, and you have to negotiate with the remote side logs to figure their weird settings prevented them from roaming. Then you still have to re-config the devices. Not to mention that it damages the eduroam brand, since these people will believe "roaming doesn't work". Contrary to that, changing one setting once on those few(I guess - not everyone on your campus uses Nokia cell phones, do they?) misconfigured clients will fix the issue permanently and globally. I'm shepherding about 10000 end-users myself on an eduroam IdP setup, and a HOWTO for Symbian which highlights neuralgic parts seems to work for me (at least I don't drown in user requests, and still have time to read and write freeradius-users :-) ). Greetings, Stefan Winter
-euroreg
On Wed, Oct 7, 2009 at 1:50 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk <mailto:A.L.M.Buxey@lboro.ac.uk>> wrote:
Hi,
> we do have one realm configured domainname.com <http://domainname.com> which works perfectly. every > user who wants to authenticate with a different realm is proxied to an > outside radius. server. the setup works fine. > > we do have some mobile devices who send something like: > username@company.com <mailto:username@company.com>@wlan.mnc003.mc <http://wlan.mnc003.mc> > username@company.com <mailto:username@company.com>@Verisign...
as Stefan says - this looks suspiciously like Nokia Symbian clients. if the client hasnt been configured correctly it will send the CN of the certificate as the realm details...and other things - so you get that double realm issue... which might get to you via external proxy.. or might not.
reject if you see more than one @ - or, if these are your people, find them and fix their client. (in case of Nokia, its ensure that the realm is specified rather than left to default setting.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
hey, yes we are talking about eduroam and after reading your post, it seems like that it is the best to deny such users. thanks alot -euroreg On Wed, Oct 7, 2009 at 2:44 PM, Stefan Winter <stefan.winter@restena.lu>wrote:
Hi,
problem is, that we are a university, so they are "our" people. tousands of students and teachers. if we deny those users, our helpdesk will get more work. is there a way to remove the double entries or do i have to block those?
Any chance we are talking about eduroam? In this case: doing something locally to make it work for these users even with misconfigured devices is *not* going to do any good, and you will have helpdesk trouble as soon as your users roam.
The rationale being straightforward: you "fix" your local realm stripping, misconfigured clients are happy on your campus. Then they go to other hotspots without your magic fixes, and roaming will break. At some point they come back and whine, and you have to negotiate with the remote side logs to figure their weird settings prevented them from roaming. Then you still have to re-config the devices.
Not to mention that it damages the eduroam brand, since these people will believe "roaming doesn't work".
Contrary to that, changing one setting once on those few(I guess - not everyone on your campus uses Nokia cell phones, do they?) misconfigured clients will fix the issue permanently and globally. I'm shepherding about 10000 end-users myself on an eduroam IdP setup, and a HOWTO for Symbian which highlights neuralgic parts seems to work for me (at least I don't drown in user requests, and still have time to read and write freeradius-users :-) ).
Greetings,
Stefan Winter
-euroreg
On Wed, Oct 7, 2009 at 1:50 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk <mailto:A.L.M.Buxey@lboro.ac.uk>> wrote:
Hi,
> we do have one realm configured domainname.com <http://domainname.com> which works perfectly. every > user who wants to authenticate with a different realm is proxied to an > outside radius. server. the setup works fine. > > we do have some mobile devices who send something like: > username@company.com <mailto:username@company.com>@wlan.mnc003.mc <http://wlan.mnc003.mc> > username@company.com <mailto:username@company.com>@Verisign...
as Stefan says - this looks suspiciously like Nokia Symbian clients. if the client hasnt been configured correctly it will send the CN of the certificate as the realm details...and other things - so you get that double realm issue... which might get to you via external
proxy..
or might not.
reject if you see more than one @ - or, if these are your people, find them and fix their client. (in case of Nokia, its ensure that
the
realm is specified rather than left to default setting.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg
Tel: +352 424409 1 Fax: +352 422473
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
where would be the best place to deny those users? we do not have alot of practice with freeradius, so any help would be appreciated, kind regards -euroreg On Wed, Oct 7, 2009 at 3:03 PM, mr typo <euroregistrar@gmail.com> wrote:
hey, yes we are talking about eduroam and after reading your post, it seems like that it is the best to deny such users.
thanks alot
-euroreg
On Wed, Oct 7, 2009 at 2:44 PM, Stefan Winter <stefan.winter@restena.lu>wrote:
Hi,
problem is, that we are a university, so they are "our" people. tousands of students and teachers. if we deny those users, our helpdesk will get more work. is there a way to remove the double entries or do i have to block those?
Any chance we are talking about eduroam? In this case: doing something locally to make it work for these users even with misconfigured devices is *not* going to do any good, and you will have helpdesk trouble as soon as your users roam.
The rationale being straightforward: you "fix" your local realm stripping, misconfigured clients are happy on your campus. Then they go to other hotspots without your magic fixes, and roaming will break. At some point they come back and whine, and you have to negotiate with the remote side logs to figure their weird settings prevented them from roaming. Then you still have to re-config the devices.
Not to mention that it damages the eduroam brand, since these people will believe "roaming doesn't work".
Contrary to that, changing one setting once on those few(I guess - not everyone on your campus uses Nokia cell phones, do they?) misconfigured clients will fix the issue permanently and globally. I'm shepherding about 10000 end-users myself on an eduroam IdP setup, and a HOWTO for Symbian which highlights neuralgic parts seems to work for me (at least I don't drown in user requests, and still have time to read and write freeradius-users :-) ).
Greetings,
Stefan Winter
-euroreg
On Wed, Oct 7, 2009 at 1:50 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk <mailto:A.L.M.Buxey@lboro.ac.uk>> wrote:
Hi,
> we do have one realm configured domainname.com <http://domainname.com> which works perfectly. every > user who wants to authenticate with a different realm is proxied to an > outside radius. server. the setup works fine. > > we do have some mobile devices who send something like: > username@company.com <mailto:username@company.com>@wlan.mnc003.mc <http://wlan.mnc003.mc
> username@company.com <mailto:username@company.com>@Verisign...
as Stefan says - this looks suspiciously like Nokia Symbian clients. if the client hasnt been configured correctly it will send the CN of the certificate as the realm details...and other things - so you get that double realm issue... which might get to you via external
proxy..
or might not.
reject if you see more than one @ - or, if these are your people, find them and fix their client. (in case of Nokia, its ensure that
the
realm is specified rather than left to default setting.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg
Tel: +352 424409 1 Fax: +352 422473
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, Since upgrading FR to 2.1.7 from 2.1.3 and 2.1.1 on our 2 servers there's been an issue with our proxy pool. There are three servers in the auth and acct pools, but unless I comment two of them out (as below) I receive a 'Request Denied' message back in response to the first access-request packet that is proxied to one of the auth servers. Is this a bug in 2.1.7, or is there a difference in configuration file format between the versions? # POOL Server config... pool_config { test_username = 'test-user@remote-realm.com' test_password = '***************' secret0 = '***************' secret1 = '***************' secret2 = '***************' } realm pool { nostrip auth_pool = pool_auth acct_pool = pool_acct } # Server Pools server_pool pool_auth { type = client-port-balance # home_server = pool0 home_server = pool1 # home_server = pool2 } server_pool pool_acct { type = client-port-balance # home_server = pool0 home_server = pool1 # home_server = pool2 } home_server pool0 { status_check = request username = ${pool_config.test_username} password = ${pool_config.test_password} ipaddr = server0.net secret = ${pool_config.secret0} port = 1812 type = auth+acct } home_server pool1 { status_check = request username = ${pool_config.test_username} password = ${pool_config.test_password} ipaddr = server1.net secret = ${pool_config.secret1} port = 1812 type = auth+acct } home_server pool2 { status_check = request username = ${pool_config.test_username} password = ${pool_config.test_password} ipaddr = server2.net secret = ${pool_config.secret2} port = 1812 type = auth+acct } Thanks, Jezz Palmer. ------------------------------------- Jezz Palmer Library & Information Services Swansea University Singleton Park Swansea SA2 8PP -------------------------------------
hi, there does seem to be an issue with 2.1.7 - I've had a couple of reports stating that the proxy doesnt seem to 'stick' to one remote proxy during EAP (eg with client-balance or client-ip-balance methods). not sure what has changed since 2.1.6 - but a rollback to 2.1.6 with exactly the same configuration works.... alan
hi,
there does seem to be an issue with 2.1.7 - I've had a couple of reports stating that the proxy doesnt seem to 'stick' to one remote proxy during EAP (eg with client-balance or client-ip-balance methods). not sure what has changed since 2.1.6 - but a rollback to 2.1.6 with exactly the same configuration works....
Thanks Alan & Alexander. It's Good to know, for once, that it's not my fault. :-D Cheers, Jezz.
Palmer J.D.F. <J.D.F.Palmer@swansea.ac.uk> wrote:
there does seem to be an issue with 2.1.7 - I've had a couple of reports stating that the proxy doesnt seem to 'stick' to one remote proxy during EAP (eg with client-balance or client-ip-balance methods). not sure what has changed since 2.1.6 - but a rollback to 2.1.6 with exactly the same configuration works....
It's Good to know, for once, that it's not my fault. :-D
I summary, just crank it to 'fail-over' or apply my patch and move to the much better keyed hashing method. Both approaches have their advantages and disadvantages, depending on which 'Alan' you are more fearful of. Mr RADIUS 'owns' your server(s) whilst Mr JRS might be beering buddies with people who can turn off your uplink :) Cheers -- Alexander Clouter .sigmonster says: * lilo hereby declares OPN a virtual pain in the ass :)
Alan Buxey wrote:
there does seem to be an issue with 2.1.7 - I've had a couple of reports stating that the proxy doesnt seem to 'stick' to one remote proxy during EAP (eg with client-balance or client-ip-balance methods). not sure what has changed since 2.1.6 - but a rollback to 2.1.6 with exactly the same configuration works....
2.1.7 is more aggressive about failing requests from one server to another when a home server goes down. See "no_response_fail" in proxy.conf. It's also more aggressive about *not* using zombie servers. It treats zombie servers as dead for new requests. i.e. it will retransmit the *same* request to a zombie server, but a *new* request will ignore the zombie server. That change was really made for stability. If a home server isn't responding, we shouldn't really be sending it new packets. Yes, this might break EAP. But if the home server isn't responding, it's not doing EAP already, right? Alan DeKok.
Hi, Just experienced a bit of strange behaviour, or at least seems strange to me. One of our FR 2.1.7 boxes has been proxying access-requests with a source port of 1815, to which the authenticating server has replied to with an access-accept on port 1815, only there is no listener for port 1815 running on the box and hence fails. This was happening to ~50% of requests, but once one failed the FR box was marking the authenticator dead. It started yesterday following a FR restart for a small config change (added a client to client.conf), I restarted it about an hour ago and it seems to be behaving now. Is that as odd as it seems, or am I missing something? Thanks, Jezz. ------------------------------------- Jezz Palmer Library & Information Services Swansea University Singleton Park Swansea SA2 8PP -------------------------------------
Palmer J.D.F. wrote:
One of our FR 2.1.7 boxes has been proxying access-requests with a source port of 1815, to which the authenticating server has replied to with an access-accept on port 1815, only there is no listener for port 1815 running on the box and hence fails. This was happening to ~50% of requests, but once one failed the FR box was marking the authenticator dead. It started yesterday following a FR restart for a small config change (added a client to client.conf), I restarted it about an hour ago and it seems to be behaving now.
Is that as odd as it seems, or am I missing something?
I think it's a bug in 2.1.7. We should be releasing 2.1.8 to address this, and to have other minor enhancements. Alan DeKok.
Ok, thanks Alan. :) Jezz.
Palmer J.D.F. wrote:
One of our FR 2.1.7 boxes has been proxying access-requests with a source port of 1815, to which the authenticating server has replied to with an access-accept on port 1815, only there is no listener for port 1815 running on the box and hence fails. This was happening to ~50% of requests, but once one failed the FR box was marking the authenticator dead. It started yesterday following a FR restart for a small config
change
(added a client to client.conf), I restarted it about an hour ago and it seems to be behaving now.
Is that as odd as it seems, or am I missing something?
I think it's a bug in 2.1.7. We should be releasing 2.1.8 to address this, and to have other minor enhancements.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Palmer J.D.F. <J.D.F.Palmer@swansea.ac.uk> wrote:
Since upgrading FR to 2.1.7 from 2.1.3 and 2.1.1 on our 2 servers there's been an issue with our proxy pool.
There are three servers in the auth and acct pools, but unless I comment two of them out (as below) I receive a 'Request Denied' message back in response to the first access-request packet that is proxied to one of the auth servers.
Is this a bug in 2.1.7, or is there a difference in configuration file format between the versions?
...I just made a posting FreeRADIUS dev that covers this. Cheers -- Alexander Clouter .sigmonster says: "If value corrupts then absolute value corrupts absolutely."
Palmer J.D.F. wrote:
There are three servers in the auth and acct pools, but unless I comment two of them out (as below) I receive a 'Request Denied' message back in response to the first access-request packet that is proxied to one of the auth servers.
? The only way that happens is if the proxy is using the wrong shared secret.
Is this a bug in 2.1.7, or is there a difference in configuration file format between the versions?
I've never tried that particular configuration. I would suggest using templates, instead. e.g. define a template, and then do: home_server foo { $template foo-template secret = testing123 } All of the "common" configuration can go into the template. Alan DeKok.
mr typo <euroregistrar@gmail.com> wrote:
i do have a problem with our freeradius configuration and i have no idea how to solve it.
we do have one realm configured domainname.com which works perfectly. every user who wants to authenticate with a different realm is proxied to an outside radius. server. the setup works fine.
we do have some mobile devices who send something like: username@company.com@wlan.mnc003.mc username@company.com@Verisign... . .
we send these requests to our proxy and the proxy sends it back to us,....
from my understanding i cant solve it with a regex in the proxy.conf, right? since the "realm" is just the string after the last @?
anyone has an idea how i can process such request in my company.com realm? inside the realm i strip everything out, so it should work then.
Use some unlang in 'authorize' *before* you call 'suffix' that looks like: ---- if (User-Name ~= /^(.*@company.com)@.*/) { User-Name := "%{1}" } ---- As a side note, I currently have in proxy.conf: ---- # blackhole routing realm myabc.com { virtual_server = auth-reject nostrip } realm "~\\.3gppnetwork\\.org$" { virtual_server = auth-reject nostrip } ---- ...and a virtual server: ---- server auth-reject { authorize { suffix switch "%{Realm}" { case "NULL" { update reply { Reply-Message := "No Realm" } } # we should not get here case "DEFAULT" { update reply { Reply-Message := "ERROR" } } # we *really* should not get here case "%{config:local.MY.realm}" { update reply { Reply-Message := "BIG ERROR" } } case { update reply { Reply-Message := "Realm Blackholed" } } } reject } } ---- I would recommend you reject straight away any double realmed users as you will only find yourself later on still having to deal with misconfigured kit; pain now means a *lot* less pain later down the road in my experience. Cheers -- Alexander Clouter .sigmonster says: This Fortune Examined By INSPECTOR NO. 2-14
i was trying to reject those "double" realm. but i cannot find the right syntax and/or where to put the lines. i was trying to put this lines in the user file: DEFAULT User-Name =~ "/^.*@company.com@.*/" Auth-Type := Reject that did not work. when putting: if (User-Name ~= /^.*@company.com@.*/) { reject } in the server configuration in authorize section, i get a strange error.. i am quite new with configuring freeradius, it would be nice if someone could give me some real hint how to and where reject those double @ @ thanks in advance. -euro On Wed, Oct 7, 2009 at 5:36 PM, Alexander Clouter <alex@digriz.org.uk>wrote:
mr typo <euroregistrar@gmail.com> wrote:
i do have a problem with our freeradius configuration and i have no idea
how
to solve it.
we do have one realm configured domainname.com which works perfectly. every user who wants to authenticate with a different realm is proxied to an outside radius. server. the setup works fine.
we do have some mobile devices who send something like: username@company.com@wlan.mnc003.mc username@company.com@Verisign... . .
we send these requests to our proxy and the proxy sends it back to us,....
from my understanding i cant solve it with a regex in the proxy.conf, right? since the "realm" is just the string after the last @?
anyone has an idea how i can process such request in my company.comrealm? inside the realm i strip everything out, so it should work then.
Use some unlang in 'authorize' *before* you call 'suffix' that looks like: ---- if (User-Name ~= /^(.*@company.com)@.*/) { User-Name := "%{1}" } ----
As a side note, I currently have in proxy.conf: ---- # blackhole routing realm myabc.com { virtual_server = auth-reject
nostrip } realm "~\\.3gppnetwork\\.org$" { virtual_server = auth-reject
nostrip } ----
...and a virtual server: ---- server auth-reject { authorize { suffix
switch "%{Realm}" { case "NULL" { update reply { Reply-Message := "No Realm" } }
# we should not get here case "DEFAULT" { update reply { Reply-Message := "ERROR" } }
# we *really* should not get here case "%{config:local.MY.realm}" { update reply { Reply-Message := "BIG ERROR" } }
case { update reply { Reply-Message := "Realm Blackholed" } } }
reject } } ----
I would recommend you reject straight away any double realmed users as you will only find yourself later on still having to deal with misconfigured kit; pain now means a *lot* less pain later down the road in my experience.
Cheers
-- Alexander Clouter .sigmonster says: This Fortune Examined By INSPECTOR NO. 2-14
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
mr typo <euroregistrar@gmail.com> wrote:
i was trying to reject those "double" realm. but i cannot find the right syntax and/or where to put the lines.
i was trying to put this lines in the user file: DEFAULT User-Name =~ "/^.*@company.com@.*/" Auth-Type := Reject
that did not work. when putting: if (User-Name ~= /^.*@company.com@.*/) { reject } in the server configuration in authorize section, i get a strange error..
i am quite new with configuring freeradius, it would be nice if someone could give me some real hint how to and where reject those double @ @
In addition to my blackholing I now have added to my policy.conf file: ---- # 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 } } ---- Then in your authorize section you just place 'validate_username' and it looks after everything for you. What the above bumpf does is: * permit realmless (usernames without an '@') through, these are rejected later by matching against the NULL realm (*important*) * if there is an '@' in there then it * reject's if there are two or more '@'s * reject if the *realm* is not valid, for example the realm *must* be made up of at least two parts, and the end part must be at least two characters long Hope that helps Cheers -- Alexander Clouter .sigmonster says: The best things in life are for a fee.
hello alexander, thanks alot for this piece of code. but now i have a problem with getting this to work. in radiusd.conf i have an $INCLUDE policy.conf and in my authorize section i got the following: authorize { auth_log validate_username suffix eap { ok = return } } upon restarting i get the following: /etc/raddb/sites-enabled/eduroam[9]: Failed to find module "validate_username". /etc/raddb/sites-enabled/eduroam[2]: Errors parsing authorize section. any hints? -euro On Tue, Oct 27, 2009 at 11:09 AM, Alexander Clouter <alex@digriz.org.uk>wrote:
mr typo <euroregistrar@gmail.com> wrote:
i was trying to reject those "double" realm. but i cannot find the right syntax and/or where to put the lines.
i was trying to put this lines in the user file: DEFAULT User-Name =~ "/^.*@company.com@.*/" Auth-Type := Reject
that did not work. when putting: if (User-Name ~= /^.*@company.com@.*/) { reject } in the server configuration in authorize section, i get a strange error..
i am quite new with configuring freeradius, it would be nice if someone could give me some real hint how to and where reject those double @ @
In addition to my blackholing I now have added to my policy.conf file: ---- # 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 } } ----
Then in your authorize section you just place 'validate_username' and it looks after everything for you.
What the above bumpf does is: * permit realmless (usernames without an '@') through, these are rejected later by matching against the NULL realm (*important*) * if there is an '@' in there then it * reject's if there are two or more '@'s * reject if the *realm* is not valid, for example the realm *must* be made up of at least two parts, and the end part must be at least two characters long
Hope that helps
Cheers
-- Alexander Clouter .sigmonster says: The best things in life are for a fee.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
/etc/raddb/sites-enabled/eduroam[9]: Failed to find module "validate_username". /etc/raddb/sites-enabled/eduroam[2]: Errors parsing authorize section.
hmm, interesting - this looks very much like a post i made here earlier this month where 3rd-party virtual servers dont seem to pick up details from main modules and include files - my case was that Autz-Type wasnt known if i called 'users' file in my virtual-server alan
when i put the "validate_username" direct after server eduroam { validate_username authorize { ..... i do not get an error. but it doesnt work. i am just trying around, i know that the "validate_username" doesnt make sense when NOT in the authorize section. so anyone has an idea redgarding the "failed to find module..." problem? thanks -euro On Tue, Oct 27, 2009 at 2:33 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Hi,
/etc/raddb/sites-enabled/eduroam[9]: Failed to find module "validate_username". /etc/raddb/sites-enabled/eduroam[2]: Errors parsing authorize section.
hmm, interesting - this looks very much like a post i made here earlier this month where 3rd-party virtual servers dont seem to pick up details from main modules and include files - my case was that Autz-Type wasnt known if i called 'users' file in my virtual-server
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
solved it now another way: authorize { auth_log suffix mschap eap { ok = return } if ( ("%{User-Name}" !~ /@/) || ("%{User-Name}" =~ /@.*@/)) { update reply { Reply-Message := "FHSCommon: Wrong Username" } reject } } maybe someone knows why the "failed to find module..." appears when using policy.conf kind regards -euro On Wed, Oct 28, 2009 at 9:31 AM, mr typo <euroregistrar@gmail.com> wrote:
when i put the "validate_username" direct after server eduroam { validate_username authorize { .....
i do not get an error. but it doesnt work. i am just trying around, i know that the "validate_username" doesnt make sense when NOT in the authorize section.
so anyone has an idea redgarding the "failed to find module..." problem?
thanks
-euro
On Tue, Oct 27, 2009 at 2:33 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk>wrote:
Hi,
/etc/raddb/sites-enabled/eduroam[9]: Failed to find module "validate_username". /etc/raddb/sites-enabled/eduroam[2]: Errors parsing authorize section.
hmm, interesting - this looks very much like a post i made here earlier this month where 3rd-party virtual servers dont seem to pick up details from main modules and include files - my case was that Autz-Type wasnt known if i called 'users' file in my virtual-server
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (6)
-
Alan Buxey -
Alan DeKok -
Alexander Clouter -
mr typo -
Palmer J.D.F. -
Stefan Winter