<div dir="ltr"><div>Holy #*@&. I'm starting to wish I had programmed inheritance on the groups. However, when I first started it, I had NO CLUE that it would ever be necessary (due to strange different tacacs implementations, NOT a failure of tac_plus). It wasn't till later that I even added the ability to change the tac_pairs. As it is right now, you'll be in group #^!!:</div>
<div><br></div><div>homer = </div><div> brocade_tier1</div><div> juniper_tier1</div><div> dell_tier1</div><div> no_name_piece_of_junk_ tier1</div><div><br></div><div>Now, kudos to Aaron for thinking of an entirely different approach. Expect to see his name on <a href="http://tacacs.org">tacacs.org</a>, (At least, I think he'd the first person - can't remember, anybody else do this?) Create a teir1.ini and define all your groups there as ONE access level. Assign them all to the default group and do all your assignments in tac_plus.conf like so:</div>
<div><br></div><div><div>default = </div><div> brocade_tier1</div><div> juniper_tier1</div><div> dell_tier1</div><div> no_name_piece_of_junk_ tier1</div></div><div><br></div><div><br></div>Then, in the tac_plus.conf file do all your user assignments, changing only the "ini" file you use in the after authentication. <div>
<br><div># example group with a bunch of seemingly random #*@& you have to do to get nexus and wlc working</div><div><div>group = tier1_access {</div><div> default service = permit</div><div> service = exec { priv-lvl = 15</div>
<div> shell:roles="network-operator"</div><div> idletime = 20 }</div><div> # The wlc will not take a return value of 2. English: those roles must exist in tac_plus.conf</div>
<div> service = ciscowlc {</div><div> role1 = MONITOR</div><div> }</div><div> after authorization "/usr/bin/python /root/do_auth.pyo -i $address -fix_crs_bug -u $user -d $name -l /root/log.txt -f /root/tier1.ini"</div>
<div>}</div></div><div><br></div><div><div>user = homer {</div><div> member = tier1_access</div><div> service = ciscowlc {</div><div> role1 = ALL</div><div> }</div><div> # optional enable password, if they insist<br>
</div><div> enable = file /etc/passwd</div><div>}</div></div><div><br></div><div>That there might be your better bet. </div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 6:41 PM, Asif Iqbal <span dir="ltr"><<a href="mailto:vadud3@gmail.com" target="_blank">vadud3@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="">On Mon, Apr 7, 2014 at 2:24 PM, Daniel Schmidt <span dir="ltr"><<a href="mailto:daniel.schmidt@wyo.gov" target="_blank">daniel.schmidt@wyo.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I see no reason why you couldn't do it with one instance with the help of do_auth. Just need to know what pairs to send to who. </div>
</blockquote><div><br></div></div><div>Please let me know if I should start a new discussion thread, but I have 13 different tac_plus</div><div>instances with 267 groups and 11969 user = foo {..} entries.</div><div><br></div>
<div>
So any user could be on any of those groups as long as no one user in multiple groups on any</div><div>of the 13 instances.</div><div><br></div><div>I would love to see if I can consolidate all two one instance. </div><div>
<br></div><div>It will probably also help adding a user using a script to multiple groups. Currently doing</div><div>tons of awk magics to keep the {} pairs in track while adding new users on multiple instances</div><div>
into multiple groups. </div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
<div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 6, 2014 at 1:16 PM, Asif Iqbal <span dir="ltr"><<a href="mailto:vadud3@gmail.com" target="_blank">vadud3@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div>On Sun, Apr 6, 2014 at 2:53 PM, Daniel Schmidt <span dir="ltr"><<a href="mailto:daniel.schmidt@wyo.gov" target="_blank">daniel.schmidt@wyo.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
On a side note, while thanking Alan for his assisting while I was out, I<br>
have to also smile at a bit of irony in that the one person who was wary<br>
and wouldn't touch do_auth is now helping people with it. :-P Thanks Alan!<br></blockquote><div><br></div></div><div>Another offtopic comment, but we manage about 8 different tac_plus instances</div><div>on different IP/PORT combination. And command authorizations are different,</div>
<div>at least between cisco and juniper. We also have arista, alcatel and others.</div><div><br></div><div>I should give the do_auth a try, not sure how different command authorization</div><div>syntax can be consolidated?</div>
<div><br></div><div>Sorry about injecting offtopic conversation here.</div><span><font color="#888888"><div><br></div></font></span></div><span><font color="#888888"><div><br></div>-- <br>Asif Iqbal<br>
PGP Key: 0xE62693C5 KeyServer: <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a><br>A: Because it messes up the order in which people normally read text.<br>
Q: Why is top-posting such a bad thing?<br><br>
</font></span></div></div>
</blockquote></div><br></div>
</div></div></div><div class=""><div><div><pre>E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.
</pre></div></div></div></blockquote></div><br><br clear="all"><div class=""><div><br></div>-- <br>Asif Iqbal<br>PGP Key: 0xE62693C5 KeyServer: <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a><br>A: Because it messes up the order in which people normally read text.<br>
Q: Why is top-posting such a bad thing?<br><br>
</div></div></div>
</blockquote></div><br></div>
<pre>
E-Mail to and from me, in connection with the transaction
of public business, is subject to the Wyoming Public Records
Act and may be disclosed to third parties.