(RADIATOR) clarity on the ContinueXXXYYY statements
Hugh Irvine
hugh at open.com.au
Fri Sep 8 18:39:09 CDT 2006
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.
--
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