Re: [Freeradius-Users]modcall[authenticate]: module unix returns notfound for request
the unix module searched for users in /etc/passwd (or whatever file you tell it to search). this has nothing to do with mysql. if you want to use the unix module, then make sure the user exists in /etc/passwd and that freeradius has read ability to that file. if you want to use mysql, then configure the mysql module. On 3/7/06, Jedliu [EMAIL PROTECTED] wrote: Hi, All! When I wanna run freeradius with the support of MySQL, I found such mes * modcall[authenticate]: module unix returns notfound for request 12 modcall: group authenticate returns notfound for request 12 * in radiusd -X mode,but the user in USERS file can be authenticated successfully. I've googled,but not find the solution. And i've searched from the mailing list,though there're some troubleshooting too,no way to solove. So pls help! Thx in advance! Regards for everyone. jedliu [EMAIL PROTECTED] 2006-03-06 - 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: V1.10 File and LDAP Problems
NOT WORKING: Ready to process requests. rad_recv: Access-Request packet from host 10.0.90.32:2017, id=62, length=46 User-Name = testme User-Password = 123456 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module preprocess returns ok for request 0 users: Matched entry testme at line 142 modcall[authorize]: module files returns ok for request 0 modcall[authorize]: module mschap returns noop for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for testme radius_xlat: '(sAMAccountname=testme)' radius_xlat: 'dc=consolidated,dc=com' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to 10.0.60.177:389, authentication 0 rlm_ldap: bind as cn=someuser,cn=Users,dc=ourcompany,dc=com/secret to 10.0.xx.xxx:389 rlm_ldap: waiting for bind result ... rlm_ldap: LDAP login failed: check identity, password settings in ldap section of radiusd.conf Looks like you don't have the LDAP information setup correctly. FreeRADIUS can't login to LDAP with the settings (un)specified. rlm_ldap: (re)connection attempt failed rlm_ldap: search failed rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap returns fail for request 0 modcall: leaving group authorize (returns fail) for request 0 LDAP returns fail, which is weighted heavier than the both the noop returned by mschap and the ok returned by files. Because LDAP returns fail, the entire request returns fail. You can specify different weighted settings for noop, fail, etc, but the obvious answer is to fix your LDAP settings and then try again. Once you can login to the LDAP, if the user does not exist in there then LDAP should return noop for the request. If you want a user to exist in both the LDAP and the users file with different passwords, that requires a bit of tweaking but I've got it working if you need to see how sometime. Hope this helps! Andrew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: V1.10 File and LDAP Problems
How do you go about setting the weighting. I want to be able to use text,
ldap and mysql so that we have various fall back options with a failure of
the external databases (ldap and mysql).
I'm pulling this straight from the configurable_failover.gz file
from the documentation:
---cut-
Rewriting results for single modules
Normally, when a module fails, the entire section (authorize,
accounting, etc.) stops being processed. In some cases, we may want
to permit soft failures. That is, we may want to tell the server
that it is ok for a module to fail, and that the failure should not
be treated as a fatal error.
In this case, the module is treated as a section, rather than just
as a single line in radiusd.conf. The configuration entries for
that section are taken from the configurable fail-over code, and not
from the configuration information for that module.
For example, the detail module normally returns fail if it is
unable to write its information to the detail file. As a test, we
can configure the server so that it continues processing the request,
even if the detail module fails. The following example shows how:
#--
# Handle accounting packets
accounting {
detail {
fail = 1
}
redundant {
sql1
sql2
handled
}
}
#--
The fail = 1 entry tells the server to remember the fail code,
with priority 1. The normal configuration is fail = return, which
means if the detail module fails, stop processing the accounting
section.
---cut-
So by setting fail equal to a value (1-9) you override the default
fail = return.
Once you can
login to the LDAP, if the user does not exist in there then LDAP
should return noop for the request. If you want a user to
exist in
both the LDAP and the users file with different passwords, that
requires a bit of tweaking but I've got it working if you need to see
Would like to see how you did it.
Here's how I have ldap/unix redundant group setup:
Auth-Type LDAP {
ldap {
reject = 3
fail = 3
}
unix
}
If the user exists in the LDAP (module ldap returns ok for the
request), then the Auth-Type is set to LDAP by default (assuming you
have things setup correctly). If the password provided by the user
does not match the one in the LDAP, then instead of flat out rejecting
the user and stopping processing, I assign an arbitrary value of 3 to
the reject codes (I do the same with fail, although looking back I
don't know if there's any real reason to do so). Now rather than
returning reject (or fail) for the entire request, the section calls
the unix module to attempt to authorize via /etc/passwd. You could
just as simply have it check the users file (module files) or a
number of other methods.
Does that make things any more clear?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: V1.10 File and LDAP Problems
After sending the second email, I realized that while you're having problems with the Authorization section, I gave solutions applicable to the Authentication section. I don't know if you can set certain fail and reject codes in the Autz section. The real answer to your first question was that as long as you setup the LDAP information correctly, you'll no longer have the Autz section failing on you. The rest of the information I gave should be useful in the Auth section though. Sorry for the confusion. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [radius] Re: Auth question
The only files I know of that use the secret password are clients.conf and proxy.conf. Make sure your clients.conf has an entry for your NAS with the correct IP address and the correct secret. I don't think you'll need to touch the proxy.conf file; its used for proxying RADIUS requests that successfully reach you to another RADIUS server, and you apparently aren't receving requests successfully. On 2/7/06, Nick Marino [EMAIL PROTECTED] wrote: Nick Marino - IT Solutions - Original Message - From: Alan DeKok [EMAIL PROTECTED] To: FreeRadius users mailing list freeradius-users@lists.freeradius.org Sent: Tuesday, February 07, 2006 11:50 AM Subject: Re: [radius] Re: Auth question Nick Marino [EMAIL PROTECTED] wrote: Only when NAS send the request to FR does it generate that garbled password. Then the shared secret is wrong. Or, there's a bug in the server that mangles the password only for that NAS. Which is more likely? Alan DeKok. - Its more likely that the password is wrong but, I am sure that they are the same. Like I said I even reset the password in the nas to make sure. I will check again but I dont think that is the problem. Shared secret has been the same in the nas for 3 years now and it has always worked. This just started after upgrading to the newest version of FR 1.1.0. Is there a place that I am missing that should have the shared secret in it that I havent changed. I hate to ask but exactly what all files need the shared password in it. clients.conf and where else? This just started after upgrading to the newest version of FR. - 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: Not-really-a-bug issue with rlm_unix and maybe other modules
I'm not too sure if such a patch would be necessary. The section of
radiusd.conf in which you set the user/group for radiusd to run as
remind people to make sure that /etc/passwd, /etc/group, and
/etc/shadow (if applicable) are readable by that user/group. Adding a
more verbose output in case of wrong permissions may help some people,
but I think the majority of people catch that the first time through
the config files and set permissions or groups accordingly.
On 10/17/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi,
I had a problem with the Radius server where I was using the rlm_unix
module to authenticate users against the passwd and shadow files, but even
when the correct login and password was being used the user was not being
authenticated. There was nothing reported in the log files at all apart
from Authentication refused.
After much digging around and scrabbling through the source code I
eventually found out that the permissions on the /etc/shadow file were
incorrect. The permissions were 0400 with a group ownership of sys
instead of being 0440 with a group ownership of shadow (or any other
group of which the freerad user was a member), Changing the permissions and
group membership fixed the problem.
To make other people's lives easier I would like to request an update to
the rlm_unix module to report a permissions error, or simply to report the
output of strerror() to the log file, when such file errors occur.
In the rlm_unix source file files are opened using the code:
function_name(function defs) {
FILE*file = fopen(fname, ro);
struct passwd *pwd = NULL;
if(file == NULL) return NULL;
...
I would suggest replacing the last line above with:
if(file == NULL) {radlog(L_ERR, strerror(errno)); return
NULL; }
or whatever equivalent is required. I don't know about the portability of
the strerror() function though, nor of all the details required when
calling the radlog function.
|\/|artin
--
Senior Network Administrator, NEC (Europe) Ltd.
Acton extension: 3379
NEC*Net: 800-44-21-3379
Direct: +44 20 8752 3379
Fax: +44 20 8752 3389
Mobile: +44 7721 869 356
*
IMPORTANT: The information contained in this e-mail and attachment (if any)
is intended for the person to whom it is addressed and may contain
confidential and/or privileged information. The contents of this message
may contain personal views which are not the views of NEC Europe Ltd or its
subsidiaries, unless specifically stated. You should not copy, retain,
forward or disclose its contents to anyone else, or take any action based
upon it, if it is not addressed to you personally. If you have received
this e-mail in error please contact the sender immediately. Any legally
binding agreement resulting from its content must be made separately in a
printed medium.
*
-
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: Which Operating System is best for freeRADIUS
just for the record, freeradius has worked wonderfully on gentoo 2005.1 On 10/7/05, Daniel Jensen [EMAIL PROTECTED] wrote: Well I am currently using it with FreeBSD can't say that I have had any problems with it, at least not functionality out of the box. On Fri, 2005-10-07 at 01:04 -0400, Gunther wrote: Nicolas Baradakis wrote: I was talking about the user point of view: the users are assured that FreeRADIUS is regulary tested under Debian, and the Debian package is up-to-date. Well, I tried CentOS (Redhat EL4) on a VPS server and with a few problems (missing libraries, rpm's) I got FR105 compiled. FR is up and running and now I have to find a way to pass the firewall ... Gunther - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - 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: CHAP and LDAP
are you sure that you have passwords in ldap in cleartext format?
Mon Oct 3 02:16:05 2005 : Debug: rlm_ldap: checking if remote access for
dmitry is allowed by dialupAccess
Mon Oct 3 02:16:05 2005 : Debug: rlm_ldap: Password header not found in
password qazxsw for user dmitry
Mon Oct 3 02:16:05 2005 : Debug: rlm_ldap: looking for check items in
directory...
Mon Oct 3 02:16:05 2005 : Debug: rlm_ldap: looking for reply items in
directory...
Mon Oct 3 02:16:05 2005 : Debug: rlm_ldap: user dmitry authorized to use
remote access
Mon Oct 3 02:16:05 2005 : Debug: rlm_ldap: ldap_release_conn: Release Id: 0
Mon Oct 3 02:16:05 2005 : Debug: modsingle[authorize]: returned from ldap
(rlm_ldap) for request 3
Mon Oct 3 02:16:05 2005 : Debug: modcall[authorize]: module ldap
returns ok for request 3
Mon Oct 3 02:16:05 2005 : Debug: modcall: group authorize returns ok for
request 3
so the user dmitry is found in the ldap, and authorize succeeds.
Mon Oct 3 02:16:05 2005 : Debug: rad_check_password: Found Auth-Type
CHAP
Mon Oct 3 02:16:05 2005 : Debug: auth: type CHAP
Mon Oct 3 02:16:05 2005 : Debug: Processing the authenticate section of
radiusd.conf
Mon Oct 3 02:16:05 2005 : Debug: modcall: entering group Auth-Type for
request 3
Mon Oct 3 02:16:05 2005 : Debug: modsingle[authenticate]: calling chap
(rlm_chap) for request 3
Mon Oct 3 02:16:05 2005 : Debug: rlm_chap: login attempt by dmitry with
CHAP password
Mon Oct 3 02:16:05 2005 : Debug: rlm_chap: Could not find clear text
password for user dmitry
here radius complains that it can't find a cleartext password for the
user dmitry. check your ldap configs again to see that passwords are
in cleartext. if you're using openldap, you have to set the
password-hash to {CLEARTEXT}, and that actually doesn't work in
current stable versions of openldap. if you don't have any value set,
then I think it uses SHA by default but I'm not sure on that one.
if you're using some other type of ldap server, read the appropriate
docs and check over your config files once again.
because PAP authentication does work, that also leads me to believe
that the problem is not with freeradius, but with the passwords in
ldap.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
