[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