[tac_plus] tacacs+ custom reply messages

[heasley]

Mon, Feb 23, 2015 at 11:42:04AM -0500, Chandan Kumar:
> Hi Heasley,
> 
> Thanks for your response. Basically I am not able to get a working example
> of how to use those AVPs in tac_plus.conf. Whatever I have used so far,
> they appear to have no impact on the server at all. [the basic
> authentication using file /etc/passwd is working though].

I'm fairly sure that IOS supports the syntax below to change the username
prompt, but the device is not required to honor it, it is optional according
to the spec and is not applicable in all contexts.  the daemon sets a default
if one isnt in the config, default_v0_fn.c:default_v0_fn().

> While googling I mostly get examples of how to configure CISCO device
> [client side] and very limited configuration examples associated with
> server configuration other than the file that is packaged with the tac_plus
> source code itself.
> 
> Example 1:
> 
> I want to send a prompt message to host connecting from 192.168.2.53
> 
> 
> default authentication = file /etc/passwd
> 
> host = 192.168.2.53 {
>     prompt = "Welcome\n"
>   }
> 
> Now when I login, I do not see any "welcome" attched in the reply message
> in wireshark. I only see
> 
> Status: 0x1 (Authetication Passed)

it would occur before this; in the GETUSER packet.

> Flags : 0x0
> Server message length : 0
> Data Lengh :0
> 
> I would appreciate if you could provide a working example of tac_plus.conf
> with some AVPs either at authentication or at authorization phase.

see priv-lvl, autocmd, inacl, and outacl in the sample config.

> I would appreciate any help in this regard.
> 
> 
> Thanks
> Chandan
> 
> PS: In RADIUS it is very simple to send a reply with auth example:
> 
> joe     Cleartext-Password := "1234"
>         Reply-Message := "Welcom"
> 
> On auth success, the server sends this welcom string, which could be used
> by the client side to provide additional functionality. [I agree it is not
> the best way to do, this example is only for illustration purpose]

technically it is possible, afaict, to send any message back, but the daemon
does not offer this.  it sends actualy status messages, like "failed",
"succees", etc; for the daemon to provide this from the config it would need
to differentiate between all those.