Global User Blacklist
Hello folks, I am trying to devise the best way to configure a global blacklist in freeradius. In the current configuration, I am handling a number of different authentication types with various virtual servers. For PEAP, I have integrated active directory, and for the other services, I use LDAP. Since LDAP makes group checking very easy, I was hoping that I could leverage that for my blacklisting needs. So, my question is: Is it possible to do LDAP group checking in post-auth of the default server even if the request is EAP? Cheers, Dave
Thanks for your response, Alan. I'll give that a shot. Is it to correct to assume that the only additional thing I should need is to uncomment "ldap" in the authorize stanza of the inner-tunnel? I would imagine listing it after eap in the default server would have a large impact on performance. Dave On 2012-07-30, at 1:11 PM, Alan DeKok <aland@deployingradius.com> wrote:
David Aldwinckle wrote:
Is it possible to do LDAP group checking in post-auth of the default server even if the request is EAP?
Yes.
if (LDAP-Group == "banned") { reject } - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hello, I figure that other people might benefit from this too, so... I was correct in my previous message. I added ldap to the authorize section of the inner tunnel, and did the group checking in the post-auth of the default server and everything worked wonderfully. Dave On 2012-07-30, at 1:28 PM, David Aldwinckle <daldwinc@uwaterloo.ca> wrote:
Thanks for your response, Alan.
I'll give that a shot.
Is it to correct to assume that the only additional thing I should need is to uncomment "ldap" in the authorize stanza of the inner-tunnel? I would imagine listing it after eap in the default server would have a large impact on performance.
Dave
On 2012-07-30, at 1:11 PM, Alan DeKok <aland@deployingradius.com> wrote:
David Aldwinckle wrote:
Is it possible to do LDAP group checking in post-auth of the default server even if the request is EAP?
Yes.
if (LDAP-Group == "banned") { reject } - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 31/07/12 13:26, David Aldwinckle wrote:
Hello,
I figure that other people might benefit from this too, so...
I was correct in my previous message. I added ldap to the authorize section of the inner tunnel, and did the group checking in the post-auth of the default server and everything worked wonderfully.
This isn't working for the reasons you seem to think. The syntax: if (Ldap-Group == xx) ...performs a dynamic search against the LDAP directory for the user & group membership. If you're doing this in the "default" post-auth, you're running LDAP twice - once in the "inner-tunnel" authorize section, and once in the "default" post-auth.
Hi Phil, I tried a test where I commented out "ldap" from the inner tunnel and it appears that you are correct. I had thought that I would need to "load" the module for the LDAP-Group to be populated. Anyway, thanks for the tip! Dave On 2012-07-31, at 8:41 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 31/07/12 13:26, David Aldwinckle wrote:
Hello,
I figure that other people might benefit from this too, so...
I was correct in my previous message. I added ldap to the authorize section of the inner tunnel, and did the group checking in the post-auth of the default server and everything worked wonderfully.
This isn't working for the reasons you seem to think.
The syntax:
if (Ldap-Group == xx)
...performs a dynamic search against the LDAP directory for the user & group membership.
If you're doing this in the "default" post-auth, you're running LDAP twice - once in the "inner-tunnel" authorize section, and once in the "default" post-auth. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 31/07/12 13:47, David Aldwinckle wrote:
Hi Phil,
I tried a test where I commented out "ldap" from the inner tunnel and it appears that you are correct.
I had thought that I would need to "load" the module for the LDAP-Group to be populated.
It's a common misconception, and in some ways I wish it were more obvious that this isn't the case. But as I say, the attribute is a "virtual" one, and comparisons are executed by a handler that dynamically does the query, as opposed to a list of groups. Same thing for SQL-Group and (IIRC) the huntgroup attributes. This can be relevant if you want to do a lot of group comparisons e.g. if (Ldap-Group = abc123) { .. } elsif (Ldap-Group == def456) { ... } ...involves two LDAP directory searches. This can get slow with a lot of groups, for which there are various solutions.
On 2012-07-31, at 9:02 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
...involves two LDAP directory searches. This can get slow with a lot of groups, for which there are various solutions. -
Can you elaborate on that last bit? In another scenario I do have quite a few different group checks and I am always interested in improving performance. Thanks! Dave
participants (3)
-
Alan DeKok -
David Aldwinckle -
Phil Mayers