Authenticating users on LDAP based on Group name

Jose Torres-Berrocal jetsystemservices at gmail.com
Fri Apr 24 23:16:30 CEST 2015


It works!  Thank you very much!  And yes the trick was to disable LDAP
in Authorize section.

In my case I had to do a work around. For a newbe, this makes more
difficult to understand this service. See the following comment.

Just for information to anyone reading this thread that uses pfsense.
In pfsense 2.1.5, there is a bug.  You can not disable Authorize LDAP
check box on the GUI.  If you do, the LDAP connection values are
disabled and emptied, so LDAP won't work.  You have to make your
settings and after every SAVE configuration you have to manually edit
the "sites-enable" configuration file, or disable and make the changes
in LDAP file.  I think is better the first approach.  In pfsense 2.1.5
is in "/usr/pbi/freeradius-i386/etc/raddb/sites-enable/default" for
i386 platform.  There, go to the Authorize section and comment the
corresponding LDAP lines.  Restart and reload the Freeradius service
so it picks the configuration change.


On Fri, Apr 24, 2015 at 3:51 PM, Jose Torres-Berrocal
<jetsystemservices at gmail.com> wrote:
> On Thu, Apr 23, 2015 at 4:57 PM, Alan DeKok <aland at deployingradius.com> wrote:
>> On Apr 23, 2015, at 4:24 PM, Jose Torres-Berrocal <jetsystemservices at gmail.com> wrote:
>>> I think one coffusion is that Radius has a setting called Groupname
>>> attribute.
>>
>>   FreeRADIUS has an LDAP-Group attribute.  Is that what you mean?
>>
>
> No.  I mean Groupname_attribute.  In my configuration is set
> Groupname_attribute = cn.
>
>>>  I am talking about the Group name in Active Directory as Domain
>>> Admins, Administrators, etc.  Let say that the AD/LDAP groups are called
>>> Wingroups, and Wingroup name is for instance Domain Admins.  In my case I
>>> want to use the Wingroup InternetAccess.
>>
>>   Please don't invent new terminology.  That makes it more confusing.
>>
>
> OK, then. When I say Group I am talking about the Group name in Active
> Directory as Domain Admins, Administrators, etc. In my case Group =
> IntenerAccess.
>
>>   FreeRADIUS uses LDAP-Group to check.... groups in LDAP.  In your case, AD.  That should be clear.
>>
>>> I do not know how to make aside the conffusion on Authorization and
>>> Authentication, but let say that Authentication is having a process where
>>> the username/password combination values that are received in the
>>> connection request is verified against the LDAP and if found it is say to
>>> be Authenticated succesfully otherwise failed.
>>
>>   Don't re-define existing terminology.  Authentication is where users are authenticated.
>>
>>   And no, their connection request is not verified against LDAP.  You're again using vague and imprecise terminology.  Please stop.
>>
>
> OK. Is verified against Active Directory using LDAP. Right?
>
>>>  I know there are other
>>> types of Authentications but I want to keep it simple.  Now, Authorization
>>> is the process to allow or denied the request to connect.  I now there are
>>> branches to this, but for simplicity I would like to keep it in that.
>>
>>   Requests don't connect.  Users connect.  This difference MATTERS.
>>
> Well, yes, the one who connects is the user but the allow or denied is
> the answer to a request, signified by the Access-Request packet. In
> RADIUS, the allow is signified by the Access-Accept, the denied by the
> Access-Reject, right?
>
>>> Then, I want to allow connection to requests that have a username/password
>>> combination authenticated succesfully against an LDAP (Windows AD) and
>>> which user belongs to Wingroup InternetAccess.
>>
>>   This is really the first simple explanation I've seen.  It shouldn't be that hard to do, to be honest.
>>
>>> I have being succesfull allowing connection by username/password or by the
>>> user belonging to Wingroup, but not at the same time.  Those are the debugs
>>> I already sent you.
>>
>>   There's hundreds of lines of output, but it's not clear what you want.  So... it's hard to say what's going wrong in the debug output.
>>
>>> When I set the Group name attribute, groupmembership_filter and
>>> groupmembership_attribute (Which is what I call using group options)
>>
>>   Again, you're inventing terminology.  Stop it.  You're confusing yourself, and making the problem worse.  MUCH worse.
>>
> My bad. I should have written groupname_attribute instead of Group
> name attribute.
>
>>> I am
>>> succesfull allowing/denied connection by the user belonging to the
>>> Wingroup, but it currently ignores the password.
>>
>>   Well, no.  You didn't do what you said.  Instead, you checked for the group, and if the user was in the group, you set Auth-Type := Accept.  That's a bit different.
>>
>>>  When I comment the Group
>>> name attribute, groupmembership_attribute, etc (Which is what I call not
>>> using group options), I am succesfull allowing/denied connection by the
>>> username/password, but clearly does not work with the Wingroup.
>>
>>   So... when you don't check groups, it doesn't do group checking?  That's not a surprise.
>>
>>> I have being playing with the Users.conf file and I think is really close
>>> for what I need, not sure if it is the correct way
>>
>>   It's not a "users.conf" file.  Again, you're inventing terminology.
>>
> My bad. I should have written "Users" file. Is that some files are
> .conf, others are .cnf and other without extension.  There is no
> standard.
>
>>   What do I need to do in order to convince you that your entire approach is wrong?  That inventing things, and changing the meaning of existing words is a PROBLEM?
>>
>>   Don't do it.  Just... don't.
>>
>>> ====================================================
>>> /usr/pbi/freeradius-i386/etc/raddb/users
>>>
>>> "test" Cleartext-Password := "squidtest"
>>> DEFAULT Ldap-Group != "InternetAccess", Auth-Type := Reject
>>> Ldap-Group == "InternetAccess", Auth-Type := LDAP
>>> ====================================================
>>
>>   That isn't what you have in the file.  It's been modified and re-formatted.
>>
> The initial file that I sent you is not the same as the one I
> currently have.  As I told in the previous email, I have being playing
> with the Users file ( I written the name wrongly as Users.conf in the
> sentence) and clearly I change it trying to get closer to what I need.
> In fact is closer.
>
>>
>>> Debug output that closely do what I want. Ii is long because is showing on
>>> the same run four (4) tests.
>>> 1. Username/password combination found in LDAP but NOT in Wingroup.
>>> 2. Username/password combination not found in LDAP but in Wingroup
>>> 3. Username/password combination found in LDAP and in Wingroup
>>> 4. Username/password combination not found in LDAP and not in Wingroup
>>
>>   If you understand what's going on, and don't invent new terminology, it's simple.  Just do this:
>>
>> 1) configure the ldap module.  ALL of it.  Including the groupmembership_attribute, groupmembership_filter, etc.
>>
>> 2) put this into the "users" file, at the TOP of the file:
>>
>> #
>> DEFAULT   LDAP-Group == "InternetAccess", Auth-Type := LDAP
>> #
>>
>> 3) be sure there's no "ldap" in the "authorize" section
>>
>> 4) be sure there's "Auth-Type LDAP" in the "authenticate" section
>>
>>   Try to connect.  Users in the "InternetAccess" group will get authenticated.  But ONLY if their name and password is correct.
>>
>>   Users NOT in the "InternetAccess" group will not get authenticated.
>>
>>   It really is that easy.
>>
>>   But you SHOULD NOT invent new terminology.  You MUST understand what the existing words mean.  You MUST describe what you want in simple, clear, terms.
>>
>>    Alan DeKok.
>>
>>
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
> OK.  I will try that configuration.  I think the trick, as I call it,
> is to turn off Authorization for LDAP. Will let you know how it goes.


More information about the Freeradius-Users mailing list