(RADIATOR) clarity on the ContinueXXXYYY statements
Stuart Kendrick
skendric at fhcrc.org
Fri Sep 8 16:37:53 CDT 2006
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.
--
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