Re: Access-Accept / Access-Reject based on LDAP Group & SSID

23 Mar 2015

      ...
...
...
On Mar 20, 2015, at 5:05 PM, Ben Humpert <ben@an3k.de> wrote:
RADIUS should check if the users group has a radiusCalledStationId
attribute matching the Called-Station-Id. If not it should check if
the user itself has a matching attribute. If not, Access-Reject. In
case a match is found and Called-Station-Ssid is set RADIUS should now
check if the users group has a matching radiusCalledStationSsid
attribute. If not it should check if the user itself has a matching
attribute. If not, Access-Reject. In case a match is found RADIUS
should finally check the users group for other attributes (eg.
radiusTunnelType, etc.) and apply them as long as the user itself
doesn't have these attributes set too. In that case the users
attributes take precedence.
Finally I got everything I wanted. However I don't know if how it's
done is the right or at least a good way. I would appreciate if
someone could quickly check my implementation and comment it :)

In server default authorize {} I first sanitize supplied
Called-Station-Id (& create Called-Station-Ssid if supplied) and
Calling-Station-Id using policies and at the very end I use policies
again to check supplied Called-Station-Id, Called-Station-Ssid and
Calling-Station-Id values with those stored in LDAP. In server default
post-auth {} the first policy is for applying dynamic vlan assignment
attributes.

policy.ldap_called-station-ssid {
        if (&Called-Station-Ssid) {
                if
("%{ldap:ldap:///ou=Groups,dc=home,dc=lan?gidNumber?sub?(&(cn=%{control:LDAP-Group})(memberUid=%{User-Name})(radiusCalledStationSsid=%{Called-Station-Ssid}))}"
|| "%{ldap:ldap:///ou=Users,dc=home,dc=lan?uidNumber?sub?(&(uid=%{User-Name})(radiusCalledStationSsid=%{Called-Station-Ssid}))}")
{
                        noop
                }
                else {
                        reject
                }
        }
        else {
                noop
        }
}

policy.ldap_called-station-id and policy.ldap_calling-station-id are
the same, respectively. These are checked only once after the first
Access-Request package directly after eap so I guess it's fine. The
next policy is maybe not a good solution since the LDAP is queried up
to eight times.

policy.ldap_vlan-assignment {
        if ("%{ldap:ldap:///ou=Users,dc=home,dc=lan?uidNumber?sub?(&(uid=%{User-Name})(radiusTunnelType=VLAN))}")
{
                update reply {
                        &Tunnel-Medium-Type :=
"%{ldap:ldap:///ou=Users,dc=home,dc=lan?radiusTunnelMediumType?sub?(&(uid=%{User-Name}))}"
                        &Tunnel-Private-Group-Id :=
"%{ldap:ldap:///ou=Users,dc=home,dc=lan?radiusTunnelPrivateGroupId?sub?(&(uid=%{User-Name}))}"
                        &Tunnel-Type :=
"%{ldap:ldap:///ou=Users,dc=home,dc=lan?radiusTunnelType?sub?(&(uid=%{User-Name}))}"
                }
        }
        elsif ("%{ldap:ldap:///ou=Groups,dc=home,dc=lan?gidNumber?sub?(&(objectClass=posixGroup)(memberUid=%{User-Name})(radiusTunnelType=VLAN))}")
{
                update reply {
                        &Tunnel-Medium-Type :=
"%{ldap:ldap:///ou=Groups,dc=home,dc=lan?radiusTunnelMediumType?sub?(&(objectClass=posixGroup)(memberUid=%{User-Name}))}"
                        &Tunnel-Private-Group-Id :=
"%{ldap:ldap:///ou=Groups,dc=home,dc=lan?radiusTunnelPrivateGroupId?sub?(&(objectClass=posixGroup)(memberUid=%{User-Name}))}"
                        &Tunnel-Type :=
"%{ldap:ldap:///ou=Groups,dc=home,dc=lan?radiusTunnelType?sub?(&(objectClass=posixGroup)(memberUid=%{User-Name}))}"
                }
        }
        else {
                update reply {
                        &Tunnel-Medium-Type := "IEEE-802"
                        &Tunnel-Private-Group-Id := "1"
                        &Tunnel-Type := "VLAN"
                }
        }
        updated
}

That policy is only executed once directly before the final
Access-Accept package is sent. However, if one (existing) user wants
to login the LDAP is queried 14 times (worst-case) or 7 times
(best-case). Generally said, is that a very good, acceptable or
extremely worse amount of queries per user?

I also found some configurations I couldn't understand. First is in
sites-enabled/default line 494: why is eap not called as "Auth-Type
EAP { eap }" like pap, chap and ms-chap?
I also noticed that the server looks for a Post-Auth-Type Challenge {}
but couldn't find it thus ignoring it (debug output), so I added it to
the post-auth section with attr_filter.access_challenge in it.
Shouldn't this be the default?
At last I got confused by the commented out routine in
sites-enabled/default line 502 to 510. Here we have "Auth-Type EAP {
eap }" and the attr_filter.access_challenge but doesn't the added
Post-Auth-Type Challenge routine do exactly the same (except setting
handled = 1)?

Thank you very much in advance.

Best regards,

Ben Humpert