RE: Generating timing stats for ntlm_auth
Phil wrote: I could wrap ntlm_auth in a script that times it and lots the info, but I'm slightly wary of that - it might perturb the timings. Any obvious/easy thing I'm missing? You might be able to run FR under gdb (or attach/resume a running FR), and set breakpoints with commands that resume after running the GDB commands. Google gdb breakpoint commands Note sure how that would impact the overall timing. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Version 3.0.0 has been released
Neal wrote: When I click on it I get a 404 error.. Upgrading instructions are available here: https://github.com/FreeRADIUS/freeradius- server/blob/release_branch_3.0.0/raddb/README.rst That link would have changed when the release was officially renamed from release_branch_3.0.0 to v3.0.x, so use: https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/README.rst Basically it is just a link into a web view of the git repository, so you could also just pull the source and you'd have it. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Version 3.0.0 has been released
Congratulations Alan, Arran for pushing this out of the nest, all the while being so attentive on the mailing list, along with Phil and the other Alan :-) You guys are truly obsessed. I get exhausted just reading your commit logs. :-) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP + SSL + Certificate chains
Trevor Jennings wrote: We are using freeradius with EAP/SSL and although it is working fine, I was wondering if there was a way to prevent the user from getting the prompt to accept the certificate? I have combined the intermediate and server certificates to one file and used that file in the 'certificate_file' config in eap.conf. On OSX, the certificates are marked as valid, including the root, intermediate and server, but still prompts the user to accept. Is there a way around this? About the only way I can think of is to install a profile (.mobileconfig) which pre-approves the use of that certificate authority. Reason being, if you just accept any old certificate authority any compromised certificate will work, and on newer OSX/iOS the only way to check the certificate subject for the name of your RADIUS server. which is a better option for patching the hole, is to install a profile, anyway. So really, this means without prompting the user, any stolen key for any unrevoked certificate from any CA in that entire list, worldwide, could be used to launch a MITM attack and steal passwords or other data. This is not a particularly difficult object to get your hands on. (Incidentally this is why many environments do not like having Android devices on their wireless LANs since they don't have any such native options accessible from the UI or even a decent way to distribute profiles. Heck they don't even fake it by making the first certificate they see sticky. The first time warez to perform an MITM on WPA2-Enterprise is packaged in a way that any old script kiddie can use, there will be pain.) -- Brian Julin Network Administrator Clark University - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP + SSL + Certificate chains
Mathieu wrote: At least from that side there is hope for improvements with Android 4.3 onwards there are API calls for enterprise wireless configuration. Maybe someone steps up by making an application that can manage profiles or something like this. That is promising, but I hope this does not become a case of Oh, there's an app for that basic system function versus it being in the core UI. Because nobody will have it pre-installed. -- Brian - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
(was) RE: how to limit the repeating ldap lookups
Arran wrote: and wow did they get rid of the 802.1X profile configuration GUI interface in OSX 10.8? That sucks. If you think that sucks, wait till you see the horrible things you have to do to generate a .mobileconfig without access to an OSX server license. -- Brian S. Julin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: (was) RE: how to limit the repeating ldap lookups
OK, fine since everyone seems to have done this more recently than me, thanks all three of you for the update :-) This is an improvement. Back when I was messing with it IIRC this was only available for server 10.7. The instructions for signing it are easier than I remember them being as well: http://www.rootmanager.com/iphone-ota-configuration/iphone-ota-setup-with-signed-mobileconfig.html -Original Message- From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of David Aldwinckle Sent: Wednesday, August 28, 2013 2:32 PM To: FreeRadius users mailing list Subject: Re: (was) RE: how to limit the repeating ldap lookups Its been a while since I'Ve used it, but doesn't the iPhone Config Utility generate mobileconfigs that work on OS X? http://support.apple.com/kb/DL1465 Dave Aldwinckle On 2013-08-28 11:13 AM, Brian Julin bju...@clarku.edu wrote: Arran wrote: and wow did they get rid of the 802.1X profile configuration GUI interface in OSX 10.8? That sucks. If you think that sucks, wait till you see the horrible things you have to do to generate a .mobileconfig without access to an OSX server license. -- Brian S. Julin - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Apple devices can´t authenticate
Roberto Carna wrote: I can authenticate with Windows, Linux and Android devices, but I can't authenticate with Apple devices (iphone and ipad) at all. Is it an intrinsic problem of Freeradius ??? No, Apple devices auth off FreeRADIUS just fine. More likely it is a problem with certs/CAs, or client configurations. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Apple devices can´t authenticate
Since all your auth attempts are coming from easyhotspot, compare the difference in FreeRADIUS logs between a successful authentication and an unsuccessful one, for the same user and password. Compare both the username and password, and all other attributes in the request, very carefully. Odds are that easyhotspot is sending something different when an iOS client tries to connect. This would not be a surprise, since iOS has been known to try to play cute games by hijacking web portals. -Original Message- From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of Roberto Carna Sent: Wednesday, August 14, 2013 10:01 AM To: FreeRadius users mailing list Subject: Re: Apple devices can´t authenticate Dear, the debug is this: [chap] Login attempt by pepe with CHAP password [chap] Using clear text password 1234 for user pepe authentication [chap] Password check failed ++[chap] Returns reject Failed to authenticate the user THe password is 1234 and I try many times... Any idea ??? Because from other Windos and Android devices the authentication works OK. Thanks again 2013/8/14 Brian Julin bju...@clarku.edu: Roberto Carna wrote: I can authenticate with Windows, Linux and Android devices, but I can't authenticate with Apple devices (iphone and ipad) at all. Is it an intrinsic problem of Freeradius ??? No, Apple devices auth off FreeRADIUS just fine. More likely it is a problem with certs/CAs, or client configurations. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
Alan DeKok wrote:
Well... I tried it, and I didn't see any errors.
Can you check that you're really running a *stock* binary, and a
*stock* configuration?
Attached is a recipe for how I replicated it (and another doublefree) on a
clean system.
1) started on a fresh system that had never seen freeradius before.
2) apt-get build-dep freeradius
3) apt-get install libtalloc-dev
4) git clone git://git.freeradius.org/freeradius-server
5) git branch --track release_branch_3.0.0
6) git checkout release_branch_3.0.0
7) configure --prefix=/usr/local; make; make install
8) download wpa source and build eapol_test
9) configure an eapol_peap.conf:
network={
ssid=example
key_mgmt=WPA-EAP
eap=PEAP
identity=f...@domain.site
anonymous_identity=a...@domain.site
password=foo
phase1=peaplabel=0
phase2=auth=MSCHAPv2
}
10) Try an auth against stock config, no memory errors as expected
11) copy proxy-inner-tunnel from sites-available to sites-enabled
12) change mods-enabled/eap peap{} to virtual_server = proxy-inner-tunnel
13) Run the test. Get a GCC doublefree that ends as follows:
(7) # Executing section post-proxy from file
/usr/local/etc/raddb/sites-enabled/default
(7) group post-proxy {
(7) - entering group post-proxy {...}
(7) eap : Doing post-proxy callback
(7) eap : Passing reply from proxy back into the tunnel
(7) eap : Got tunneled reply RADIUS code 11
EAP-Message = 0x010800160410ea08d4982a033fac8f7f1f0bc63b952f
Message-Authenticator = 0xbe82b369c495e2bceed47fd6f1b710d5
State = 0xc10fbed8c107ba1915db9798d8125486
Proxy-State = 0x37
(7) eap : Got tunneled Access-Challenge
(7) eap : Reply was handled
*** glibc detected *** /usr/local/sbin/radiusd: double free or corruption
(out): 0x08cb34d8 ***
15) Note that proxy-inner-tunnel.post-proxy is not being entered, scratch head
14) Note this is a different error that the talloc-detected double-use
I originally reported. To see that one proceed as follows:
16) comment out virtual-server option in mods-enabled/eap peap{}
17) add this clause to top of sites-enabled/default.authorize:
if (Freeradius-Proxied-To == 127.0.0.1) {
update control {
Proxy-To-Realm = example.com
}
}
18) Run the test. Get the talloc error originally reported:
(7) [suffix] = noop
(7) eap : Request is supposed to be proxied to Realm example.com. Not doing EAP.
(7) [eap] = noop
(7) [files] = noop
(7) [expiration] = noop
(7) [logintime] = noop
(7) [pap] = noop
} # server default
(7) eap_peap : Got tunneled reply code 0
PEAP: Tunneled authentication will be proxied to example.com
talloc: access after free error - first free may be at src/main/util.c:230
Bad talloc magic value - access after free
Aborted
18) Note that the error happens on the first unwrapped proxy before it is
sent, so decide not to worry about anything past authorize {} in the
default server.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
Alan DeKok wrote:
Brian Julin wrote:
I tried to replicate on a test server with lightly modified 3.0 stock
configs.
The error only
happens when everything is running through the same server/eap
instances, so good
instincts there. Replicating it is easy: just uncomment the peap virtual-
server directive
and add at the top of authorize:
if (Freeradius-Proxied-To == 127.0.0.1) {
update control {
Proxy-To-Realm = example.com
}
}
That doesn't make much sense. If it's in the default virtual
server, the FreeRADIUS-Proxied-To attribute will never exist. If it's
in the inner-tunnel virtual server, it will always exist, and always
have that value.
Only if you send it there with a virtual_server=inner-tunnel statement
in the peap block. This happens if you do not, as documented in the
comments for that option. Ah -- maybe to replicate you can't
have inner-tunnel in sites-enabled, since it has that loopback
listen directive. I had swapped in proxy-inner-tunnel at some point,
it appears, which does not have it.
...and it doesn't matter that example.com defaults to home_server
localhost, it does not get that far.
Well... I tried it, and I didn't see any errors.
Can you check that you're really running a *stock* binary, and a
*stock* configuration?
I will -- should I preferably be testing against the release git branch, or
against a release tag in master, BTW?
I believe it is the way it is because at some point we were having trouble
using outer.request
and such between virtual servers. I'll have to test those and see if that
limitation is still
in effect.
All that should work...
Good.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
I finally got around to trying some RC code (the release_branch_3.0.0 on
github) on our
production configurations, after a bit of massaging got them looking like they
were working,
but not so much the one that re-proxies the inner tunnel contents to an internal
server after unwrapping EAP-PEAP:
peap {
default_eap_type = mschapv2
proxy_tunneled_request_as_eap = yes
copy_request_to_tunnel = no
use_tunneled_reply = yes
tls = eduroam-eap-tls
}
Any request that tries to go to the proxy causes this to happen:
Wed Aug 7 11:57:35 2013 : Debug: (5) - entering if
(%{FreeRADIUS-Proxied-To} == 127.0.0.1) {...}
Wed Aug 7 11:57:35 2013 : Debug: (5)update control {
Wed Aug 7 11:57:35 2013 : Debug: (5) Proxy-To-Realm := idpi
...
Wed Aug 7 11:57:35 2013 : Debug: (5)} # update control = ok
Wed Aug 7 11:57:35 2013 : Debug: (5) - if (%{FreeRADIUS-Proxied-To} ==
127.0.0.1) returns ok
Wed Aug 7 11:57:35 2013 : Debug: (5)... skipping else for request 5:
Preceding if was taken
} # server eduroam_idp
Wed Aug 7 11:57:35 2013 : Debug: (5) eap_peap : Got tunneled reply code 0
Wed Aug 7 11:57:35 2013 : Debug: PEAP: Tunneled authentication will be
proxied to idpi
Wed Aug 7 11:57:35 2013 : Info: talloc: access after free error - first free
may be at src/main/util.c:230
Wed Aug 7 11:57:35 2013 : Info: Bad talloc magic value - access after free
... I don't know if this is of any use, being so far removed from the free():
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x75eb4700 (LWP 27579)]
0x003fe54328a5 in raise () from /lib64/libc.so.6
...
(gdb) bt
#0 0x003fe54328a5 in raise () from /lib64/libc.so.6
#1 0x003fe5434085 in abort () from /lib64/libc.so.6
#2 0x77782c3c in ?? () from /usr/lib64/libtalloc.so.2
#3 0x77782dd8 in talloc_get_name () from /usr/lib64/libtalloc.so.2
#4 0x777857eb in _talloc_get_type_abort ()
from /usr/lib64/libtalloc.so.2
#5 0x77bb4d95 in pairnext (cursor=0x75eb2950)
at src/lib/valuepair.c:290
#6 0x77bb4b42 in pairfind (vp=0x7fffe8007d80, attr=80, vendor=0,
tag=-128 '\200') at src/lib/valuepair.c:209
#7 0x76f58d45 in mod_authenticate (instance=0x7f8b30,
request=0x844e40) at src/modules/rlm_eap/rlm_eap.c:360
#8 0x00421812 in call_modsingle (component=0, sp=0x81ce30,
request=0x844e40) at src/main/modcall.c:311
#9 0x00422f93 in modcall (component=0, c=0x81cf30, request=0x844e40)
at src/main/modcall.c:782
#10 0x0041f4c6 in indexed_modcall (comp=0, idx=6, request=0x844e40)
at src/main/modules.c:758
#11 0x00421127 in process_authenticate (auth_type=6, request=0x844e40)
at src/main/modules.c:1648
#12 0x0040c910 in rad_check_password (request=0x844e40)
at src/main/auth.c:252
#13 0x0040cee4 in rad_authenticate (request=0x844e40)
---Type return to continue, or q return to quit---
at src/main/auth.c:490
#14 0x00430b79 in request_running (request=0x844e40, action=1)
at src/main/process.c:1185
#15 0x0042d02e in request_handler_thread (arg=0x8397c0)
at src/main/threads.c:685
#16 0x003fe5c07851 in start_thread () from /lib64/libpthread.so.0
#17 0x003fe54e811d in clone () from /lib64/libc.so.6
(gdb)
(gdb) up
#1 0x003fe5434085 in abort () from /lib64/libc.so.6
(gdb) up
#2 0x77782c3c in ?? () from /usr/lib64/libtalloc.so.2
(gdb) up
#3 0x77782dd8 in talloc_get_name () from /usr/lib64/libtalloc.so.2
(gdb) up
#4 0x777857eb in _talloc_get_type_abort ()
from /usr/lib64/libtalloc.so.2
(gdb) up
#5 0x77bb4d95 in pairnext (cursor=0x75eb2950)
at src/lib/valuepair.c:290
290 VERIFY_VP(cursor-current);
(gdb) list
285*/
286VALUE_PAIR *pairnext(vp_cursor_t *cursor)
287{
288 cursor-current = cursor-next;
289 if (cursor-current) {
290 VERIFY_VP(cursor-current);
291
292 /*
293 * Set this now in case 'current' gets freed before
294 * pairnext is called again.
(gdb) print cursor-current
$1 = (VALUE_PAIR *) 0x7fffe8007820
(gdb) print cursor-current-da
$2 = (const DICT_ATTR *) 0x6c6c617420646142
(gdb) print *cursor-current-da
Cannot access memory at address 0x6c6c617420646142
(gdb) up
#6 0x77bb4b42 in pairfind (vp=0x7fffe8007d80, attr=80, vendor=0,
tag=-128 '\200') at src/lib/valuepair.c:209
209 i = pairnext(cursor)) {
(gdb) list
204 vp_cursor_t cursor;
205 VALUE_PAIR *i;
206
207 for (i = paircursor(cursor, vp);
208 i;
209 i = pairnext(cursor)) {
210 VERIFY_VP(i);
211 if ((i-da-attr == attr) (i-da-vendor == vendor)
212 ((tag == TAG_ANY) || (i-da-flags.has_tag
213 (i-tag == tag {
(gdb) print attr
$3 = 80
(gdb) print vendor
$4 = 0
(gdb) print tag
$5 = -128 '\200'
(gdb)
RE: Talloc sanity error (3.0 release branch, reproxying from PEAP inner tunnel)
a.l.m.bu...@lboro.ac.uk [a.l.m.bu...@lboro.ac.uk] wrote:
how did you configure the server...from scratch or copy pasting bits over
from a 2.x ?
It's a mongrel, not an alteration of fresh 3.0. It was working on a pre-talloc
3.0 development branch.
does this 'eap' module use its own virtual_server or does it inherit the
virtual_server that
instigated it (you have no 'virtual_server = blah' line in your peap{}
section...so i assume
its using eduroam_idp VS for the unwrapping?)
There's only one incestuous server clause, and only one EAP configuration
block, yes.
I tried to replicate on a test server with lightly modified 3.0 stock configs.
The error only
happens when everything is running through the same server/eap instances, so
good
instincts there. Replicating it is easy: just uncomment the peap
virtual-server directive
and add at the top of authorize:
if (Freeradius-Proxied-To == 127.0.0.1) {
update control {
Proxy-To-Realm = example.com
}
}
...and it doesn't matter that example.com defaults to home_server localhost, it
does not get that far.
I believe it is the way it is because at some point we were having trouble
using outer.request
and such between virtual servers. I'll have to test those and see if that
limitation is still
in effect.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
3.0 regex realm syntax
It seems to be last call for refactoring some of the user-visible
config items that are easier to change when bumping a major
rev number. The syntax for regexp-based realms has always
struck me as a bit hinky:
realm ~regexp\\.edu {
}
Would it require too much tokenization witchdoctoring to make:
realm /regexp\.edu/ {
}
...work?
Also I find a note in my config file comments about some regexp
availability in the hints file being in-transition and so not
to use it, but cannot remember what that was about, it has been
so long, and there seems to be no example in the stock configs.
I'm looking forward to finally bumping to 3.0 on our non-RadSec
servers as soon as things look to test out right and we can tell
the boss that the package is supported on our distro. We'll
be getting rid of a LOT of cruft in config files during the
process due to the many new ease-of-use features. Things
are sure looking up :-)
--
Brian S. Julin
Network Administrator
Clark University
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Indexing multi-valued attrbutes (was RE: 3.0)
Arran Cudbard-Bell wrote: Soon. We've gone into official feature freeze. Still finding bugs though, it'd be helpful if people could test. Just to make sure it was understood during the foreach fixup patch I sent on github, I mentioned that indexed attribute accesses were broken. None of var[#] var[2] or var[*] work in xlats, unless that's been fixed recently. -- Brian - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
JFYI, a start on DDDS support
I started working on DDDS support a while back and the code is to the point where I can swallow my pride enough to let other people see it. It is far from completely debugged/tested, and it is just the analogue to rlm_realm for DDDS -- it does nothing but create some attributes and will be moot without corresponding lb/pool handling code in the core, and that second part is an endeavor in and of itself, especially given connection affinity challenges surrounding tunneled EAP conversations. This is just an FYI in case anyone would like to read through it, offer suggestions, or just keep track. Best place to start is probably the manpage: https://github.com/skids/freeradius-server/blob/ddds/man/man5/rlm_ddds.5 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Radius vs Tacacs+
Roberto Carna wrote: Sent: Monday, May 20, 2013 3:43 PM To: FreeRadius users mailing list Subject: Radius vs Tacacs+ Dear, my chief ask me to choose between Tacacs+ and Radius for switches and Linux SSH user authentication. This depends primarily on your cryptographic needs, and secondarily on your needs for a consolidated AAA environment. While there are options to provide stronger cryptography for RADIUS, those options are not generally implemented by vendors in switch RADIUS clients. If you are passing your AAA sessions over networks which may leak data, the basic RADIUS secret may not offer the level of protection you need. However, if you feel secure that your control plane is protected, you may want to consider RADIUS as it has better cross-vendor compatibility and also because it can integrate multiple AAA scenarios quite easily, centralizing your AAA services in one place without as much time invested for integration between systems. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Normalising the User-Name AVP in an Access-Accept
Nick Lowe wrote: So, a compliant NAS that is able to treat the User-Name AVP as being authoritative would get to see the real, inner identity and in a normalised form. As an aside to the mechanics of this, if you do this, test your NAS under simulated user load. We found that our Cisco WLC equipment didn't like that and leaked internal resources, which eventually ran out. We were adding some additional information to the username, so we had many more differences between the outer and inner IDs, and even so it took a few days for the problem to come to a head. This should be fixed in latest software, but we haven't re-tested that yet. It also wouldn't hurt to sniff the resulting EAPOL and any associated packets to ensure the NAS hasn't figured out some vendor-specific way to leak that inner identity to the wire/wifi, and of course review your security expectations between the AS and NAS. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Normalising the User-Name AVP in an Access-Accept
Nick Lowe wrote: I would have thought that it is perfectly reasonable to return the identity back in the case you have roaming federations as long as it was an agreed requirement beforehand. I am of the opinion that this -should- be mandated as part of Eduroam, for example. I'd have to disagree. We don't want to know anything about eduroam guest users other than an ID which to hand authorities which they can use to investigate with the home institution. The less we know, the less work we have to do when we get a subpoena. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: RADIUS shared secret over internet
Muhammad Nuzaihan wrote: What are the roadmap for this? Are there any initial work being done or proof-of-concept work on this? By looking at implementations of TLS (in combination of openssl/gnutls) on other protocols might be similar to this but i may be wrong (i have yet to read on the RFC) as it's another layer taking place. I've been piloting FR3's RADSEC between our campus and our eduroam federation for close to a year now. There were some initial bugs but it's been stable since those were dealt with. Just be sure to turn off max_requests_per_server by setting it to zero. Sometime soon EDUROAM-US is moving to a redundant setup so we'll be able to test any interactions with home server pooling. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Andriod certificate validation behavior
Slightly OT, but I'd like to encourage folks here who have a google account to star up issue #37178 on code.google.com to see if we cannot get Android developers to make future versions of the OS behave sanely WRT which AAA server certificates they will accept. I also left a long screed there about what the optimal behavior might be which some here might like to comment on. The URL is http://code.google.com/p/android/issues/detail?id=37178 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Andriod certificate validation behavior
Alan DeKok wrote: I'd suggest putting up a web page explaining how you can steal android credentials via a malicious AP. If you can get it to do TTLS + PAP for a random certificate, that's good for a CERT issue. And they'll pay attention to that. The FreeRADIUS-WPE patches have been out since at least 2008, but I guess having something that specifically shows an Android yielding up credentials might be more provocative, yes. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Freeradius like WPA2-PSK
James JJ Hooper wrote: WPA2-Enterprise with PEAP authentication is automatically recognized by most new clients these days. The clients will prompt for a username and a password. If you generate an ntcrypt (by shelling out of FR to a utility to do so) for an inbound username/password on the RADIUS side from a known cleartext password on the fly, you can arrange things such that that password is accepted for any username. Hi Brian, Slightly tangential to the original question. But if you want to implement as per this suggestion, why do you need the external ntcrypt script. All that functionality is built in, just do this: You don't, unless you want to do something like telling people to enter usernameBLAH as their password. Sorry, I was mincing scenarios. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Freeradius like WPA2-PSK
Paulo wrote: Is there any way that freeradius act as WPA-PSK?? What i am trying to deploy is a wi-fi network with only one password that is changed every week. Right now I have a open wireless signal distributed over 20 wi-fi routers. This signal is used by all the clients of the hotel, so there is no way to distribute certificate to the clients. WPA2-Enterprise with PEAP authentication is automatically recognized by most new clients these days. The clients will prompt for a username and a password. If you generate an ntcrypt (by shelling out of FR to a utility to do so) for an inbound username/password on the RADIUS side from a known cleartext password on the fly, you can arrange things such that that password is accepted for any username. No certificate is required on the client side. The server will need a certificate signed by an authority that is already trusted by the clients ($$$). You can also abuse MS domain notation to select from a set of passwords for different groups, but that will require the users to correctly type a backslash, which can be asking a bit much for certain types of users. So yes, but there is no way to get rid of the username box in the login prompt, you just need to tell the users (when you give them the password) to enter something in the username box. Also without provisioning and distributing a client-side-verification profile, your users may be hijacked by an AP pretending to be one of yours, as long as it knows the password and has any valid cert; but this is the case with WPA2-PSK as well (worse, in fact, without the server-side certificate.) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Complex eduroam radius design
Phil Mayers wrote: Yes. However, buying separate certs might not be a good idea as it will complicate the client setup - they'll all have to come from the same CA and share the same CN (or you'll have to rely on wildcard CN matching on the clients). Has that actually been tested to work across the gallery of clients? It is my impression that a lot of clients (e.g. IOS) will just barf on any certificate that isn't the first one it encountered on an SSID, unless and until the user gets frustrated and reconfigures. Not that I think running multiple certs offers any real benefit. Perhaps for transitional purposes when expiry dates come up. (Note: this behavior, while not completely secure, is probably as secure as one could expect on a ...ehem... BYOD network with a nonconforming user base, and is certainly superior to Android which will trust anything you hand it.) (Oh, also, if anyone wants to play with clients in a test environment by sending them strange certificates at inopportune times, I left some code on github at skids/freeradius-server/tree/clientverify. It is too ugly to propose as a serious patch, though.) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Concatenating/inserting strings with backslashes
Brian Candler writes:
Or is there another way I can concatenate strings, which doesn't involve
expanding them into another string?
The workaround I've used for this is to feed the value through a regexp
match to get it into %{1}, which does not seem to be subject to unescaping.
try:
if (%{reply:Reply-Message} =~ /(.*)/) {
update reply {
Reply-Message = stuff %{1}
}
}
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Concatenating/inserting strings with backslashes
Brian Candler wrote
try:
if (%{reply:Reply-Message} =~ /(.*)/) {
update reply {
Reply-Message = stuff %{1}
}
}
Nice idea, but it appears to suffer the same expansion problem.
As you have written it gives this error:
Bare %{...} is invalid in condition at: %{reply:Reply-Message} =~ /(.*)/)
Adding the double quotes:
Oh right.
I usually do this with e.g. User-Name without having to specify the attribute
list
explicitly; I forget whether syntax works to do that with a raw variable.
I know outer.VarName works raw, so maybe just reply:Reply-Message
without the braces or quotes?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: migration from ACS 4.2 NAR
Menard, Yannick writes: Example: I am able to permit only certain user based on their active directory group to connect to my certain wireless SSID. Also I use ACS to configure Downloadable IP ACLs for the VPN access Does freeradius have similar option? Yes and yes, but it will be more programmatic than you are used to with ACS. Meaning, FreeRADIUS can do just about anything that's actually possible, but if you utilize this flexibility deeply, the result will end up looking like a script, rather than a config file. Which is really a result of business logic being more naturally expressed as procedural code than as a collection of settings. Whether it's a good fit for your organization depends on the people who will have to administer it. There are many modules that make common tasks use config files and even store some business logic on the database side. Whether these modules will fit all your particular needs depends on how peculiar your needs are. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: request_dequeue problems (recent 3.0, when home-server stalls)
I had some more time to play with this; it seems to be related to retiring old threads, not actual problem on the home server. Some new observations below. Alan DeKok wrote on Aug28, 2012: Brian Julin wrote: I'm currently hunting a problem that causes a recent checkout of FR3.0 to abort but which does not seem to be affecting an older revision (April 8th or so) of FR3.0 on another box. I do have a couple small in-house patches applied but they should probably not be relevant. It's always worth checking. OK, I've tested with a recent clean clone and it still has the problem. request_dequeue found request 0x13d5220 ASSERT FAILED threads.c[468]: request-magic == REQUEST_MAGIC Which means that the request has been deleted, but is still in the queue. That's not supposed to happen... After collecting some more debug logs, I noticed that this problem was happening too often on requests numbered around 260 to be a coincidence. It turns out this happens after a thread is marked for recycling due to having handled over 128 requests. I'm no longer positive that the home server is not responding, though it could have similar limits set up on the RADSEC connection so we cannot completely eliminate that as a possibility. It seems a lot more likely, though, that something is getting wedged up locally and the request to the home server never actually hits the wire. The server will ride over the thread recycling if it is handling requests that do not need to be proxied at the moment when the threads are marked; it only has trouble in the middle of conversations. Below is a debug log with some extra radlogs thrown in by hand. The Reaping lines happen in the loop that tests whether threads have handled so many connections that they should be retired. Is it normal for a thread to grab and handle requests after it has been marked for recycling? We start in the middle of an ongoing EAP conversation. Sending Access-Challenge of id 96 to 127.0.0.1 port 34912 [request dump omitted] (259) Finished request 259. Thread 2 waiting to be assigned a request Waking up in 0.3 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 34912, id=242, length=273 Deleting thread 3 Deleting thread 4 Reaping... Reaping thread 1 due to number of requests handled (130/128 handled) Reaping... Reaping thread 2 due to number of requests handled (131/128 handled) Waking up in 0.2 seconds. Thread 2 got semaphore Thread 2 handling request 260, (132 handled so far) [request dump omitted] Thread 1 got semaphore Thread 1 exiting... [unlang trace omitted] Sending Access-Request of id 238 to XXX port 2083 [request dump omitted] Thread 2 exiting... Waking up in 0.3 seconds. Waking up in 0.4 seconds. Waking up in 0.7 seconds. Waking up in 1.1 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 34912, id=242, length=273 Discarding duplicate request from client EDUROAM_OUT port 34912 - ID: 242 due to unfinished request 260 Waking up in 0.9 seconds. Waking up in 1.1 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 34912, id=242, length=273 Discarding duplicate request from client EDUROAM_OUT port 34912 - ID: 242 due to unfinished request 260 (256) Cleaning up request packet ID 213 with timestamp +11084 rad_recv: Access-Request packet from host 127.0.0.1 port 34912, id=242, length=273 Discarding duplicate request from client EDUROAM_OUT port 34912 - ID: 242 due to unfinished request 260 (256) Cleaning up request packet ID 213 with timestamp +11084 Waking up in 0.2 seconds. (257) Cleaning up request packet ID 10 with timestamp +11085 Waking up in 0.2 seconds. (258) Cleaning up request packet ID 151 with timestamp +11085 Waking up in 0.2 seconds. (259) Cleaning up request packet ID 96 with timestamp +11085 Waking up in 2.2 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 34912, id=242, length=273 Discarding duplicate request from client EDUROAM_OUT port 34912 - ID: 242 due to unfinished request 260 Waking up in 1.1 seconds. Waking up in 3.7 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 34912, id=242, length=273 Discarding duplicate request from client EDUROAM_OUT port 34912 - ID: 242 due to unfinished request 260 Waking up in 2.9 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 34912, id=242, length=273 Discarding duplicate request from client EDUROAM_OUT port 34912 - ID: 242 due to unfinished request 260 Waking up in 0.9 seconds. Waking up in 5.6 seconds. Waking up in 8.5 seconds. Waking up in 12.8 seconds. Waking up in 19.2 seconds. Waking up in 28.8 seconds. (260) queue : Cleaning up request packet ID 242 with timestamp +11086 Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 34912, id=104, length=272 Threads: total/active/spare threads = 2/0/2 Threads: Spawning 2 spares Thread spawned new child 5. Total threads in pool: 3 Thread spawned new child 6. Total threads
RE: building FR3.0 jlibtool problem
Scott Armitage wrote: gmake[4]: /usr/local/src/freeradius-server/libtool: Command not found gmake[4]: *** [dict.lo] Error 127 gmake[3]: *** [lib] Error 2 gmake[2]: *** [all] Error 2 gmake[1]: *** [src] Error 2 make: *** [all] Error 2 IIRC running libtoolize cleared this up. I'm not sure if that's the way things are supposed to work, or whether the build system should be setting LIBTOOL to the system installed path. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: .rpmnew files during RPM upgrade
-Original Message- On 11/09/12 12:16, Phil Mayers wrote: This approach of a separate available/enabled modules dir is the default approach in the MASTER branch (to be 3.x) Would redhat packaging policy allow the package scripts to instead create e.g. modules.rpmnew/ and stuff its files under there instead? (My hopes aren't high.) I don't think blacklisting specific extensions in the conffile.c source is helpful, personally. It's magic and hardcoded lists are a pain - what seems reasonable to one person can be annoying to another. Sounds like the job of a main config file directive, e.g. ignore_suffixes= That way it could appear right before the INCLUDE line in the configuration file so it's right out there in the open. Not that I'm volunteering :-) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
request_dequeue problems (recent 3.0, when home-server stalls)
I'm currently hunting a problem that causes a recent checkout of FR3.0 to abort but which does not seem to be affecting an older revision (April 8th or so) of FR3.0 on another box. I do have a couple small in-house patches applied but they should probably not be relevant. The issue seems to happen when a home-server does not respond to a request, and then FR re-enqueues the request as a retransmit. The request then gets dequeued again, and at that point fails a REQUEST_MAGIC assert. That is, if I am reading the logs correctly... Logs are included, with a few added printfs thrown in. Anyone have any suggestions for good commits to bisect at? rad_recv: Access-Request packet from host 127.0.0.1 port 57940, id=104, length=2 63 request_enqueue 0x13d5220 Thread 1 got semaphore request_dequeue prequest before 0x13c0a00-(nil) Thread 3 got semaphore request_dequeue found request 0x13d5220 Thread 2 got semaphore request_dequeue prequest after 0x13c0a00-0x13d5220 request_dequeue prequest before 0x13c0b80-(nil) Thread 4 got semaphore Thread 2 exiting... Thread 1 handling request 258, (130 handled so far) request_dequeue prequest before 0x13c0e80-(nil) Thread 4 exiting... [... request dump ...] request_dequeue prequest before 0x13c0d00-(nil) Thread 3 exiting... (258) thread : # Executing section authorize from file /etc/raddb/eduroam_sp.c onf [... bunch of unlang/realm chatter ...] Sending Access-Request of id 38 to [... request dump ...] (258) Proxying request to home server ... Thread 1 exiting... Waking up in 0.2 seconds. request_enqueue 0x13d5220 Waking up in 0.2 seconds. Waking up in 0.4 seconds. Waking up in 0.7 seconds. Waking up in 1.1 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 57940, id=104, length=263 Discarding duplicate request from client EDUROAM_OUT port 57940 - ID: 104 due to unfinished request 258 Waking up in 0.9 seconds. Waking up in 1.4 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 57940, id=104, length=263 Discarding duplicate request from client EDUROAM_OUT port 57940 - ID: 104 due to unfinished request 258 Waking up in 0.4 seconds. (255) Cleaning up request packet ID 198 with timestamp +6868 Waking up in 0.2 seconds. (256) Cleaning up request packet ID 166 with timestamp +6868 Waking up in 0.2 seconds. (257) Cleaning up request packet ID 128 with timestamp +6868 Waking up in 2.1 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 57940, id=104, length=263 Discarding duplicate request from client EDUROAM_OUT port 57940 - ID: 104 due to unfinished request 258 Waking up in 1.1 seconds. Waking up in 3.7 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 57940, id=104, length=263 Discarding duplicate request from client EDUROAM_OUT port 57940 - ID: 104 due to unfinished request 258 Waking up in 2.9 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 57940, id=104, length=263 Discarding duplicate request from client EDUROAM_OUT port 57940 - ID: 104 due to unfinished request 258 Waking up in 0.9 seconds. Waking up in 5.6 seconds. Waking up in 8.5 seconds. Waking up in 12.8 seconds. Waking up in 19.2 seconds. Waking up in 28.8 seconds. (258) queue : Cleaning up request packet ID 104 with timestamp +6869 Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 57940, id=125, length=254 request_enqueue 0x13c2080 Deleting thread 1 Deleting thread 2 Deleting thread 3 Deleting thread 4 Waking up in 0.3 seconds. Waking up in 0.4 seconds. Waking up in 0.7 seconds. Waking up in 1.1 seconds. Waking up in 1.6 seconds. Waking up in 2.5 seconds. Waking up in 3.7 seconds. Waking up in 5.6 seconds. Waking up in 8.5 seconds. Waking up in 12.8 seconds. Waking up in 19.2 seconds. Waking up in 28.8 seconds. (259) queue : Cleaning up request packet ID 125 with timestamp +10992 Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 57940, id=228, length=254 request_enqueue 0x13c2080 Threads: total/active/spare threads = 0/0/0 Threads: Spawning 4 spares Thread spawned new child 5. Total threads in pool: 1 Thread spawned new child 6. Total threads in pool: 2 Thread spawned new child 7. Total threads in pool: 3 Thread 5 waiting to be assigned a request Thread 5 got semaphore request_dequeue prequest before 0x13c0e80-(nil) request_dequeue found request 0x13d5220 ASSERT FAILED threads.c[468]: request-magic == REQUEST_MAGIC Thread spawned new child 8. Total threads in pool: 4 Thread 7 waiting to be assigned a request Thread 6 waiting to be assigned a request Thread 6 got semaphore Thread 7 got semaphore - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[PATCH] fix connection limits
Attached is an improved version of one of the patches originally posted here.
http://lists.freeradius.org/pipermail/freeradius-users/2012-May/060820.html
It moves decrements of socket/client num_connections counters into event_new_fd
so that it
happens on all paths by which a connection may be removed. As the code now
stands,
when a connection is terminated by the other side, num_connections continues to
count
it towards connection limits.
(Note that with the above code, num_connections will still count a dead
connection
towards limits until it has been abandoned by all users and cleaned up. Also
I'm not completely
sure this is immune to races since I haven't yet figured out if the connection
garbage collection
might be reentrant.)
This has been tested in a radsec pure-proxy relay setup. It has not yet been
tested in an AS
setup.
diff --git a/src/main/listen.c b/src/main/listen.c
index cb774d5..e39ee4f 100644
--- a/src/main/listen.c
+++ b/src/main/listen.c
@@ -476,14 +476,4 @@ static int dual_tcp_recv(rad_listen_t *listener)
/*
- * Decrement the number of connections.
- */
- if (sock-parent-limit.num_connections 0) {
- sock-parent-limit.num_connections--;
- }
- if (sock-client-limit.num_connections 0) {
- sock-client-limit.num_connections--;
- }
-
- /*
* Tell the event handler that an FD has disappeared.
*/
diff --git a/src/main/process.c b/src/main/process.c
index bc1b35e..6b369d8 100644
--- a/src/main/process.c
+++ b/src/main/process.c
@@ -1603,5 +1603,5 @@ static void remove_from_proxy_hash_nl(REQUEST *request)
/*
- * Got from YES in hash, to NO, not in hash while we hold
+ * Go from YES in hash, to NO, not in hash while we hold
* the mutex. This guarantees that when another thread
* grabs the mutex, the not in hash flag is correct.
@@ -3770,4 +3770,13 @@ finish:
#endif
+ if (sock-parent) {
+ if (sock-parent-limit.num_connections 0) {
+sock-parent-limit.num_connections--;
+ }
+ if (sock-client-limit.num_connections 0) {
+sock-client-limit.num_connections--;
+ }
+ }
+
/*
* Remove any pending cleanups.
diff --git a/src/main/tls_listen.c b/src/main/tls_listen.c
index 91eeec8..d7edacd 100644
--- a/src/main/tls_listen.c
+++ b/src/main/tls_listen.c
@@ -77,16 +77,4 @@ static void tls_socket_close(rad_listen_t *listener)
listener-tls = NULL; /* parent owns this! */
- if (sock-parent) {
- /*
- * Decrement the number of connections.
- */
- if (sock-parent-limit.num_connections 0) {
- sock-parent-limit.num_connections--;
- }
- if (sock-client-limit.num_connections 0) {
- sock-client-limit.num_connections--;
- }
- }
-
/*
* Tell the event handler that an FD has disappeared.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Cisco phones loosing connectivity with VMPS and IOS upgrade to 15.0(1)SE2
Kaya Saman Sent: Friday, June 01, 2012 10:05 AM To: FreeRadius users mailing list Subject: Re: Cisco phones loosing connectivity with VMPS and IOS upgrade to 15.0(1)SE2 On Thu, May 31, 2012 at 3:45 PM, Brian Julin bju...@clarku.edu wrote: Kaya Saman wrote: I will perform a wireshark and tcpdump packet capture this evening in order to try to debug more clearly what is going on between the devices however, in the mean time I was wondering if there was some sort of interoperability quircks between newer Cisco IOS releases and FreeRADIUS (VMPS)?? Likely the CISCO decided to change the way they interpret the tunnel-group-id attribute. There are two ways to pass this attribute (normally, and using a cisco vendor specific attribute.) There are three ways the switch may interpret the string contained therein. 1) numerically 2) vlan name 3) vlan group name Can anyone suggest anything? Play with different combinations of the above. Also verify that all the global and interface commands which are applied on a working 12.2 switch remain applied on 15.0. Sometimes command syntax changes and the commands get rejected on upgrade. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thanks for the information. I will have a look at the tunnel-group-id attribute. Actually now that I've looked up VMPS I doubt it is in use. Also my bad, it's tunnel-private-group-id. VMPS is widely considered deprecated, in favor of dot1x+mab. If you're having trouble moving forward on upgrades, it might be a good time to consider modernizing. However, if you are also using the more basic non-auth-related first-hop security features such as ip sourceguard+port-security, I would recommend you to steer clear of the 15 release train for now; it has issues. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Cisco phones loosing connectivity with VMPS and IOS upgrade to 15.0(1)SE2
Kaya Saman wrote: I will perform a wireshark and tcpdump packet capture this evening in order to try to debug more clearly what is going on between the devices however, in the mean time I was wondering if there was some sort of interoperability quircks between newer Cisco IOS releases and FreeRADIUS (VMPS)?? Likely the CISCO decided to change the way they interpret the tunnel-group-id attribute. There are two ways to pass this attribute (normally, and using a cisco vendor specific attribute.) There are three ways the switch may interpret the string contained therein. 1) numerically 2) vlan name 3) vlan group name Can anyone suggest anything? Play with different combinations of the above. Also verify that all the global and interface commands which are applied on a working 12.2 switch remain applied on 15.0. Sometimes command syntax changes and the commands get rejected on upgrade. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Escaped backslash in User-Name when sending Access-Accept
Roberto Franceschetti wrote:
Mine is just a theory, but I cannot verify it until I figure out how to have
the
un-escaped ocg\cmctrf3 string being sent in the output instead of the
current escaped one.
It probably is not escaped. Some logs and debug outputs escape before
outputting to syslog or the screen, but some do not, so it is hard to
be sure what you are seeing without taking an actual packet dump
and looking at the actual bytes sent.
The only time you should ever have to deal with problems with unescaping
in the User-Name attribute is when you edit it by hand, for example,
if you take an inner tunnel copy of the user-name and then place
it by hand in the outer reply (which you should only do if you can trust
your NAS and the network between it to keep that secret.)
If you do such a thing, it is very hard to get an unescaped edited string back
into an attribute, because any attribute you define will be escaped when
you try to glue it back together with an xlat. You can, however, do so
using %{1}, %{2}, %{3} etc from a regexp match.
# The following will take the User-Name from the request and put it into the
reply,
# without adding any escaping.
if (User-Name =~ /(.*)/) {
update reply {
User-Name = %{1}
}
}
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Anon repo access?
Is anyone else getting this problem, or have I just managed to confuse git somehow? $ git pull origin master fatal: remote error: access denied or repository not exported: /freeradius-server.git $ git remote -v origin git://git.freeradius.org/freeradius-server.git (fetch) origin git://git.freeradius.org/freeradius-server.git (push) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[PATCH]es decrement client limit on socket timeout, saner tls sample conf, and a pasto
Three patches versus master attached:
The first puts a saner default config for radsec connections from clients,
because in the dominant
use-case for radsec clients (outside federation servers pointing to your IDP
service) these connections
are often nailed up by the client so if they timeout every thirty seconds
(which is
the new default as of the limit structure changes), the client just proceeds to
rebuild them every
30 seconds.
The second patch is a pasto that was preventing dhcp.c from compiling. Note I
don't use this
module, so I haven't tested that at all.
The third patch decrements the client's connection limit counter when a socket
times
out so that a TCP connection falling down and restoring does not eventually run
afoul
of max_connections. Note this problem was pre-existing before for the new
limit structure
changes but also occured with them applied. This is only slightly tested, and
might benefit
from an experienced eyeball or two, especially WRT possibly backporting it.
diff --git a/raddb/sites-available/tls b/raddb/sites-available/tls
index b1c531d..2108bbc 100644
--- a/raddb/sites-available/tls
+++ b/raddb/sites-available/tls
@@ -243,6 +243,18 @@ listen {
# client = /path/to/openssl verify -CApath ${..CA_path} %{TLS-Client-Cert-Filename}
}
}
+
+ # Unless you are doing P2P radsec meshes, or you are a federation
+ # level server, you likely want a long life on connections from
+ # federation servers that are proxying to you. These limits are
+ # applied to each connection on this socket. You should also set
+ # limits for clients as well. Both limits will apply.
+ limit {
+ max_connections = 16
+ lifetime = 7200
+ idle_timeout = 3600
+ }
+
}
clients radsec {
@@ -250,6 +262,19 @@ clients radsec {
ipaddr = 127.0.0.1
proto = tcp
secret = testing123
+
+ # Unless you are doing P2P radsec meshes, or you are a
+ # federation level server, you likely want a long life
+ # on connections from federation servers that are proxying
+ # to you. These limits are applied to each connection from
+ # this client. They will be enforced alongside the
+ # limits defined in the listen directive(s) for the socket(s)
+ # where connections arrive.
+ limit {
+ max_connections = 16
+ lifetime = 7200
+ idle_timeout = 3600
+ }
}
}
diff --git a/src/lib/dhcp.c b/src/lib/dhcp.c
index 1b2a73c..012b7f6 100644
--- a/src/lib/dhcp.c
+++ b/src/lib/dhcp.c
@@ -1551,7 +1551,7 @@ int fr_dhcp_add_arp_entry(int fd, const char *interface,
VALUE_PAIR *macaddr, VALUE_PAIR *ip)
{
#ifdef SIOCSARP
- struct sockaddr_in *sin
+ struct sockaddr_in *sin;
struct arpreq req;
if (macaddr-length sizeof (req.arp_ha.sa_data)) {
diff --git a/src/main/process.c b/src/main/process.c
index f641e5f..c16e81d 100644
--- a/src/main/process.c
+++ b/src/main/process.c
@@ -3769,6 +3769,10 @@ finish:
}
#endif
+ if (sock-client != NULL) {
+ sock-client-limit.num_connections--;
+ }
+
/*
* Remove any pending cleanups.
*/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Assign VLAN from freeradius to Cisco 3550 switch.
Wassim Zaarour wrote:
Look at this
http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg40162.html
The user says that it worked, I tried the attributes he used and still got
the same error.
I don't even know how this was ever working for that user. On my wired switch
plant, which
includes some 3550s, wherever I have tested VLAN assignment I have had to use
Cisco's
cretinous hack:
if (Cisco-AVPair) { # Cisco switch.
# We have to Accept it to the Registration VLAN manually
# (because host-mode multi-auth is currently retarded.)
update reply {
Tunnel-Type = VLAN
Tunnel-Medium-Type = 6
# CISCO broke the IETF attribute...
# Tunnel-Private-Group-Id = Registration
# ... so use their proprietary method to get it in there.
# NOTE: This is CaSe SeNsItIvE!!
Cisco-AVPair += tunnel-private-group-id=Registration
}
This is of course extremely case-sensitive. It also uses the vlan names, not
the numbers, though
you can use the automatically generated names just fine.
Be warned the 3550s are old EOL switches and their latest software version (the
one that is only
supposed to be used for the 24 port switch but works on the 48 port one) is
still not current enough
to pick up the latest bugfixes to multi-auth mode. Not that multi-auth mode
works sensibly in the
newest firmware either, but at least it has workarounds.
(BTW, even I am starting to pull these 3550s from the net, and I tend to try to
bleed devices for every
minute they can manage to hack it. Right now the only ones I have out there
are essentially
serving as lightening rods for this summer's thunder storms, and then will be
replaced by new
switches after that.)
Typical switch port configuration (this is not from a 3550, sorry):
interface FastEthernet0/24
switchport access vlan XXX
switchport mode access
switchport block unicast
switchport port-security maximum 16
switchport port-security
switchport port-security aging time 240
switchport port-security violation restrict
switchport port-security aging type inactivity
ip arp inspection limit rate 100
authentication control-direction in
authentication event fail action authorize vlan YYY
authentication event server dead action authorize vlan XXX
authentication event no-response action authorize vlan XXX
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication order mab
authentication priority mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate 1300
authentication timer inactivity 1200
authentication violation restrict
mab
no lldp transmit
no lldp receive
no cdp enable
no cdp tlv server-location
no cdp tlv app
spanning-tree portfast
spanning-tree bpduguard enable
ip verify source port-security
ip dhcp snooping limit rate 50
end
XXX and YYY above are actually decimals.
Note that the auth-fail VLAN setting is not actually used, because in order to
get multi-auth to behave
sensibly (so you can handle VMs) you have to actually succeed every
authentication and just send
the quaranteen VLAN from RADIUS when you want the user locked out.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Assign VLAN from freeradius to Cisco 3550 switch.
Alan Buxley wrote I can tell you right now that you dont need that hack to assign VLANs on cisco switches (well, not if you are running reasonably up to date firmware on the cisco devices anyway - ie something less than 2 years old) The latest public firmware for the 3550 is 3+ years old, FWIW, and the newer one I grabbed before they yanked it off the site wasn't much newer. IIRC (it was long ago) the hack was needed because the IETF attrib value is supposed to be a string, but the ciscos were expecting a binary integer encoding. I'll have to give the newer loads another whack at a straight authentication at some point and see if it indeed is fixed, but the hack works on the newer loads as well. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: ldap redundant-load-balance issue
-Original Message-
Tobias Hachmer
Am 19.04.2012 13:44, schrieb Alan DeKok:
Tobias Hachmer wrote:
During FreeRADIUS performance test as described in
/usr/share/doc/freeradius/performance-testing.gz I noticed that FR
does
for the ldap-group query above (Ldap-Group ==
cn=radius.users,ou=Groups,dc=test,dc=local) no load-balancing or
fall-through to other ldap modules. Every time only ldap module
ldap3 is
taken to do this ldap-group query.
That's how it works. The LDAP-Group queries are not load balanced.
Hmm, but then there is no big benefit instantiating multiple ldap
modules inside a redundant-load-balance group.
I recognized that the last referred module inside the group is taken to
do the query. Can I affect this in a different way as changing the
order?
Create a single RRDNS entry for your LDAP servers and use a single
LDAP definition. The DNS name(s) in the LDAP definition is sent to
directly to the underlying LDAP library and should be looked up for
each connection instantiated; FreeRADIUS does not resolve it
internally before use, even when using LDAPS.
You can also enter the RRDNS entry multiple times in a space
separated string, which should allow for statistically probable
failover, e.g.:
ldap rrdns_ldap {
# If 1/2 servers are down this should only fail 1/8th of the time
server = ldap.rrnds.site ldap.rrdns.site ldap.rrdns.site
...
}
(Whether that works may depend on the internal implementation of
the LDAP libraries and/or the way DNS is set up on the server on which
FreeRADIUS is running.)
This all assumes there are no differences in the schema used between
the servers, though.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
CVE-2012-2110
A cursory look suggests we may use some of the effected codepaths in CVE-2012-2110 (http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/086585.html) and given that FreeRADIUS often deals with certificates from sources that are not under direct control of administrators (dot1x clients, federation servers, etc.) this might be worth a news page post. -- Brian S. Julin Network Administrator Clark University - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: ldap redundant-load-balance issue
Tobias Hachmer wrote:
Am 19.04.2012 15:46, schrieb Brian Julin:
Create a single RRDNS entry for your LDAP servers and use a single
LDAP definition. The DNS name(s) in the LDAP definition is sent to
directly to the underlying LDAP library and should be looked up for
each connection instantiated; FreeRADIUS does not resolve it
internally before use, even when using LDAPS.
You can also enter the RRDNS entry multiple times in a space
separated string, which should allow for statistically probable
failover, e.g.:
ldap rrdns_ldap {
# If 1/2 servers are down this should only fail 1/8th of the time
server = ldap.rrnds.site ldap.rrdns.site ldap.rrdns.site
...
}
Thanks for that suggestion. Sounds quite simple to achieve fail-over
for ldap-queries.
But I have one problem when I enter my ldap servers like you mentioned
because the common name in the ldap server certificate won't match the
new defined dns name.
Yes we use a certificate with alternate names for this. Not sure what the
tweaking options are as far as OpenLDAP's certificate verification process...
I will test this scenario with the following configuration:
server = ldap1.test.local ldap2.test.local ldap3.test.local
The OpenLDAP documentation states that space separated host
lists are tried in order, so this would always use ldap1, unless the
ldap1 host lookup failed. (An utter hack, if you are locked into the
certs you have, would be to cause it to fail occasionally on purpose
using iptables.)
Perhaps I can still use multiple ldap modules and adapt only the server
directive of the last ldap module (or all ldap modules) in
redundant-load-balance group to the format you have mentioned.
I don't see why this would not work; and should allow the initial
(non-xlat, non-ldap-group) queries to balance more granularly.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
PATCH: Correct ldaps port number in stock config comments.
This just replaces some wrong port numbers in comments. This incorrect 689
port has also made it onto the wiki, FWIW.
diff --git a/raddb/mods-available/ldap b/raddb/mods-available/ldap
index c9520f4..218e69d 100644
--- a/raddb/mods-available/ldap
+++ b/raddb/mods-available/ldap
@@ -73,7 +73,7 @@ ldap {
#
# The StartTLS operation is supposed to be
# used with normal ldap connections instead of
- # using ldaps (port 689) connections
+ # using ldaps (port 636) connections
start_tls = no
# cacertfile = /path/to/cacert.pem
diff --git a/src/tests/eapsim-03/radiusd-example.txt b/src/tests/eapsim-03/radiusd-example.txt
index 2e0a402..4e551bc 100644
--- a/src/tests/eapsim-03/radiusd-example.txt
+++ b/src/tests/eapsim-03/radiusd-example.txt
@@ -709,7 +709,7 @@ modules {
# to the LDAP database by using the StartTLS extended
# operation.
# The StartTLS operation is supposed to be used with normal
- # ldap connections instead of using ldaps (port 689) connections
+ # ldap connections instead of using ldaps (port 636) connections
start_tls = no
# default_profile = cn=radprofile,ou=dialup,o=My Org,c=UA
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: optimize questions for unlang code
Tobias Hachmer wrote: Now I'm coming closer to my questions. When a local user logon to a telnet device freeradius does all the ldap membership queries. When an AD user will logon to a telnet device freeradius also does all the ldap membership queries. Q1: Can I abbreviate this process that when a local user wants access to a telnet device the ldap queries will be skipped? Q2: Is there a smarter way to reject a local user immediately when he wants to logon to a non telnet device? Q3: Is there a smarter way to reject an AD user immediately when he wants to logon to a telnet device? You could use Auth-Type subsections, but with LDAP the control flow can be a bit confusing (the statements in the block outside those sections all run, and then the block gets run again from the top once an Auth-Type is selected, which happens inside of the ldap module.) Your best bet for this scenario is to look at the as of 2.0 instructions in clients.conf, where you can select a virtual server to enter based on which clients are requesting, and construct a separate virtual server for telnet devices. Q4: Are there any tweaking capabilities to my unlang code to make it smarter or more hardened? Q5: Can I abbreviate any code snippets like using a switch/case block or use variables or anything I don't know? When using Ldap-Group as a check item, you have to be careful, because it is a special case. You are not really comparing the value after the '==' to a variable, rather each time an LDAP group query is launched looking for the value after the '=='. This is the way LDAP groups work -- you do not query a list of groups, you query them one-by-one. Note that using Ldap-Group in the users file is also inefficient. I use a nested if statement to short-circuit, and sort by prevalence, but I do not have quite as many cases as you. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: load balancing and if statements
Alan DeKok wrote: Scott McLane Gardner wrote: So, now I'm confused again. If this doesn¹t load balance, then how should I really be going about this? It's hard. Actually, on some further reading, it might not be: the LDAP library/DNS may take care of this instead of requiring special attention on the FreeRADIUS end. Firstly, for redundancy (and I tested this and it seems to work) ldap_init allows a space separated list of hostnames which will be tried in order. FreeRADIUS just passes this string through and the LDAP libraries seem to be happy about that. The only rough edge is, cosmetically, the debug log statement appends :port which ends up looking like the port designation belongs just to the last host. There might also be trouble between FreeRADIUS config syntax (with separate port) and the fact that the LDAP libraries also allow :port appendixes on each of the space-separated hostnames; that I did not test. For load-balancing (this I have not tested) a round-robin DNS for the LDAP servername may result in connections load balancing. Really this depends on the DNS caching behavior inside the LDAP library and on the host OS, but my impression is that by and large LDAP libraries treat DNS lookups sanely as a volatile item that needs to be re-loaded on re-use (there are Mozilla tickets wrestling with this for their LDAP re-implementation some years back, so even that lib might be OK.) At worst FreeRADIUS might need to add some fuzzing/connection-limits so that connections are regularly torn down and re-established, but not all at once, to force multiple DNS lookups when the server is started/hupped. If someone needs finer grained balancing, perhaps randomizing the connection pool selection may be needed. Also not tested is the space-separated multi-url form that goes through ldap_initialize instead of ldap_init, but openldap docs say that is supported as well. So if that works, the only reason someone would still need to do r-l-m tricks is if they need to validate TLS certs and the LDAP servers are not presenting the round-robin name and cannot be fixed to do so. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: FreeRarius with multiple LDAP
Sebastijan Šilec wrote
Sent: Wednesday, March 28, 2012 10:06 AM
DEFAULT Realm == mydomain.com, Freeradius-Proxied-To ==
127.0.0.1, Auth-Type := PAP
User-Name = `%{User-Name}`,
Fall-Through = yes
DEFAULT Realm == mydomain.com, Freeradius-Proxied-To ==
127.0.0.1, Autz-Type := LDAP
DEFAULT User-Name =~
^[Aa][Nn][Oo][Nn][Yy][Mm][Oo][Uu][Ss]|[Aa][Nn][Oo][Nn][Yy][Mm
][Oo][Uu][Ss]@mydomain.com,
Auth-Type := EAP
...
Wed Mar 28 15:17:25 2012 : Info: [suffix] Found realm mydomain.com
Wed Mar 28 15:17:25 2012 : Info: [suffix] Adding Realm =
mydomain.comi
Is that just a typo from anonymizing, or is there really an extra i there?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: load balancing and if statements
Scott McLane Gardner wrote: Sent: Tuesday, March 27, 2012 9:34 AM To: FreeRadius users mailing list Subject: Re: load balancing and if statements This is the answer. Also, this is much easier than what I was trying to do. Thank you for the pointer, Alan. -Scott I'd be surprised if using Ldap-Group in the user's file resulted in load balancing of the group membership queries to the LDAP servers. Does it? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: load balancing and if statements
Scott McLane Gardner I'd be surprised if using Ldap-Group in the user's file resulted in load balancing of the group membership queries to the LDAP servers. Does it? It does, actually. Or at least it appears to. The first time it used ldap2 and the second time it used ldap1. Probably you are seeing the auth checks load balance while the group membership checks are not. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: load balancing and if statements
Scott McLane Gardner
(A sensible wishlist item might be to have load-balance
sections in the
instantiate section register the same hooks as their
submodules, then
you'd be able to name the load-balance and use
lbr-modulename-Ldap-Group. But that sounds mildly hairy to
implement.)
Does this mean that what I want to do is not possible?
I don't know, but I'll probably look into it over the next week
or two, because I never looked too hard at the LDAP config
I inherited, and didn't realize it was not load-balancing those
requests myself, and in fact isn't even redundant, so I'll be
looking to fix that (thanks for pointing it out BTW.)
I would think you might be able to get at least fail-over
redundancy working using the XLAT %{%{thing1}:-%{thing2}} syntax,
but I'm unsure right now as to how the interaction between the
Ldap-Group check attribute and the XLAT mechanism works.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: load balancing and if statements
Scott McLane Gardner Wrote:
Here is the configuration I am attempting:
load-balance {
ldap1
if (Ldap-Group == NET Staff) {
I cannot answer your question about if statements, but this
much is clear: the Ldap-Group check attribute will query
the ldap module that was instantiated last. If you want
to query a specific module, you have to use modulename-Ldap-Group.
Similarly for ldap xlats, you have to use the module name.
(A sensible wishlist item might be to have load-balance sections
in the instantiate section register the same hooks as their
submodules, then you'd be able to name the load-balance and
use lbr-modulename-Ldap-Group. But that sounds mildly
hairy to implement.)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: can you internally proxy a request more than once?
Phil Mayers wrote: I'm not entirely sure I buy that it ensures only the outer server is affected; once compromised, the outer server can be used to send arbitrary UDP packets to the inner server since the sockets are already open. But I guess the same could be said of any perimeter defence architecture. True, it's just one layer. You still have some unnecessary code surface exposure what with EAP being processed on the internal server (unless you were to manage to somehow get tunneling of unwrapped MSCHAP working and do the EAP unwrap on the external server.) If you were going to do that, I would strongly recommend *not* transforming EAP-MSCHAPv2 into plain MSCHAP; the code that does this is hairy. In an exercise of folly I did try that. Then I tried letting it rewrap the EAP, but it didn't seem up for the task. Left it for future dull days. Normally I wouldn't be quite so bug-paranoid, but RADIUS is tied pretty tightly to the most security-sensitive and mission-critical systems we have. As in... what? It authenticates against your password database? I would have thought that all the internet-facing web properties would be rather more of a risk than radius requests coming from hosts with a shared secret. Well, I shouldn't go into that on a public forum. As far as SSO web services, there are things I'm responsible for, and things I am not. I don't worry too much about the latter :-) I'm wondering if you would feel all this was necessary if RadSec were in use? It is. Some decade from now it is also possible RadSec within eduroam will migrate to a more (PKI-based) peer-to-peer model, so if anything that's more hosts we'd be talking to. (As an aside, while the virtual server functionality is very useful when it comes to providing an integrated inner/outer tunnel solution, I've found it much more convenient to administer discrete usage cases with individual instances. Then you can do work on one server without worrying that a change will somehow have unintended consequences on other services when you reload the config.) This is something that we *do* use. Basically I have separate processes for wired macauth, local wireless/wired 802.1x, eduroam visited/SP, eduroam home/IdP, vpn mschap and so on. Same here, but the eduroam instances are each split into two (a 3.0 for radsec/filter and a system stock version for the internal.) The SP instance also allows our users to gain the same privileges (and be subject to the same NAC criteria) as they would on the normal SSID. That way they can configure for eduroam and never have to mess with changing profiles, but it also means that a crash of the instance that does this local authentication will strand my users and then the pitchfork closets will be raided, so I'd rather any problems that might occur when a guest makes us talk to the federation were isolated to guests only. The main reason is fault isolation; a long while ago (several years now) the occasional crash bug would surface in either the TLS or SQL code, and it was useful for this to be confined. This is the most tangible benefit, yes. Helps me sleep much sounder. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: can you internally proxy a request more than once?
Phil Mayers [p.may...@imperial.ac.uk] wrote I'm curious about what you mean here. I don't see the difference between a single server performing attribute filter auth, versus two separate processes. Can you explain what threat model you think this addresses? It limits the exposed fuzzable surface. Any vulnerabilities present or introduced in the low level RADIUS packet processing compromise only the external server. The packets that reach the internal server post-filter have been cleanly regenerated. The option also exists at that point to place the external server on an entirely different host, for DoS mitigation. You still have some unnecessary code surface exposure what with EAP being processed on the internal server (unless you were to manage to somehow get tunneling of unwrapped MSCHAP working and do the EAP unwrap on the external server.) Normally I wouldn't be quite so bug-paranoid, but RADIUS is tied pretty tightly to the most security-sensitive and mission-critical systems we have. (As an aside, while the virtual server functionality is very useful when it comes to providing an integrated inner/outer tunnel solution, I've found it much more convenient to administer discrete usage cases with individual instances. Then you can do work on one server without worrying that a change will somehow have unintended consequences on other services when you reload the config.) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: can you internally proxy a request more than once?
Not sure, but you should consider running non-virtual instances
(not that hard to do) and using privilage separation such that
there is little potential for exposure of your internal authentication
structure or internally-utilized crypto material to an externally
presented service.
Also, it is possible to get your local users to have local privileges
when using their eduroam-formatted credentials on the eduroam
SSID, just a bit tricky.
Here we run 4 instances for eduroam, two for IDP and two for SP
(one each 3.0 radsec proxy/filter and one 2.x internal.) Only the internal
sessions have any interaction with LDAP/SQL/AD.
From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org
[mailto:freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On
Behalf Of mark.le...@stfc.ac.uk
Sent: Friday, March 23, 2012 10:13 AM
To: freeradius-users@lists.freeradius.org
Subject: can you internally proxy a request more than once?
Hi,
I have been using FreeRADIUS to authenticate visitors onto a wireless network
using LDAP against Active Directory. I now need to also deploy eduroam.
I thought it would be sensible to do this as two separate virtual servers, so I
created a new minimal 'default' server that proxies to a 'visitors' or
'eduroam' virtual server based on the wireless SSID, which the wireless NAS
adds to an attribute in the Access-Request. The default server sets the
Proxy-To-Realm attribute in the list of control items. The Realm then maps to a
home_server in proxy.conf which has an associated virtual server e.g.
home_server virtual_server_for_eduroam {
type =auth+acct
virtual_server = eduroam
}
home_server_pool virtual_server_for_eduroam_pool {
home_server = virtual_server_for_eduroam
}
realm EDUROAM_VIRTUAL_SERVER {
pool = virtual_server_for_eduroam_pool
}
The 'visitors' virtual server works fine.
The 'eduroam' virtual server proxies the Access-Request to LOCAL or our
National RADIUS Proxy Servers depending on whether the realm in the User-Name
attribute is our realm or not. Local authentications are performed against
Active Directory, and so we are using PEAP-MS-CHAPv2. For local authentications
the inner MS-CHAPv2 authentications are proxied to the 'inner-tunnel' virtual
server.
If (for testing) I configure clients.conf so that Access-Requests from the
wireless NAS are always sent to the 'eduroam' virtual server, then it works
fine. The 'eduroam' virtual server doesn't work if it is called from the new
'default' server using internal proxying. In that case I get an error saying
Multiple levels of TLS nesting is invalid.
I'm running FreeRADIUS 2.1.11.
I may not have provided enough detail, but am I doing something that obviously
won't work? I don't know if it's possible to internally proxy a request more
than once, e.g. to two different virtual servers. If it isn't possible, do I
have any other options? Would a solution be to make the virtual servers listen
on two different IP addresses, and configure the NAS to use a different RADIUS
server IP address for each SSID? Alternatively, could the NAS continue to send
all RADIUS packets to one IP address, and the default server proxy to virtual
servers listening on different IP addresses?
Thanks in advance of any help you can give,
Have a good weekend,
Mark.
--
Scanned by iCritical.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: TCP/TLS - radsec / application
Jason Rohm wrote: I'm unclear about the state of radsec within the freeradius codebase. I've downloaded the current master source as of a few days ago and successfully compiled it on CentOS 6.2 64bit. Everything seems to work save some EAP stuff that I'm not using and was able to disable around, but I can't figure out if the radsec is there and not documented or if it isn't in there at all. -Is the radsec code included in the mainline git repo? -If not, where do I get it? The repository code has it, I have it up and working to our federation server, where they run radiator. Over the last few weeks some bugs have surfaced, but some have been patched already and I suspect the rest of the patches should land in the repository before too long. -If so, does anyone have any quick and dirty doc somewhere or a working example? The docs don't plaster the word RadSec everywhere it is just setting the protocol on home servers or listen directives to TCP and setting some additional options, as documented in etc/raddb/sites-available/tls (in the git tree, of course) (Dealing with the cert stuff is the most fiddly part of it and will help to have openssl expertise on hand.) -Am I nuts for even trying this? Only if your timeline does not allow several months for performance and long-term stability testing/patching, because you'll be bleeding edge at this point. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
sqltrace happens in non-debug mode, too
Good morning, A minor item (at least until your disk fills up): The inline help in sql.conf says the sqltrace option should not log to the SQL trace file unless the server is in debug mode. The rlm_sql manpage uses somewhat less specific language. I don't know what the current intent is, but either the code or docs need to be fixed, as the server is logging SQL queries while not being run in debug mode. This is hapenning in canned RHEL 2.1.10 and glossing over the 3.0 git code I don't see any checks for debug mode there either, and the documentation is the same in both. -- Brian - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: VPN
-Original Message- danegirl Wrote: At the moment all the customers are able to use all the VPN services (L2TP, PPTP,) I want to know how can I define user A can only use PPTP and user B can use L2TP and user C can use all the services? I wonder how should it define in FreeRadius This depends a lot on what your particular NAS sends to FreeRadius. You would want to capture packets from a PPTP request and from an L2TP reuest and compare them, to see of the NAS puts different information in any fields that would allow FreeRadius to tell the difference between PPTP and L2TP. A likely field would be the Framed-Protocol field. Once you have such a field, you can either add it as a check item in your users file (if you are using one) or use unlang to change the authorization step depending on the contents of that field. -- Brian - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: proxy server goes deaf after Client has closed connection (RadSec to home server)
Alan DeKok Wrote Brian Julin wrote: The latter makes me wonder why or if request_proxy_anew works at all. It was tested at one point. But the code has changed since then. Given the complexity of RADIUS state management, automating a comprehensive test suite for it would be a very interesting endeavor. It might even be worthy of a GSoC project proposal, to get an aspiring coder to flesh out src/tests, firing up test servers and VMs/fragrouters to really work the corner cases and cover previous issues from the ML/git-log against regressions. Not sure how far they would get, but they'd sure learn a lot about application internetworking by trying, and the resulting framework would probably be applicable to other heavily-interfaced server suites. It's nice to know that code was understandable. That... took a while. I even had to draw pictures. :-) If I ever do that again, maybe I'll finish them enough to submit them as devel docs. Thanks again for holding it all together, Alan. -- Brian - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: proxy server goes deaf after Client has closed connection (RadSec to home server)
Alan DeKok [al...@deployingradius.com] wrote:
Sent: Friday, March 09, 2012 3:25 AM
Brian Julin wrote:
This keeps the server listening, but there are some lingering issues:
Well, fixes are welcome.
I don't have time to look into this for a few weeks at least.
request_proxy_anew was assuming its argument would be installed in the
proxy_list, which wasn't the case, so it was removing it twice causing
.num_outgoing counters to roll over. Then, request_proxy was not expecting
the case where the argument was already in the proxy_list (put there by
request_proxy_anew) and was failing when attempting to add it a second
time. The latter makes me wonder why or if request_proxy_anew works at all.
The attached patch seems to do the trick. Some caveats:
This bypasses (for certain situations) the attempts to make sure that
a duplicate packet does not reuse the proxy_list ID of its predecessor.
Not knowing the reasoning behind that, I don't know if that's important
or not.
request_proxy has a retransmit flag as a parameter, which might be the
better test to avoid inserting the entry twice, or might not be.
Off topic, JOOC, while reading through the source I was left wondering what
prevents proxy_wait_for_reply from entering master-only functions from a
non-master thread when it falls through the DUP case into the TIMER case.
diff --git a/src/main/process.c b/src/main/process.c
index 4b5f084..f3b0c3f 100644
--- a/src/main/process.c
+++ b/src/main/process.c
@@ -1596,7 +1596,7 @@ static void remove_from_proxy_hash_nl(REQUEST *request)
request-proxy_listener = NULL;
/*
- * Got from YES in hash, to NO, not in hash while we hold
+ * Go from YES in hash, to NO, not in hash while we hold
* the mutex. This guarantees that when another thread
* grabs the mutex, the not in hash flag is correct.
*/
@@ -2264,7 +2264,7 @@ static int request_proxy(REQUEST *request, int retransmit)
/*
* We're actually sending a proxied packet. Do that now.
*/
- if (!insert_into_proxy_hash(request)) {
+ if (!request-in_proxy_hash !insert_into_proxy_hash(request)) {
radlog_request(L_PROXY, 0, request, Failed to insert initial packet into the proxy list.);
return -1;
}
@@ -2298,9 +2298,13 @@ static int request_proxy_anew(REQUEST *request)
/*
* Keep a copy of the old Id so that the
* re-transmitted request doesn't re-use the old
- * Id.
+ * Id. Note that in certain cases (socket crash)
+ * there is no Id as they have been purged from
+ * proxy_list, but there should still be a leftover
+ * packet hung off this request.
*/
RADIUS_PACKET old = *request-proxy;
+ int old_hash = request-in_proxy_hash;
home_server *home;
home_server *old_home = request-home_server;
#ifdef WITH_TCP
@@ -2327,7 +2331,7 @@ static int request_proxy_anew(REQUEST *request)
}
/*
- * Don't free the old Id on error.
+ * Don't free the old Id (if any) on error.
*/
if (!insert_into_proxy_hash(request)) {
radlog_request(L_PROXY, 0, request, Failed to insert retransmission into the proxy list.);
@@ -2335,16 +2339,18 @@ static int request_proxy_anew(REQUEST *request)
}
/*
- * Now that we have a new Id, free the old one
+ * Now that we have a new Id, free the old one (if any)
* and update the various statistics.
*/
PTHREAD_MUTEX_LOCK(proxy_mutex);
- fr_packet_list_yank(proxy_list, old);
- fr_packet_list_id_free(proxy_list, old);
- old_home-currently_outstanding--;
+ if (old_hash) {
+ fr_packet_list_yank(proxy_list, old);
+ fr_packet_list_id_free(proxy_list, old);
+ old_home-currently_outstanding--;
#ifdef WITH_TCP
- if (listener) listener-count--;
+ if (listener) listener-count--;
#endif
+ }
PTHREAD_MUTEX_UNLOCK(proxy_mutex);
/*
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Centos 6 Compile error
David Peterson Wrote: Sent: Tuesday, March 13, 2012 7:12 AM To: FreeRadius users mailing list Subject: Centos 6 Compile error Has anyone seen this error? I am not sure what might be missing: RHEL variants don't include EC support in OpenSSL due to some licensing/patent/whatnot issues. Just delete the src/modules/rlm_eap/types/rlm_eap_pwd source code directory and it will compile fine. It is likely you are not going to be using that submodule anyway. -- Brian - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: proxy server goes deaf after Client has closed connection (RadSec to home server)
Alan DeKok [al...@deployingradius.com] wrote Sent: Wednesday, March 07, 2012 3:52 AM To: FreeRadius users mailing list Subject: Re: proxy server goes deaf after Client has closed connection (RadSec to home server) Brian Julin wrote: (at this point the server does not see any additional requests sent to it, so we kill it to see if it is hanging out anywhere interesting... really should do this several times more to verify... maybe try a kill -9 next time...) It's hanging because it's trying to lock the proxy mutex twice. That's a no-no. I'll push a fix later today. This keeps the server listening, but there are some lingering issues: 10:40:31 : Info: (18) Proxying request to home server XXX.XXX.XXX.XXX port 2083 10:40:31 : Debug: Proxy is writing 123 bytes to SSL 10:40:31 : Debug: Thread 1 waiting to be assigned a request 10:40:31 : Debug: Proxy SSL socket has data to read 10:40:31 : Debug: Client has closed connection 10:40:31 : Info: ... closing socket proxy (YYY.YYY.YYY.YYY, 39314) - home_server (XXX.XXX.XXX.XXX, 2083) 10:40:31 : Debug: Waking up in 0.3 seconds. 10:40:31 : Debug: Waking up in 0.4 seconds. 10:40:31 : Debug: Waking up in 29.1 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 51126, id=247, length=147 10:40:34 : Debug: Opening new proxy (YYY.YYY.YYY.YYY, 0) - home_server (XXX.XXX.XXX.XXX, 2083) 10:40:34 : Debug: Trying SSL to port 2083 10:40:34 : Debug: Requiring Server certificate 10:40:34 : Debug: Listening on proxy (YYY.YYY.YYY.YYY, 41712) - home_server (XXX.XXX.XXX.XXX, 2083) 10:40:34 : Debug: No Post-Proxy-Type Fail: ignoring 10:40:34 : Debug: Waking up in 26.8 seconds. (... resends from the client don't work... This may or may not be time-window related...) rad_recv: Access-Request packet from host 127.0.0.1 port 51126, id=247, length=147 10:40:40 : Proxy: (18) Failed to insert entry into proxy list. 10:40:40 : Proxy: (18) Failed to insert initial packet into the proxy list. 10:40:40 : Debug: No Post-Proxy-Type Fail: ignoring 10:40:40 : Debug: Waking up in 20.9 seconds. rad_recv: Access-Request packet from host 127.0.0.1 port 51126, id=247, length=147 10:40:52 : Proxy: (18) Failed to insert entry into proxy list. 10:40:52 : Proxy: (18) Failed to insert initial packet into the proxy list. 10:40:52 : Debug: No Post-Proxy-Type Fail: ignoring 10:40:52 : Debug: Waking up in 8.9 seconds. 10:41:01 : Debug: Waking up in 4.9 seconds. 10:41:06 : Info: (18) Cleaning up request packet ID 247 with timestamp +4879 10:41:06 : Info: Ready to process requests. (...this next set of requests succeeds...) rad_recv: Access-Request packet from host 127.0.0.1 port 51126, id=251, length=147 10:48:06 : Debug: Waking up in 0.3 seconds. 10:48:06 : Debug: Thread 4 got semaphore 10:48:06 : Debug: Thread 4 handling request 19, (10 handled so far) (...) 10:48:06 : Info: (27) Finished request 27. 10:48:06 : Debug: Thread 2 waiting to be assigned a request 10:48:06 : Debug: Waking up in 0.1 seconds. 10:48:07 : Debug: Waking up in 4.1 seconds. 10:48:11 : Info: (19) Cleaning up request packet ID 251 with timestamp +5334 10:48:11 : Info: (20) Cleaning up request packet ID 177 with timestamp +5334 10:48:11 : Info: (21) Cleaning up request packet ID 59 with timestamp +5334 10:48:11 : Info: (22) Cleaning up request packet ID 56 with timestamp +5334 10:48:11 : Debug: Waking up in 0.1 seconds. 10:48:11 : Info: (24) Cleaning up request packet ID 183 with timestamp +5334 10:48:11 : Info: (25) Cleaning up request packet ID 243 with timestamp +5334 10:48:11 : Info: (26) Cleaning up request packet ID 134 with timestamp +5334 10:48:11 : Info: (27) Cleaning up request packet ID 128 with timestamp +5334 10:48:11 : Info: Ready to process requests. (...however, this can now happen on subsequent requests, or sometimes out of the blue. It doesn't always...) 10:56:37 : Debug: Proxy SSL socket has data to read 10:56:37 : Debug: Client has closed connection 10:56:37 : Info: ... closing socket proxy (YYY.YYY.YYY.YYY, 41712) - home_server (XXX.XXX.XXX.XXX, 2083) 10:56:37 : Error: Fatal error removing socket: (unknown error) [Thread 0x74f94700 (LWP 24568) exited] [Thread 0x75995700 (LWP 24567) exited] [Thread 0x76d97700 (LWP 24565) exited] [Thread 0x76396700 (LWP 24566) exited] (...That one above was from out of the blue. This one I put a breakpoint in and it happened while processing a request..) Breakpoint 1, event_new_fd (this=0x805790) at process.c:3715 3715 radlog(L_ERR, Fatal error removing socket: %s, (gdb) bt #0 event_new_fd (this=0x805790) at process.c:3715 #1 0x0043c718 in proxy_tls_recv (listener=0x805790) at tls_listen.c:499 #2 0x00430a9a in event_socket_handler (xel=value optimized out, fd=value optimized out, ctx=0x805790) at process.c:3327 #3 0x77deddfb in fr_event_loop (el=0x7d0c20) at event.c:415 #4
RE: status_check vs src_ipaddr
Alan DeKok wrote: Brian Julin wrote: It appears that a home server entry configured with src_ipaddr will use that source ip address for auth requests, but when directed to do status_check, it sends status request packets using some interface address from some other config item somewhere (not sure from which one yet.) Ah. That's an easy fix. ... A fix will go into the next release. Thank you again. In case it matters, I also was able to verify this happened with status_check=request as well. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
proxy server goes deaf after Client has closed connection (RadSec to home server)
It appears there was another layer to my latest issue. Sometimes a server using RadSec to proxy to a home server ends up just waiting around unable to see any more incoming requests, and not having completed the current request. In this case the server is 3.0, and is sandwiched between our internal instance and our federation server (doing radsecproxy-ish stuff.) This may only happen in a corner case when the federation server is taking a while to reply, perhaps in this case where it exceeds our internal instance's response_window. I'm testing now whether using an immense response_window on the internal instance works as a workaround (assuming the federation server doesn't have any prolonged issues, of course) which would help support that theory. Info: (32) Proxying request to home server XXX.XXX.XXX.XXX port 2083 Tue Mar 6 13:59:08 2012 : Debug: Proxy is writing 122 bytes to SSL Tue Mar 6 13:59:08 2012 : Debug: Thread 3 waiting to be assigned a request Tue Mar 6 13:59:08 2012 : Debug: Proxy SSL socket has data to read Tue Mar 6 13:59:08 2012 : Debug: Client has closed connection (though, the client is UDP which has no transport layer connection, so... maybe that's talking about the home server, not a client? Not sure if that's coming from listen.c or tls_listen.c) (at this point the server does not see any additional requests sent to it, so we kill it to see if it is hanging out anywhere interesting... really should do this several times more to verify... maybe try a kill -9 next time...) Program received signal SIGINT, Interrupt. 0x003c7520dff4 in __lll_lock_wait () from /lib64/libpthread.so.0 #0 0x003c7520dff4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003c75209328 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x003c752091f7 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x0042bb54 in remove_from_proxy_hash (request=0x805170) at process.c:1579 #4 0x0042d4f5 in request_done (request=value optimized out, action=value optimized out) at process.c:532 #5 0x0042f42d in remove_all_proxied_requests ( ctx=value optimized out, data=value optimized out) at process.c:1540 #6 0x77de7822 in WalkNodeInOrder (X=value optimized out, callback=0x42f400 remove_all_proxied_requests, context=0x7fffec003710) at rbtree.c:551 #7 0x00431354 in event_new_fd (this=0x7fffec003710) at process.c:3553 #8 0x0043c648 in proxy_tls_recv (listener=0x7fffec003710) at tls_listen.c:499 #9 0x00430a8a in event_socket_handler (xel=value optimized out, fd=value optimized out, ctx=0x7fffec003710) at process.c:3309 #10 0x77deddfb in fr_event_loop (el=0x7d0b10) at event.c:415 #11 0x00422534 in main (argc=value optimized out, argv=value optimized out) at radiusd.c:413 Just one of those occasions where the grass looks greener on the SEGV side of the fence :-) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Authentification
The password and the secret are two different things. When you set up FreeRadius you had to put a secret = line in the client clause for your NAS. You have to put that same secret in the NAS (don't ask us where, that depends on the NAS.) In your case your NAS is your AP or your LWAP/CWAP controller. The secret is used to encrypt sensitive fields in RADIUS packets. If it does not match on both ends, those fields look scrambled on the receiving end. From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of Javier Ruiz Escalante Sent: Monday, March 05, 2012 10:04 AM To: freeradius-users@lists.freeradius.org Subject: RE: Authentification Thank you very much, but the password is testsecret, I don't know why it shows this strange password, I don't know if it is related to the port 443, as in the server console is working perfectly with the password testsecret Thanks!! Regards Javier Ruiz Escalante Teléfono: 00 34 512 700 524 Skype: fruiz002 Date: Mon, 5 Mar 2012 06:46:01 -0800 From: whope...@vocollect.com To: freeradius-users@lists.freeradius.org Subject: Re: Authentification Hi, NOTE the section here: User-Name = mysqltest User-Password = O%:snv\nB\334Ξ\300H\035\235e And here Mon Mar 5 12:36:33 2012 : Info: [pap] login attempt with password O%:snv B��?�H??e Mon Mar 5 12:36:33 2012 : Info: [pap] Using clear text password testsecret Mon Mar 5 12:36:33 2012 : Info: [pap] Passwords don't match The password that the client is sending and the one listed in the DB are different. You will need to fix the client password or update the DB. --Ward -- View this message in context: http://freeradius.1045715.n5.nabble.com/Authentification-tp5537600p5537725.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
status_check vs src_ipaddr
Too late in the week to dig in like I should, but I was just diagnosing a problem and preliminary signs point to this: It appears that a home server entry configured with src_ipaddr will use that source ip address for auth requests, but when directed to do status_check, it sends status request packets using some interface address from some other config item somewhere (not sure from which one yet.) Also the source port on auth requests is usually taken from the OS dynamic range (high port numbers), but for some reason these are sourced from port 1647. Which is odd because I can't seem to grep 1647 out of the source code. Note the server sending these requests is a tad crusty (2.1.10) FWIW. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: RadSec FR3.0 to Radiator: Received packet will be too large
Thanks for looking into this, Alan. After merging this (and a bunch of other stuff that had built up) and rebuilding, this happens: Thu Feb 23 10:02:13 2012 : Debug: Opening new proxy (, 0) - home_server (XXX, 2083) Thu Feb 23 10:02:13 2012 : Debug: Trying SSL to port 2083 Thu Feb 23 10:02:13 2012 : Debug: Requiring Server certificate Thu Feb 23 10:02:14 2012 : Debug: Listening on proxy (YY, 59751) - home_server (XXX, 2083) Sending Access-Request of id 51 to port 2083 User-Name = UU NAS-IP-Address = NAS-Identifier = Airespace-Wlan-Id = V Framed-MTU = 1300 EAP-Message = snip Message-Authenticator = snip Proxy-State = 0x313433 Proxy-State = 0x3735 Thu Feb 23 10:02:14 2012 : Info: (0) Proxying request to home server port 2083 Thu Feb 23 10:02:14 2012 : Debug: Proxy is writing 150 bytes to SSL Thu Feb 23 10:02:14 2012 : Debug: Thread 4 waiting to be assigned a request Thu Feb 23 10:02:14 2012 : Debug: Waking up in 0.4 seconds. Program received signal SIGSEGV, Segmentation fault. 0x0043c6a7 in proxy_tls_recv (listener=0x700024d0) at tls_listen.c:478 478 if (!sock-data) sock-data = rad_malloc(listener-tls-fragment_size); Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.47.el6.x86_64 keyutils-libs-1.4-3.el6.x86_64 krb5-libs-1.9-22.el6_2.1.x86_64 libcom_err-1.41.12-11.el6.x86_64 libselinux-2.0.94-5.2.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-20.el6.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) print sock $1 = (listen_socket_t *) 0x700047a0 (gdb) print sock-data $2 = (uint8_t *) 0x0 (gdb) print listener $3 = (rad_listen_t *) 0x700024d0 (gdb) print listener-tls $4 = (fr_tls_server_conf_t *) 0x0 From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of Alan DeKok [al...@deployingradius.com] Sent: Thursday, February 23, 2012 4:12 AM To: FreeRadius users mailing list Subject: Re: RadSec FR3.0 to Radiator: Received packet will be too large Brian Julin wrote: We're piloting RadSec as a federation server uplink. They use Radiator. When we first attempted to connect we'd get a Received packet will be too large! carp from main/tls.c. They checked on their end and say they have no fragment size option for RadSec TLS connections, only for EAP-TLS connections. So we applied the below as a test and it works, but I was wondering as to the wisdom of it... I've pushed a more functional fix. It now allocates the receive buffer based on fragment_size. If the RadSec connection sends too much data, the server prints out an error saying: ... set fragment_size=16384 Or whatever value will allow it to receive the data. I've also updated the comments about fragment_size in raddb/sites-available/tls Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: RadSec FR3.0 to Radiator: Received packet will be too large
-Original Message- From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.or g [mailto:freeradius-users-bounces+bjulin=clarku.edu@lists.freer adius.org] On Behalf Of Alan DeKok Sent: Thursday, February 23, 2012 10:31 AM Subject: Re: RadSec FR3.0 to Radiator: Received packet will be too large Oops. Do a git pull, and I think it should be fixed. That seems to have done the trick. I also tested the codepath that prints an error when fragment_size is too small, and that works fine, too. Thanks, again, very much. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RadSec FR3.0 to Radiator: Received packet will be too large
Hello again, We're piloting RadSec as a federation server uplink. They use Radiator. When we first attempted to connect we'd get a Received packet will be too large! carp from main/tls.c. They checked on their end and say they have no fragment size option for RadSec TLS connections, only for EAP-TLS connections. So we applied the below as a test and it works, but I was wondering as to the wisdom of it... diff --git a/src/main/tls.c b/src/main/tls.c index 10caec4..947409f 100644 --- a/src/main/tls.c +++ b/src/main/tls.c @@ -2709,7 +2709,7 @@ int proxy_tls_recv(rad_listen_t *listener) size_t length; listen_socket_t *sock = listener-data; char buffer[256]; - uint8_t data[1024]; + uint8_t data[2048]; RADIUS_PACKET *packet; RAD_REQUEST_FUNP fun = NULL; - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: merging two systems
Blake Hudson [bl...@ispn.net] writes: What is the preferred method to configure freeradius to authenticate two sets of users out of two databases? Should I look at running multiple instances of freeRADIUS or can I utilize both databases with one instance? This should be doable by defining multiple named sql instances, then, based on the criteria you use to separate sessions for the two services, invoke one or the other of them by name appropriately. Basically look for every place in the configs where the sql module is called, either as a directive, or inside a string xlat, and you would have to multiplex each of those statements to use the appropriate name (instead of sql) in the appropriate case. Also, multiple instances of FreeRADIUS are not hard to do, and can sometimes be preferable is you would like to add a bit more partitioning from a security perspective, but each will require its own port and/or IP address so your NAS flexibility may play a part in that decision. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Next release of the server?
Alan DeKok wrote:
If you run 3.0 on 2.x dictionaries
Don't. Just... don't.
In that case, it might help to document the dictionary = main configuration
item.
Patch attached.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
diff --git a/raddb/dictionary.in b/raddb/dictionary.in
index 7e84794..fa7076b 100644
--- a/raddb/dictionary.in
+++ b/raddb/dictionary.in
@@ -2,6 +2,10 @@
# This is the master dictionary file, which references the
# pre-defined dictionary files included with the server.
#
+# Usually this file is located in ${raddbdir}/dictionary,
+# however, servers configured with a dictionary = PATH
+# directive will source from ${dictionary}/dictionary instead.
+#
# Any new/changed attributes MUST be placed in this file, as
# the pre-defined dictionaries SHOULD NOT be edited.
#
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: SQL Statement in users file
McSparin, Joe wrote:
Does anyone know if there is a way in the users file to set
the Tunnel-Private-Group-id = some_default_vlan if the
following sql statement comes back blank.
DEFAULT Auth-Type = ntlm_auth
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-id = %{sql:SELECT
radius.vlans.assigned_vl an FROM radius.vlans WHERE
radius.vlans.device_mac = '%{Calling-Station-Id}'}
maybe %{%{sql:SELECT radius.vlans.assigned_vl an FROM radius.vlans WHERE
radius.vlans.device_mac = '%{Calling-Station-Id}'}:-some_default_vlan}
?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Next release of the server?
Alan DeKok [al...@deployingradius.com] wrote: Brian Julin wrote: Add to this, IIRC there are some differences (regressions?) in regexp support in some ancillary files (e.g. users) I don't recall that... it *should* be compatible. For example, a line like this in a hints file: DEFAULT User-Name =~ foo ...which works for a 2.x server will cause this: hints_test[4]: Parse error (check) for entry DEFAULT: No regular expression found in User-Name rlm_preprocess: Error reading hints_test ...in 3.0 I tried to track it down at the time, but I got pretty lost. It seemed like an extra token was being dropped into the processing, but that's a wild-ass guess. At the time I didn't know whether the syntax had changed for regexp in check lines, so wasn't sure whether it was a bug or not, and I was leaning towards ditching hints in favor of unlang anyway. and a minor dictionary entry glitch that need to be worked around to use 3.0 in a 2.x config tree. Which is... ? If you run 3.0 on 2.x dictionaries you need to exclude dictionary.dhcp because something in there does this: including dictionary file /etc/raddb/dictionary Errors reading dictionary: dict_init: /usr/share/freeradius/dictionary.dhcp[202]: Type tlv can only be for format=1,1. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Using FreeRadius to override VLAN Assignment
The first order of business would be to freeradius in debug mode, or launch an eapol_test client against it, and look to see whether the attribute is being sent. If you do not know whether the attribute is being sent, you cannot determine whether it is the AP or the freeradius server that needs fixing. From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of McSparin, Joe Sent: Wednesday, January 04, 2012 11:00 AM To: FreeRadius users mailing list Subject: Using FreeRadius to override VLAN Assignment I have put the following into my users files DEFAULT Auth-Type = ntlm_auth Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-id = 1001 I have told my access point to Allow RADIUS Override on the VLAN Assignment however the VLAN is not getting overridden. Does the Above entry into my users file not actually send back a vlan assignment and if not is there somewhere else this is supposed to be done? Joseph R. McSparin Network Administrator Hill Country Memorial Hospital 830 990 6638 phone 830 990 6623 fax jmcspa...@hillcountrymemorial.org This email message and any attachments are for the sole use of the intended recipient(s) and contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Next release of the server?
Add to this, IIRC there are some differences (regressions?) in regexp support in some ancillary files (e.g. users) and a minor dictionary entry glitch that need to be worked around to use 3.0 in a 2.x config tree. I managed to future proof most of my configs already by installing 3.0 in a separate directory and running/debugging with -d /etc/raddb -n confname.conf -fxx -l stdout and fixing anything that broke. It wasn't too hard in my case. YMMV. -Original Message- From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of Alan Buxey Sent: Wednesday, January 04, 2012 1:00 PM To: FreeRadius users mailing list Cc: Alan DeKok Subject: Re: Next release of the server? Hi, Will 3.0 be configuration compatible with 2.0? no - it is currently not - mainly because of the new methods used int he SQL/LDAP etc servers. the current config is now different to the old config...and the old config will cause the new server to fail at startup. as the new features are fundamental to its operation, having some '-compat' flag to stop new features working would be pointless - as the new code is designed around the new features. 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
RE: Using FreeRadius to override VLAN Assignment
A few things -- I do note the case doesn't match (-id vs -Id) in your original paste. Second, even though the value of 16 is not what you want, even if you get that fixed, note that it is not being copied to the outer reply (e.g. with use_tunelled_reply in peap, or maybe you are filtering it away in ./attrs.) (Also note that once you get that working, it should work, but there are some Cisco devices that instead want Cisco-AVPair += tunnel-private-group-id=XXX, though I have only seen this on wired switches not APs.) From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of McSparin, Joe Sent: Wednesday, January 04, 2012 1:37 PM To: FreeRadius users mailing list Subject: RE: Using FreeRadius to override VLAN Assignment Here is my radiusd -X it looks to me like the Access-Accept is not returning the vlan with it. # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/inner-tunnel } # server inner-tunnel [peap] Got tunneled reply code 2 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = 16 MS-MPPE-Encryption-Policy = 0x0001 MS-MPPE-Encryption-Types = 0x0006 MS-MPPE-Send-Key = 0xa15daac8db91138c9543ff1dd79193d8 MS-MPPE-Recv-Key = 0x5b23ada7251bf55e939f78211bc91ee9 EAP-Message = 0x030a0004 Message-Authenticator = 0x User-Name = jmcsparin [peap] Got tunneled reply RADIUS code 2 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = 16 MS-MPPE-Encryption-Policy = 0x0001 MS-MPPE-Encryption-Types = 0x0006 MS-MPPE-Send-Key = 0xa15daac8db91138c9543ff1dd79193d8 MS-MPPE-Recv-Key = 0x5b23ada7251bf55e939f78211bc91ee9 EAP-Message = 0x030a0004 Message-Authenticator = 0x User-Name = jmcsparin [peap] Tunneled authentication was successful. [peap] SUCCESS ++[eap] returns handled Sending Access-Challenge of id 199 to 10.1.1.50 port 35858 EAP-Message = 0x010b002b19001703010020c4f38e69d73c88a387eba5b0923e812f7d609d6c9d329f90acd78fc19eb2381f Message-Authenticator = 0x State = 0x11074b60180c524471e7db294b4fecfb Sending Access-Accept of id 200 to 10.1.1.50 port 35858 MS-MPPE-Recv-Key = 0x3d7918ad48100976d9f4db012a50f82b6dba74d3777f6bdca2648b0db3eb9650 MS-MPPE-Send-Key = 0xd4fcd3d81bc0e75431a4baa52fff9b7dce70f1cf1025fe2aac060f30f45b35bb EAP-Message = 0x030b0004 Message-Authenticator = 0x User-Name = jmcsparin Finished request 49. Joseph R. McSparin Network Administrator Hill Country Memorial Hospital 830 990 6638 phone 830 990 6623 fax jmcspa...@hillcountrymemorial.org From: freeradius-users-bounces+jmcsparin=hillcountrymemorial@lists.freeradius.org [mailto:freeradius-users-bounces+jmcsparin=hillcountrymemorial@lists.freeradius.org] On Behalf Of Brian Julin Sent: Wednesday, January 04, 2012 10:49 AM To: FreeRadius users mailing list Subject: RE: Using FreeRadius to override VLAN Assignment The first order of business would be to freeradius in debug mode, or launch an eapol_test client against it, and look to see whether the attribute is being sent. If you do not know whether the attribute is being sent, you cannot determine whether it is the AP or the freeradius server that needs fixing. From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of McSparin, Joe Sent: Wednesday, January 04, 2012 11:00 AM To: FreeRadius users mailing list Subject: Using FreeRadius to override VLAN Assignment I have put the following into my users files DEFAULT Auth-Type = ntlm_auth Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-id = 1001 I have told my access point to Allow RADIUS Override on the VLAN Assignment however the VLAN is not getting overridden. Does the Above entry into my users file not actually send back a vlan assignment and if not is there somewhere else this is supposed to be done? Joseph R. McSparin Network Administrator Hill Country Memorial Hospital 830 990 6638 phone 830 990 6623 fax jmcspa...@hillcountrymemorial.org This email message and any attachments are for the sole use of the intended recipient(s) and contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original
RE: Domain Group Authentication
Automate an export of the list of WiFi MAC addresses of your managed computers from the DC. Then in post-auth, query that list (we use an SQL database) and use the result to alter the tunnel-group-ID sent back in the outer reply. Users can spoof their MAC addresses, of course, but as long as you are doing this mainly to contain contagion rather than high security, it is satisfactory. The other option in a managed environment is of course to use TLS for the managed computers and install certs. You could even embed the MAC address into the cert and check that that matches the Calling-Station-ID. Still spoofable, of course, but barring a hardware crypto solution, everything is to a pro. From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of McSparin, Joe [jmcspa...@hillcountrymemorial.org] Sent: Tuesday, December 27, 2011 5:51 PM To: FreeRadius users mailing list Subject: Domain Group Authentication I currently have FreeRadius setup to authenticate agains Active Directory and it works great. I was wondering though for everyone out there using it if you had any reccomendations for this scenario: I have users that will connect wirelessly using their NT domain username and password on the hospitals wireless devices. I also however have doctors that will bring in their own laptops and connect. When they connect with their laptops though I do not want them to have the same privileges as when they connect on the hospital wireless devices. If they are connecting with their laptops even though they use their Ntdomain user name and password I want to restrict them to a public vlan. Joseph R. McSparin Network Administrator Hill Country Memorial Hospital 830 990 6638 phone 830 990 6623 fax jmcspa...@hillcountrymemorial.org This email message and any attachments are for the sole use of the intended recipient(s) and contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[PATCH] Fix debug output in auth.c
The attached patch fixes a parameter juxtaposition and a couple broken RDEBUG
statements
in auth.c that were trying to print vp_strvalue of a VALUE_PAIR of type integer.
I haven't looked but there could very well be other instances of this over in
the accounting area,
and the Session-Type in auth.c may also need a similar fix. I don't use those
codepaths.
diff --git a/src/main/auth.c b/src/main/auth.c
index 6a392be..30e6350 100644
--- a/src/main/auth.c
+++ b/src/main/auth.c
@@ -188,7 +188,7 @@ static int rad_check_password(REQUEST *request)
auth_type = auth_type_pair-vp_integer;
auth_type_count++;
dv = dict_valbyattr(PW_AUTH_TYPE,
-auth_type_pair-vp_integer, 0);
+0, auth_type_pair-vp_integer);
RDEBUG2(Found Auth-Type = %s,
(dv != NULL) ? dv-name : ?);
@@ -426,7 +426,12 @@ int rad_postauth(REQUEST *request)
*/
vp = pairfind(request-config_items, PW_POST_AUTH_TYPE, 0);
if (vp) {
- RDEBUG2(Using Post-Auth-Type %s, vp-vp_strvalue);
+ DICT_VALUE *dv;
+ dv = dict_valbyattr(PW_POST_AUTH_TYPE,
+0, vp-vp_integer);
+
+ RDEBUG2(Using Post-Auth-Type %s,
+ (dv != NULL) ? dv-name : ?);
postauth_type = vp-vp_integer;
}
result = module_post_auth(postauth_type, request);
@@ -602,7 +607,11 @@ autz_redo:
if (!autz_retry) {
tmp = pairfind(request-config_items, PW_AUTZ_TYPE, 0);
if (tmp) {
- RDEBUG2(Using Autz-Type %s, tmp-vp_strvalue);
+ DICT_VALUE *dv;
+ dv = dict_valbyattr(PW_AUTZ_TYPE, 0, tmp-vp_integer);
+
+ RDEBUG2(Using Autz-Type %s,
+(dv != NULL) ? dv-name : ?);
autz_type = tmp-vp_integer;
autz_retry = 1;
goto autz_redo;
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: certificate compatibility
The big box of exclamation points talking about certificates in the debug log happens any time an EAP session does not complete all the way. It is not always a certificate problem, just if you are only having trouble with certain types of clients and other types connect fine, then that is a good place to look for trouble. -Original Message- From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of Erick Rojas Bastidas Sent: Wednesday, December 21, 2011 10:48 AM To: freeradius-users@lists.freeradius.org Subject: RV: certificate compatibility I did certificates with xpextensions and install the CA cert in the client.. But the debug output of freeradius displays a warning of compatibility certificate.. This may be the problem?? Enviado desde mi dispositivo movil BlackBerry(r) de Digitel. -Original Message- From: erickj_roj...@hotmail.com Date: Wed, 21 Dec 2011 14:24:28 To: freeradius-users@lists.freeradius.org Reply-To: erickj_roj...@hotmail.com Subject: Acces-Accept, but connectivity is almost zero Hi all, thanks for your help! I have the CA certificate installed on the client, and freeradius -X responded with an 'Acces-Accept', but connectivity is almost zero, received packets are very few.. This could be due to problems of the certificate?? Enviado desde mi dispositivo movil BlackBerry(r) de Digitel. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Reading winbind reply failed!
Add any users (like yourself, or the user RADIUS is running as) that need to use winbind to the winbindd_priv in /etc/group. -Original Message- From: freeradius-users-bounces+bjulin=clarku@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku@lists.freeradius.org] On Behalf Of Erick Rojas Bastidas Sent: Tuesday, December 20, 2011 10:34 AM To: freeradius-users@lists.freeradius.org Subject: RV: Reading winbind reply failed! If run the command winbindd -i receive 'invalid permissions on socket directory /var/run/samba/winbindd_privileged' Winbindd_setup_listeners() failed.. Why is this? What are the correct permissions? I have: dwrx-x--- 2 freerad winbindd_priv 4096 dic 16 09:09 winbindd_privileged. Help me please!! Enviado desde mi dispositivo movil BlackBerry(r) de Digitel. -Original Message- From: erickj_roj...@hotmail.com Date: Tue, 20 Dec 2011 13:22:21 To: freeradius-users@lists.freeradius.org Reply-To: erickj_roj...@hotmail.com Subject: RV: Reading winbind reply failed! Help please!! Enviado desde mi dispositivo movil BlackBerry(r) de Digitel. -Original Message- From: erickj_roj...@hotmail.com Date: Tue, 20 Dec 2011 13:20:50 To: Alan Buxeya.l.m.bu...@lboro.ac.uk Reply-To: erickj_roj...@hotmail.com Subject: Re: Reading winbind reply failed! Hi Alan, Yes, I do 'net ads join' and responds with Using short domain name -- Worgroup Joined 'machine' to realm 'domain' No DNS domain configured for freeradius. Unable to perform DNS update. DNS update failed! You know why this problem with winbind? Appreciate your help.. Thank you! Enviado desde mi dispositivo movil BlackBerry(r) de Digitel. -Original Message- From: Alan Buxey a.l.m.bu...@lboro.ac.uk Date: Mon, 19 Dec 2011 21:39:12 To: erickj_roj...@hotmail.com Subject: Re: Reading winbind reply failed! Hi, If run the command ntlm_auth responds with: Could not obtain winbind separator! sounds to me linke winbindd isnt running - the winbindd and smbd processes must both be running...and you did 'net ads join' process as per the docs, yes? 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
Inner tunnel external proxy fails under stress due to zero vectors
Greetings,
While testing a setup that uses inner tunnel proxying I was
noticing that there were spurious failures if the setup was
stress tested.
I managed to eliminate back-end latency as a possible cause
by testing instead to a simple auth against rlm_passwd (with
NTLM crypts.) I also tried with both servers running recent
3.0 repo code, so it's a problem that has likely been there at
least from 2.1.10.
After a long dig through the debugs, finally I noticed from
a packet dump that packets with 0x00 vectors were hitting
the wire, and when IDs were recycled that of course results
in false duplicates (as well as the other crypto-related
issues with that.)
The packets with the 0x00 vectors were the inner-tunneled
packets emitted from the proxying server. If I understand things
right, these packets are generated by the EAP modules allocating
a fake request, which is passed back through as if the server
were handling the inner tunnel itself, and then when the proxy
codepath is taken, this fake packet is then recycled as the outgoing
request to the home server.
Looking through the source we have this warning in
request_alloc_fake src/main/utils.c:
/*
*This isn't STRICTLY required, as the fake request MUST NEVER
*be put into the request list. However, it's still reasonable
*practice.
*/
...however this seems to be just what is happening. In fact, if
above that I change:
diff --git a/src/main/util.c b/src/main/util.c
index 94ee443..e6a1a26 100644
--- a/src/main/util.c
+++ b/src/main/util.c
@@ -437,7 +437,7 @@ REQUEST *request_alloc_fake(REQUEST *request)
*/
fake-server = request-server;
- fake-packet = rad_alloc(0);
+ fake-packet = rad_alloc(1);
if (!fake-packet) {
request_free(fake);
return NULL;
...then the setup passes stress testing just fine.
Trouble is I'm not sure if there are ramifications to doing that...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
