Using variables in unlang conditions

Fri Feb 25 13:28:53 UTC 2022

I put it in the authorize section of the default virtual server, just
before if conditions. So this file is not considered a "configuration file"
:) I just put definitions to the end of the radiusd.conf file, try to start
in debug mode with freeradius -X, getting the same error:

((&Packet-Src-IP-Address < ${etu_aruba_wlc_rektorluk})   ^ Failed to parse
value for attribute

bottom of radiusd.conf
#### VARIABLES  #############################
etu_aruba_wlc_rektorluk = 10.10.243.0/24
etu_aruba_wlc_ogrenci_merkezi = 10.10.244.0/24

I read all the documentation about using variables already. But it seems I
miss something.

Rahman Duran

Message: 2
> Date: Thu, 24 Feb 2022 09:51:13 -0500
> From: Alan DeKok <aland at deployingradius.com>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: Using variables in unlang conditions
> Message-ID: <701442B2-1FCC-4232-BCF2-85A83572176E at deployingradius.com>
> Content-Type: text/plain;       charset=us-ascii
>
> On Feb 24, 2022, at 5:50 AM, Rahman Duran <rahman.duran at erzurum.edu.tr>
> wrote:
> > I am trying to do some filtering/policing in the authorize section of the
> > default virtual server. I need to check source ip matches our Wireless
> > Controllers and SSID and username format etc then decide what to do with
> > the request. How can I user some kind of alias/variable for our IP
> address
> > block so I should not need to write and update IP addresses multiple
> places?
>
>   You can edit raddb/dictionary to define local attributes.  Or, if the
> values don't change too often (i.e. rarely), you can out them into the
> configuration files themselves.
>
> > Here sample of what I try to achieve:
> >
> > //////////////////////
> > etu_aruba_wlc_001 = 10.10.243.0/24
> > etu_aruba_wlc_002 = 10.10.244.0/24
> > etu_aruba_wlc_002 = 10.10.245.0/24
>
>   You can just put that at the bottom of radiusd.conf.
>
>   Where did you put the above text?  Into a configuration file?  Which
> one?  Or some other file?  If so, how is the server supposed to find it?
>
> >  ### 001: Test Wifi Service ###
> >  *if ((&Packet-Src-IP-Address < ${etu_aruba_wlc_001}) \*
>
>   Then that will work.
>
>   There are many examples of this.
>
> > Well using variables (${...}) in conditions not working, Freeradius
> > daemon not starting with parse error:
> >
> > /etc/freeradius/3.0/sites-enabled/default[40]:
> > ((&Packet-Src-IP-Address < *${etu_aruba_wlc_001})
> > *      && (&NAS-Port-Type == "Wireless-80...
> > /etc/freeradius/3.0/sites-enabled/default[40]:
>   ^
> > Failed to parse value for attribute
>
>   Because you didn't define "etu_aruba_wlc_001" anywhere.
>
>   There are many examples of using variables defined in configuration
> files.  It works.  You just have to define the variables in the
> configuration files...
>
>   Alan DeKok.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 24 Feb 2022 10:08:39 -0500
> From: Alan DeKok <aland at deployingradius.com>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: Advice on RADIUS security and MD5 encryption?
> Message-ID: <0B7CD3D0-8BD3-4773-BFDD-7700C1A01B7F at deployingradius.com>
> Content-Type: text/plain;       charset=us-ascii
>
> On Feb 24, 2022, at 4:39 AM, Ole Holm Nielsen via Freeradius-Users <
> freeradius-users at lists.freeradius.org> wrote:
> >
> > We're using the pam_radius module for SSH login authentication on a
> CentOS 7 server.  Our university's RADIUS server is a Microsoft Windows
> server. This seems to work well.
> >
> > Some of my colleagues are wary about using RADIUS for authentication
> because the network traffic is encrypted with the obsolete MD5 algorithm.
>
>   The real question is: "Has anyone broken the encryption method used by
> RADIUS?"
>
>   The answer is "no".
>
> > I would like to understand if this is a relevant objection or not for
> the present case.
>
>   It's not relevant.
>
> >  The Wikipedia article https://en.wikipedia.org/wiki/RADIUS does raise
> some security concerns.
>
>   Anyone can edit Wikipedia.  It doesn't really mean anything.
>
> > Question: When the user's password hash is transmitted across the
> network, how secure is the password from decryption by eavesdroppers?
>
>   If you have a shared secret of "hello", it's easy to crack.
>
>   If the shared secret of "284nv82fskljhfw9yf2hfjb3fjgf8gb83bg", then no
> one will be able to crack it.
>
> >  Are there any good articles on RADIUS security?
>
>   Not really.
>
>   In short, it's fine.
>
>   Alan DeKok.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 25 Feb 2022 09:06:36 +0100
> From: Ole Holm Nielsen <Ole.H.Nielsen at fysik.dtu.dk>
> To: <freeradius-users at lists.freeradius.org>
> Subject: Re: Advice on RADIUS security and MD5 encryption?
> Message-ID: <11d65956-d0b7-8ccd-791b-e605539ce21b at fysik.dtu.dk>
> Content-Type: text/plain; charset="UTF-8"; format=flowed
>
> Hi Alan,
>
> Thanks very much for your definitive answers, it's much appreciated!  Such
> clear messages are almost impossible to find elsewhere.  So we should be
> good to go with RADIUS, provided that we use hard-to-crack shared secrets.
>
> Best regards,
> Ole
>
> --
> Ole Holm Nielsen
> PhD, Senior HPC Officer
> Department of Physics, Technical University of Denmark
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
>
> ------------------------------
>
> End of Freeradius-Users Digest, Vol 202, Issue 34
> *************************************************
>