Authenticating groups via LDAP

[Peter Lambrechtsen]

This is how I did it.

Works well for me.

http://lists.freeradius.org/mailman/htdig/freeradius-users/2009-November/msg00001.html

On Fri, May 21, 2010 at 5:26 PM, John Dennis <jdennis at redhat.com> wrote:

> On 05/20/2010 05:44 PM, John Maher wrote:
>
>> I really didn't want to post here, but I just can't make any headway
>> with my radius implementation.  I am very new at this and still quite
>> confused on how the various config files function and interact with each
>> other.  So, I'm not surprised that my implementation is only sort of
>> working.
>>
>> I have installed freeradius 2.1.8 on Ubuntu Server 8.04 by making deb
>> packages from the source and installing the deb packages.
>>
>> Radius is relying on an LDAP server for authentication of wireless
>> clients. Only clients with valid usernames and passwords in LDAP will
>> get authenticated.
>>
>> What I would really like to do (other than actually be able to
>> understand the concepts behind the config files) is require clients to
>> be in a particular LDAP group (e.g., wireless-users) in order to
>> successfully authenticate.  I don't understand how to make that happen.
>> I've tried creating group filters like this in "modules/ldap":
>>
>> groupname_attribute = cn
>> groupmembership_filter =
>>
>> "(&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}}))"
>> groupmembership_attribute = memberUid
>>
>> and this in "users":
>>
>> DEFAULT LDAP-GROUP == vpn-users
>>         Service-Type = Administrative-User
>>
>> But the output seems to indicate that it is not even considering my
>> radiusd.conf config when it comes to the filter.  (see output below).
>>
>> I would so welcome assistance with this.  In addition, is there any
>> resource that is particularly good at explaining how radius and its
>> config files really works?
>>
>
> I feel your pain, the ldap module is poorly documented and hard to use.
> There is doc in doc/ldap_howto.txt, not sure where that might be installed
> on Ubuntu though. Just a caveat about that ldap_howto.txt, it's a bit out of
> date and was written with a particular configuration in mind, but you do
> need to wrap your head around it to understand where values are coming from.
>
> ldap-group isn't very meaningful to set in the users file because it's an
> attribute in the ldap directory. In fact using the users file isn't
> generally useful in combination with with ldap because your users are in
> ldap, not a flat file, right? The users file can be useful when you want to
> match on the NAS via huntgroups, the ldap_howto does a fair job of
> illustrating that. So anyway you won't ever find "vpn-users" defined via the
> users file because the line you have won't be matched by anything Why?
> Because group gets set via ldap lookups using the groupmembership_filter and
> asking for the groupname_attribute for what the filter matched. So one
> question to ask is: is your ldap directory populated with the object classes
> and attributes this filter is searching for?
>
> As an aside one of the very first things I noticed looking at your debug
> output is the ldap module was built to use the Novell eDirectory server
> (which is a compile time switch). Unless you're using the Novell eDirectory
> server rather than a generic directory server things are going to behave a
> bit weird. Any idea why it's built to use Novell? Anyway that's probably not
> the crux of your problem at the moment, just a data point. I don't know why
> the eDirectory #ifdef's are even in rlm_ldap, to be honest they seem to be
> "odd" to put it politely.
>
> I don't have time at the moment to fully analyze what's going on in your
> set up but one of the very first things I noticed was this:
>
>
>
> (|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))
> ->
>
> (|(&(objectClass=GroupOfNames)(member=))(&(objectClass=GroupOfUniqueNames)(uniquemember=)))
>
> Notice something? Ldap-UserDn was replaced by the empty string and that
> search filter isn't going to do you much good is it? So where does
> Ldap-UserDn come from? From doing a search in LDAP for the user. If the user
> is found then Ldap-UserDn is set to the location at which the user was found
> (think of a dn (i.e. distinguished name) as an address or pointer in an LDAP
> directory). So how was the search done to find the user? Well that's just a
> couple of lines above in the debug output:
>
>
>  [ldap] performing search in dc=cns, with filter (uid=jmaher)
>
> One of the frustrating things about rlm_ldap is it doesn't provide debug
> output on successful searches, only failures. There is no failure, so we
> assume the search succeeded, but we really don't know what the result was
> :-( As a debugging tip I would suggest running ldapsearch on the command
> line with the same filter and see what you get back.
>
> You should get back a ldap search result with exactly one match with a
> specific dn, that dn is what should be showing up as Ldap-UserDn in
> rlm_ldap. So for starters you need to either populate your directory such
> that ldapsearch finds your user using the same parameters you configured in
> rlm_ldap, or you need to modify the parameters in rlm_ldap to match your
> directory such that it can find the user. That's a good starting place from
> which you can build further functionality.
>
> Hope that helps,
>
> --
> John Dennis <jdennis at redhat.com>
>
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20100521/4c3cc5ff/attachment.html>