Applying the same rule to multiple values in an attribute/config value

Alan DeKok aland at deployingradius.com
Thu Feb 14 21:25:07 CET 2019


On Feb 14, 2019, at 3:17 PM, Alex Perez-Mendez <Alex.Perez-Mendez at jisc.ac.uk> wrote:
> a further question has come to my mind when configuring this "bangpath" 
> realm.
> When the conditions are met and it is executed, it provides a value to 
> &Request:Realm, so "suffix" results in "noop" and, hence, it Rejects the 
> authentication because in our "sites-enabled/abfab-tr-idp" file we have 
> the following:
>     suffix {
>             updated = 1
>             noop = reject
>     }

  Well.. don't do that, then. :)

> I'm not sure why this was set here. I guess because we wanted that if no 
> realm was resolved using the Trust Router, it should fail right away 
> (I'm not sure that's necessarily true, though, as I guess it will 
> eventually fail nonetheless as it will try to authenticate a local user 
> that does not exist).
> 
> But now we have two different resolvers instead of just one. Would it 
> have any security implications if I removed the "noop" line? If I do 
> that it works.

  I would instead do:

	bangpath
	if (!updated) {
		suffix {
			...
		}
	}

  i.e. run bangpath first, and then suffix only if there's no match for bangpath.

> If that's not desirable, would it be acceptable to make the check that 
> if &request:Realm is set, then circumvent the suffix module?

  The "realm" module does that already.

  Alan DeKok.




More information about the Freeradius-Users mailing list