On 26/8/2013 12:15 μμ, Arran Cudbard-Bell wrote:
No. It's a really inefficient way of doing this.
Thanks Arran,
Yet, would it be logically/technically correct?
Use generic attribute maps or an update ldap schema to pull the necessary
values into control attributes,
and then do the comparison in policy language.
Hmm, if I understand right, I could query once a custom attribute with
e.g. the value of 0/1/2 depending on the type of mac-auth we would like
to do.
Thus, two LDAP queries would suffice to check correctly the client in
all cases, where in my initial script we would need 3 at best or 4 at
worst.
The example would be to use a policy like:
set_mac_auth_type {
update request {
auth_type :=
%{ldap_macauth:ldap:///ou=Nodes,dc=example,dc=com?macauthtype?sub?macAddress=%{Calling-Station-Id}})
}
}
And finally:
server macauth {
authorize {
preprocess
rewrite_calling_station_id
set_mac_auth_type
if (%{auth_type} = 0) {
ldap_macauth
if (ok) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
else if (%{auth_type} = 1) {
ldap_macauth_NAS_only
if (ok) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
else if (%{auth_type} = 2) {
ldap_macauth_mobility
if (ok) {
update control {
Auth-Type := Accept
}
}
else {
reject
}
}
else {
reject
}
}
...
}
Is the above syntax/logic correct? That is what you are suggesting?
Otherwise you end up doing multiple LDAP queries which are
comparatively extremely slow to anything else you're doing in the policy.
OK, although we are mirroring the LDAP DIT locally (OpenLDAP Consumer)
so LDAP queries are VERY fast, and our FreeRadius load is expected to be
low (hosts on campus are less than 1000).
Thanks,
Nick
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html