Migration of FreeRadius Server from 2.1 to 3.X
Bhagwat, Shrikant
shrbhagw at med.umich.edu
Fri Sep 8 04:19:05 CEST 2017
Got it working finally,
-----Original Message-----
From: Freeradius-Users [mailto:freeradius-users-bounces+shrbhagw=med.umich.edu at lists.freeradius.org] On Behalf Of Alan Buxey
Sent: Thursday, September 7, 2017 5:10 PM
To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
Subject: RE: Migration of FreeRadius Server from 2.1 to 3.X
What are you trying to do? You say you added custom unix but haven't/didn't from info you provided. What are those auth-type entries for? You can't just make up your own random syntax.
alan
On 7 Sep 2017 1:49 pm, "Bhagwat, Shrikant" <shrbhagw at med.umich.edu> wrote:
> Hi Alan
>
> In sites-enabled/default file in authenticate section I have added
> custom section unix
>
> authenticate {
>
>
> # unix
>
> # Uncomment it if you want to use ldap for authentication
> #
> # Note that this means "check plain-text password against
> # the ldap database", which means that EAP won't work,
> # as it does not supply a plain-text password.
>
> Auth-Type level1_and_duopush {
> level1_and_duopush
> }
>
> Auth-Type level1_and_duophone {
> level1_and_duophone
> }
>
> Auth-Type level2_and_duopush {
> level2_and_duopush
> }
>
> Auth-Type level2_and_duophone {
> level2_and_duophone
> }
>
> Auth-Type PhoneFactor {
> phonefactor
> }
>
> Auth-Type Level-1 {
> level-1
> }
> }
>
> In Post Auth section of default file I have following :
>
>
> post-auth {
> # Get an address from the IP Pool.
> # main_pool
>
>
> # Create the CUI value and add the attribute to Access-Accept.
> # Uncomment the line below if *returning* the CUI.
> # cui
>
> #
> # If you want to have a log of authentication replies,
> # un-comment the following line, and enable the
> # 'detail reply_log' module.
> reply_log
>
> #
> # After authenticating the user, do another SQL query.
> #
> # See "Authentication Logging Queries" in sql.conf
> -sql
>
> #
> # Instead of sending the query to the SQL server,
> # write it into a log file.
> #
> # sql_log
>
> #
> # Un-comment the following if you want to modify the user's object
> # in LDAP after a successful login.
> #
> # ldap
>
> # For Exec-Program and Exec-Program-Wait
> exec
>
> #
> # Calculate the various WiMAX keys. In order for this to work,
> # you will need to define the WiMAX NAI, usually via
> #
> # update request {
> # WiMAX-MN-NAI = "%{User-Name}"
> # }
> #
> # If you want various keys to be calculated, you will need to
> # update the reply with "template" values. The module will see
> # this, and replace the template values with the correct ones
> # taken from the cryptographic calculations. e.g.
> #
> # update reply {
> # WiMAX-FA-RK-Key = 0x00
> # WiMAX-MSK = "%{EAP-MSK}"
> # }
> #
> # You may want to delete the MS-MPPE-*-Keys from the reply,
> # as some WiMAX clients behave badly when those attributes
> # are included. See "raddb/modules/wimax", configuration
> # entry "delete_mppe_keys" for more information.
> #
> # wimax
>
>
>
> -----Original Message-----
> From: Freeradius-Users [mailto:freeradius-users-bounces+shrbhagw=
> med.umich.edu at lists.freeradius.org] On Behalf Of Alan Buxey
> Sent: Thursday, September 7, 2017 5:25 AM
> To: FreeRadius users mailing list
> <freeradius-users at lists.freeradius.org>
> Subject: Re: Migration of FreeRadius Server from 2.1 to 3.X
>
> hi,
>
> > I know config of version 2 will not work with config of version 3.
> > It looks like echo module controls the exe module
>
> ??
>
> the exec module is the main module
>
> the provided example echo module USES the exec module
>
>
> exec echo {
> }
>
> see?
>
> >
> > From exec module
> >
> > exec default {
> > wait = yes
> > output = none
> > #input_pairs = request
> > output_pairs = none
> > # 0 - level-2 proxy; 1 - level-2 proxy password; 2 -
> level-2 server; 3 - level-2 basedn; 4 - level-2 account found flag;
> > # 5 - level-1 kdc domain; 6 - log file name.
> > program =
> > "/idm/idmt_home/PhoneFactor/Level1Factor.pl
> %{config:modules.ldap.identity} %{config:modules.ldap.password}
> %{config:modules.ldap.server} %{config:modules.ldap.basedn} not_found
> \
> > %{config:modules.ldap.level-1_kdc}
> %{config:modules.ldap.logFILEname}"
> > shell_escape = yes
> > }
> >
> > # Phone Factor
> > exec phonefactor {
> > wait = yes
> > output = none
> > #input_pairs = request
> > output_pairs = none
> > # 0 - level-2 proxy; 1 - level-2 proxy password; 2 -
> level-2 server; 3 - level-2 basedn; 4 - level-2 account found flag;
> > # 5 - level-1 kdc domain; 6 - log file name; 7 -
> > phone
> factor call back number
> > program = "/idm/idmt_home/PhoneFactor/PhoneFactor.pl
> %{config:modules.ldap.identity} %{config:modules.ldap.password}
> %{config:modules.ldap.server} %{config:modules.ldap.basedn} found \
> > %{config:modules.ldap.level-1_kdc}
> %{config:modules.ldap.logFILEname} %{reply:Callback-Number}"
> > shell_escape = yes
> > }
> >
> >
> > Do I modify echo module to match in exec module ? or vice versa ?
>
> so, these two sub-modules of exec, which can be called as 'default'
> and 'phonefactor' elsewhere in your config - eg in the sites-enabled/*
> virtual servers (PS 'default' is an awful choice)
>
> and yes, you need to look at the FR 3.x docs and ensure your format
> and entries match the 3.x configuration/specification..... also, as
> already said, this is the IDEAL time, during a migration, to clean up
> and optimise the config. operations with LDAP can be done natively
> through LDAP module and unang and will be MUCH MUCH quicker than calls
> to scripts (more than an order of magnitude quicker AND able to deal
> natively with multiple servers, failover, connection pools etc etc -
> thread safe etc) in previous migrations I have removed most modules
> and random functions and sped server up - in most cases being able to
> make the server more like a default install with far fewer changes and
> stopping the use of eg rlm_perl and rlm_python
>
> alan
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html
> **********************************************************
> Electronic Mail is not secure, may not be read every day, and should
> not be used for urgent or sensitive issues
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/
> list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
**********************************************************
Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues
More information about the Freeradius-Users
mailing list