Re: (RADIATOR) Berkley DB format database

2002-09-20 Thread Hugh Irvine
Hello Pete - By far the best approach is to manage your users in the Platypus database and have Radiator read and write directly to Platypus with the AuthBy PLATYPUS clause (see section 6.33 in the Radiator 3.3.1 reference manual). Otherwise Radiator can also deal with Berkley DB files using the

Re: (RADIATOR) FailureBackoffTime within

2002-09-20 Thread Hugh Irvine
Hello Claudio - Yes state is maintained for a particular request, however state is *not* maintained for a Host object, hence FailureBackoffTime has no relevance to the AuthBy RADIUS when used in an AuthBy SQLRADIUS clause (although it does have relevance for the SQL database). regards Hugh

Re: (RADIATOR) FailureBackoffTime within

2002-09-20 Thread Claudio Lapidus
Hello Hugh You wrote: >The FailureBackoffTime parameter is not useful in the context of an AuthBy >SQLRADIUS clause, because the "Host" objects are only instanciated for very >brief periods of time (until the request is forwarded), and new "Host" >objects are created for every request (or tim

Re: (RADIATOR) users database format

2002-09-20 Thread Ayotunde Itayemi
Hi TDN, You can use AddToRequestIfNotExist or AddToRequest parameter in your Handler or Realm clause. For example, AddToRequestIfNotExist Service-Type = Framed-User See section 6.16.19 and 6.16.20 of the reference manual (version 3.0) formore details. Regards, Tunde Itayemi. -

RE: (RADIATOR) CHAP issues

2002-09-20 Thread Danil Melomedman
> That may be but CHAP doesn't secure you any better. Storing the > passwords in clear text on the server is more likely to get > compromised versus someone sniffing the wiring for clear text. > > This is a no-win situation. I agree with this. I think people who designed

RE: (RADIATOR) users database format

2002-09-20 Thread Frank Danielson
Why not use an AddToReply in your Client clause for this NAS? See section 6.5.18 in the manual. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 10:26 AM To: [EMAIL PROTECTED] Subject: (RADIATOR) users database format Hello, I have

(RADIATOR) users database format

2002-09-20 Thread tdn
Hello, I have a flat file users database, which has the format below: user1 Password = {crypt}* Framed-Protocol=PPP The configuration of one of our new Nases requres that the users database be of this format: user1 Password = {crypt}* Service-Type = Framed-Us

Re: (RADIATOR) Orinoco AP-500/1000 MAC auth problem

2002-09-20 Thread Bon sy
Sehr geehrter Charly Vielen Dank! Ich bin sehr froh. Mein AP funktioniert. Dass gefaellt mir sehr gut. Das ist mein Log im attachment. Bon P.S. I wish I can write more than this with my limited German proficiency. More inline reply On Fri, 20 Sep 2002, Karl Gaissmaier w

(RADIATOR) Berkley DB format database

2002-09-20 Thread Pete
Hi All, We're installing a couple of new Cobalt Raq 550s (one as a backup for the other) and I personally don't have a clue about what's going on. Of course we are using Radiator on the apache servers with Redhat Linux but we are also using Platypus billing system on a windows server for

Re: (RADIATOR) CHAP issues

2002-09-20 Thread Mike McCauley
Hi Dan, On Fri, 20 Sep 2002 09:35, Hugh Irvine wrote: > Hello Dan - > > What is a " multi-valued userPassword (LDAP) attribute"? > > Mike may know more on this than I. No it doesnt support a multivalued LDAP password attribute. If you server understands how to authenticate against a multiva;lue

RE: (RADIATOR) Orinoco AP-500/1000 MAC auth problem

2002-09-20 Thread Ingvar Berg (EAB)
> > I am completely surprised by the tech support when they told me they > > themselves have to get in touch with the AP-1000 developer > to get that > > information. I am hoping someone in the list may have the > information > > handy. > > what tech support? Compare it to the tech support fo