(RADIATOR) tunnel-password questions
Hugh Irvine
hugh at open.com.au
Tue Oct 4 05:37:37 CDT 2005
Salut Laurent -
I suggest you consider the following approach.
1. Add Identifier's to your Client clauses like this:
<Client n.n.n.n>
Identifier Cisco
.....
</Client>
<Client m.m.m.m>
Identifier Cisco
.....
</Client>
......
<Client x.x.x.x>
Identifier Ascend
.....
</Client>
<Client y.y.y.y>
Identifier Ascend
.....
</Client>
......
2. Add a suitable hook to your Realm's or Handler's that checks the
Identifier in the Client clause and formats the Tunnel-Password as
required.
You will find an example hook that does something similar in the file
"goodies/hooks.txt" in the Radiator 3.13 distribution.
As an alternative you could also add pseudonym's in the Radiator
dictionary for the different Tunnel-Password formats.
There are a number of pseudonyms in the standard Radiator 3.13
dictionary (near the top of the file).
Hope that helps.
regards
Hugh
On 4 Oct 2005, at 13:04, PREVOSTO, Laurent wrote:
> Actually, we're dealing with all kind of NASes : some accept tagged
> attribute, some not, some accept encrypted tunnel password, some
> not :-(
>
> And I'm trying to figure out what the best setup is :
> - should I put Tunnel-Password as string or tagged-string in the
> dictionary ? (I use 3.13 + patches)
> - if I need to manually add a tagged Tunnel-Password, should I
> AddToReply \001password or 1:password (which I prefer)
>
> Regards
>
> Laurent
>
>
>
>> -----Message d'origine-----
>> De : Patrik Forsberg [mailto:patrik.forsberg at dataphone.net]
>> Envoyé : mardi 4 octobre 2005 05:34
>> À : Mike McCauley; PREVOSTO, Laurent
>> Cc : radiator at open.com.au
>> Objet : RE: (RADIATOR) tunnel-password questions
>>
>> This might me totally out of subject but I thought I'd give a comment
>> atleast ;)
>>
>> We used to have old crappy (now)Lucent Portmaster3 NASes and did
>> L2TP with
>> it.. in that configuration we needed both ClearTextPassword(I
>> belive this
>> is where this option got implemented aculy) and the password were
>> to be
>> sent without the 0:/1: and so on tag. PM3 just doesn't accept a
>> tagged
>> response.
>> As you say yourself that you're dealing with old crappy NASes this
>> might
>> be a hint. I could be totally wrong, ofcourse ;)
>>
>> Regards,
>> Patrik
>>
>>
>>
>>> -----Original Message-----
>>> From: owner-radiator at open.com.au
>>> [mailto:owner-radiator at open.com.au] On Behalf Of Mike McCauley
>>> Sent: den 4 oktober 2005 00:01
>>> To: PREVOSTO, Laurent
>>> Cc: radiator at open.com.au
>>> Subject: Re: (RADIATOR) tunnel-password questions
>>>
>>> Hello Laurent,
>>>
>>> On Tuesday 04 October 2005 03:46, PREVOSTO, Laurent wrote:
>>>
>>>>> De : Mike McCauley [mailto:mikem at open.com.au]
>>>>> Envoyé : lundi 3 octobre 2005 02:02
>>>>> À : PREVOSTO, Laurent
>>>>> Cc : radiator at open.com.au
>>>>> Objet : Re: (RADIATOR) tunnel-password questions
>>>>>
>>>>> Hello Laurent,
>>>>>
>>>>> On Thursday 29 September 2005 20:16, PREVOSTO, Laurent wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am not sure everything works perfectly, i have made a
>>>>>>
>>> few tests with
>>>
>>>>>> radiator 3.13 + patches
>>>>>>
>>>>>> The conf is the following :
>>>>>>
>>>>>> <Client DEFAULT>
>>>>>> Secret secret
>>>>>> </Client>
>>>>>>
>>>>>> <AuthBy INTERNAL>
>>>>>> Identifier Always-Accept
>>>>>> AuthResult ACCEPT
>>>>>> </AuthBy>
>>>>>>
>>>>>> <Handler Realm="test">
>>>>>> AuthBy Always-Accept
>>>>>> AddToReply Tunnel-Password="1:password"
>>>>>> </Handler>
>>>>>>
>>>>>> I plan to test what is the value of the returned
>>>>>>
>>> Tunnel-Password if I
>>>
>>>>>
>>>>> put
>>>>>
>>>>>
>>>>>> string or tagged-string for the Tunnel-Password attribute in the
>>>>>>
>>>>>
>>>>> dictionary
>>>>>
>>>>>
>>>>>> file and if is add or not ClearTextTunnelPassword in
>>>>>>
>>> the Client clause.
>>>
>>>>>>
>>>>>> I do a radpwtest -trace 4 -s localhost -noacct -dictionary
>>>>>> dictionary.with.no.tag -user lp at test -password test
>>>>>>
>>>>>> (I use a dictionary with no tag for radpwtst so I can
>>>>>>
>>> see the very
>>>
>>>>>> value
>>>>>>
>>>>>
>>>>> of
>>>>>
>>>>>
>>>>>> the attribute).
>>>>>>
>>>>>
>>>>> The key to understanding the opertion is that Radiator
>>>>>
>>> keeps Tunnel-
>>>
>>>>> Password
>>>>> in plaintext format internally and encrypts/decrypts it
>>>>>
>>> at the 'edges'
>>>
>>>>> when
>>>>> receiving replies from a remote server and sending
>>>>>
>>> replies back to the
>>>
>>>>> client.
>>>>>
>>>>> Therefore, Tunnel-Password in a user file or user
>>>>>
>>> database _must_ be in
>>>
>>>>> plaintext format. Indeed, it does not make sense to have
>>>>>
>>> Tunnel-Password
>>>
>>>>> in a
>>>>> user file alrteady encrypted, since the encryption
>>>>>
>>> depends on the RADIUS
>>>
>>>>> shared secret.
>>>>>
>>>>>
>>>>>> There are 4 cases :
>>>>>>
>>>>>> 1. Tunnel-Password is string and tunnel password is NOT
>>>>>>
>>> clear text
>>>
>>>>>> Tunnel-Password =
>>>>>>
>>>>>>
>>> "<1><224><21><153><141><226>0<134>it<197>b<0<232><13><202><227
>>> <237>" I
>>>
>>>>>> assume this is ok : there is a <1> byte tag and it is encrypted
>>>>>>
>>>>>
>>>>> OK.
>>>>>
>>>>>
>>>>>> 2. Tunnel-Password is string and I put
>>>>>>
>>> ClearTextTunnelPassword in the
>>>
>>>>>> Client clause : Tunnel-Password = "1:password"
>>>>>> I assume this is wrong : I was expecting something like
>>>>>>
>>> <1>password
>>>
>>>>>
>>>>> Expected.
>>>>> If ClearTextTunnelPassword is set then there is no
>>>>> encryption/tagging/special
>>>>> processing: the Tunnel-Password in the user database wil lbe sent
>>>>> literally
>>>>> and unchanged to the client.
>>>>>
>>>>>
>>>>>> 3. Tunnel-Password is tagged-string and tunnel password
>>>>>>
>>> is NOT clear
>>>
>>>>>
>>>>> text
>>>>>
>>>>>
>>>>>> Tunnel-Password =
>>>>>>
>>>>>>
>>> "<0><1><161><139><0>Y<230><173><12><1>b_J><232><127>s<191><223>g" I
>>>
>>>>>
>>>>> assume
>>>>>
>>>>>
>>>>>> this is wrong : the password is encrypted but I have
>>>>>>
>>> the wrong tag
>>>
>>>>>
>>>>> No, it will get encrypted again when sent to the client.
>>>>>
>>> Thats why you
>>>
>>>>> are seeing the wrong tag.
>>>>>
>>>>
>>>> I don't get it : in my config file i have AddToReply
>>>> Tunnel-Password=1:password : the value is not in encrypted
>>>>
>>> form. So there
>>>
>>>> is no way it should be encrypted "again". When I say
>>>>
>>> "tunnel password is
>>>
>>>> not clear text", I mean : i did not put
>>>>
>>> ClearTextTunnelPassword in the
>>>
>>>> config file...
>>>>
>>>
>>> Sorry, I made the wrong explanation.
>>> Curious.
>>> Tests here show that if you have
>>> AddToReply Tunnel-Password=1:password
>>> in the AuthBy and
>>> ClearTextTunnelPassword
>>> in the Client, you get:
>>>
>>> *** Received from 127.0.0.1 port 1645 ....
>>> Code: Access-Accept
>>> Identifier: 90
>>> Authentic:
>>> <251><212><158>R<149><172>e<142>x<240><163><133><226>><152><155>
>>> Attributes:
>>> Tunnel-Password = "1:password"
>>>
>>> and if you have:
>>> AddToReply Tunnel-Password=\001password
>>> you get
>>>
>>> *** Received from 127.0.0.1 port 1645 ....
>>> Code: Access-Accept
>>> Identifier: 226
>>> Authentic: 7<162><130><132>n<215>><173><147>>z<185>l<6>u<224>
>>> Attributes:
>>> Tunnel-Password = "<1>password"
>>>
>>> showing that when ClearTextTunnelPassword is set, the
>>> Tunnel-Password contains
>>> the literal string. Caution, AddToReply will not recognise
>>> <n> as an escape
>>> code for character n.
>>>
>>>
>>>>
>>>>
>>>>>> 4. Tunnel-Password is tagged-string and I put
>>>>>>
>>> ClearTextTunnelPassword
>>>
>>>>>> in the Client : Tunnel-Password = "<1>password"
>>>>>> I assume this is ok : there is the <1> byte tag and the
>>>>>>
>>> password is
>>>
>>>>>
>>>>> clear
>>>>>
>>>>>
>>>>>> text.
>>>>>>
>>>>>
>>>>> Expected.
>>>>> As per 2 above.
>>>>>
>>>>
>>>> Not exactly : in 2. you say if ClearTextTunnelPassword is
>>>>
>>> set, there is no
>>>
>>>> processing concerning tag. But the "1:" is parsed since I
>>>>
>>> get <1>password
>>>
>>>> as a result and not <0>1:password
>>>>
>>>>
>>>>>> Am I missing something ?
>>>>>> I could have been fooled by radpwtst output but this is
>>>>>>
>>> quite unclear
>>>
>>>>>> to me.
>>>>>>
>>>>>
>>>>> Yes, CAUTION: radpwtst always shows the wire version of
>>>>>
>>> Tunnel-Password,
>>>
>>>>> it
>>>>> does not show decrypted Tunnel-Passwords
>>>>>
>>>>
>>>> That's what i expect :-)
>>>> Or my tests would mean nothing...
>>>>
>>>> Regards
>>>>
>>>> Laurent
>>>>
>>>>
>>>>>> Could anybody explain to me what really happens, we
>>>>>>
>>> have clients with
>>>
>>>>>
>>>>> all
>>>>>
>>>>>
>>>>>> kinds of setups and I am sorta confused...
>>>>>>
>>>>>
>>>>> Hope that helps.
>>>>>
>>>>> Cheers.
>>>>>
>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Laurent
>>>>>>
>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Mike McCauley [mailto:mikem at open.com.au]
>>>>>>> Envoyé : samedi 24 septembre 2005 01:15
>>>>>>> À : PREVOSTO, Laurent
>>>>>>> Cc : radiator at open.com.au
>>>>>>> Objet : Re: (RADIATOR) tunnel-password questions
>>>>>>>
>>>>>>> Hello Laurent,
>>>>>>>
>>>>>>> The answer to your questions depends on what version
>>>>>>>
>>> of Radiator you
>>>
>>>>>>> have. We
>>>>>>> made recent changes to rationalise the behaviour of encrypyted
>>>>>>>
>>>>>
>>>>> attributes
>>>>>
>>>>>
>>>>>>> like Tunnel-Password when proxying.
>>>>>>>
>>>>>>> Now, when a proxy reply contains Tunnel-Password, the
>>>>>>>
>>> Tunnel-Password
>>>
>>>>>
>>>>> is
>>>>>
>>>>>
>>>>>>> decrypted by AuthRADIUS using the shared secret for
>>>>>>>
>>> the hop to the
>>>
>>>>>
>>>>> proxy
>>>>>
>>>>>
>>>>>>> (unless ClearTextTunnelPassword is set in the
>>>>>>>
>>> AuthRADIUS Host). It is
>>>
>>>>>>> then kept in plaintext form until shortly before
>>>>>>>
>>> being replied to the
>>>
>>>>>>> original client, when it is encrypted with the
>>>>>>>
>>> original clients
>>>
>>>>>>> shared password (unless ClearTextTunnelPassword is
>>>>>>>
>>> set in the Client
>>>
>>>>>>> clause).
>>>>>>>
>>>>>>> That means that now you can do stuff to
>>>>>>>
>>> Tunnel-Password in AddToReply
>>>
>>>>>>> etc. and
>>>>>>> it should work.
>>>>>>>
>>>>>>> You can use ClearTextTunnelPassword in AuthBy RADIUS
>>>>>>>
>>> or in Client
>>>
>>>>>>>
>>>>>>> When encrypting Tunnel-Password and similar, you can
>>>>>>>
>>> use either
>>>
>>>>>>> tagged
>>>>>>>
>>>>>
>>>>> or
>>>>>
>>>>>
>>>>>>> non-tagged strings. If there is no tag at the beginning of the
>>>>>>>
>>>>>
>>>>> password,
>>>>>
>>>>>
>>>>>>> Radiator assumes the tag is 0:
>>>>>>>
>>>>>>> This is all quite different to earlier behaviour. It
>>>>>>>
>>> is available now
>>>
>>>>>
>>>>> in
>>>>>
>>>>>
>>>>>>> the
>>>>>>> latest Radiator patch set.
>>>>>>>
>>>>>>> Hope that helps.
>>>>>>>
>>>>>>> Cheers.
>>>>>>>
>>>>>>> On Thursday 22 September 2005 20:00, PREVOSTO, Laurent wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> Bonjour,
>>>>>>>>
>>>>>>>>
>>>>>>>> I have the following situation :
>>>>>>>>
>>>>>>>> Old crappy NAS <----> radiator proxy <----> old crappy SMC
>>>>>>>>
>>>>>>>> I have problems concerning the tunnel password
>>>>>>>>
>>> reply-item so I'd
>>>
>>>>>
>>>>> like
>>>>>
>>>>>
>>>>>>>> to verify a few things concerning the way radiator
>>>>>>>>
>>> handles it :
>>>
>>>>>>>>
>>>>>>>> 1. if SMC sends back encrypted tunnel-password and
>>>>>>>>
>>> I don't use
>>>
>>>>>>>> PlainTextTunnelPassword, I have the following
>>>>>>>> *** Received from SMC port 1812 ....
>>>>>>>> Code: Access-Accept
>>>>>>>> Identifier: 2
>>>>>>>> Authentic:
>>>>>>>>
>>> oc<202>Xx4<176><187><21><252>9<250><189><149><150><132>
>>>
>>>>>>>> Attributes:
>>>>>>>> Proxy-State = OSC-Extended-Id=2
>>>>>>>> Class = "<128><141><128><128>"
>>>>>>>> Service-Type = Framed-User
>>>>>>>> Tunnel-Type = 1:L2TP
>>>>>>>> Tunnel-Medium-Type = 1:IP
>>>>>>>> Tunnel-Client-Endpoint = 1:xxxx
>>>>>>>> Tunnel-Server-Endpoint = 1:yyyy
>>>>>>>> Tunnel-Password =
>>>>>>>> "<1><255><212><1>A<174><133><8><29>"28&<202>>[<200><3><165>"
>>>>>>>>
>>>>>>>> Tue Sep 20 18:18:03 2005: DEBUG: Received reply in
>>>>>>>>
>>> AuthRADIUS for
>>>
>>>>>
>>>>> req 2
>>>>>
>>>>>
>>>>>>>> from 192.168.162
>>>>>>>> .120:1812
>>>>>>>> Tue Sep 20 18:18:03 2005: DEBUG: Access accepted
>>>>>>>>
>>> for zzzz at demo.fr
>>>
>>>>>>>> Tue Sep 20 18:18:03 2005: DEBUG: Packet dump:
>>>>>>>> *** Sending to NAS port 32839 ....
>>>>>>>> Code: Access-Accept
>>>>>>>> Identifier: 228
>>>>>>>> Authentic: 1234567890123456
>>>>>>>> Attributes:
>>>>>>>> Class = "<128><141><128><128>"
>>>>>>>> Service-Type = Framed-User
>>>>>>>> Tunnel-Type = 1:L2TP
>>>>>>>> Tunnel-Medium-Type = 1:IP
>>>>>>>> Tunnel-Client-Endpoint = 1:xxxx
>>>>>>>> Tunnel-Server-Endpoint = 1:yyyy
>>>>>>>> Tunnel-Password = "<1><201><183><139>a<251><134>b
>>>>>>>> <131>B<192><7><9>X<187><248>fa
>>>>>>>> "
>>>>>>>>
>>>>>>>> So it looks like radiator decrypts then reencrypts
>>>>>>>>
>>> Tunnel-Password.
>>>
>>>>>>>> Moreover, I have to use the "string" type in the
>>>>>>>>
>>> dictionary (as
>>>
>>>>>>>> documented) and NOT tagged-string since it seems to
>>>>>>>>
>>> mess things up.
>>>
>>>>>>>> Am I right ?
>>>>>>>>
>>>>>>>> 2. if SMC sends back encrypted tunnel-password and I do use
>>>>>>>> PlainTextTunnelPassword, I have the following
>>>>>>>>
>>>>>>>> *** Received from SMC port 1812 ....
>>>>>>>> Code: Access-Accept
>>>>>>>> Identifier: 1
>>>>>>>> Authentic:
>>>>>>>>
>>>>>>>>
>>> <244>_<149><215><251>;<175>O<250><194><165><30><173><31><240>#
>>>
>>>>>>>> Attributes:
>>>>>>>> Proxy-State = OSC-Extended-Id=1
>>>>>>>> Class = "<128><141><128><128>"
>>>>>>>> Service-Type = Framed-User
>>>>>>>> Tunnel-Type = 1:L2TP
>>>>>>>> Tunnel-Medium-Type = 1:IP
>>>>>>>> Tunnel-Client-Endpoint = 1:xxxx
>>>>>>>> Tunnel-Server-Endpoint = 1:yyyy
>>>>>>>> Tunnel-Password =
>>>>>>>>
>>>>>>>>
>>> "<1><175>.<213>8<165><7><26><223><163><16><164>L<231><188>[<25
>>>
>>>>>>>> 0>fM"
>>>>>>>>
>>>>>>>> Tue Sep 20 18:19:12 2005: DEBUG: Received reply in
>>>>>>>>
>>> AuthRADIUS for
>>>
>>>>>
>>>>> req 1
>>>>>
>>>>>
>>>>>>>> from 192.168.162
>>>>>>>> .120:1812
>>>>>>>> Tue Sep 20 18:19:12 2005: DEBUG: Access accepted
>>>>>>>>
>>> for zzzz at demo.fr
>>>
>>>>>>>> Tue Sep 20 18:19:12 2005: DEBUG: Packet dump:
>>>>>>>> *** Sending to NAS port 32839 ....
>>>>>>>> Code: Access-Accept
>>>>>>>> Identifier: 42
>>>>>>>> Authentic: 1234567890123456
>>>>>>>> Attributes:
>>>>>>>> Class = "<128><141><128><128>"
>>>>>>>> Service-Type = Framed-User
>>>>>>>> Tunnel-Type = 1:L2TP
>>>>>>>> Tunnel-Medium-Type = 1:IP
>>>>>>>> Tunnel-Client-Endpoint = 1:xxxx
>>>>>>>> Tunnel-Server-Endpoint = 1:yyyy
>>>>>>>> Tunnel-Password =
>>>>>>>>
>>>>>>>>
>>> "<1><175>.<213>8<165><7><26><223><163><16><164>L<231><188>[<25
>>>
>>>>>>>> 0>fM"
>>>>>>>>
>>>>>>>> So it looks like if radiator receives an encrypted
>>>>>>>>
>>> Tunnel-Password,
>>>
>>>>>
>>>>> he
>>>>>
>>>>>
>>>>>>>> will send it encrypted (but unchanged) even if
>>>>>>>>
>>>>>
>>>>> ClearTextTunnelPassword
>>>>>
>>>>>
>>>>>>>> is set.
>>>>>>>> Once again, am I right ?
>>>>>>>> In that very case, is there a way radiator sends back the
>>>>>>>> Tunnel-Password as clear text ?
>>>>>>>>
>>>>>>>>
>>>>>>>> 3. mixing ClearTextTunnelPassword and Handler
>>>>>>>> I can add ClearTextTunnelPassword in an <AuthBy
>>>>>>>>
>>> Radius> clause and
>>>
>>>>>
>>>>> it
>>>>>
>>>>>
>>>>>>>> works fine (if the Tunnel-Password is not received
>>>>>>>>
>>> encrypted, as in
>>>
>>>>>
>>>>> 2.)
>>>>>
>>>>>
>>>>>>>> But it looks like I can't put it in an <Handler>
>>>>>>>>
>>> clause, so I can't
>>>
>>>>>
>>>>> do
>>>>>
>>>>>
>>>>>>>> something like :
>>>>>>>>
>>>>>>>> <Handler Realm=/foo/>
>>>>>>>> AuthBy Something
>>>>>>>> ClearTextTunnelPassword
>>>>>>>> AddToReply Tunnel-Password = 1:somepasswd
>>>>>>>> </Handler>
>>>>>>>>
>>>>>>>> Plus writing :
>>>>>>>> <AuthBy whatever>
>>>>>>>> Identifier Something
>>>>>>>> ClearTextTunnelPassword
>>>>>>>> ...
>>>>>>>> </AuthBy>
>>>>>>>> <Handler Realm=/foo/>
>>>>>>>> AuthBy Something
>>>>>>>> AddToReply Tunnel-Password = 1:somepasswd
>>>>>>>> </Handler>
>>>>>>>> Won't work either.
>>>>>>>>
>>>>>>>> This is quite frustrating... is there a way to do
>>>>>>>>
>>> such a thing ?
>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Laurent
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Archive at http://www.open.com.au/archives/radiator/
>>>>>>>> Announcements on radiator-announce at open.com.au
>>>>>>>> To unsubscribe, email 'majordomo at open.com.au' with
>>>>>>>> 'unsubscribe radiator' in the body of the message.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mike McCauley mikem at open.com.au
>>>>>>> Open System Consultants Pty. Ltd Unix,
>>>>>>>
>>> Perl, Motif, C++,
>>>
>>>>>
>>>>> WWW
>>>>>
>>>>>
>>>>>>> 9 Bulbul Place Currumbin Waters QLD 4223 Australia
>>>>>>> http://www.open.com.au
>>>>>>> Phone +61 7 5598-7474 Fax +61
>>>>>>>
>>> 7 5598-7070
>>>
>>>>>>>
>>>>>>> Radiator: the most portable, flexible and
>>>>>>>
>>> configurable RADIUS server
>>>
>>>>>>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+,
>>>>>>>
>>> password, NT, Emerald,
>>>
>>>>>>> Platypus, Freeside, TACACS+, PAM, external, Active
>>>>>>>
>>> Directory, EAP,
>>>
>>>>>
>>>>> TLS,
>>>>>
>>>>>
>>>>>>> TTLS, PEAP etc on Unix, Windows, MacOS etc.
>>>>>>>
>>>>>
>>>>> --
>>>>> Mike McCauley mikem at open.com.au
>>>>> Open System Consultants Pty. Ltd Unix, Perl,
>>>>>
>>> Motif, C++, WWW
>>>
>>>>> 9 Bulbul Place Currumbin Waters QLD 4223 Australia
>>>>> http://www.open.com.au
>>>>> Phone +61 7 5598-7474 Fax +61 7 5598-7070
>>>>>
>>>>> Radiator: the most portable, flexible and configurable
>>>>>
>>> RADIUS server
>>>
>>>>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password,
>>>>>
>>> NT, Emerald,
>>>
>>>>> Platypus, Freeside, TACACS+, PAM, external, Active
>>>>>
>>> Directory, EAP, TLS,
>>>
>>>>> TTLS, PEAP etc on Unix, Windows, MacOS etc.
>>>>>
>>>
>>> --
>>> Mike McCauley mikem at open.com.au
>>> Open System Consultants Pty. Ltd Unix, Perl,
>>> Motif, C++, WWW
>>> 9 Bulbul Place Currumbin Waters QLD 4223 Australia
>>> http://www.open.com.au
>>> Phone +61 7 5598-7474 Fax +61 7 5598-7070
>>>
>>> Radiator: the most portable, flexible and configurable RADIUS server
>>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>>> Platypus, Freeside, TACACS+, PAM, external, Active Directory,
>>> EAP, TLS,
>>> TTLS, PEAP etc on Unix, Windows, MacOS etc.
>>>
>>> --
>>> Archive at http://www.open.com.au/archives/radiator/
>>> Announcements on radiator-announce at open.com.au
>>> To unsubscribe, email 'majordomo at open.com.au' with
>>> 'unsubscribe radiator' in the body of the message.
>>>
>>>
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
NB:
Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list