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