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
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.dehttps://en.khm.de
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.dehttps://en.khm.de
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
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
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
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
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
