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.
On 05/21/2010 07:31 PM, sbchem wrote:
Greetings,
I installed a fresh copy of FreeRadius v 2.1.7 on CentOS 5. Ran radtest
locally as well as remotely and it works great. Now I want to point the
server to my /etc/shadow file which lives on the same machine. I have not
made any changes to the
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
Hi
I have been testing freeradius for a while and its seems really straight
forward. I would just like to know if its possible to right login scripts.
What I am trying to achieve is this. we currently have two different
gateways out there (nomadix and mikrotik) and if the users from nomadix
sbchem wrote:
I installed a fresh copy of FreeRadius v 2.1.7 on CentOS 5. Ran radtest
locally as well as remotely and it works great. Now I want to point the
server to my /etc/shadow file which lives on the same machine. I have not
made any changes to the default config except to change the
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
It's not a good idea to change the ownership of /etc/shadow from a
security and system perspective. Rather than using rlm_unix use rlm_pam
instead
Understood and agreed. This is not a production environment. I was just
trying to understand how the modules worked. That being said, I am now
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
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
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
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
You need to edit raddb/sites-available/inner-tunnel, too.
sites-available or sites-enabled? I did edit inner-tunnel in
sites-enabled as well as default
See raddb/modules/passwd instead
added the following to passwd:
unix {
filename = /etc/shadow
format =
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
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
sbchem wrote:
You need to edit raddb/sites-available/inner-tunnel, too.
sites-available or sites-enabled? I did edit inner-tunnel in
sites-enabled as well as default
The original debug log you posted shows *no* reference to unix in
the inner-tunnel server. That's why authentication is
That's why authentication is failing.
++[unix] returns notfound
So... what can you conclude from that?
I would assume it means that the unix module could not find the user.
Let's simplify. I am now running radtest locally on the same box with this
command:
radtest test password 127.0.0.1
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
sbchem wrote:
I would assume it means that the unix module could not find the user.
Yes. Is the user in /etc/passwd and /etc/shadow?
If so, check permissions, and maybe configure PAM.
If not...
Based on your prior mesage should I be putting the reference to /etc/shadow
in the unix
Is the user in /etc/passwd and /etc/shadow?
Yes
If so, check permissions
/etc/shadow was chgrp'd to radiusd in spite of John Dennis' warnings to the
contrary --
BUT I forgot to change the read permission -- my fault totally --
Which file did I tell you to modify?
modules/passwd edited as
sbchem wrote:
you and John Dennis both mentioned PAM so I went ahead and commented out the
passwd entires and I am now looking at PAM per your suggestion.
Installed the pam-radius client per
http://freeradius.org/pam_radius_auth/
Uh... no. PLease *read* the documentation for
20 matches
Mail list logo
