On May 15, 2017, at 2:57 PM, Martin Bednar <mato.bednar@gmail.com> wrote:

again thanks for your time. The goal is simple. When is user connecting to the wireless network he is asked for username/password if there is a match and at the same time he is allowed to use this SSID he is authenticated.

That's still too high level. My suggestion was to read the rlm_sql documentation and write things down. If you're not going to do that, you're just wasting everyone's time. i.e. go through the rlm_sql documentation. Read the discussion on how the packets are processed. For each item in the list, write down what is in the packet, and what is in the SQL table. Then, check the processing to see if it matches.

username/password check should happen in radcheck table SSID check should happen in radusergroup table

So you want users to be checked, and SSIDs to be checked. But there's nothing about how users are put into groups. Again, see the wiki for rlm_sql. Look for the "usergroup" table. It's largely what I suggested earlier, but integrated with rlm_sql.

...

i.e. anyone who logs into the EMPL-Test SSID gets accepted?

You're right - that's not right. In this case even if the username/password would be wrong user would receive Access Accept. I believe that normally there is no need for radgroupreply item because Access Accept/Reject is already set from rcadcheck.

That's the wrong way to do it. It's OK to reject users anywhere. Because a reject is always a reject. It's *not* OK to definitively accept a user anywhere. Because a later processing stage may decide to reject the user. i.e. *not* being in rcadcheck means they're rejected. Being in rcadcheck means they *might* be accepted, if they're in the right group and are using the right SSID.

Would it works like this ? \ Check user in radcheck -> is username/passsword are ok -> Accept otherwise Reject

Again, you don't want to "accept" users here.

Check user in radgroupcheck -> for allowed SSID there would be group with no reply action -> if no match last group (highest priority)

From the sql documentation... if the group matches AND there's no Fall-Through, then group processing stops.

would be Reject which would be always matched.

Does the SQL module documentation mention "always matched"? Again, you're trying to design a solution based on what you want it to do. You need instead to design a solution based on how it actually works. And write things down, in detail. Follow the flow of the documentation. Posting vague requirements and guesses for "will this work?" is just unhelpful/ Alan DeKok.