(RADIATOR) clarity on the ContinueXXXYYY statements
Hugh Irvine
hugh at open.com.au
Sun Sep 10 21:44:05 CDT 2006
Hello Stuart -
You might try using the AuthBy LSA clause instead of AuthBy NT.
See section 5.51 in the Radiator 3.15 manual ("doc/ref.html").
regards
Hugh
On 11 Sep 2006, at 12:25, Stuart Kendrick wrote:
> 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.
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