Re: Authenticating groups via LDAP
On Sun, May 23, 2010 at 12:54:49PM +0200, Alan DeKok wrote: > Josip Rodin wrote: > > IMHO just changing modules to the -enabled/-available scheme would be a good > > first step and it should be done first, in 2.1.10 or whenever. > > I'd say 2.2.0. And then move eap.conf && sql.conf to raddb/modules*, too. > > The only reason that eap.conf && sql.conf aren't in the modules > directory is that too many documents point to them. And I couldn't take > the thought of having raddb/eap.conf say: > > "look in modules/eap for the real configuration" > > ... and then getting questions asking "what does that mean?" You already had one such transition, from clients to clients.conf, which was more painful because of a different format, IIRC. IMHO if done right this small change doesn't have to be painful at all. sites-available/enabled is already done in 2.1.x so the groundwork is already laid. -- 2. That which causes joy or happiness. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
John Maher wrote: > Yes, obviously an important distinction. But where my mind goes > immediately is "why is it that if I enter an incorrect password for that > user that the user fails to gain access, but a correct password results > in access granted?". doc/rlm_ldap explains this. > But I imagine the answer is more complicated than > the difference between authentication and authorization, and probably > has something to do with some other authentication routine that takes > place later. I have a lot to learn. No... it's a historial leftover from ISP authentication. It's not clear, but it does serve a purpose. > Thanks for the direction. I'll study those now. Remember: DNS (bind) reads config files. DHCP (ISC) reads config files. FreeRADIUS reads config files, LDAP, SQL, DBM, shell scripts, Perl, Python, Java, Ruby, and implements EAP, WiMAX, IP address assignment (i.e. most of DHCP), name lookups (i.e. most of DNS) ... It's not surprising that people find it complicated. But a basic step-by-step approach helps a *lot*. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On 05/23/2010 11:27 AM, Alan DeKok wrote: > authorization != authentication > > If there isn't a password... the user can't be authenticated. The > debug log shows this. Yes, obviously an important distinction. But where my mind goes immediately is "why is it that if I enter an incorrect password for that user that the user fails to gain access, but a correct password results in access granted?". But I imagine the answer is more complicated than the difference between authentication and authorization, and probably has something to do with some other authentication routine that takes place later. I have a lot to learn. >> Anyway, a good resource for understanding how radius and its modules do >> their jobs would be good to know about. > > doc/rlm_ldap explains how the LDAP module is used, and how the > "access" is checked. > > Again... this *is* documented. The filenames shouldn't be hard to > figure out: doc/rlm_ldap should be pretty easy to find. > > doc/aaa.txt explains how the authentication process works. > > While the documentation isn't perfect, I'm not sure what you want. > The questions you're asking are answered in the existing documentation, > which is reasonably well organized. (try: ls doc/*ldap* ...) Thanks for the direction. I'll study those now. John > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
John Maher wrote: > Thanks for this information. Being very new to radius, and a bit sloppy > with my wording, I was not clear about what I was looking for. It's true > that the function of the different config files not that complicated. > What is not clear to me, when looking at the output of freeradius -X > that is generated from a user's connection attempt, is the sequencing > and reasoning behind the output. Well.. it does a lot. Remember, this isn't... DNS: what is the IP for name X? DHCP: please allocate an IP for MAC Y, I'm on switch X port Y RADIUS is *enormously* more complicated. As a result, the configuration files are more complicated, and the debug output is more complicated. > For example, the output I posted included this: ... > I don't understand several things from this, but one example is why does > it state: > > WARNING: No "known good" password was found in LDAP. Are you sure that > the user is configured correctly? > > and the next line states: > > [ldap] user jmaher authorized to use remote access > > ? authorization != authentication If there isn't a password... the user can't be authenticated. The debug log shows this. > Anyway, a good resource for understanding how radius and its modules do > their jobs would be good to know about. doc/rlm_ldap explains how the LDAP module is used, and how the "access" is checked. Again... this *is* documented. The filenames shouldn't be hard to figure out: doc/rlm_ldap should be pretty easy to find. doc/aaa.txt explains how the authentication process works. While the documentation isn't perfect, I'm not sure what you want. The questions you're asking are answered in the existing documentation, which is reasonably well organized. (try: ls doc/*ldap* ...) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On 05/22/2010 01:45 PM, Alan DeKok wrote:
> Johnny R wrote:
>> Alan,
>>
>> John Maher at the first post asked if there is any resource that is
>> particularly good at explaining how radius and its config files really
>> works. I want just to ask it again, if possible, it there is any thread
>> or link illustrating how all files in /etc/radb interact to each other.
>
> radiusd.conf is the "master" file, and reads all of the other ones.
>
> The "modules" directory contains module configuration.
>
> The "sites-available" directory contains sample virtual servers.
>
> The "sites-enabled" directory contains enabled virtual servers.
>
> The "dictionary" file references dictionaries.
>
> Everything else is usually a file needed by a module.
>
> It's really not that complicated, and the filenames are usually
> descriptive, so you can tell what they do.
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan,
Thanks for this information. Being very new to radius, and a bit sloppy
with my wording, I was not clear about what I was looking for. It's true
that the function of the different config files not that complicated.
What is not clear to me, when looking at the output of freeradius -X
that is generated from a user's connection attempt, is the sequencing
and reasoning behind the output.
For example, the output I posted included this:
[ldap] performing user authorization for jmaher
[ldap] WARNING: Deprecated conditional expansion ":-". See "man unlang"
for details
[ldap] ... expanding second conditional
[ldap] expand: %{User-Name} -> jmaher
[ldap] expand: (uid=%{Stripped-User-Name:-%{User-Name}}) -> (uid=jmaher)
[ldap] expand: dc=cns -> dc=cns
[ldap] ldap_get_conn: Checking Id: 0
[ldap] ldap_get_conn: Got Id: 0
[ldap] performing search in dc=cns, with filter (uid=jmaher)
[ldap] No default NMAS login sequence
[ldap] looking for check items in directory...
[ldap] sambaNtPassword -> NT-Password ==
0x453735323843413532363245374530364543832363635383830453042333
[ldap] sambaLmPassword -> LM-Password ==
0x3743414639453142313632453745303645463337453431343231373532384341
[ldap] looking for reply items in directory...
WARNING: No "known good" password was found in LDAP. Are you sure that
the user is configured correctly?
[ldap] user jmaher authorized to use remote access
[ldap] ldap_release_conn: Release Id: 0
++[ldap] returns ok
I don't understand several things from this, but one example is why does
it state:
WARNING: No "known good" password was found in LDAP. Are you sure that
the user is configured correctly?
and the next line states:
[ldap] user jmaher authorized to use remote access
?
Anyway, a good resource for understanding how radius and its modules do
their jobs would be good to know about.
Thanks.
John
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
Josip Rodin wrote: > IMHO just changing modules to the -enabled/-available scheme would be a good > first step and it should be done first, in 2.1.10 or whenever. I'd say 2.2.0. And then move eap.conf && sql.conf to raddb/modules*, too. The only reason that eap.conf && sql.conf aren't in the modules directory is that too many documents point to them. And I couldn't take the thought of having raddb/eap.conf say: "look in modules/eap for the real configuration" ... and then getting questions asking "what does that mean?" Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On Sat, May 22, 2010 at 01:45:59PM -0400, John Dennis wrote: > rather than renaming all the config files to have a common extension and > only loading those files with extension the correct extension the > preferred model would be to utilize enabled,available directories. The > filenames would stay the same as would the practice of loading every > file in the enabled directory. But the enabled directory would contain > only symlinks. However that would still probably leave the problem of > editor back up files and the naive admin who might copy a file (which > invisibly would be a symlink) to a backup name. We already have that particular problem with -enabled/ but it's confined to the realm of really sloppy admins who forget to edit in -available/. This is still acceptable and alleviates the original problem sufficiently, and it requires no code changes, just the default configuration changes. IMHO just changing modules to the -enabled/-available scheme would be a good first step and it should be done first, in 2.1.10 or whenever. -- 2. That which causes joy or happiness. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On Sat, May 22, 2010 at 07:17:29PM +0100, Alan Buxey wrote:
> although some would say thats the package people talking - and that the issue
> is only present because of how package management tools etc work. surely
> the best way of RPM, APT etc leaving behind all their
> rubbish/old-files/new-files
> etc is for them to utilise some revision control system or drop the files into
> a .special directory, eg .rpmnew for example.
Even if there was no packaging system, you would still have users who aren't
excessively pedantic who would leave their own copies of files in the same
folder. For example leaving an explicit copy of an old configuration in e.g.
ldap-2010-05-23.bak.
It still seems best to avoid the greediest match...
> moving to a new system where eg module files have a .mod extension and virtual
> servers have a .vsf extension (virtual server file ;-) ) then any present
> systems need to have quite a few tweaks to be upgraded from their present
> situation...
That's why the mods-{available,enabled} idea is IMHO best. All Apache users
are used to it, which covers most people anyway, the FR users got used to
sites-{available,enabled} already so it's not much of a leap, and the
upgrade procedure is simple:
mv $confdir/modules $confdir/mods-available
mkdir $confdir/mods-enabled
cd $confdir/mods-enabled && ln -s ../mods-available/* .
That preserves existing functionality to the letter - but it allows people
to later disable what they don't want/need easily - just remove some extra
symlinks.
> you could also argue that the easiest way is to include each file line
> by line in the radiusd.conf instead of using funky directories and including
> files wholesale.
This is bad for packaged radiusd.conf's because it requires explicit user
intervention into the file contents.
The unconditional inclusion of (also packaged) eap.conf is an example of why
this is bad - the admin who wants to tweak those settings has to either
modify radiusd.conf to comment out the inclusion, or modify eap.conf to
adjust the parameters. And either one of those causes the packaging system
to notice that the user changed a configuration file upon the next upgrade,
and in turn present a possibly confusing choice to the upgrading admin - and
that kind of a situation doesn't necessarily end well :)
Since this file simply defines the eap module, I don't really see any reason
why it should not exist simply as a modules/eap file (or analogous in the
future). Same goes for sql.conf, but luckily that one is commented out by
default.
--
2. That which causes joy or happiness.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On Sat, May 22, 2010 at 10:22:12AM -0400, John Dennis wrote:
> Alan I didn't see any open bugs on this, should we open one? Is this a
> planned modification for 2.2? I recall some discussion of this a while
> back on the mailing list. I suppose changing this is 2.1 would be a
> version violation. But it has such serious negative consequences I
> wonder if we shouldn't bite the bullet and change it in 2.1.9 before
> more people get bitten by this. But to be honest I'm not sure which is
> worse, an unexpected config file change on upgrade or mysterious
> *silent* failures after upgrade.
>
> I think the RPM spec file (and the deb files) could include a script
> which would detect the an old modules directory layout and convert it to
> modules-{available,enabled} layout automatically during a package
> upgrade.
The deb package maintenance scripts can and will do the same.
> Also, I was just looking at our RPM spec file and I noticed that files
> in /etc/raddb/sites-enabled (which should just be symlinks) are marked
> as config(noreplace) which means RPM will leave backup files there
> instead of treating sites-enabled as just a collection of symlinks to be
> left alone. I think this represents a packaging bug on my end. However I
> noticed the suse freeradius.spec file in the freeradius-server tarballs
> also have the exact same config(noreplace) in raddb/sites-enabled so
> that packaging bug seems universal.
We had the same problem in Debian packages at one point, but we unmarked
them as conffiles already.
--
2. That which causes joy or happiness.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
Hi, > Bottom line: I think the practice of loading every file found in a > directory is inherently risky and bug prone. I think it should only load > files with a specific extension, that seems much safer. This still works > nicely with the enabled/available split. although some would say thats the package people talking - and that the issue is only present because of how package management tools etc work. surely the best way of RPM, APT etc leaving behind all their rubbish/old-files/new-files etc is for them to utilise some revision control system or drop the files into a .special directory, eg .rpmnew for example. moving to a new system where eg module files have a .mod extension and virtual servers have a .vsf extension (virtual server file ;-) ) then any present systems need to have quite a few tweaks to be upgraded from their present situation... you could also argue that the easiest way is to include each file line by line in the radiusd.conf instead of using funky directories and including files wholesale. choices. choices. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On 05/22/2010 01:56 PM, Alan DeKok wrote: John Dennis wrote: Bottom line: I think the practice of loading every file found in a directory is inherently risky and bug prone. I think it should only load files with a specific extension, that seems much safer. This still works nicely with the enabled/available split. Sure. Is it critical enough to delay 2.1.9? Consider that there have been *sporadic* complaints since 2.0.0 (late 2007). Personally, I'd wait for 2.1.10. This work involves code changes *and* renaming configuration files. That's pretty drastic, and should be well tested before being released. Agreed. It should wait. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
John Dennis wrote: > Bottom line: I think the practice of loading every file found in a > directory is inherently risky and bug prone. I think it should only load > files with a specific extension, that seems much safer. This still works > nicely with the enabled/available split. Sure. Is it critical enough to delay 2.1.9? Consider that there have been *sporadic* complaints since 2.0.0 (late 2007). Personally, I'd wait for 2.1.10. This work involves code changes *and* renaming configuration files. That's pretty drastic, and should be well tested before being released. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On 05/22/2010 12:32 PM, Alan DeKok wrote:
John Dennis wrote:
Alan I didn't see any open bugs on this, should we open one? Is this a
planned modification for 2.2?
Yes.
I recall some discussion of this a while
back on the mailing list. I suppose changing this is 2.1 would be a
version violation. But it has such serious negative consequences I
wonder if we shouldn't bite the bullet and change it in 2.1.9 before
more people get bitten by this. But to be honest I'm not sure which is
worse, an unexpected config file change on upgrade or mysterious
*silent* failures after upgrade.
I'd make the change in 2.1.10, if at all. It's a relatively rare
problem compared to other issues seen regularly on the list.
I think the RPM spec file (and the deb files) could include a script
which would detect the an old modules directory layout and convert it to
modules-{available,enabled} layout automatically during a package upgrade.
Sure...
Also, I was just looking at our RPM spec file and I noticed that files
in /etc/raddb/sites-enabled (which should just be symlinks) are marked
as config(noreplace) which means RPM will leave backup files there
instead of treating sites-enabled as just a collection of symlinks to be
left alone. I think this represents a packaging bug on my end. However I
noticed the suse freeradius.spec file in the freeradius-server tarballs
also have the exact same config(noreplace) in raddb/sites-enabled so
that packaging bug seems universal.
Sure. Not everyone uses symlinks in sites-enabled. Some put files
there directly.
Well, if that's the case then the current practice of reading every file
found in the directory won't work. Why? Because many package managers
leave backup files behind for configuration files. Then there is also
the issue of editor backup files (e.g. the ~ files from emacs). When
this issue originally came up I thought I recalled the argument was
rather than renaming all the config files to have a common extension and
only loading those files with extension the correct extension the
preferred model would be to utilize enabled,available directories. The
filenames would stay the same as would the practice of loading every
file in the enabled directory. But the enabled directory would contain
only symlinks. However that would still probably leave the problem of
editor back up files and the naive admin who might copy a file (which
invisibly would be a symlink) to a backup name.
Bottom line: I think the practice of loading every file found in a
directory is inherently risky and bug prone. I think it should only load
files with a specific extension, that seems much safer. This still works
nicely with the enabled/available split.
--
John Dennis
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
Johnny R wrote: > Alan, > > John Maher at the first post asked if there is any resource that is > particularly good at explaining how radius and its config files really > works. I want just to ask it again, if possible, it there is any thread > or link illustrating how all files in /etc/radb interact to each other. radiusd.conf is the "master" file, and reads all of the other ones. The "modules" directory contains module configuration. The "sites-available" directory contains sample virtual servers. The "sites-enabled" directory contains enabled virtual servers. The "dictionary" file references dictionaries. Everything else is usually a file needed by a module. It's really not that complicated, and the filenames are usually descriptive, so you can tell what they do. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
Alan,
John Maher at the first post asked if there is any resource that is
particularly good at explaining how radius and its config files really
works. I want just to ask it again, if possible, it there is any thread or
link illustrating how all files in /etc/radb interact to each other.
Thank U.
On Sat, May 22, 2010 at 4:32 PM, Alan DeKok wrote:
> John Dennis wrote:
> > Alan I didn't see any open bugs on this, should we open one? Is this a
> > planned modification for 2.2?
>
> Yes.
>
> > I recall some discussion of this a while
> > back on the mailing list. I suppose changing this is 2.1 would be a
> > version violation. But it has such serious negative consequences I
> > wonder if we shouldn't bite the bullet and change it in 2.1.9 before
> > more people get bitten by this. But to be honest I'm not sure which is
> > worse, an unexpected config file change on upgrade or mysterious
> > *silent* failures after upgrade.
>
> I'd make the change in 2.1.10, if at all. It's a relatively rare
> problem compared to other issues seen regularly on the list.
>
> > I think the RPM spec file (and the deb files) could include a script
> > which would detect the an old modules directory layout and convert it to
> > modules-{available,enabled} layout automatically during a package
> upgrade.
>
> Sure...
>
> > Also, I was just looking at our RPM spec file and I noticed that files
> > in /etc/raddb/sites-enabled (which should just be symlinks) are marked
> > as config(noreplace) which means RPM will leave backup files there
> > instead of treating sites-enabled as just a collection of symlinks to be
> > left alone. I think this represents a packaging bug on my end. However I
> > noticed the suse freeradius.spec file in the freeradius-server tarballs
> > also have the exact same config(noreplace) in raddb/sites-enabled so
> > that packaging bug seems universal.
>
> Sure. Not everyone uses symlinks in sites-enabled. Some put files
> there directly.
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
--
-
|JJohnny RANDRIAMAMPIONONA |
| Phone: +212663682554|
| National School of Applied Sciences |
| 1818 TANGIER 9 |
||
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
John Dennis wrote:
> Alan I didn't see any open bugs on this, should we open one? Is this a
> planned modification for 2.2?
Yes.
> I recall some discussion of this a while
> back on the mailing list. I suppose changing this is 2.1 would be a
> version violation. But it has such serious negative consequences I
> wonder if we shouldn't bite the bullet and change it in 2.1.9 before
> more people get bitten by this. But to be honest I'm not sure which is
> worse, an unexpected config file change on upgrade or mysterious
> *silent* failures after upgrade.
I'd make the change in 2.1.10, if at all. It's a relatively rare
problem compared to other issues seen regularly on the list.
> I think the RPM spec file (and the deb files) could include a script
> which would detect the an old modules directory layout and convert it to
> modules-{available,enabled} layout automatically during a package upgrade.
Sure...
> Also, I was just looking at our RPM spec file and I noticed that files
> in /etc/raddb/sites-enabled (which should just be symlinks) are marked
> as config(noreplace) which means RPM will leave backup files there
> instead of treating sites-enabled as just a collection of symlinks to be
> left alone. I think this represents a packaging bug on my end. However I
> noticed the suse freeradius.spec file in the freeradius-server tarballs
> also have the exact same config(noreplace) in raddb/sites-enabled so
> that packaging bug seems universal.
Sure. Not everyone uses symlinks in sites-enabled. Some put files
there directly.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On 05/22/2010 04:34 AM, Josip Rodin wrote:
On Fri, May 21, 2010 at 05:19:55PM -0400, John Dennis wrote:
I just figured this part out. The radiusd.conf file has an Include
/etc/freeradius/modules statement, and there was a file in the modules
directory called ldap.dpkg-old in that directory that was overiding the
ldap config file. That doesn't mean everything works, but at least that
mystery is solved.
I think Josip Rodin is maintaining the deb packages. If somehow the old
config files are overriding the new config files in the deb packages
then you and Josip might want to work out what the problem is, sounds
like a packaging bug. I've cc'ed Josip on this email, I know he reads
this list but might not be paying attention to this thread.
Thanks. The real problem here is that FreeRADIUS includes *all* files in the
modules/ directory, whereas excess files are really legitimate - *.dpkg-*
conffile resolution backups, editor lock files and backup files, etc.
This will be fixed either with code changes to reduce the filename pattern
matched (e.g. *.conf) or by moving to modules-{available,enabled}/, like
Apache does it.
Until then, users need to be extra careful to keep modules/ clean.
This applies everywhere (not just on Debian).
Oh, that's right, I had forgotten FreeRADIUS reads all files in the
modules directory irrespective of it's name or extension. That's a
serious problem. RPM installations will also leave old config files in
those directories (.rpmsave files) when the package is updated.
Alan I didn't see any open bugs on this, should we open one? Is this a
planned modification for 2.2? I recall some discussion of this a while
back on the mailing list. I suppose changing this is 2.1 would be a
version violation. But it has such serious negative consequences I
wonder if we shouldn't bite the bullet and change it in 2.1.9 before
more people get bitten by this. But to be honest I'm not sure which is
worse, an unexpected config file change on upgrade or mysterious
*silent* failures after upgrade.
I think the RPM spec file (and the deb files) could include a script
which would detect the an old modules directory layout and convert it to
modules-{available,enabled} layout automatically during a package upgrade.
Also, I was just looking at our RPM spec file and I noticed that files
in /etc/raddb/sites-enabled (which should just be symlinks) are marked
as config(noreplace) which means RPM will leave backup files there
instead of treating sites-enabled as just a collection of symlinks to be
left alone. I think this represents a packaging bug on my end. However I
noticed the suse freeradius.spec file in the freeradius-server tarballs
also have the exact same config(noreplace) in raddb/sites-enabled so
that packaging bug seems universal.
--
John Dennis
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On Fri, May 21, 2010 at 05:19:55PM -0400, John Dennis wrote:
>> I just figured this part out. The radiusd.conf file has an Include
>> /etc/freeradius/modules statement, and there was a file in the modules
>> directory called ldap.dpkg-old in that directory that was overiding the
>> ldap config file. That doesn't mean everything works, but at least that
>> mystery is solved.
>
> I think Josip Rodin is maintaining the deb packages. If somehow the old
> config files are overriding the new config files in the deb packages
> then you and Josip might want to work out what the problem is, sounds
> like a packaging bug. I've cc'ed Josip on this email, I know he reads
> this list but might not be paying attention to this thread.
Thanks. The real problem here is that FreeRADIUS includes *all* files in the
modules/ directory, whereas excess files are really legitimate - *.dpkg-*
conffile resolution backups, editor lock files and backup files, etc.
This will be fixed either with code changes to reduce the filename pattern
matched (e.g. *.conf) or by moving to modules-{available,enabled}/, like
Apache does it.
Until then, users need to be extra careful to keep modules/ clean.
This applies everywhere (not just on Debian).
--
2. That which causes joy or happiness.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On 05/21/2010 05:10 PM, John Maher wrote:
On 05/21/2010 10:44 AM, John Maher wrote:
I didn't notice what you pointed out, but it's telling. Actually, the
thing I noticed and am confused by is that the filter I have in
/etc/freeradius/modules/ldap (is that simply the configuration file for
rlm_ldap?) is this:
groupmembership_filter =
"(&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}}))"
So why is the filter in the output this:
(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))
I just figured this part out. The radiusd.conf file has an Include
/etc/freeradius/modules statement, and there was a file in the modules
directory called ldap.dpkg-old in that directory that was overiding the
ldap config file. That doesn't mean everything works, but at least that
mystery is solved.
I think Josip Rodin is maintaining the deb packages. If somehow the old
config files are overriding the new config files in the deb packages
then you and Josip might want to work out what the problem is, sounds
like a packaging bug. I've cc'ed Josip on this email, I know he reads
this list but might not be paying attention to this thread.
--
John Dennis
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On 05/21/2010 10:44 AM, John Maher wrote:
> I didn't notice what you pointed out, but it's telling. Actually, the
> thing I noticed and am confused by is that the filter I have in
> /etc/freeradius/modules/ldap (is that simply the configuration file for
> rlm_ldap?) is this:
>
> groupmembership_filter =
> "(&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}}))"
>
> So why is the filter in the output this:
>
> (|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))
I just figured this part out. The radiusd.conf file has an Include
/etc/freeradius/modules statement, and there was a file in the modules
directory called ldap.dpkg-old in that directory that was overiding the
ldap config file. That doesn't mean everything works, but at least that
mystery is solved.
John
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
On 05/21/2010 01:26 AM, John Dennis wrote:
John,
Thank you very much for responding with such detail and clarity. And
thanks for pointing me to ldap_howto.txt. I'll be studying this to
understand it better.
Please see below for other comments.
> 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 have no idea why that is the case. I did the following to create and
install freeradius on Ubuntu (as suggested by this page:
http://wiki.freeradius.org/Build#Building_Debian_packages):
$ tar zxf freeradius-server-2.X.Y.tar.gz
$ cd freeradius-server-2.X.Y
$ fakeroot dpkg-buildpackage -b -uc
$ sudo dpkg -i ../freeradius_2.X.Y-0_i386.deb
> 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?
I didn't notice what you pointed out, but it's telling. Actually, the
thing I noticed and am confused by is that the filter I have in
/etc/freeradius/modules/ldap (is that simply the configuration file for
rlm_ldap?) is this:
groupmembership_filter =
"(&(objectClass=posixGroup)(memberUid=%{Stripped-User-Name:-%{User-Name}}))"
So why is the filter in the output this:
(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))
That filter is VERY similar to the commented out line in
/etc/freeradius/modules/ldap. It appears to be hard coded in rlm_ldap,
which is not likely, right? That commented out line is this:
# groupmembership_filter =
"(|(&(objectClass=GroupOfNames)(member=%{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:Ldap-UserDn})))"
I'm going to think through your other comments now.
Thanks again.
John
--
* - - - - * - - - - * - - - - * - - - - * - - - - * - - - - * - - - - *
John Maher
Senior Systems and Network Administrator
Department of Biochemistry & Molecular Biology and
Department of Chemistry
University of Massachusetts - Amherst
voice: 413-577-3120 fax: 413-545-4490
OpenPGP Key ID: 0x2970A144
Want your email to be private? http://enigmail.mozdev.org
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authenticating groups via LDAP
This is how I did it.
Works well for me.
http://lists.freeradius.org/mailman/htdig/freeradius-users/2009-November/msg1.html
On Fri, May 21, 2010 at 5:26 PM, John Dennis 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
Re: Authenticating groups via LDAP
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 function
Authenticating groups via LDAP
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?
Thanks.
John
# freeradius -X
FreeRADIUS Version 2.1.8, for host i486-pc-linux-gnu, built on May 14
2010 at 09:29:10
Copyright (C) 1999-2009 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License v2.
Starting - reading configuration files ...
including configuration file /etc/freeradius/radiusd.conf
including configuration file /etc/freeradius/proxy.conf
including configuration file /etc/freeradius/clients.conf
including files in directory /etc/freeradius/modules/
including configuration file /etc/freeradius/modules/unix
including configuration file /etc/freeradius/modules/detail
including configuration file /etc/freeradius/modules/ldap.dpkg-old
including configuration file /etc/freeradius/modules/ntlm_auth
including configuration file /etc/freeradius/modules/sql_log
including configuration file /etc/freeradius/modules/sradutmp
including configuration file /etc/freeradius/modules/attr_filter
including configuration file /etc/freeradius/modules/realm
including configuration file /etc/freeradius/modules/echo
including configuration file /etc/freeradius/modules/pap
including configuration file /etc/freeradius/modules/radutmp
including configuration file /etc/freeradius/modules/ldap
including configuration file /etc/freeradius/modules/ippool
including configuration file /etc/freeradius/modules/files
including configuration file /etc/freeradius/modules/linelog
including configuration file /etc/freeradius/modules/pam
including configuration file /etc/freeradius/modules/mac2ip
including configuration file /etc/freeradius/modules/perl
including configuration file /etc/freeradius/modules/chap
including configuration file /etc/freeradius/modules/checkval
including configuration file /etc/freeradius/modules/smsotp
including configuration file /etc/freeradius/modules/etc_group
including configuration file /etc/freeradius/modules/digest
including configuration file /etc/freeradius/modules/always
including configuration file /etc/freeradius/modules/detail.example.com
including configuration file /etc/freeradius/modules/krb5
including configuration file /etc/freeradius/modules/expiration
including configuration file /etc/freeradius/modules/mschap
including configuration file /etc/freeradius/modules/exec
including configuration file /etc/freeradius/modules/policy
including configuration file /etc/freeradius/modules/counter
including configuration file
/etc/freeradius/modules/sqlcounter_expire_on_login
including configuration file /etc/freeradius/modules/otp
including configuration file /etc/freeradius/modules/mac2vlan
including configuration file /etc/freeradius/modules/acct_unique
including configuration file /etc/freeradius/modules/wimax
including configuration file /etc/freeradius/modules/passwd
including configuration file /etc/freeradius/modules/smbpasswd
including configuration file /etc/freeradius/modules/attr_rewrite
including configuration file /etc/freeradius/modules/expr
including configuration file /etc/freeradius/modules/detail.log
including configuration file /etc/freeradius/modules/inner-eap
including configuration file /etc/freeradius/modules/cui
including configuration file /etc/freeradius/modules/logintime
including configuration file /etc/freeradius/modules/preprocess
including configuration file /etc/freeradius/eap.conf
including configuration file /etc/freeradius/policy.conf
incl
