allow WLAN-access in certain offices only

Alan DeKok aland at deployingradius.com
Thu Apr 22 20:53:00 CEST 2021


On Apr 22, 2021, at 2:11 PM, radius.pkoch at dfgh.net wrote:
> I understand that you need precise information about what my problem is in order to point me into the 100% correct direction. But I don't know exactly what my problem is. Describing the problem seems to be part of the solution.

  You know that location-specific and time-specific passwords give a very bad experience.  So you should drop that.

  For OTP authentication, you know you have a 6-digit token.  You know you have some API to check that.  You haven't said *what* that API is.  We've asked...

> The rlm_sql module does not only read user-information from certain SQL-tables and store account information into other SQL-tables, but loading this model enables %{sql:select ....} variable expansions in the rlm_expr module. I wasn't aware of this functionality of rlm_sql and since the select-statement in %{sql:....} can fetch data from any table or view I can easily select both the room number of User-Name and the room number of %{Packet-SRC-IP-Address}.

  Yes.

> I tried that today and created file policy.d/check_rooms with content
> 
> check_rooms {
>         update request {
>                 &Tmp-Integer-0 = "%{sql:select nmi_nra_id from nav_mitarbeiter where nmi_kuerzel='%{User-Name}'}"
>                 &Tmp-String-0 = "%{sql:select nra_name from nav_raeume where nra_id=%{Tmp-Integer-0}}"
>                 &Tmp-Integer-1 = "%{sql:select egr.nra_id(egr_id) from edv_geraete where egr.ip_adresse(egr_id,7)='%{Packet-SRC-IP-Address}'}"
>                 &Tmp-String-1 = "%{sql:select nra_name from nav_raeume where nra_id=%{Tmp-Integer-1}}"
>         }
> }
> 
> Since the decision wether an accesspoint with a certain IP-address is located in the office of a user or not is completly based on information within our oracle database, I felt that instead of fetching multiple pieces of data from the database and then compare that with Unlang in FreeRadius, this logic should be better placed within the database. By the way - this is what I ment when I mentioned that it's "our business how this decision has to be taken". Sorry, if that sounded unfriendly.

  It's your *decision* to put logic in one place or another.  If I ask "what does the logic do", I don't expect to get an answer which comes across as "none of your business".

> Hence I created an oracle database function check_rooms(user, ip) that does everything and my check_rooms policy now is just a one-liner. Tmp-String-0 will have either value "OK" or an error-message or will be empty if something went wrong within the database. And I extended this function so it takes care of our conference-rooms as well.

  That's good.

> check_rooms {
>         update request {
>                 &Tmp-String-0 = "%{sql:select egr.check_rooms('%{User-Name}','%{Packet-SRC-IP-Address}') from dual}"
>         }
> }
> 
> I still have to figure out how to reject the request if Tmp-String-0 is not "OK". There are enough examples so I can figure that out on my own.

  Do this:

	if ("%{sql:select egr.check_rooms('%{User-Name}','%{Packet-SRC-IP-Address}') from dual}" != "ok") {
		reject
	}

  It's that easy.

> But you pointed me at a different problem, namely "How do I force our employees to use their OATH TOTP-token as a second factor when they authenticate against a WiFi accesspoint"

  The answer is pretty much "you don't, it's a terrible idea.  It will annoy your uses to no end".

> - we are running an authentication server, that may verify a token values
> - the authentication server has - among others - a REST interface
> - the authentication server caches successful results for a certain period of time, so valid token-values can be reused
> - doing two-factor authentication is part of our security policy, using certificates will fullfill this requirement only if the private key of the certificate was created within a smart card
> 
> It won't surprise you that I have already tried to figure out, what a solution might be. Since my original idea (i.e. delegating the validation of the password to a script via either rlm_exec or rlm_perl) was absolutely unrealistic, I spare you what I have in mind, now that I have realized that passwords are contained in radius packets in clear only when sent with radtest, but are missing, when eap is used.

  You didn't read the web page I pointed you to about protocol and password compatibility.  You're not reading the debug output.  You didn't pay attention when I said you would need to change the supplicant configuration.

  The passwords are not "missing" when EAP is used.  The users *credentials* come across as MS-CHAP, or PAP, or CHAP, or ... many other forms.  Only one of those sends a clear-text password.  Only the clear-text password will work with OTP systems.

  What you are trying to do is likely (a) horrifically frustrating for end users, and/or (b) impossible to implement.

  Stop trying to force a solution.  Instead, make sure you understand what is going on.  WHAT do you see when EAP is used?  Is that compatible with OTP?  Can you change the supplicant configuration to send clear-text passwords?

  You're still stuck on a particular set of requirements.  We know you're trying to do OTP.   We're trying to convince you that you need to understand more about the system before deciding if the solution will work.

  You can't just say "passwords are missing when EAP is used".  You have to understand WHY they're "missing".  Otherwise you're randomly changing configuration options, hoping that one will magically fix the problem.  This is very much not an efficient approach.

  Alan DeKok.




More information about the Freeradius-Users mailing list