Authenticating users on LDAP based on Group name

[Jose Torres-Berrocal]

Sorry I thought the debug output included the Conf files.

Here I include the Users.Conf:


/usr/pbi/freeradius-i386/etc/raddb/users

"test" Cleartext-Password := "squidtest"
DEFAULT Ldap-Group == "internetaccess", Auth-Type := Accept


On Thu, Mar 26, 2015 at 8:52 AM, Ben Humpert <ben at an3k.de> wrote:

> 2015-03-26 3:20 GMT+01:00 Jose Torres-Berrocal <
> jetsystemservices at gmail.com>:
> > I have setup the group in groupmembership_attribute as a naive intent to
> > accomplish my goal.  If that is not the correct parameter I will really
> > appreciate your help on where I should set my Group and the syntax.
>
> Well, the setting clearly asks for an attribute such as sAMAccountName
> or userPassword. The name of a group is a value, the value of the
> attribute cn. So yes, it is not the correct parameter ;)
>
> > On my first email I included my LDAP.conf file as generated by pfsense.
> >
> > I think is closed as needed because I was successful matching user/pass
> > with AD when group membership_attribute is default, but for all Users.
> Now
> > I need to change it to consider the Group.
>
> Setting up user authentication is kind of simple. You just need to
> match the basedn, filter and base_filter to your directory and that's
> it. After understanding how these settings are merged into a search
> request it is also easy to set up group authentication. I did so after
> working with XLAT, now it's easy for me but before I had no clue at
> all what I was doing :)
> What helped me much was the information that unlike in databases like
> *SQL you always want to get only ONE result in Directories, thus the
> filter needs to be as strict as required to only find one user or
> group. If you would find more how should Radius know which is the
> correct entry?
>
> The original ldap file says the following about membership_filter
>
> "Filter to find group objects a user is a member of. That is, group
> objects with attributes that identify members (the inverse of
> membership_attribute)."
>
> and this about membership_attribute
>
> "The attribute in user objects which contain the names or DNs of
> groups a user is a member of. Unless a conversion between group name
> and group DN is needed, there's no requirement for the group objects
> referenced to actually exist."
>
> That means that if your groups have attributes which contain the names
> or uids of the users that are member of that group you do not use
> membership_attribute but membership_filter. If instead your users have
> attributes containing the names or gids of the groups the user is
> member of then you use membership_attribute instead of
> membership_filter.
>
> What is the case in your setup? Could you post an example of a group
> and as well an user like the one below?
>
> # Guest, Groups, example.com
> dn: cn=Guest,ou=Groups,dc=example,dc=com
> objectClass: posixGroup
> objectClass: top
> objectClass: radiusProfile
> cn: Guest
> gidNumber: 17068
> memberUid: guest
> memberUid: tobtsc
> memberUid: marhab
>
> # guest, Users, example.com
> dn: uid=guest,ou=Users,dc=example,dc=com
> objectClass: posixAccount
> objectClass: top
> objectClass: inetOrgPerson
> objectClass: radiusProfile
> gidNumber: 0
> uid: guest
> uidNumber: 18459
> dialupAccess: Yes
> cn: Guest
>
> As you can see, the attribute "memberUid" is used to store the names
> of those users who are member of the group Guest, thus
> membership_attribute is not in use in my setup.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>