On Fri, May 21, 2010 at 5:26 PM, John Dennis
<jdennis@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?
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@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/