<div dir="ltr"><div><div><div>Version info:<br><br>tac_plus -v<br>tac_plus version F4.0.4.28<br>ACLS<br>FIONBIO<br>LIBWRAP<br>LINUX<br>LITTLE_ENDIAN<br>LOG_DAEMON<br>PAM<br>NO_PWAGE<br>REAPCHILD<br>RETSIGTYPE RETSIGTYPE<br>SHADOW_PASSWORDS<br>SIGTSTP<br>SIGTTIN<br>SIGTTOU<br>SO_REUSEADDR<br>STRERROR<br>TAC_PLUS_PORT<br>UENABLE<br>__STDC__<br><br></div><br></div>I tried using other service option including service=system, and it is working. but service=shell protocol=ssh does not.<br><br> service = system  {<br>                default attribute = permit<br>                priv-lvl = 15<br>        }<br></div><br><br><div><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><br><div>--</div><div><a href="http://about.me/chandank" target="_blank">http://about.me/chandank</a><br></div></div></div>
<br><div class="gmail_quote">On Mon, Feb 23, 2015 at 7:22 PM, heasley <span dir="ltr"><<a href="mailto:heas@shrubbery.net" target="_blank">heas@shrubbery.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mon, Feb 23, 2015 at 03:08:48PM -0500, Chandan Kumar:<br>
<span class="">> Thanks for the input.<br>
><br>
> I am not using IOS, I am using/customizing pam_tacplus.so Linux module.<br>
><br>
> I am trying to set AVP in service=shell, but I am not able to get it right.<br>
><br>
> user = joe {<br>
>         pap = cleartext 123<br>
>         service = shell {<br>
>                 default attribute = permit<br>
>                 priv-lvl = 15<br>
>         }<br>
><br>
> And from client I am sending service=shell protocol=ssh. However, the<br>
> server [tacplus daemon ] is not able to find these AVPs and returning error.<br>
><br>
><br>
> Mon Feb 23 15:03:04 2015 [17466]: Start authorization request<br>
> Mon Feb 23 15:03:04 2015 [17466]: cfg_get_value: name=joe isuser=1 attr=acl<br>
> rec=1<br>
> Mon Feb 23 15:03:04 2015 [17466]: cfg_get_pvalue: returns NULL<br>
> Mon Feb 23 15:03:04 2015 [17466]: do_author: user='joe'<br>
> Mon Feb 23 15:03:04 2015 [17466]: cfg_get_value: name=joe isuser=1<br>
> attr=before rec=1<br>
> Mon Feb 23 15:03:04 2015 [17466]: cfg_get_pvalue: returns NULL<br>
> Mon Feb 23 15:03:04 2015 [17466]: user joe No identifiable service/protocol<br>
> in authorization request<br>
> Mon Feb 23 15:03:04 2015 [17466]: Writing AUTHOR/ERROR size=75<br>
<br>
</span>use debugging to make sure that the daemon is sending or receiving what<br>
you expect and that the config has a match for service or service/proto<br>
that is in the config to be matched.<br>
<span class=""><br>
> What is the right format for using service=shell? It does not accept the<br>
> service=shell protocol=ssh, it returns error<br>
><br>
> Starting tacacs+: Error: expecting '{' but found 'protocol' on line 19<br>
>                                                            [FAILED]<br>
<br>
</span>the daemon accepts both of these configs, though i do not know of protocol<br>
ssh.  what version?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> However, it works well for service= ppp protocol =ssh<br>
><br>
> user = joe {<br>
>         pap = cleartext 123<br>
>         service = ppp protocol = ssh {<br>
>                tunnel-id = my_nas<br>
>                ip-addresses = "173.20.12.19 173.20.12.20"<br>
>                source-ip = 173.5.10.1<br>
>         }<br>
> }<br>
><br>
> This is accepted by the tacplu daemon. If I send service=ppp, protocol=ssh<br>
> from the client.<br>
><br>
><br>
><br>
><br>
> --<br>
> <a href="http://about.me/chandank" target="_blank">http://about.me/chandank</a><br>
><br>
> On Mon, Feb 23, 2015 at 1:49 PM, heasley <<a href="mailto:heas@shrubbery.net">heas@shrubbery.net</a>> wrote:<br>
><br>
> > Mon, Feb 23, 2015 at 11:42:04AM -0500, Chandan Kumar:<br>
> > > Hi Heasley,<br>
> > ><br>
> > > Thanks for your response. Basically I am not able to get a working<br>
> > example<br>
> > > of how to use those AVPs in tac_plus.conf. Whatever I have used so far,<br>
> > > they appear to have no impact on the server at all. [the basic<br>
> > > authentication using file /etc/passwd is working though].<br>
> ><br>
> > I'm fairly sure that IOS supports the syntax below to change the username<br>
> > prompt, but the device is not required to honor it, it is optional<br>
> > according<br>
> > to the spec and is not applicable in all contexts.  the daemon sets a<br>
> > default<br>
> > if one isnt in the config, default_v0_fn.c:default_v0_fn().<br>
> ><br>
> > > While googling I mostly get examples of how to configure CISCO device<br>
> > > [client side] and very limited configuration examples associated with<br>
> > > server configuration other than the file that is packaged with the<br>
> > tac_plus<br>
> > > source code itself.<br>
> > ><br>
> > > Example 1:<br>
> > ><br>
> > > I want to send a prompt message to host connecting from 192.168.2.53<br>
> > ><br>
> > ><br>
> > > default authentication = file /etc/passwd<br>
> > ><br>
> > > host = 192.168.2.53 {<br>
> > >     prompt = "Welcome\n"<br>
> > >   }<br>
> > ><br>
> > > Now when I login, I do not see any "welcome" attched in the reply message<br>
> > > in wireshark. I only see<br>
> > ><br>
> > > Status: 0x1 (Authetication Passed)<br>
> ><br>
> > it would occur before this; in the GETUSER packet.<br>
> ><br>
> > > Flags : 0x0<br>
> > > Server message length : 0<br>
> > > Data Lengh :0<br>
> > ><br>
> > > I would appreciate if you could provide a working example of<br>
> > tac_plus.conf<br>
> > > with some AVPs either at authentication or at authorization phase.<br>
> ><br>
> > see priv-lvl, autocmd, inacl, and outacl in the sample config.<br>
> ><br>
> > > I would appreciate any help in this regard.<br>
> > ><br>
> > ><br>
> > > Thanks<br>
> > > Chandan<br>
> > ><br>
> > > PS: In RADIUS it is very simple to send a reply with auth example:<br>
> > ><br>
> > > joe     Cleartext-Password := "1234"<br>
> > >         Reply-Message := "Welcom"<br>
> > ><br>
> > > On auth success, the server sends this welcom string, which could be used<br>
> > > by the client side to provide additional functionality. [I agree it is<br>
> > not<br>
> > > the best way to do, this example is only for illustration purpose]<br>
> ><br>
> > technically it is possible, afaict, to send any message back, but the<br>
> > daemon<br>
> > does not offer this.  it sends actualy status messages, like "failed",<br>
> > "succees", etc; for the daemon to provide this from the config it would<br>
> > need<br>
> > to differentiate between all those.<br>
> ><br>
</div></div></blockquote></div><br></div>