thorization not working if proxying to anoither radius

[Alan DeKok]

On Jan 28, 2025, at 6:30 AM, Peter Hudec via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> I would like to ask  you to help me solve my issue.
> Forst, the freeradius is aliite bit older - Alma 9, freeradius-3.0.21-43.el9_5.x86_64
> 
> The packages froem the https://networkradius.com/packages/ do not wolr on Alma 9 ;( tehre is SSL ISSUE.

  IIRC, those packages use OpenSSL3.  Almost every distribution has switched to OpenSSL.

  If you want to upgrade, it takes about 15 minutes to build FreeRADIUS from source.  Upgrading also gets you bug fixes and nice new feature requests.

> My problemis as follows.
> 
> I have users, with realms, there based on the relam I need to send request to another radius for 2FA.
> 
> My radius should do the first FA, means the password authorization, the realm radius should do the 2fa In my case Cisco Duo for onretype of realm and some 3rd party radius for another realm.

  That can be done, but it takes a careful design.   While FreeRADIUS can do almost anything, the default configuration is meant to work in the most common deployments.  If you have a very unusual requirement like this, you will have to change the defaults.

> Based on the documentation, the PAPIf one is found, and no Auth-Type or Proxy-To-Realm attribute is set, the module will set Auth-Type := pap.
> 
> So if I run the suffix module, to get the realm and pass the request to another radius, the PAP is omitted.

  Yes.   That can be changed by editing the configuration.

> I gva tried various solution as setting the Proxy-To-Realm after PAP in authorize section
> or
> set Auth-Type ;= PAP manually

  Which forces PAP authentication, and not proxing.

> but neither solution is working, the PAP is not working and I have just the 2FA ;(

  You have to come up with a solution by understanding how everything works.  You can't just tweak one or two configuration settings and expect a complex workflow to come out of it.

> Anyone got such a solution, wgere the freeradius is doing the fisrt facror and the 3rd party radius second ?

  Something like the configuration below should work.  But you can't just copy it verbatim and expect it to magically solve the problem.  The problem description you gave is fairly vague, and is missing almost all technical information.
 
  i.e. Computers don't work on "I want to do stuff".  They work on very very clearly defined inputs and outputs.

  You should also read "man radiusd", and http://wiki.freeradius.org/list-help.  They both give explicit directions on how to design and debug issues. 

  Anyways... assuming that the problem description is right, the first step is to write down the requirements.  This is ABSOLUTELY the most critical step.  Without this, you're just making random changes, with no goal or any way to test those changes.

  Here are the requirements:

* The local RADIUS server knows about all of the User-Names in the packets

* i.e. it can look up the User-Name in a database (you don't say which one), and get a password from it

* the local RADIUS server needs to then check the password it got from the database against the password 

* if the user isn't found, or the password is wrong, reject the user

* otherwise proxy it to the destination realm

* this ASSUMES that the destination realm doesn't check the password in the first request, and instead sends back an Access-Challenge

* the one bit of RADIUS magic is that the first Access-Request packet doesn't contain a State attribute.  The Access-Challenge contains a State attribute, which is echoed back in the next Access-Request.  Figuring this out is critical to getting the solution.  You don't need deep RADIUS knowledge to do this.  You just need to run the server in debug mode (as suggested by all of the documentation and nearly daily on this list), and then read the output.

* the one piece of FreeRADIUS magic is that you can call modules from a different section.  This is documented, but it's not obvious that this is what you want to do.

  Putting all that together, the solution is fairly simple.

* leave all of the realm proxying / etc. you have in place today.  That seems to work.

* configure the server to do database lookups BEFORE running the realm module, and ONLY if there's no State attribute.

  And this is is:

authorize {
	... no realms here! ...

	if (!&State) {
		ldap		# or whatever other database you use
		if (notfound) {
			reject
		}

		pap.authenticate	# will reject if the password doesn't match
	}

	realms
	...
}

  Translating that to English:  "On the first packet, look up the user in LDAP.  unknown users are rejected.  Then check their password.  If it doesn't match, the PAP module will reject the user.  If it matches, then proxy the packet by realm to the other server".

  Alan DeKok.