Re: MS SQL Schema File
I can give you the schema file and show you what to change in the FreeRADIUS config to get it to work. The rest is an excersise left to the reader. There's plenty of documentation available on getting FreeTDS and UnixODBC to peacfully coexist on a unix system and setting up Data Sources and Driver Templates to connect to your MS SQL also isn't hardto do. This document may help you: http://www.unixodbc.org/doc/FreeTDS.html as it is the guide I used to get my configuration working As always though, YMMV I'd be willing to help you more in depth on a contractual basis. My background is quite extensive and there isn't much I cannot accomplish if given the proper amount of time. If you're interested, please call me at 321-422-9083 so we can work out the details. Regards, Daniel Corbe On 10/26/05, Troy Settle [EMAIL PROTECTED] wrote: Daniel, I'd be most interested in seeing your work, from the MSSQL schema to your Freeradius, ODBC, and FreeTDS configurations. -- Troy Settle Pulaski Networks http://www.psknet.com 866.477.5638 Daniel Corbe wrote: I have a working schema file that I have loaded on my MS SQL server right now that works with minor changes to the configuration file, if anyone is interested in it. How would I go about submiting it back for review and inclusion into CVS as well as my cosemtic changes to mssql.conf? -Daniel On 10/13/05, Craig Huckabee [EMAIL PROTECTED] wrote: Daniel Corbe wrote: The mssql.conf file is still there and says: # The database schema is available at: # # src/radiusd/src/modules/rlm_sql/drivers/rlm_sql_freetds/db_mssql.sql :( -Daniel Get it from the CVS Attic: http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/src/modules/rlm_sql/drivers/rlm_sql_freetds/Attic/db_mssql.sql Grab the 1.3 revision (last one before the file was removed). --Craig - 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS SQL Schema File
That was supposed to be a reply directly to him, not to the list. Sorry! -Daniel On 10/26/05, Daniel Corbe [EMAIL PROTECTED] wrote: I can give you the schema file and show you what to change in the FreeRADIUS config to get it to work. The rest is an excersise left to the reader. There's plenty of documentation available on getting FreeTDS and UnixODBC to peacfully coexist on a unix system and setting up Data Sources and Driver Templates to connect to your MS SQL also isn't hardto do. This document may help you: http://www.unixodbc.org/doc/FreeTDS.html as it is the guide I used to get my configuration working As always though, YMMV I'd be willing to help you more in depth on a contractual basis. My background is quite extensive and there isn't much I cannot accomplish if given the proper amount of time. If you're interested, please call me at 321-422-9083 so we can work out the details. Regards, Daniel Corbe On 10/26/05, Troy Settle [EMAIL PROTECTED] wrote: Daniel, I'd be most interested in seeing your work, from the MSSQL schema to your Freeradius, ODBC, and FreeTDS configurations. -- Troy Settle Pulaski Networks http://www.psknet.com 866.477.5638 Daniel Corbe wrote: I have a working schema file that I have loaded on my MS SQL server right now that works with minor changes to the configuration file, if anyone is interested in it. How would I go about submiting it back for review and inclusion into CVS as well as my cosemtic changes to mssql.conf? -Daniel On 10/13/05, Craig Huckabee [EMAIL PROTECTED] wrote: Daniel Corbe wrote: The mssql.conf file is still there and says: # The database schema is available at: # # src/radiusd/src/modules/rlm_sql/drivers/rlm_sql_freetds/db_mssql.sql :( -Daniel Get it from the CVS Attic: http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/src/modules/rlm_sql/drivers/rlm_sql_freetds/Attic/db_mssql.sql Grab the 1.3 revision (last one before the file was removed). --Craig - 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS SQL Schema File
I have a working schema file that I have loaded on my MS SQL server right now that works with minor changes to the configuration file, if anyone is interested in it. How would I go about submiting it back for review and inclusion into CVS as well as my cosemtic changes to mssql.conf? -Daniel On 10/13/05, Craig Huckabee [EMAIL PROTECTED] wrote: Daniel Corbe wrote: The mssql.conf file is still there and says: # The database schema is available at: # # src/radiusd/src/modules/rlm_sql/drivers/rlm_sql_freetds/db_mssql.sql :( -Daniel Get it from the CVS Attic: http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/src/modules/rlm_sql/drivers/rlm_sql_freetds/Attic/db_mssql.sql Grab the 1.3 revision (last one before the file was removed). --Craig - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Vendor Specific Attributes
Hello, How do you get FreeRADIUS to stop ingoring VSAs? I have a box that's sending them and FreeRADIUS is simply ignoring them in rad_recv rad_recv: Accounting-Request packet from host 10.10.0.90:1068, id=0, length=58 NAS-Identifier = acme-sd Acct-Status-Type = Accounting-On NAS-IP-Address = 10.10.0.90 NAS-Port = 0 Acct-Session-Id = sd1#28249 I know there are more attributes being sent than that because I can see them in the RADIUS packet. Any help/advice is appriciated. Thanks. -Daniel - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: MS SQL Schema File
The mssql.conf file is still there and says: # The database schema is available at: # # src/radiusd/src/modules/rlm_sql/drivers/rlm_sql_freetds/db_mssql.sql :( -Daniel On 10/13/05, Daniel Corbe [EMAIL PROTECTED] wrote: It seems to me like (reading back in the archives) there used to be a schmea file for MS SQL servers but that was removed from the archive once FreeTDS support was dropped. Can anyone lend me a hand here? On 10/12/05, Daniel Corbe [EMAIL PROTECTED] wrote: Hello, I have unixodbc configured as the SQL back end for my RADIUS server and the back end database is an MS SQL Server. Does anyone have a schema available for MS SQL Server? This would need to include a unix_timestamp stored procedure. Please help -Daniel - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Implementation advice needed.
Hello, I'm looking for a couple of suggestions as how to implement some specifics. I've set up a FreeRADIUS server to do AAA primarily in a SIP enviornment. I've got a B2BUA which attempts to authorize outgoing calls. I want to use this to do Least Cost Routing. Upon an INVITE packet, the B2BUA sends the following attributes User-Name = 1234 User-Password = . NAS-IP-Address = 10.10.17.5 NAS-Port = 1000 Called-Station-Id = 5551212 Calling-Station-Id = 1234 This is enough information for me to authorize the phone call. Here are my questions 1) I have tariff tables stored in a back-end database. What would be the best way to go about looking up this information? Is there some way to execute a custom SQL lookup to pull this information back? Or should I be calling exec to say a custom script? 2) If exec is the best way to go about doing this, am I correct in reading the documentation that my script should be returning 0 (Access-Accept) or 1 (Access-Reject)? 3) I can customize my B2BUA so it accepts an IP address to forward a SIP request along. Is there a way either from exec or another method to add Radius attributes to the reply packet? That way I can do true LCR and tell the B2BUA which Gateway to forward the request. Thanks. -Daniel - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Mixed-mode authentication enviornment
Also, please note; The SIP server is NOT sending the Auth-Type attribute.
On 9/8/05, Daniel Corbe [EMAIL PROTECTED] wrote:
#
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line, and the 'digest'
# line in the 'authorize' section.
digest
That?
It's already uncommented. There's a seperate entry for Auth-Type LDAP
{ } in the authorize { } block. Should I do something along the lines
of...
authorize {
Auth-Type LDAP {
digest
ldap
}
}
??
-Daniel
On 9/7/05, Alan DeKok [EMAIL PROTECTED] wrote:
Daniel Corbe [EMAIL PROTECTED] wrote:
I'm manually setting Auth-Type to DIGEST on the LDAP Server.
As I said, DON'T.
This is all radiusd.conf has to say about digest:
...
No. You missed one digest entry, in the authenticate section.
The text you quoted tells you this:
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line, and the 'digest'
# line in the 'authenticate' section.
Follow those instructions.
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: Mixed-mode authentication enviornment
Yes.. what I did below worked.
-Daniel
On 9/8/05, Daniel Corbe [EMAIL PROTECTED] wrote:
#
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line, and the 'digest'
# line in the 'authorize' section.
digest
That?
It's already uncommented. There's a seperate entry for Auth-Type LDAP
{ } in the authorize { } block. Should I do something along the lines
of...
authorize {
Auth-Type LDAP {
digest
ldap
}
}
??
-Daniel
On 9/7/05, Alan DeKok [EMAIL PROTECTED] wrote:
Daniel Corbe [EMAIL PROTECTED] wrote:
I'm manually setting Auth-Type to DIGEST on the LDAP Server.
As I said, DON'T.
This is all radiusd.conf has to say about digest:
...
No. You missed one digest entry, in the authenticate section.
The text you quoted tells you this:
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line, and the 'digest'
# line in the 'authenticate' section.
Follow those instructions.
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: Mixed-mode authentication enviornment
userPassword as User-Password, value cgpe845Z op=11 rlm_ldap: user [EMAIL PROTECTED] authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap returns ok for request 1 modcall: group authorize returns ok for request 1 rad_check_password: Found Auth-Type LDAP auth: type LDAP Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 1 rlm_ldap: - authenticate rlm_ldap: Attribute User-Password is required for authentication. modcall[authenticate]: module ldap returns invalid for request 1 modcall: group Auth-Type returns invalid for request 1 auth: Failed to validate the user. Delaying request 1 for 1 seconds Finished request 1 Going to the next request --- Walking the entire request list --- Sending Access-Reject of id 254 to 127.0.0.1:63617 Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 255 to 127.0.0.1:63619 Waking up in 2 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 254 with timestamp 43208436 Waking up in 2 seconds... --- Walking the entire request list --- Cleaning up request 1 ID 255 with timestamp 43208438 Nothing to do. Sleeping until we see a request. Thank You. -Daniel On 9/8/05, Alan DeKok [EMAIL PROTECTED] wrote: Daniel Corbe [EMAIL PROTECTED] wrote: Yes.. what I did below worked. It worked for reasons other than what you believe. The configuration you posted is, quite simply, wrong. 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: Mixed-mode authentication enviornment
I'm not sure I understand why my approach is so incorrect. If I am
wrong, please explain it to me.
My understanding is we've AUTHORIZED the request by pulling the
password information off of the LDAP server and storing it in memory.
Then (according to my understanding of the radiusd.conf) in the
authenticate {} block, we pick which modules in order will do the
AUTHENTICATION part of the AAA session. One of the two modules will
always fail.
We first try the digest module and get this:
Processing the authenticate section of radiusd.conf
modcall: entering group Auth-Type for request 1
ERROR: No Digest-Nonce: Cannot perform Digest authentication
modcall[authenticate]: module digest returns invalid for request 1
Then we move on to the next section of the Auth-Type LDAP
configuration section of the authenticate {} block, and allow the LDAP
module to take a crack at it and thus we have a sucessful
authentication:
rlm_ldap: - authenticate
rlm_ldap: login attempt by dcorbe with password cgpe845Z
rlm_ldap: user DN: uid=dcorbe,ou=People,dc=corbe,dc=net
rlm_ldap: (re)connect to 127.0.0.1:389, authentication 1
rlm_ldap: bind as uid=dcorbe,ou=People,dc=corbe,dc=net/cgpe845Z to 127.0.0.1:389
rlm_ldap: waiting for bind result ...
request 1 done
rlm_ldap: Bind was successful
rlm_ldap: user dcorbe authenticated succesfully
modcall[authenticate]: module ldap returns ok for request 1
modcall: group Auth-Type returns ok for request 1
Sending Access-Accept of id 129 to 127.0.0.1:63703
-Daniel
On 9/8/05, Daniel Corbe [EMAIL PROTECTED] wrote:
Alan,
It achieved the desired effect. Quite simply, authentication against
LDAP now works when DIGEST is present and when it is not.
I've built my radiusd.conf file based off the examples provided with
the default installation.
I do not want a broken radius server on my hands as that will create
more problems in the long run. I'm still unsure as to what the
correct approach is. In the interests of finding the correct
approach, I will undo what I have done and paste the results of the
debug output.
To Recap, here are exerpts from my radius config:
modules {
ldap {
ldap_debug = 0x0028
server = 127.0.0.1
identity = cn=Manager,dc=corbe,dc=net
password = abcBABY123
basedn = ou=People,dc=corbe,dc=net
filter = ((objectclass=posixAccount)(uid=dcorbe))
base_filter =
# set this to 'yes' to use TLS encrypted connections
# to the LDAP database by using the StartTLS extended
# operation.
# The StartTLS operation is supposed to be used with normal
# ldap connections instead of using ldaps (port 689)
connections
start_tls = no
# tls_cacertfile= /path/to/cacert.pem
# tls_cacertdir = /path/to/ca/dir/
# tls_certfile = /path/to/radius.crt
# tls_keyfile = /path/to/radius.key
# tls_randfile = /path/to/rnd
# tls_require_cert = demand
# default_profile = cn=radprofile,ou=dialup,o=My Org,c=UA
# profile_attribute = radiusProfileDn
#access_attr = dialupAccess
# Mapping of RADIUS dictionary attributes to LDAP
# directory attributes.
dictionary_mapping = /usr/local/etc/raddb/ldap.attrmap
ldap_connections_number = 5
#
# NOTICE: The password_header directive is NOT case
insensitive
#
# password_header = {clear}
#
# Set:
# password_attribute = nspmPassword
#
# to get the user's password from a Novell eDirectory
# backend. This will work *only if* freeRADIUS is
# configured to build with --with-edir option.
#
#
# The server can usually figure this out on its own, and pull
# the correct User-Password or NT-Password from the database.
# profile_attribute = radiusProfileDn
#access_attr = dialupAccess
# Mapping of RADIUS dictionary attributes to LDAP
# directory attributes.
dictionary_mapping = /usr/local/etc/raddb/ldap.attrmap
ldap_connections_number = 5
#
# Note that NT-Passwords MUST be stored as a 32-digit hex
# string, and MUST start off with 0x, such as:
#
# 0x000102030405060708090a0b0c0d0e0f
#
# Without the leading 0x, NT-Passwords will not work.
# This goes for NT
Re: Mixed-mode authentication enviornment
I didn't pull this configuration file out of my ass. I *AM* using
default configs.
More to follow...
On 9/8/05, Alan DeKok [EMAIL PROTECTED] wrote:
Daniel Corbe [EMAIL PROTECTED] wrote:
I'm not sure I understand why my approach is so incorrect. If I am
wrong, please explain it to me.
I would suggest reading the existing samples and documentation for
how to configure the server. They explain the correct way to do
things. The number of incorrect ways to do things is almost infinite.
My understanding is we've AUTHORIZED the request by pulling the
password information off of the LDAP server and storing it in memory.
Yes.
Then (according to my understanding of the radiusd.conf) in the
authenticate {} block, we pick which modules in order will do the
AUTHENTICATION part of the AAA session. One of the two modules will
always fail.
If, and ONLY if, you list BOTH modules in an Auth-Type {} section
in authenticate.
The solution is DON'T DO THAT.
List them separately, as shown in the default config.
Again, I'm a little surprised that this is so hard to configure,
given that the default config shows how to do it. It takes additional
effort to create a different configuration, which will then not work.
We first try the digest module and get this:
Processing the authenticate section of radiusd.conf
modcall: entering group Auth-Type for request 1
ERROR: No Digest-Nonce: Cannot perform Digest authentication
modcall[authenticate]: module digest returns invalid for request 1
Then we move on to the next section of the Auth-Type LDAP
configuration section of the authenticate {} block, and allow the LDAP
module to take a crack at it and thus we have a sucessful
authentication:
Yes. Your configuration seems to work, but it's inefficient and
unnecessary. Rather that following the existing examples, you appear
to have randomly added hacks until it works, with little
understanding of how the server is supposed to be configured.
Please, use the default configuration where possible. It works, and
it was designed by people who understand LDAP, digest, and the server.
Your hacks may appear to work, but they are based on misunderstandings
and confusion. They WILL NOT be maintainable by you, or anyone else
going into the future.
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: Mixed-mode authentication enviornment
I see where I err in my ways. I'm setting the Auth-Type to LDAP
specifically in the users file as I have a Fall-Through configured:
DEFAULT Auth-Type := LDAP
Fall-Through = 1
and the ldap_howto suggests using LDAP groups instead.
I'm going to go back and set this up the right way instead of the wrong way
-Daniel
On 9/8/05, Daniel Corbe [EMAIL PROTECTED] wrote:
I didn't pull this configuration file out of my ass. I *AM* using
default configs.
More to follow...
On 9/8/05, Alan DeKok [EMAIL PROTECTED] wrote:
Daniel Corbe [EMAIL PROTECTED] wrote:
I'm not sure I understand why my approach is so incorrect. If I am
wrong, please explain it to me.
I would suggest reading the existing samples and documentation for
how to configure the server. They explain the correct way to do
things. The number of incorrect ways to do things is almost infinite.
My understanding is we've AUTHORIZED the request by pulling the
password information off of the LDAP server and storing it in memory.
Yes.
Then (according to my understanding of the radiusd.conf) in the
authenticate {} block, we pick which modules in order will do the
AUTHENTICATION part of the AAA session. One of the two modules will
always fail.
If, and ONLY if, you list BOTH modules in an Auth-Type {} section
in authenticate.
The solution is DON'T DO THAT.
List them separately, as shown in the default config.
Again, I'm a little surprised that this is so hard to configure,
given that the default config shows how to do it. It takes additional
effort to create a different configuration, which will then not work.
We first try the digest module and get this:
Processing the authenticate section of radiusd.conf
modcall: entering group Auth-Type for request 1
ERROR: No Digest-Nonce: Cannot perform Digest authentication
modcall[authenticate]: module digest returns invalid for request 1
Then we move on to the next section of the Auth-Type LDAP
configuration section of the authenticate {} block, and allow the LDAP
module to take a crack at it and thus we have a sucessful
authentication:
Yes. Your configuration seems to work, but it's inefficient and
unnecessary. Rather that following the existing examples, you appear
to have randomly added hacks until it works, with little
understanding of how the server is supposed to be configured.
Please, use the default configuration where possible. It works, and
it was designed by people who understand LDAP, digest, and the server.
Your hacks may appear to work, but they are based on misunderstandings
and confusion. They WILL NOT be maintainable by you, or anyone else
going into the future.
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: Mixed-mode authentication enviornment
So that worked, group authentication. Thank you for pointing me in
the right direction.
BTW I do know how RADIUS and LDAP work. I'm not new to the
technology, just FreeRADIUS in general.
Thanks again.
-Daniel
On 9/8/05, Daniel Corbe [EMAIL PROTECTED] wrote:
I see where I err in my ways. I'm setting the Auth-Type to LDAP
specifically in the users file as I have a Fall-Through configured:
DEFAULT Auth-Type := LDAP
Fall-Through = 1
and the ldap_howto suggests using LDAP groups instead.
I'm going to go back and set this up the right way instead of the wrong
way
-Daniel
On 9/8/05, Daniel Corbe [EMAIL PROTECTED] wrote:
I didn't pull this configuration file out of my ass. I *AM* using
default configs.
More to follow...
On 9/8/05, Alan DeKok [EMAIL PROTECTED] wrote:
Daniel Corbe [EMAIL PROTECTED] wrote:
I'm not sure I understand why my approach is so incorrect. If I am
wrong, please explain it to me.
I would suggest reading the existing samples and documentation for
how to configure the server. They explain the correct way to do
things. The number of incorrect ways to do things is almost infinite.
My understanding is we've AUTHORIZED the request by pulling the
password information off of the LDAP server and storing it in memory.
Yes.
Then (according to my understanding of the radiusd.conf) in the
authenticate {} block, we pick which modules in order will do the
AUTHENTICATION part of the AAA session. One of the two modules will
always fail.
If, and ONLY if, you list BOTH modules in an Auth-Type {} section
in authenticate.
The solution is DON'T DO THAT.
List them separately, as shown in the default config.
Again, I'm a little surprised that this is so hard to configure,
given that the default config shows how to do it. It takes additional
effort to create a different configuration, which will then not work.
We first try the digest module and get this:
Processing the authenticate section of radiusd.conf
modcall: entering group Auth-Type for request 1
ERROR: No Digest-Nonce: Cannot perform Digest authentication
modcall[authenticate]: module digest returns invalid for request 1
Then we move on to the next section of the Auth-Type LDAP
configuration section of the authenticate {} block, and allow the LDAP
module to take a crack at it and thus we have a sucessful
authentication:
Yes. Your configuration seems to work, but it's inefficient and
unnecessary. Rather that following the existing examples, you appear
to have randomly added hacks until it works, with little
understanding of how the server is supposed to be configured.
Please, use the default configuration where possible. It works, and
it was designed by people who understand LDAP, digest, and the server.
Your hacks may appear to work, but they are based on misunderstandings
and confusion. They WILL NOT be maintainable by you, or anyone else
going into the future.
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
Cannot start freeradius
when I go to start radiusd I get the following error: radiusd.conf[1383] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.0.4.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.0.4.so Expected in: flat namespace This is a fresh install on a Mac OS X box. Any help is appriciated. Thanks. -Daniel - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cannot start freeradius
:( On 9/2/05, Daniel Corbe [EMAIL PROTECTED] wrote: when I go to start radiusd I get the following error: radiusd.conf[1383] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.0.4.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.0.4.so Expected in: flat namespace This is a fresh install on a Mac OS X box. Any help is appriciated. Thanks. -Daniel - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cannot start freeradius
Yes, Compiled from source. FreeRADIUS 1.0.4 jomama:/usr/local/src root# /usr/local/sbin/radiusd -X Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /usr/local/etc/raddb/proxy.conf Config: including file: /usr/local/etc/raddb/clients.conf Config: including file: /usr/local/etc/raddb/snmp.conf Config: including file: /usr/local/etc/raddb/eap.conf Config: including file: /usr/local/etc/raddb/sql.conf main: prefix = /usr/local main: localstatedir = /usr/local/var main: logdir = /usr/local/var/log/radius main: libdir = /usr/local/lib main: radacctdir = /usr/local/var/log/radius/radacct main: hostname_lookups = no main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 1024 main: delete_blocked_requests = 0 main: port = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_file = /usr/local/var/log/radius/radius.log main: log_auth = no main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = /usr/local/var/run/radiusd/radiusd.pid main: user = (null) main: group = (null) main: usercollide = no main: lower_user = no main: lower_pass = no main: nospace_user = no main: nospace_pass = no main: checkrad = /usr/local/sbin/checkrad main: proxy_requests = yes proxy: retry_delay = 5 proxy: retry_count = 3 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 120 proxy: post_proxy_authorize = yes proxy: wake_all_if_all_dead = no security: max_attributes = 200 security: reject_delay = 1 security: status_server = no main: debug_level = 0 read_config_files: reading dictionary read_config_files: reading naslist Using deprecated naslist file. Support for this will go away soon. read_config_files: reading clients read_config_files: reading realms radiusd: entering modules setup Module: Library search path is /usr/local/lib radiusd.conf[1383] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.0.4.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.0.4.so Expected in: flat namespace jomama:/usr/local/src root# On 9/2/05, Thor Spruyt [EMAIL PROTECTED] wrote: On 9/2/05, Daniel Corbe [EMAIL PROTECTED] wrote: when I go to start radiusd I get the following error: radiusd.conf[1383] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.0.4.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.0.4.so Expected in: flat namespace This is a fresh install on a Mac OS X box. Any help is appriciated. More information would also be appriciated :) Which version of freeradius? Did you try to compile freeradius from source? Provide the output. Provide the complete output, also that what comes before the error. -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: [EMAIL PROTECTED] W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
