Re:

17 Jul 2015

      On Jul 17, 2015, at 12:30 PM, ankita therese <ankitatherese@gmail.com> wrote:
...
The problem is that though it is identifying the group correctly,
RADIUS is not checking the conditions.
I don't think so.
...
radgroupcheck:
______________________________________________
| id |  groupname  |         attribute         | op |    value    |
|------------------------------------------------------------------------------|
|  1 |    student     |   NAS-IP-Address   | !=  | 127.0.1.1 |
|------------------------------------------------------------------------------|
...
radgroupreply:
___________________________________________
| id |  groupname  |      attribute      | op |    value     |
|-------------------------------------------------------------------------|
|  1 |    student     | Reply-Message | =  |    "OK"      |
|-------------------------------------------------------------------------|
which really says:

	if (NAS-IP-Address != 127.0.0.1) {
		update reply {
			Reply-Message = "OK"
		}
	}
...
The request should have been rejected based on the entry in
radgroupcheck,
No.

  Read this:  http://wiki.freeradius.org/modules/Rlm_sql
...
but its not.
When the NAS-IP-Address check is given in radcheck, it rejects
requests properly, not so much when in radgroupcheck.
No.  That's not how it works.

  If you add the NAS-IP-Address to radcheck, then the *entry* doesn't match.  The other thing in the entry is setting the Cleartext-Password... but that is ONLY done if the entry matches.  Which it doesn't.  And since there's no Cleartext-Password for the user, he's rejected.

  Don't invent your own ideas about how rlm_sql works.  It's behaviour is documented.  It works as documented.

  Alan DeKok.