[tac_plus] tacacs+ custom reply messages

Chandan Kumar chandank.kumar at gmail.com
Mon Feb 23 20:08:48 UTC 2015


Thanks for the input.

I am not using IOS, I am using/customizing pam_tacplus.so Linux module.

I am trying to set AVP in service=shell, but I am not able to get it right.

user = joe {
        pap = cleartext 123
        service = shell {
                default attribute = permit
                priv-lvl = 15
        }

And from client I am sending service=shell protocol=ssh. However, the
server [tacplus daemon ] is not able to find these AVPs and returning error.


Mon Feb 23 15:03:04 2015 [17466]: Start authorization request
Mon Feb 23 15:03:04 2015 [17466]: cfg_get_value: name=joe isuser=1 attr=acl
rec=1
Mon Feb 23 15:03:04 2015 [17466]: cfg_get_pvalue: returns NULL
Mon Feb 23 15:03:04 2015 [17466]: do_author: user='joe'
Mon Feb 23 15:03:04 2015 [17466]: cfg_get_value: name=joe isuser=1
attr=before rec=1
Mon Feb 23 15:03:04 2015 [17466]: cfg_get_pvalue: returns NULL
Mon Feb 23 15:03:04 2015 [17466]: user joe No identifiable service/protocol
in authorization request
Mon Feb 23 15:03:04 2015 [17466]: Writing AUTHOR/ERROR size=75

What is the right format for using service=shell? It does not accept the
service=shell protocol=ssh, it returns error

Starting tacacs+: Error: expecting '{' but found 'protocol' on line 19
                                                           [FAILED]


However, it works well for service= ppp protocol =ssh

user = joe {
        pap = cleartext 123
        service = ppp protocol = ssh {
               tunnel-id = my_nas
               ip-addresses = "173.20.12.19 173.20.12.20"
               source-ip = 173.5.10.1
        }
}

This is accepted by the tacplu daemon. If I send service=ppp, protocol=ssh
from the client.




--
http://about.me/chandank

On Mon, Feb 23, 2015 at 1:49 PM, heasley <heas at shrubbery.net> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20150223/06b7dee5/attachment.html>


More information about the tac_plus mailing list