Re: freeradius installation considerations
On Thu, 15 Aug 2002, Marcel wrote: The only way I am thinking is that they have to start a browser and just serve to http://www.whatever.they.want.com and a basic homepage shows up to authenticate themafter they are authenticated they will be forwarded to the homepage the enteredor they are denied of course. This can be done by employing the port forwarding feature of Linux Netfilter and other OS'es similar tools. I heard of the NoCat open source project at http://nocat.net/ There is also a paper on a similar design at http://www.nas.nasa.gov/Groups/Networks/Projects/Wireless/index.html Ilguiz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Using Mgetty And freeRadius
Bikrant, On Sun, 4 Aug 2002, Bikrant Neupane wrote: Now, I want to authenticate dialin users against the freeradius while still using mgetty to receive the incoming calls. I think the mgetty program only handles indications of incoming calls by accessing serial port. Once the CONNECT or CARRIER string is found, mgetty will fork and execute /bin/login which will inherit the serial port file handle as its stdin/stdout. I believe it is /bin/login that outputs user name and password prompts and reads user input. If your /bin/login is linked against libpam (type ldd /bin/login to find out), then /etc/pam.d/login contains the names of dynamically loaded PAM modules that get invoked through /bin/login's calls to libpam functions. My /etc/pam.d/login shows indirect use of /etc/pam.d/system-auth which in turn will call /lib/security/pam_unix with the shadow parameter. The latter will verify the hash of user password against /etc/shadow. It seems you want to pass user name and password to a RADIUS server. There is software that glues serial input/output with RADIUS interaction. I was told portslave can do that. I guess such direct coupling allows for better control over services that can be started on serial port. I.e. the RADIUS server can send a text of menu to display, and initiate different authentication methods based on user answer. I understand there is another approach where RADIUS server is used strictly for user authentication. It is sufficient to encapsulate the RADIUS protocol into a pluggable authentication module. This technique would line up well with other authentication PAMs and will have a clear scope of action. I think that pam_radius pluggable authentication module can be found in FreeRADIUS repository. I wonder if it is possible to put pam_radius into the password line in /etc/pam.d/login instead of (or in addition to) the indirect invokation of pam_unix. I had no personal experience though. Ilguiz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: promiscuous authentication
On Tue, 16 Jul 2002, Alan DeKok wrote: In addition, why would you want to expose a key piece of software to any random packet from the internet? Is it *really* that hard to type in the 10-100 client IP addresses? I was testing the perl Authen::Radius module with its make test command and typed in the external IP address of the FreeRadius host instead of internal one at the prompt. In a bigger picture, I was concerned about how much the Radius client can be separated from the Radius server in terms of networking. Again, I didn't bother to read documentation and only searched the latest mail list archive. I am in the early learning stage here! Ilguiz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Trouble with 20020715 snapshot
I do have libltdl installed on my system as part of RedHat's libtool RPM package. However, the configure script fails to find the header file which exists: === $ ./configure --without-snmp \ --with-system-libtool --disable-ltdl-install \ --with-ltdl-lib=/usr/lib --with-ltdl-include=/usr/include [...] checking for lt_dlinit in -lltdl... yes checking for ltdl.h... no configure: warning: libltdl not installed, but installation disabled [...] $ rpm -qf /usr/include/ltdl.h libtool-1.4.2-5 === I hacked up the top level configuration files from yesterday's CVS checkout to reuse the latest auto tools (mine are autoconf 2.53 and automake 1.6.1). With those modifications I was able to get rid of link failure in src/main. The bootstrap script allows to remove automatically generated files from the CVS repository. However, some constructs in the updated configure.in are valid only with the newer autoconf. Perhaps, putting AC_PREREQ(2.53) into configure.in could be a good precaution. Another small problem was due to the sql_fetch_row() prototypes in freeradius/radiusd/src/modules/rlm_sql/drivers/rlm_sql_postgresql/sql_postgresql.h and freeradius/radiusd/src/modules/rlm_sql/drivers/rlm_sql_unixodbc/sql_unixodbc.h not synchronized with their .c counterparts. Does the patch included below fix those prototypes correctly? Thank you, Ilguiz On Tue, 16 Jul 2002, Alan DeKok wrote: If you don't have libltdl onyour system already, then the build won't find *any* ltdl.h, and will die. === The following file was modified in freeradius/radiusd/src/include: NameOld version New version Comment --- --- --- autoconf.h.in 1.1.1.1 Removed The accompanying log: remove automatically generated file --- The following file was modified in freeradius/radiusd/src/modules/rlm_eap: NameOld version New version Comment --- --- --- Makefile1.1.1.1 Removed The accompanying log: remove automatically generated file --- The following file was modified in freeradius/radiusd/src/modules/rlm_eap/types/rlm_eap_tls: NameOld version New version Comment --- --- --- Makefile1.1.1.1 Removed The accompanying log: remove automatically generated file --- The following file was modified in freeradius/radiusd/src/modules: NameOld version New version Comment --- --- --- rules.mak 1.1.1.1 1.2 The accompanying log: Specify full path when copying files The diff of the modified file(s): --- rules.mak 15 Jul 2002 18:33:26 - 1.1.1.1 +++ rules.mak 16 Jul 2002 17:50:14 - 1.2 -109,11 +109,11 ### static: $(TARGET).a $(RLM_UTILS) [ x$(RLM_SUBDIRS) = x ] || $(MAKE) $(MFLAGS) WHAT_TO_MAKE=static common - cp $ $(top_builddir)/src/modules/lib + cp $ $(abs_top_srcdir)/src/modules/lib dynamic: $(TARGET).la $(RLM_UTILS) [ x$(RLM_SUBDIRS) = x ] || $(MAKE) $(MFLAGS) WHAT_TO_MAKE=dynamic common - cp $ $(top_builddir)/src/modules/lib + cp $ $(abs_top_srcdir)/src/modules/lib ### # --- The following file was modified in freeradius/radiusd/src/modules/rlm_eap/types/rlm_eap_md5: NameOld version New version Comment --- --- --- Makefile1.1.1.1 Removed The accompanying log: remove automatically generated file --- The following file was modified in freeradius/radiusd/src/modules/rlm_sql/drivers/rlm_sql_unixodbc: NameOld version New version Comment --- --- --- sql_unixodbc.h 1.1.1.1 1.2 The accompanying log: Syncronize function prototypes The diff of the modified file(s): --- sql_unixodbc.h 15 Jul 2002 18:33:26 - 1.1.1.1 +++ sql_unixodbc.h 16 Jul 2002 17:51:18 - 1.2 -28,7 +28,7 intsql_store_result(SQLSOCK * sqlsocket, SQL_CONFIG *config); int
Re: Trouble with 20020715 snapshot
On Tue, 16 Jul 2002, Ilguiz Latypov wrote:
The bootstrap script allows to remove automatically generated files from
the CVS repository.
I forgot to attach the new files:
acinclude.m4
which is former aclocal.m4 without libtool.m4 and AC_CHECK_TYPE_INCLUDE
and the
bootstrap
script.
=
dnl See whether we need a declaration for a function.
dnl RADIUSD_NEED_DECLARATION(FUNCTION [, EXTRA-HEADER-FILES])
AC_DEFUN(RADIUSD_NEED_DECLARATION,
[AC_MSG_CHECKING([whether $1 must be declared])
AC_CACHE_VAL(radius_cv_decl_needed_$1,
[AC_TRY_COMPILE([
#include stdio.h
#include string.h
#ifdef HAVE_UNISTD_H
#include unistd.h
#endif
#ifdef HAVE_CRYPT_H
#include crypt.h
#endif
#ifdef HAVE_ERRNO_H
#include errno.h
#endif
#ifdef HAVE_RESOURCE_H
#include resource.h
#endif
#ifdef HAVE_GETOPT_H
#include getopt.h
#endif
#ifdef HAVE_MALLOC_H
#include malloc.h
#endif
#ifdef HAVE_UTMP_H
#include utmp.h
#endif
#ifdef HAVE_UTMPX_H
#include utmpx.h
#endif
#ifdef HAVE_SYS_SELECT_H
#include sys/select.h
#endif
#ifdef HAVE_DLFCN_H
#include dlfcn.h
#endif
#ifdef HAVE_REGEX_H
#include regex.h
#endif
#ifdef HAVE_SYSLOG_H
#include syslog.h
#endif
#ifdef HAVE_INTTYPES_H
#include inttypes.h
#endif
#ifdef HAVE_STDINT_H
#include stdint.h
#endif
#ifdef HAVE_ARPA_INET_H
#include arpa/inet.h
#endif
$2],
[char *(*pfn) = (char *(*)) $1],
eval radius_cv_decl_needed_$1=no, eval radius_cv_decl_needed_$1=yes)])
if eval test \`echo '$radius_cv_decl_needed_'$1`\ = yes; then
AC_MSG_RESULT(yes)
radius_tr_decl=NEED_DECLARATION_`echo $1 | tr 'abcdefghijklmnopqrstuvwxyz'
'ABCDEFGHIJKLMNOPQRSTUVWXYZ'`
AC_DEFINE_UNQUOTED($radius_tr_decl)
else
AC_MSG_RESULT(no)
fi
])dnl
dnl Check multiple functions to see whether each needs a declaration.
dnl RADIUSD_NEED_DECLARATIONS(FUNCTION... [, EXTRA-HEADER-FILES])
AC_DEFUN(RADIUSD_NEED_DECLARATIONS,
[for ac_func in $1
do
RADIUSD_NEED_DECLARATION($ac_func, $2)
done
])
dnl AM_MISSING_PROG(NAME, PROGRAM, DIRECTORY)
dnl The program must properly implement --version.
AC_DEFUN(AM_MISSING_PROG,
[AC_MSG_CHECKING(for working $2)
# Run test in a subshell; some versions of sh will print an error if
# an executable is not found, even if stderr is redirected.
# Redirect stdin to placate older versions of autoconf. Sigh.
if ($2 --version) /dev/null /dev/null 21; then
$1=$2
AC_MSG_RESULT(found)
else
$1=$3/missing $2
AC_MSG_RESULT(missing)
fi
AC_SUBST($1)])
dnl Checks to see if this is SUNPro we're building with
dnl Usage:
dnl AC_PROG_CC_SUNPRO
AC_DEFUN(AC_PROG_CC_SUNPRO,
[AC_CACHE_CHECK(whether we are using SUNPro C, ac_cv_prog_suncc,
[dnl The semicolon is to pacify NeXT's syntax-checking cpp.
cat conftest.c EOF
#ifdef __SUNPRO_C
yes;
#endif
EOF
if AC_TRY_COMMAND(${CC-cc} -E conftest.c) | egrep yes /dev/null 21; then
ac_cv_prog_suncc=yes
else
ac_cv_prog_suncc=no
fi])])
dnl ###
dnl #
dnl # Look for SNMP in a variety of places.
dnl #
AC_DEFUN(SNMP_CHECKS, [
AC_SUBST(SNMP_LIBS)
AC_SUBST(SNMP_INCLUDE)
AC_MSG_CHECKING([for asn1.h])
dnl #
dnl # First, see if we can build it WITHOUT using any special includes
dnl #
AC_TRY_COMPILE([
#ifdef HAVE_SYS_TYPES_H
#include sys/types.h
#endif
#ifdef HAVE_STDINT_H
#include stdint.h
#endif
#ifdef HAVE_STDIO_H
#include stdio.h
#endif
#ifdef HAVE_NETDB_H
#include netdb.h
#endif
#ifdef HAVE_UNISTD_H
#include unistd.h
#endif
#include asn1.h],
[ int a = 1;],
SNMP_INCLUDE=,
SNMP_INCLUDE=)
dnl #
dnl # If not, look for it in a number of directories.
dnl #
if test x$SNMP_INCLUDE = x; then
old_CFLAGS=$CFLAGS
for try in /usr/include/ucd-snmp /usr/local/include/ucd-snmp $snmp_include_dir; do
CFLAGS=$old_CFLAGS -I$try
AC_TRY_COMPILE([
#ifdef HAVE_SYS_TYPES_H
#include sys/types.h
#endif
#ifdef HAVE_STDINT_H
#include stdint.h
#endif
#ifdef HAVE_STDIO_H
#include stdio.h
#endif
#ifdef HAVE_NETDB_H
#include netdb.h
#endif
#ifdef HAVE_UNISTD_H
#include unistd.h
#endif
#include asn1.h],
[ int a = 1;],
SNMP_INCLUDE=-I$try,
SNMP_INCLUDE=)
if test x$SNMP_INCLUDE != x; then
break;
fi
done
CFLAGS=$old_CFLAGS
fi
if test x$SNMP_INCLUDE = x; then
AC_MSG_RESULT(no)
else
AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_ASN1_H)
dnl #
dnl # Check for the rest of the SNMP headers.
dnl #
old_CFLAGS=$CFLAGS
CFLAGS=$CFLAGS $SNMP_INCLUDE
AC_MSG_CHECKING(for snmp.h)
AC_TRY_COMPILE([
#ifdef HAVE_SYS_TYPES_H
#include sys/types.h
#endif
#ifdef HAVE_STDINT_H
#include stdint.h
#endif
#ifdef HAVE_STDIO_H
#include stdio.h
#endif
#ifdef HAVE_NETDB_H
#include netdb.h
#endif
#ifdef HAVE_UNISTD_H
#include unistd.h
#endif
#ifdef HAVE_ASN1_H
#include asn1.h
#endif
#include snmp.h],
[ int a = 1;],
[AC_DEFINE(HAVE_SNMP_H) ac_cv_header_snmp_h=yes])
if test x
Re: Trouble with 20020715 snapshot
Alan, On Tue, 16 Jul 2002, Alan DeKok wrote: My thoughts are that the patches are a nice idea, but there's no way I'm going to re-write the autoconf stuff just before 0.6.1 is released. My patch is only a suggestion, and thanks for even paying any attention to it. Also, I'm *never* going to willingly use automake. I understand that one of the drawbacks of automake is its build rules based on naming conventions. This is difficult to comprehend. On the positive side, automake would probably help reduce areas for human errors. Luckily, automake is not employed in radiusd tree and the patch didn't introduce implicit automake rules. I only wanted automake to create symlinks install-sh, mkinstalldirs and missing. It turns out the same can be achieved without adding AM_INIT_AUTOMAKE to configure.in. So what, exactly, are the benefits of your patches? Fixing some ltdl installation issues? If so, why not supply a minimal patch to do just that? The only benefit of the patch as I see is supposedly increased portability of the radiusd build process. I admit this is far from any reasonable application. The configure scripts in subdirectories were not taken care of. I'd rather see a series of small patches to add functionality piecemeal, than one large patch which changes everything, and adds a large number of new things. Agree. Ilguiz - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
promiscuous authentication
Hello,
Is this a good idea to allow testing of a given user name/password pair
from anywhere in internet? I modified the latest conffile.c to accept
authentication requests from anywhere by using the following directive:
client 0.0.0.0/0 {
secret = XXX
shortname = superbt.ca
}
As you see, the significant part of netmask is reduced to 0 leftmost bits.
Is this a safe approach? The patch is enclosed.
--
Ilguiz Latypov
computer programmer
SuperBT Canada, Inc
153 Union St. E.
Waterloo, Ontario N2J 1C4
Canada
GMT-4 day time tel. +1 (519) 569-7818
GMT-4 night time tel. +1 (519) 569-7193
==
diff -u ../../../radiusd.orig/src/main/conffile.c ./conffile.c
--- ../../../radiusd.orig/src/main/conffile.c Mon Jun 10 11:06:16 2002
+++ ./conffile.cTue Jul 9 19:47:58 2002
-1145,15 +1145,16
int i, mask_length;
mask_length = atoi(netmask + 1);
- if ((mask_length = 0) || (mask_length 32)) {
+ if ((mask_length 0) || (mask_length 32)) {
radlog(L_ERR, %s[%d]: Invalid value '%s' for IP
network mask.,
filename, cs-item.lineno, netmask +
1);
return -1;
}
- c-netmask = (1 31);
- for (i = 1; i mask_length; i++) {
- c-netmask |= (c-netmask 1);
+ c-netmask = 0;
+ for (i = 1; i = mask_length; i++) {
+ c-netmask = 1;
+ c-netmask |= (1 31);
}
*netmask = '\0';
==
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: promiscuous authentication
I agree that promiscuous authentication is not how FreeRadius was supposed to work. Sorry for not reading the documentation first. I thought that communication between Radius clients and servers is secure by design. Is this not always true? Ilguiz On Mon, 15 Jul 2002, Alan DeKok wrote: Is this a good idea to allow testing of a given user name/password pair from anywhere in internet? I would say no. I'm not sure why it would be necessary, and it's a bad idea to expose a RADIUS server to anyone's traffic. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
