[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