On 21/04/2021 13:44, Alan DeKok wrote:
Once a password was used successfully, the same value can be used again for a certain period of time that depends on the username. With our IMAP-server this period is 30 days, for a WiFi-guest account this would be 12 hours.
As I said, that's likely a poor WiFi experience.
Yeah, there's a few things here that sound bad from an experience view. Replace password every day. Likely nasty for anyone with a supplicant (so WPA-Enterprise). Configuring supplicants correctly can be difficult enough on its own, and they like to hold on to the password. Expect pain. It's different with the old web-redirect type login, but that's just nasty anyway (and less secure). Same experience having to re-login again, though - it's annoying. "Allowed to connect in their office and the conference room". Until their device holds on to the wifi connection in the next office down the corridor, is refused to connect, and dumps the wifi config because that SSID doesn't work any more. So they get prompted to log in again. Nasty experience, expect pain. Oh, you did that by changing passwords every day already. This seems to be the normal "let's lock everything down as much as possible" thought, which sounds good until people actually have to *use* it, then you just annoy your users. Visiting a colleague in their office to ask them a question? Uh oh, can't get on wifi any more, so have to use 4G to check up on whatever they need to. Just... ugh. How about an alternative - issue certificates to anyone allowed to use the network, permit people to connect anywhere and drop them into the correct VLAN so that they get access to the stuff they need?
And it cannot query our central oracle database on its own about what accesspoint has the given IP-address and wether this accesspoint is physically located in the office of the person with the given username.
Why? You later say that the script can query the Oracle database. So why can't FreeRADIUS query the Oracle database directly? The SQL module is capable of this.
Yeah. Don't think "I can write a script so let's get FreeRADIUS to run the script". Really we should put a big warning in all the language modules to *not* use them until no other method has proven workable. Query the database directly with rlm_sql and use unlang to do policy, unless there's a really good reason not to ("I don't know unlang" isn't a good reason).
If you have a good problem description, then I can suggest a good solution. If you have just want to know "should I use exec or Perl", then I really can't help you.
Neither :)
FreeRADIUS can do database queries. FreeRADIUS can do comparisons. FreeRADIUS can do if / then / else checks.
Exactly. In over 10 years doing FreeRADIUS I've never used any of the interpreted language modules, and the only times I've used rlm_exec we've hit performance problems. -- Matthew