[tac_plus] tacacs+ custom reply messages
heasley
heas at shrubbery.net
Tue Feb 24 00:22:23 UTC 2015
Mon, Feb 23, 2015 at 03:08:48PM -0500, Chandan Kumar:
> 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
use debugging to make sure that the daemon is sending or receiving what
you expect and that the config has a match for service or service/proto
that is in the config to be matched.
> 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]
the daemon accepts both of these configs, though i do not know of protocol
ssh. what version?
>
> 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.
> >
More information about the tac_plus
mailing list