(RADIATOR) clarity on the ContinueXXXYYY statements
Stuart Kendrick
skendric at fhcrc.org
Sun Sep 10 21:25:03 CDT 2006
hi hugh,
ok, that works
so my Handler can then look as follows:
<Handler Client-Identifier=vdops-gear>
RejectHasReason
# Ask for the tokencode
AuthByPolicy ContinueWhileAccept
<AuthBy ACE>
</AuthBy>
# Check group membership, assign privileges
<AuthBy GROUP>
AuthByPolicy ContinueUntilAccept
# Check and respond to group membership: administrative
<AuthBy NT>
GroupRequired EnableGroup
CheckGroupServer dc1
NoCheckPassword
AddToReply Service-Type = "Administrative-User"
</AuthBy>
# Check and respond to group membership: read-only
<AuthBy NT>
GroupRequired ReadOnlyGroup
CheckGroupServer dc1
NoCheckPassword
AddToReply Service-Type = "NAS-Prompt-User"
</AuthBy>
</AuthBy>
# Log it
AuthLog mgmt-authlog
AcctLogFileName %L/Acct/%Y-%m-%d-acct
</Handler>
where 'dc1' is the name of an Active Directory controller
but i'm not going to use this feature ... because i haven't found a way
to specify *multiple* CheckGroupServer parameters. i have four Active
Directory domain controllers ... and i want to be able to specify all of
them
-i tried listing them ...
<AuthBy NT>
GroupRequired EnableGroup
CheckGroupServer dc1
CheckGroupServer dc2
CheckGroupServer dc3
CheckGroupServer dc4
NoCheckPassword
AddToReply Service-Type = "Administrative-User"
</AuthBy>
but it turns out that the last one is the only one used, and if it is
down, Radiator declares that the user is not a member of either
'EnableGroup' or 'ReadOnlyGroup'. staring briefly at Radius/AuthNT.pm,
i can see that the 'CheckGroupServer' element of the
Radius::AuthNT::ConfigKeywords hash is iniitialized as 'string' ...
which suggests to me that it can't handle multiple values ... though i
don't see where you read in radius.cfg ... but i'm being lazy here and
not looking too hard ... poking further, i can see that in the if clause
contributed by Mark Motley (line 215), we hand this string to
Win32::NetAdmin::GroupIsMember ... and a cursory read of 'perldoc
Win32::NetAdmin suggests to me that GroupIsMember requires a single
value for 'server' ... and i don't see any iterative effort around line
215 ... ok, so i'm going to claim that Radiator can only handle one
value for 'CheckGroupServer'
-i also tried specifying an alias
<AuthBy NT>
GroupRequired EnableGroup
CheckGroupServer dc.company.com
NoCheckPassword
AddToReply Service-Type = "Administrative-User"
</AuthBy>
where 'dc.company.com' returns all four IP addresses ... but that broke
authentication entirely. i haven't poked at this ... perhaps all four
addresses get stuffed into the 'CheckGroupServer' hash of
Radius::AuthNT::ConfigKeywords, and then Win32::NetAdmin::GroupIsMember
can't resolve the result
anyway, if y'all end up enhancing AuthNT.pm to handle *multiple* values
for CheckGroupServer, i would go this route ... but otherwise, i'm going
to stick with the more circuitous approach you outlined for me ...
because i can employ 'Domain COMPANY' using that approach, which tells
AuthBy NT (i believe) to rely on the local machine's ability to find
domain controllers ... which (i believe) ... allows the local machine to
try various domain controllers, if one or more are down. i guess ... i
outta test all this actually ...
thanx for pursuing this with me,
--sk
stuart kendrick
fhcrc
Hugh Irvine wrote:
>
> Hello Stuart -
>
> Hmmmm - in looking at the code in "Radius/AuthNT.pm" I see that the
> manual does not indicate everything that is required.
>
> So, yes you can specify "GroupRequired Some-Group", but you also need to
> specify "CheckGroupServer YourGroupServer".
>
> Presumably "YourGroupServer" is the name of the NT server that will
> check the group membership.
>
> Please let me know how you get on and I will ask Mike to amend the manual.
>
> thanks and regards
>
> Hugh
>
>
> On 11 Sep 2006, at 10:33, Stuart Kendrick wrote:
>
>> hi hugh,
>>
>> bummer. i was wanting to reduce the length of the chain of
>> stanzas/files i must view, when analyzing this particular chunk of my
>> config file
>>
>> but i'm not quite ready to give up!
>>
>> what about 5.28.10 at
>> http://www.open.com.au/radiator/ref.html#pgfId=399936 ?
>>
>> " 5.28.10 GroupRequired
>>
>> On Windows, this optional parameter causes AuthBy NT to ensure that
>> the user is a member of the named group during authentication."
>>
>> documentation bug? or am i misunderstanding how 'GroupRequired' can
>> be used with the <AuthBy NT> clause?
>>
>>
>> --sk
>>
>>
>> Hugh Irvine wrote:
>>> Hello Stuart -
>>> The difference is due to the fact that you need a "Group=SomeGroup"
>>> check item when using AuthBy NT with GroupRequired, which is what you
>>> are doing in the AuthBy FILE. You cannot specify the group directly
>>> in the AuthBy NT clause.
>>> hope that helps
>>> regards
>>> Hugh
>>> On 9 Sep 2006, at 07:37, Stuart Kendrick wrote:
>>>> hi hugh,
>>>>
>>>> ok, i buy that
>>>>
>>>> and it works
>>>>
>>>> but now i have another oddity i'm exploring
>>>>
>>>> users who belong to the AD 'EnableGroup' *and* users who belong to
>>>> the AD 'ReadOnlyGroup' *both* receive administrative privileges on a
>>>> sample client. looking at packet traces and at 'logfile', i can see
>>>> that, in fact, Radiator is sending Service-Type =
>>>> "Administrative-User" in the Access-Accept responses ... so it makes
>>>> sense that the client grants the incoming user administrative
>>>> privileges
>>>>
>>>> here's my 'consolidated' Handler:
>>>>
>>>> [...]
>>>> ##### ACE Authentication #####
>>>>
>>>> <Handler Client-Identifier=vdops-gear>
>>>> RejectHasReason
>>>>
>>>> # Ask for the tokencode
>>>> AuthByPolicy ContinueWhileAccept
>>>> <AuthBy ACE>
>>>> </AuthBy>
>>>>
>>>> # Check group membership, assign privileges
>>>> <AuthBy GROUP>
>>>> AuthByPolicy ContinueUntilAccept
>>>>
>>>> # Check and respond to group membership: administrative
>>>> <AuthBy NT>
>>>> GroupRequired EnableGroup
>>>> NoCheckPassword
>>>> AddToReply Service-Type = "Administrative-User"
>>>> </AuthBy>
>>>>
>>>> # Check and respond to group membership: read-only
>>>> <AuthBy NT>
>>>> GroupRequired ReadOnlyGroup
>>>> NoCheckPassword
>>>> AddToReply Service-Type = "NAS-Prompt-User"
>>>> </AuthBy>
>>>> </AuthBy>
>>>>
>>>> # Log it
>>>> AuthLog mgmt-authlog
>>>> AcctLogFileName %L/Acct/%Y-%m-%d-acct
>>>> </Handler>
>>>> [...]
>>>>
>>>> i played a bit and found that i could replace 'EnableGroup' with
>>>> 'Foozle' ... same results. 'Foozle' is *not* a group defined in my
>>>> Active Directory. hmmm ... so ... i switched the order of the two
>>>> <AuthBy NT> clauses
>>>>
>>>> # Check and respond to group membership: read-only
>>>> <AuthBy NT>
>>>> GroupRequired ReadOnlyGroup
>>>> NoCheckPassword
>>>> AddToReply Service-Type = "NAS-Prompt-User"
>>>> </AuthBy>
>>>>
>>>> # Check and respond to group membership: administrative
>>>> <AuthBy NT>
>>>> GroupRequired EnableGroup
>>>> NoCheckPassword
>>>> AddToReply Service-Type = "Administrative-User"
>>>> </AuthBy>
>>>>
>>>> and, in fact, now members of both groups receive minimal privileges
>>>> on the client
>>>>
>>>> so ... i would say that Radiator sees a successful authentication
>>>> event inside either <AuthBy NT> clause ... this would be consonant
>>>> with Radiator ignoring the 'GroupRequired' line. if Radiator
>>>> ignored the 'GroupRequired' line ... it would see the
>>>> 'NoCheckPassword' line ... and at that point, perhaps it says "hey,
>>>> looks like a success to me!" and then adds the Service-Type to the
>>>> Reply and away we go
>>>>
>>>> am i using GroupRequired in some invalid kind of way? [note: i
>>>> don't see Radiator complaining about the config file when it loads]
>>>>
>>>> Fri Sep 8 14:36:33 2006: DEBUG: Finished reading configuration file
>>>> 'c:\Program Files\Radiator\radius-mgmt.cfg'
>>>> Fri Sep 8 14:36:33 2006: DEBUG: Reading dictionary file 'C:/Program
>>>> Files/Radiator/dictionary'
>>>> Fri Sep 8 14:36:33 2006: DEBUG: Creating authentication port
>>>> 0.0.0.0:1812
>>>> Fri Sep 8 14:36:33 2006: DEBUG: Creating accounting port 0.0.0.0:1813
>>>> Fri Sep 8 14:36:33 2006: NOTICE: Server started: Radiator 3.15 on
>>>> vidal
>>>>
>>>>
>>>>
>>>> ok, so then i started comparing my Handler above to the Handler
>>>> which i have in place at the moment ... and which sends Service-Type
>>>> = Administrative-User if the user belongs to 'EnableGroup' and
>>>> Service-Type = NAS-Prompt-User if the user belongs to 'ReadOnlyGroup'
>>>>
>>>> [...]
>>>> #### ACE Authentication ####
>>>>
>>>> <AuthBy FILE>
>>>> Identifier CheckCiscoEnable
>>>> Filename C:\Program Files\Radiator\ChKCiscoEnable
>>>> </AuthBy>
>>>>
>>>> <AuthBy FILE>
>>>> Identifier CheckCiscoReadOnly
>>>> Filename C:\Program Files\Radiator\ChKCiscoReadOnly
>>>> </AuthBy>
>>>>
>>>> <AuthBy NT>
>>>> Identifier CheckNT
>>>> GroupRequired
>>>> NoCheckPassword
>>>> </AuthBy>
>>>>
>>>> <Handler Client-Identifier=vdops-gear>
>>>> <AuthBy GROUP>
>>>> AuthByPolicy ContinueWhileAccept
>>>> <AuthBy ACE>
>>>> </AuthBy>
>>>> <AuthBy GROUP>
>>>>
>>>> AuthByPolicy ContinueWhileReject
>>>> AuthBy CheckCiscoEnable
>>>> AuthBy CheckCiscoReadOnly
>>>> </Handler>
>>>> [...]
>>>>
>>>> C:\Program Files\Radiator>type ChkCiscoEnable
>>>> DEFAULT Auth-Type = CheckNT, Group = EnableGroup
>>>> Service-Type = "Administrative-User"
>>>>
>>>> C:\Program Files\Radiator>type ChkCiscoReadOnly
>>>> DEFAULT Auth-Type = CheckNT, Group = ReadOnlyGroup
>>>> Service-Type = "NAS-Prompt-User"
>>>>
>>>> C:\Program Files\Radiator>
>>>>
>>>>
>>>> and i don't see the difference. sure, there's a bunch of
>>>> indirection going on, going thru the external files
>>>> ChkCiscoEnable/ChkCiscoReadOnly ... and then back through the
>>>> 'CheckNT' AuthBy clause ... but in the end, both approaches are
>>>> using <AuthBy NT> with GroupRequired ...
>>>>
>>>> do you see what is different, functionally, between the two
>>>> approaches? do you see a reason why Radiator might be ignorning my
>>>> 'GroupRequired' line?
>>>>
>>>> --sk
>>>>
>>>> Hugh Irvine wrote:
>>>>> Hello Stuart -
>>>>> You can only change the AuthByPolicy inside an AuthBy GROUP, so
>>>>> your Handler should look like this:
>>>>> #### ACE authentication #####
>>>>> <Handler Client-Identifier=vdops-gear>
>>>>> AuthByPolicy ContinueWhileAccept
>>>>> RejectHasReason
>>>>> # Ask for the tokencode
>>>>> <AuthBy ACE>
>>>>> </AuthBy>
>>>>> <AuthBy GROUP>
>>>>> AuthByPolicy ContinueUntilAccept
>>>>> # Check and respond to group membership: administrative
>>>>> <AuthBy NT>
>>>>> GroupRequired EnableGroup
>>>>> NoCheckPassword
>>>>> AddToReply Service-Type = "Administrative-User"
>>>>> </AuthBy>
>>>>> # Check and respond to group membership: read-only
>>>>> <AuthBy NT>
>>>>> GroupRequired ReadOnlyGroup
>>>>> NoCheckPassword
>>>>> AddToReply Service-Type = "NAS-Prompt-User"
>>>>> </AuthBy>
>>>>> </AuthBy>
>>>>> # Log it
>>>>> AcctLogFileName %L/Acct/%Y-%m-%d-acct
>>>>> AuthLog rsa-authlog
>>>>> </Handler>
>>>>> hope that helps
>>>>> regards
>>>>> Hugh
>>>>> On 8 Sep 2006, at 01:04, Stuart Kendrick wrote:
>>>>>> hi,
>>>>>>
>>>>>> i want to better understand the various ContinueXxxxYxxx
>>>>>> statements (ContinueWhileAccept and ContinueUntilAccept and so forth)
>>>>>>
>>>>>>
>>>>>> -i want to use RSA tokens to authenticate users
>>>>>>
>>>>>> -here's my config:
>>>>>>
>>>>>> # Typical VDOPS devices (switches, routers, WAPs, Hardware VPN
>>>>>> Clients, IPSCON)
>>>>>> # Clump any client which sends us the standard shared secret into
>>>>>> the 'vdops-gear' Handler
>>>>>> <Client DEFAULT>
>>>>>> Secret moozle
>>>>>> Identifier vdops-gear
>>>>>> </Client>
>>>>>>
>>>>>>
>>>>>> #### ACE authentication #####
>>>>>> <Handler Client-Identifier=vdops-gear>
>>>>>> AuthByPolicy ContinueWhileAccept
>>>>>> RejectHasReason
>>>>>>
>>>>>> # Ask for the tokencode
>>>>>> <AuthBy ACE>
>>>>>> </AuthBy>
>>>>>> AuthByPolicy ContinueUntilAccept
>>>>>>
>>>>>> # Check and respond to group membership: administrative
>>>>>> <AuthBy NT>
>>>>>> GroupRequired EnableGroup
>>>>>> NoCheckPassword
>>>>>> AddToReply Service-Type = "Administrative-User"
>>>>>> </AuthBy>
>>>>>>
>>>>>> # Check and respond to group membership: read-only
>>>>>> <AuthBy NT>
>>>>>> GroupRequired ReadOnlyGroup
>>>>>> NoCheckPassword
>>>>>> AddToReply Service-Type = "NAS-Prompt-User"
>>>>>> </AuthBy>
>>>>>>
>>>>>> # Log it
>>>>>> AcctLogFileName %L/Acct/%Y-%m-%d-acct
>>>>>> AuthLog rsa-authlog
>>>>>> </Handler>
>>>>>>
>>>>>>
>>>>>> [i've also tried moving the 'AuthByPolicy ContinueUntilAccept'
>>>>>> line to just above the '# Check and respond to group membership:
>>>>>> read-only' line -- same results]
>>>>>>
>>>>>>
>>>>>> -i can see from a packet trace, and from logfile, that Radiator
>>>>>> returns an 'Access-Accept' ... but nothing more. the client
>>>>>> refuses the login. i believe that the client refuses the login
>>>>>> because the client requires more than an 'Access-Accept' ... it
>>>>>> requires Service-Type as well
>>>>>>
>>>>>> Thu Sep 7 07:42:47 2006: DEBUG: Finished reading configuration
>>>>>> file 'c:\Program Files\Radiator\radius-mgmt.cfg'
>>>>>> Thu Sep 7 07:42:47 2006: DEBUG: Reading dictionary file
>>>>>> 'C:/Program Files/Radiator/dictionary'
>>>>>> Thu Sep 7 07:42:48 2006: DEBUG: Creating authentication port
>>>>>> 0.0.0.0:1812
>>>>>> Thu Sep 7 07:42:48 2006: DEBUG: Creating accounting port
>>>>>> 0.0.0.0:1813
>>>>>> Thu Sep 7 07:42:48 2006: NOTICE: Server started: Radiator 3.15 on
>>>>>> vidal
>>>>>> Thu Sep 7 07:43:06 2006: DEBUG: Packet dump:
>>>>>> *** Received from 140.107.6.205 port 1645 ....
>>>>>> Code: Access-Request
>>>>>> Identifier: 7
>>>>>> Authentic: [...]
>>>>>> Attributes:
>>>>>> NAS-IP-Address = 140.107.6.5
>>>>>> NAS-Port = 1
>>>>>> NAS-Port-Type = Virtual
>>>>>> User-Name = "skendric"
>>>>>> Calling-Station-Id = "140.107.41.9"
>>>>>> User-Password = "[...]"
>>>>>>
>>>>>> Thu Sep 7 07:43:06 2006: DEBUG: Handling request with Handler
>>>>>> 'Client-Identifier=vdops-gear'
>>>>>> Thu Sep 7 07:43:06 2006: DEBUG: Deleting session for skendric,
>>>>>> 140.107.6.5,1
>>>>>> Thu Sep 7 07:43:06 2006: DEBUG: Handling with Radius::AuthACE:
>>>>>> Thu Sep 7 07:43:06 2006: DEBUG: Radius::AuthACE looks for match
>>>>>> with skendric [skendric]
>>>>>> Thu Sep 7 07:43:08 2006: DEBUG: Radius::AuthACE ACCEPT: :
>>>>>> skendric [skendric]
>>>>>> Thu Sep 7 07:43:08 2006: DEBUG: AuthBy ACE result: ACCEPT,
>>>>>> Thu Sep 7 07:43:08 2006: DEBUG: Access accepted for skendric
>>>>>> Thu Sep 7 07:43:08 2006: DEBUG: Packet dump:
>>>>>>
>>>>>>
>>>>>> -so, i'm guessing that Radiator processes the <AuthBy
>>>>>> ACE><\AuthBy> section ... and then quits processing this Handler.
>>>>>> why? wouldn't the 'AuthByPolicy ContinueWhileAccept' phrase
>>>>>> instruct Radiator to continue to the next stanza within this
>>>>>> Handler, i.e. to the first <AuthBy NT> stanza? [btw: user
>>>>>> 'skendric' belongs to EnableGroup]
>>>>>>
>>>>>>
>>>>>> -i have a working config file ... when this config file is in
>>>>>> place, i can successfully login. [but i'd like to simplify it ...
>>>>>> ergo my efforts above]
>>>>>>
>>>>>> here is the working config file:
>>>>>>
>>>>>> ########## CLIENT DEFINITIONS ############
>>>>>>
>>>>>> # Typical VDOPS devices (switches, routers, WAPs, Hardware VPN
>>>>>> Clients, IPSCON)
>>>>>> # Clump any client which sends us the standard shared secret into
>>>>>> the 'vdops-gear' Handler
>>>>>> <Client DEFAULT>
>>>>>> Secret Spann1n9
>>>>>> Identifier vdops-gear
>>>>>> </Client>
>>>>>>
>>>>>>
>>>>>> ########## AUTHENTICATION HANDLERS ############
>>>>>>
>>>>>> <AuthBy FILE>
>>>>>> Identifier CheckCiscoEnable
>>>>>> Filename C:\Program Files\Radiator\ChKCiscoEnable
>>>>>> </AuthBy>
>>>>>>
>>>>>> <AuthBy FILE>
>>>>>> Identifier CheckCiscoReadOnly
>>>>>> Filename C:\Program Files\Radiator\ChKCiscoReadOnly
>>>>>> </AuthBy>
>>>>>>
>>>>>> <AuthBy NT>
>>>>>> Identifier CheckNT
>>>>>> GroupRequired
>>>>>> NoCheckPassword
>>>>>> </AuthBy>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ##### ACE Authentication #####
>>>>>>
>>>>>> <Handler Client-Identifier=vdops-gear>
>>>>>> <AuthBy GROUP>
>>>>>> AuthByPolicy ContinueWhileAccept
>>>>>> <AuthBy ACE>
>>>>>> </AuthBy>
>>>>>> <AuthBy GROUP>
>>>>>>
>>>>>> AuthByPolicy ContinueWhileReject
>>>>>> AuthBy CheckCiscoEnable
>>>>>> AuthBy CheckCiscoReadOnly
>>>>>> </Handler>
>>>>>>
>>>>>> C:\Program Files\Radiator>type ChkCiscoEnable
>>>>>> DEFAULT Auth-Type = CheckNT, Group = CiscoEnable
>>>>>> Service-Type = "Administrative-User"
>>>>>>
>>>>>> C:\Program Files\Radiator>type ChkCiscoReadOnly
>>>>>> DEFAULT Auth-Type = CheckNT, Group = CiscoReadOnly
>>>>>> Service-Type = "NAS-Prompt-User"
>>>>>>
>>>>>> C:\Program Files\Radiator>
>>>>>>
>>>>>>
>>>>>> -when this config file is in place, the logfile output looks the
>>>>>> same ... and from the packet trace, i can see that in addition to
>>>>>> returning an 'Access-Accept', Radiator also returns
>>>>>> "Service-Type(6): Administrative-User(6)" ... and i successfully
>>>>>> login to the device
>>>>>>
>>>>>>
>>>>>> insights or additional trouble-shooting steps solicted
>>>>>>
>>>>>> --sk
>>>>>>
>>>>>> stuart kendrick
>>>>>> fhcrc
>>>>>>
>>>>>>
>>>>>> --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.
>>>>> Includes support for reliable RADIUS transport (RadSec),
>>>>> and DIAMETER translation agent.
>>>>> -
>>>>> 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.
>>> 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.
>>> Includes support for reliable RADIUS transport (RadSec),
>>> and DIAMETER translation agent.
>>> -
>>> 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.
>
>
>
> 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.
> Includes support for reliable RADIUS transport (RadSec),
> and DIAMETER translation agent.
> -
> 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