Alan:

Yes, that works when run through ldapsearch.

I was able to get the attribute checking working (added to dictionary, then ldap.attrmap) so I can now reject based on the value of an attribute. Thanks for the input on that.

However, if the user isn't found in LDAP (Active Directory), how do I get it to outright reject the user? I can't do attribute checking (tried that and checking for an empty value, but got attribute was not found). Right now if the user isn't found in LDAP it happily goes to authentication (which for testing purposes right now is just using the users file).

On Thu, Mar 7, 2013 at 10:22 AM, Alan DeKok <aland@deployingradius.com> wrote:

Matthew Ceroni wrote:
> That is what I tried. So I set
>
> base_filter =
> "(&(objectclass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"
>
> But what I am finding is whether the user is found and enabled, user is
> found but disabled, or user isn't found at the output (from radius
> debug) shows

Does that filter work when you use it with the command-line ldap
search tool?

> [ldap] user XXXXXX authorized to use remote access
>
> So then it continues onto the authorization part. How do I get it to
> reject if the user isn't found (or user is disabled)?

Use ldap.attrmap, as I said in my previous message.

Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html