(RADIATOR) clarity on the ContinueXXXYYY statements
Stuart Kendrick
skendric at fhcrc.org
Sun Sep 10 19:33:01 CDT 2006
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.
>
>
--
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