Authenticating groups via LDAP

[John Dennis]

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/