matthewceroni at gmail.com
Thu Mar 7 22:06:12 CET 2013
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 at deployingradius.com>wrote:
> Matthew Ceroni wrote:
> > That is what I tried. So I set
> > base_filter =
> > "(&(objectclass=user)(!(userAccountControl:1.2.840.1135220.127.116.113:=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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Freeradius-Users