[RADIATOR] (RADIATOR) enable privilege levels for TACACS+ server

Hugh Irvine hugh at open.com.au
Sun Sep 26 16:30:36 CDT 2010


Hello Markus -

Yes, but the derived RADIUS request is $tp.

regards

Hugh


On 26 Sep 2010, at 21:14, Markus Moeller wrote:

> Hi Hugh,
> 
>  That should work.  BTW service is already added as $self->{service} and wouldn't have to be added again as cisco av pair.
> 
> Thank you
> Markus
> 
> ----- Original Message ----- From: "Hugh Irvine" <hugh at open.com.au>
> To: "Markus Moeller" <huaraz at moeller.plus.com>
> Cc: <radiator at open.com.au>
> Sent: Sunday, September 26, 2010 5:36 AM
> Subject: Re: [RADIATOR] (RADIATOR) enable privilege levels for TACACS+ server
> 
> 
> 
> Hello Markus -
> 
> We have now added these values into cisco-avpair attributes in the derived RADIUS request.
> 
> This support is in the latest Radiator 4.7 patch set (from today), and the reference manual will be updated in the next release.
> 
> Please let us know how you get on with this.
> 
> regards
> 
> Hugh
> 
> 
> On 25 Sep 2010, at 21:13, Markus Moeller wrote:
> 
>> Hi Hugh
>> 
>> Is this anywhere documented  ? I can't find anything in the reference manual
>> (e.g. what are the arguments) .  Looking at the code I see $action and
>> $authen_type are handed over but not privilege level.
>> 
>> Also it looks more like the Hook is replacing the standard authentication handling and is not what I want.
>> 
>> Anyway why does this basic TACACS attribute need special treatment ?
>> 
>> Thank you
>> Markus
>> 
>> ----- Original Message ----- From: "Hugh Irvine" <hugh at open.com.au>
>> To: "Markus Moeller" <huaraz at moeller.plus.com>
>> Cc: <radiator at open.com.au>
>> Sent: Friday, September 24, 2010 11:51 PM
>> Subject: Re: [RADIATOR] (RADIATOR) enable privilege levels for TACACS+
>> server
>> 
>> 
>> 
>> Hello Markus -
>> 
>> You can do this already with the AuthenticationStartHook.
>> 
>> See the code immediately following what you show below.
>> 
>> regards
>> 
>> Hugh
>> 
>> 
>> On 25 Sep 2010, at 03:09, Markus Moeller wrote:
>> 
>>> Hi,
>>> 
>>> Would it be possible to map also the privilege level from the tacacs
>>> request into a radius attribute ? This will allow to differentiate in
>>> Radiator if a user typed enable or enable 5 or enable 7.
>>> 
>>> Thank you
>>> Markus
>>> 
>>> 
>>> ####################################################################
>>> # Handle a TACACS+ authentication START request
>>> sub authentication_start
>>> {
>>>   my ($self, $body) = @_;
>>> 
>>>   $self->{user} = undef;
>>>   $self->{password} = undef;
>>> 
>>>   my ($action, $priv_lvl, $authen_type, $service,
>>>       $user_len, $port_len, $rem_addr_len, $data_len,
>>>       $fields) = unpack('CCCCCCCCa*', $body);
>>>   if ($user_len + $port_len + $rem_addr_len + $data_len >
>>> length($fields))
>>>   {
>>>       $self->{parent}->log($main::LOG_ERR, "Inconsistent lengths in
>>> Tacacs Authentication request from $self->{peeraddr}:$self->{peerport}.
>>> Bad Key?");
>>> 
>>> $self->authentication_reply($Radius::Tacacsplus::TAC_PLUS_AUTHEN_STATUS_ERROR,
>>> 0, 'Inconsistent lengths');
>>>       $self->disconnect();
>>>       return;
>>>   }
>>>   # Decode the variable length fields
>>>   my $i = 0;
>>>   my $user     = substr($fields, $i, $user_len);     $i += $user_len;
>>>   my $port     = substr($fields, $i, $port_len);     $i += $port_len;
>>>   my $rem_addr = substr($fields, $i, $rem_addr_len); $i +=
>>> $rem_addr_len;
>>>   my $data     = substr($fields, $i, $data_len);     $i += $data_len;
>>> 
>>>   $self->{parent}->log($main::LOG_DEBUG, "TacacsplusConnection
>>> Authentication START $action, $authen_type, $service for $user, $port,
>>> $rem_addr");
>>> 
>>>   $self->{user} = $user;
>>>   $self->{port} = $port;
>>>   $self->{service} = $service;
>>>   $self->{rem_addr} = $rem_addr;
>>>   my $tp = $self->create_radius_request('Access-Request');
>>> 
>>> The Tacacs request contains the following, but only user, port, servicve
>>> and remote address are converted not the privelege level.
>>> 
>>> >   Decrypted Request
>>> >        Action: Inbound Login
>>> >        Privilege Level: 15
>>> >        Authentication type: ASCII
>>> >        Service: ENABLE
>>> >        User len: 6
>>> >        User: fred
>>> >        Port len: 5
>>> >        Port: tty18
>>> >        Remaddr len: 12
>>> >        Remote Address: 192.168.1.1
>>> >        Data: 0 (not used)
>>> 
>>> 
>>> ----- Original Message -----
>>> From: Markus Moeller
>>> To: radiator at open.com.au
>>> Sent: Tuesday, January 29, 2008 11:17 PM
>>> Subject: (RADIATOR) enable privilege levels for TACACS+ server
>>> 
>>> I try to run in addition to the Radius server the TACACS+ server.  On
>>> cisco router you can get into different privilege leves by using enable #
>>> where # is a number between 1 and 15.  On a normal TACACS+ server this
>>> corresponds to users enable#  e.g. 15 different users and passwords.
>>> 
>>> The Tacacs+ client sends among others the following AV pairs
>>> 
>>> Service = ENABLE
>>> Privilege Level = #
>>> User-name = fred
>>> User-password = fred
>>> 
>>> In the Radiator log  I can only see among others the following attributes:
>>> 
>>> Service-Type = Administrative-Login
>>> User-name = fred
>>> User-password = fred
>>> 
>>> The Service Type changes from User-Login to Administrative-Login but I
>>> can't identify the privilege level attribute ?
>>> 
>>> How can I get access to the privilege level attribute from TACACS+ ?
>>> 
>>> Thank you
>>> Markus
>>> 
>>> _______________________________________________
>>> radiator mailing list
>>> radiator at open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>> 
>> 
>> 
>> 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.





More information about the radiator mailing list