radsecproxy

radsecproxy@lists.nordu.net

72 discussions

radsecproxy-1.8.2 released
by Fabian Mauchle 07 Aug '20

07 Aug '20

Dear radsecproxy community, It took way too long, but finally I can announce the release of radsecproxy-1.8.0. Get it on https://radsecproxy.github.io It's just some bugfixes for now, but 1.9 is already in the works and hopefully will be ready in the not too distant future. A big thank you to all contributors! Best regards, Fabian -- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39 fabian.mauchle(a)switch.ch, http://www.switch.ch

1 0

Rewrite not working correctly
by Marc Sauer 11 Feb '20

11 Feb '20

Hello, I need to setup a rewrite, that removes the realm when forwarded to the local Radius server. I've already set up a rewrite with the following content: modifyAttribute 1:/^(.*)@mydomain.de$/\1/ My local radius server only accept usernames without the realm. When I include the realm in the server block of the config file nothing is changing. The only way it works is when I include it in the client block. There is a problem when including it in the client block, though: Since the realm is removed so early, radsecproxy thinks that it's a user from another organization and forwards it to the top level radius server. That's not what I want. So I need the following setup: User tries to log in with realm @example.com -> Radsecproxy sees thats it's coming from my organization -> Radsecproxy looks into the server block of my local radius -> Before sending the request to my local radius, it removes the @example.com from the username. Can anyone help me with that setup? I hope my explanation was clear enough. Thank you and greetings from Cologne, Germany. -- Marc Sauer Linux Systems Administrator Kunsthochschule für Medien Köln/ Academy of Media Arts Cologne Peter-Welter-Platz 2 50676 Köln https://www.khm.de https://en.khm.de

2 1

Error while connecting using TLS 1.3
by Marc Sauer 29 Nov '19

29 Nov '19

Hello, I'm currently setting up our radsecproxy for the use with Eduroam. The TLS connection seems to be not possible though. When I try to start the daemon, I get the following error in the log file: sslreadtimeout: SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca My certificate is definetly valid and I've configured the right certificate chain. When I try to connect to the federation radius server (by DFN here in Germany) manually with openssl s_client it works, but only using tls 1.0,tls 1.1 and tls 1.2. It does not work with TLS 1.3. Any idea why this is happening? So the real problem is: It works with all other TLS versions, but not 1.3. Is there a way to force OpenSSL lib to use only 1.2 somehow? Thank you in advance to you all. Marc Sauer -- Marc Sauer Linux Systems Administrator Kunsthochschule für Medien Köln/ Academy of Media Arts Cologne Peter-Welter-Platz 2 50676 Köln https://www.khm.de https://en.khm.de

4 9

Problem with some values of secret string ?
by Christian Claveleira 22 Oct '19

22 Oct '19

3 6

Re: [radsecproxy] radsecproxy with fticks
by Fabian Mauchle 23 Sep '19

23 Sep '19

Hi Ramzi, On 23.09.19, 13:40, "radsecproxy on behalf of Ramzi Abdallah" <radsecproxy-bounces(a)lists.nordu.net on behalf of rsa(a)aub.edu.lb> wrote: Greetings, I'm trying to compile radsecproxy-1.8.0 with fticks. For some reason the configure script does not recognize the --enable-fticks option. When I run ./configure --enable-fticks I get the bellow error message: [root@eduroam radsecproxy-1.8.0]# ./configure --enable-fticks configure: WARNING: unrecognized options: --enable-fticks Any help is greatly appreciated. There is no need to specify fticks with configure. This feature is always available. (maybe you got an old guide somewhere... fticks was included in the default compile with radsecproxy 1.7.1) Best Regards, Fabian -- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39 fabian.mauchle(a)switch.ch, http://www.switch.ch

1 0

radsecproxy with fticks
by Ramzi Abdallah 23 Sep '19

23 Sep '19

Greetings, I'm trying to compile radsecproxy-1.8.0 with fticks. For some reason the configure script does not recognize the --enable-fticks option. When I run ./configure --enable-fticks I get the bellow error message: [root@eduroam radsecproxy-1.8.0]# ./configure --enable-fticks configure: WARNING: unrecognized options: --enable-fticks Any help is greatly appreciated. Regards, Ramzi

2 2

Re: [radsecproxy] Rather severe bug in 1.8.0 : secret field content erroneously interpreted
by Guy Halse 12 Sep '19

12 Sep '19

Hi Whatever software you use, you need to deal with some sort of escaping of user-supplied secrets because you can't predict what characters may be used. In FreeRADIUS, quote characters and spaces would be problematic in secrets; in radsecproxy, percents and spaces are. We deal with the escaping in the script that generates our radsecproxy configuration. I've some python I could share when I get back to a real PC. - Guy Sent from my cell phone. Please excuse brevity and spelling. On 12 Sep 2019 16:47, Christian Claveleira <Christian.Claveleira(a)renater.fr> wrote: Fabian Mauchle wrote on 12/09/2019 15:54: > Hi Christian, > > On 12.09.19, 15:34, "radsecproxy on behalf of Christian Claveleira" <radsecproxy-bounces(a)lists.nordu.net on behalf of Christian.Claveleira(a)renater.fr> wrote: > it seems the content of the secret string is interpreted when it contains a "%" : > > when a client (or server) declaration contains > secret fht8CD%E7am > > it is interpreted as > getgenericconfig: block client xxxx.yyyyy: secret = fht8CDçam > > One can see "%E7" is translated as the "ç" character. > > This case is mentioned in the manpage radsecproxy.conf(5): > If you want to write a % and not use this decoding, you may of course write % in hex; i.e., %25. > > Regards, > Fabian > > -- > SWITCH > Fabian Mauchle, Network Engineer > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland > Phone +41 44 268 15 30, direct +41 44 268 15 39 > fabian.mauchle(a)switch.ch, http://www.switch.ch > Hi Fabian, Sorry for not have seen that but we don't choose the secrets used : the clients/servers administrators choose their secret which are put in configuration files for FreeRadius (in production) and radsecproxy (for evaluation). It's not expected to have to translate the content of the secret string :-\. Regards, Christian

1 0

Rather severe bug in 1.8.0 : secret field content erroneously interpreted
by Christian Claveleira 12 Sep '19

12 Sep '19

Hi, it seems the content of the secret string is interpreted when it contains a "%" : when a client (or server) declaration contains secret fht8CD%E7am it is interpreted as getgenericconfig: block client xxxx.yyyyy: secret = fht8CDçam One can see "%E7" is translated as the "ç" character. Result : clients and/or servers who use a secret containing substring "%hh" are rejected ! I suspect the function unhex() in gconfig.c to be the culprit... Christian

2 2

No space in realm regexp ?
by Christian Claveleira 11 Sep '19

11 Sep '19

1 0

radsecproxy-1.8.0 released
by Fabian Mauchle 04 Jul '19

04 Jul '19

Dear radsecproxy community, I'm very happy to announce the release of radsecproxy-1.8.0. Get it on https://radsecproxy.github.io The main focus of this release is attribute-rewrite, new options for status-server and new options for checking certificates. A big thank you to all who helped to enhance, test and fix radsecproxy! Best regards, Fabian -- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39 fabian.mauchle(a)switch.ch, http://www.switch.ch

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

radsecproxy