Re: (RADIATOR) logging acct to FILE and proxying
On Sat, 7 Aug 1999, Hugh Irvine wrote: [...] > I would suggest something like this: > > > # Force all clauses to be executed > AuthByPolicy ContinueAlways > # Do our normal processing > > .. > > # Set up a proxy for Accounting only > > Host > Secret > NoForwardAuthentication > > # Log accounting to local file > AcctLogFileName filename > Thanks Hugh, this looks likely. Is there something else we can/should add to tell Radiator not to worry if the other host doesn't ACK the accounting packets? Thanks, Neale. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging acct to FILE and proxying
On Sat, 7 Aug 1999, Neale Banks wrote: > On Sat, 7 Aug 1999, Hugh Irvine wrote: > > [...] > > I would suggest something like this: > > > > > > # Force all clauses to be executed > > AuthByPolicy ContinueAlways > > # Do our normal processing > > > > .. > > > > # Set up a proxy for Accounting only > > > > Host > > Secret > > NoForwardAuthentication > > > > # Log accounting to local file > > AcctLogFileName filename > > > > Thanks Hugh, this looks likely. Is there something else we can/should > add to tell Radiator not to worry if the other host doesn't ACK the > accounting packets? I experienced some troubles with the suggested configuration. If you use NoForwardAuthentication RADIUS Authentication-Requests are not forwarded but ACCEPTED. I noticed that if the first AuthBy failed the user would be granted access anyway because of the second AuthBy. Accounting was taken care of exactly as I wanted. But this was not true for Authentication ;-) Currently I am using statements as discussed on this list to make a copy of accounting information without granting everybody access. -Wim === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging acct to FILE and proxying
On Sat, 7 Aug 1999, Wim Biemolt wrote: > I experienced some troubles with the suggested configuration. If you use > NoForwardAuthentication RADIUS Authentication-Requests are not forwarded > but ACCEPTED. I noticed that if the first AuthBy failed the user would be > granted access anyway because of the second AuthBy. Accounting was taken > care of exactly as I wanted. But this was not true for Authentication ;-) > Currently I am using statements as discussed on this list to > make a copy of accounting information without granting everybody access. Thanks for that - ACCEPTing everybody is definitely not what we want 8-O What's the trick to doing this with a ? Thanks, Neale. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging acct to FILE and proxying
On Sat, 7 Aug 1999, Neale Banks wrote: > Thanks for that - ACCEPTing everybody is definitely not what we want 8-O > > What's the trick to doing this with a ? I used to make a copy of all accounting by simply running "Trace 4". But now that I am monitoring radiusd with MRTG my logging really exploded. So I wanted to make a copy of all Stop-record without using "Trace 4". The configuration which works for me looks like this: # Handler matches only Stop-records for realm *.foo.bar AuthByPolicy ContinueAlways .. .. # lots of the same handlers for different foo.bar's # Handler matches all records for realm *.foo.bar # but Stop-records were taken care of above. .. # lots of the same handlers for different foo.bar's You could replace Stop by a regular expression if you also would like to have a copy of all Start records. And be carefull if you mix and statements. Sometimes mixing both of them doesn't work. -Wim === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Linux<->SQL Server 6.5 connectivity
I'm looking for a way to have an ODBC query on Linux talk to a SQL 6.5 server, as well as a way to have Crystal Reports on NT talk to Linux databases. I figure people on this group have a bit of experience with these. Basically, I want to be able to have RADIATOR databases on both platforms, and have client-side queries be possible from either one. Thanks for any leads. Chris === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Allow All
We want to setup radiator so that all users get authenticated regrdless of what password or username they enter. We also want to accounting. So basically, we have an open system if our SQL server goes down so our users will still have access. Can someone please show me a config file to do this. Thank You. Greg ZooLink === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Pam Radius Authentication
I run a small internet service provider and have just started to use the
Cryptocard Pam Radius Authentication module. I have got the basic
authentication work but have a few loose ends to tidy up.
The recommended Pam config for a service using Pam Radius Authentication is
#auth
auth required /lib/security/pam_securetty.so
auth sufficient /lib/security/pam_radius_auth.so
auth required /lib/security/pam_unix_auth.so
The problem is that the pam_securetty.so module always fails. Reading the docs
indicates that some files in /etc/security need to be setup, but I dont know
where to start. It would be real handy if I could get pam_securetty to tell me
why it is failing. Is this possible?
I'm using the Pam Radius Authentication with the GNU_POP3D 0.97 server. The
PAM authentication section of this pop server contains the following code. The
pam_authenticate call works ok but the pam_acct_mgmt and pam_setcred calls
fail. Pam_authenticate is authenticating correctly off of the radius server.
If anyone has any ideas on how to sort this out I like to hear them.
Regards. Paul
#else /* HAVE_SECURITY_PAM_APPL_H */
_user = (char *) arg;
_pwd = pass;
/* libpam doesn't log to LOG_MAIL */
closelog ();
pamerror = pam_start ("pop", arg, &PAM_conversation, &pamh);
PAM_ERROR;
pamerror = pam_authenticate (pamh, 0);
username = strdup (arg);
syslog (LOG_INFO, "Pam trying to authenticate %s", username);
PAM_ERROR;
/* pamerror = pam_acct_mgmt (pamh, 0);
PAM_ERROR;
syslog (LOG_INFO, "Pam acct mgmt ok");
pamerror = pam_setcred (pamh, PAM_ESTABLISH_CRED);
PAM_ERROR;
syslog (LOG_INFO, "Pam set cred ok");
*/
pam_end (pamh, PAM_SUCCESS);
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Sendmail & Radiator
I've now got my POP server authenticating from Radiator and I thought I would be ready to go ahead and use authentication from a database. When I tried to send an email to a test user in the Radiator database I received an error message from sendmail. The message said that the test user did not exist, ie he was not in the password file. Has anyone come across this problem before and managed to solve it? Regards. Paul === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Sendmail & Radiator
> Hey, just curious here. Why do you want people to authenticate from > Radiator instead of the password file? > > I'm just curious, I don't know what your problem is. Thinking you might > have a neat application I haven't thought of... Hi Chris, I'm using Radmin which has a nice www interface, it easy for my support reps to add new users. Radmin only supports authentication from the database. Authentication from the database gives me on point to set the access policies for my whole system. These are the sort of things that make the use of a database attractive. Sendmail does not appear to know about PAM though, unless there is a patch I don't know about. Cheers. Paul === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Client, NAS-Type and Handler
I looked in the docs, but this one's not mentioned either way. If I specify a Client: NasType=vendor . DefaultRealm foo.bar 1. Are there any side-effects of NAS-Type if I don't specify any Simultaneus-Use anywhere? 2. Can I then use NAS-Type as a check item in a Handler, like: # generic stuff for foo.bar # vendor-specific stuff # just generic stuff for foo.bar If that won't work, any reason why I couldn't get around it by constructing a handler like: Thanks, Neale. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Linux<->SQL Server 6.5 connectivity
Hi Chris - On Sun, 08 Aug 1999, Chris Magnuson wrote: > I'm looking for a way to have an ODBC query on Linux talk to a SQL 6.5 > server, as well as a way to have Crystal Reports on NT talk to Linux > databases. I figure people on this group have a bit of experience with > these. Basically, I want to be able to have RADIATOR databases on both > platforms, and have client-side queries be possible from either one. > > Thanks for any leads. > Have a look at the following: http://www.open.com.au/radiator/faq.html#13 hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) logging acct to FILE and proxying
Hi Neale - On Sat, 07 Aug 1999, Neale Banks wrote: > On Sat, 7 Aug 1999, Wim Biemolt wrote: > > > I experienced some troubles with the suggested configuration. If you use > > NoForwardAuthentication RADIUS Authentication-Requests are not forwarded > > but ACCEPTED. I noticed that if the first AuthBy failed the user would be > > granted access anyway because of the second AuthBy. Accounting was taken > > care of exactly as I wanted. But this was not true for Authentication ;-) > > Currently I am using statements as discussed on this list to > > make a copy of accounting information without granting everybody access. > > Thanks for that - ACCEPTing everybody is definitely not what we want 8-O > I realised after I sent this that I had put the clauses around the wrong way. What I should have said was this: # Force all clauses to be executed AuthByPolicy ContinueAlways # Set up a proxy for Accounting only Host Secret NoForwardAuthentication # Do our normal processing .. # Log accounting to local file AcctLogFileName filename In this case the Accounting packets will be forwarded to the proxy and the Authentication packets will be accepted. The following AuthBy will either accept or reject normally. > What's the trick to doing this with a ? Realms are just special cases of Handlers. There is no difference other than Realms look for an exact match on a realm and then stop processing, while all Handlers are executed in configuration file sequence and can match on any attribute(s). is equivalent to Note that you should not mix Realms and Handlers in the same configuration (because of the conflicting continuation behaviour described above), so you could also do something like this: # Handler for Realm=foo.bar # Do our normal processing .. # Log accounting to local file AcctLogFileName filename # Additional Handler for Accounting packets only # Set up a proxy for accounting Host Secret In both cases above, two Accounting-Accept packets will be retutned to the Clinet NAS. And to answer Neale's other question about - the retry behaviour can be modified with the "Retries" and "RetryTimeout" parameters (Section 6.25 in the 2.14.1 manual). hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
