<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>TACACS+ stuff &#187; Cisco</title>
	<atom:link href="http://tacacs.org/category/cisco/feed/" rel="self" type="application/rss+xml" />
	<link>http://tacacs.org</link>
	<description>Casting Light on the Dark Art of TACACS+</description>
	<lastBuildDate>Thu, 27 Oct 2011 21:04:07 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>do_auth &amp; IOS-XR</title>
		<link>http://tacacs.org/2009/11/09/do_auth-ios-xr/</link>
		<comments>http://tacacs.org/2009/11/09/do_auth-ios-xr/#comments</comments>
		<pubDate>Mon, 09 Nov 2009 19:56:27 +0000</pubDate>
		<dc:creator>helpdeskdan</dc:creator>
				<category><![CDATA[Cisco]]></category>

		<guid isPermaLink="false">http://blogs.sackheads.org/tacacsplus/2009/11/09/do_auth-ios-xr/</guid>
		<description><![CDATA[ios-xr bug: sends blank ip in conf t.  tac_plus really should send an &#8220;unknown&#8221; for this.  I&#8217;d submit a patch, but I&#8217;m no good at C.  job == networker, job != programmer.  Heasley strongly disagrees with me on this though.  Even though I&#8217;m obviously right, I suppose someday I&#8217;ll have [...]]]></description>
			<content:encoded><![CDATA[<p>ios-xr bug: sends blank ip in conf t.  tac_plus really should send an &#8220;unknown&#8221; for this.  I&#8217;d submit a patch, but I&#8217;m no good at C.  job == networker, job != programmer.  Heasley strongly disagrees with me on this though.  Even though I&#8217;m obviously right, I suppose someday I&#8217;ll have fix the parsing to ignore any options not sent.  <img src='http://tacacs.org/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />   Till then:</p>

<p>v1.4:
(Removed)</p>

<p>Simple workaround: <strong>-i $address -fix<em>crs</em>bug</strong>.  I advise you use it even if you don&#8217;t use ios-xr.</p>

<p>Version 1.5 Feb 28 2011
Corrected a stupid mistake in the example.  (python do_auth.py | less)  Thanks to aojea.
v1.5
(Also removed &#8211; scroll up for latest version)</p>

<p>Note: I haven&#8217;t done any work on this because, to the best of my knowledge, I&#8217;m the only one who uses it.  If you find it useful, write a quick post!</p>
]]></content:encoded>
			<wfw:commentRss>http://tacacs.org/2009/11/09/do_auth-ios-xr/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Granular Tacacs Control (Yes, you can do multiple groups)</title>
		<link>http://tacacs.org/2009/05/08/granular-tacacs-control/</link>
		<comments>http://tacacs.org/2009/05/08/granular-tacacs-control/#comments</comments>
		<pubDate>Fri, 08 May 2009 23:17:45 +0000</pubDate>
		<dc:creator>helpdeskdan</dc:creator>
				<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Uncategorized]]></category>

		<guid isPermaLink="false">http://blogs.sackheads.org/tacacsplus/?p=34</guid>
		<description><![CDATA[By using an authorization script, we can make tacplus to do very granular authentication, having different permissions granted to different switches defined by user, source IP and device IP.  However, writing/editing a script to change access can be difficult.  Hard coded authorization scripts are not very flexible, hence, I decided to implement a python program [...]]]></description>
			<content:encoded><![CDATA[<p>By using an authorization script, we can make tac<em>plus to do very granular authentication, having different permissions granted to different switches defined by user, source IP and device IP.  However, writing/editing a script to change access can be difficult.  Hard coded authorization scripts are not very flexible, hence, I decided to implement a python program to facilitate flexibility.  It is now included in the tac</em>plus package.</p>

<p>Configuration is fairly simple; as an example, let&#8217;s say I wanted to have user Homer have full access to 192.168.1.1 and 10.1.1.0/24, but only do show commands for everything else in 10.0.0.0/8.  For the heck of it, let&#8217;s say we only want Homer to connect from 192.168.1.0/24, but never 192.168.1.4, which host can only do the show commands.   The config file would simply be as follows:</p>

<p><code>[users]<br />
homer =<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;simpson<em>group<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;television</em>group<br />
[simpson<em>group]<br /> 
host</em>deny =<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192.168.1.4<br />
host<em>allow =<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192.168.1.*<br />
device</em>permit =<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192.168.1.1<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;10.1.1.* <br />
command<em>permit = <br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;.* <br />
[television</em>group] <br />
host<em>allow = <br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;192.168.1.* <br />
device</em>permit = <br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;10.* <br />
command_permit = <br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;show.*</code> <br /></p>

<p>Example line to put in tac<em>plus user or group:
after authorization &#8220;/usr/bin/python /root/do</em>auth.pyc -i $address -u $user -d $name -l /root/log.txt -f /root/do_auth.ini&#8221;
(that&#8217;s all ONE line)</p>

<p>On my server, I set homer&#8217;s password file to /etc/passwd and enable cracklib.  Homer can change his password any time he wants just by logging to Linux and typing passwd – he does not need root access.  Homer is also forced to pick a secure password, and has different access based on different devices.  Given these abilities, combined with the quick administration, tac_plus makes purchasing Cisco&#8217;s tacacs server seem like a waste of money.</p>

<p>In the future, I may alter the program to have the ability to send back additional av-pairs, and/or completely new av-pairs.   However, currently I simply don&#8217;t need this feature as I pass these pairs back to tac<em>plus.  The source code is very simple and is GPL&#8217;ed for all to see at: <a href="http://pastie.org/506002">http://pastie.org/506002</a> and is available in compiled/ready to use form <a href="http://tacacs.org/files/2009/05/do_auth.pyc">here</a>.   For more instructions, you can download this compiled pyc and type “python do</em>auth.pyc” If I ever get time, I may consider a gui or web interface.</p>

<p>Update: New version 1.2
Fixed pix.  Also, apparently there is a bug in the pix that makes it necessary to add a 0.0.0.0 to your allowed hosts.</p>

<p>-Dan Schmidt</p>
]]></content:encoded>
			<wfw:commentRss>http://tacacs.org/2009/05/08/granular-tacacs-control/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Cisco Wireless Control System</title>
		<link>http://tacacs.org/2008/11/04/cisco-wireless-control-system/</link>
		<comments>http://tacacs.org/2008/11/04/cisco-wireless-control-system/#comments</comments>
		<pubDate>Tue, 04 Nov 2008 18:55:27 +0000</pubDate>
		<dc:creator>jpayne</dc:creator>
				<category><![CDATA[Cisco]]></category>
		<category><![CDATA[WCS]]></category>
		<category><![CDATA[Cisco WCS WLC Wireless Control System]]></category>

		<guid isPermaLink="false">http://blogs.sackheads.org/tacacsplus/?p=23</guid>
		<description><![CDATA[Guy Morrell at the University of Oxford provides this snippet for Cisco WCS

 

service = ciscowlc {
role1 = ALL
}





]]></description>
			<content:encoded><![CDATA[<p>Guy Morrell at the University of Oxford provides this snippet for Cisco WCS</p>

<p> 
<pre>
service = ciscowlc {
role1 = ALL
}
</pre></p>

<p><script type="text/javascript"><!--
google_ad_client = "pub-1306007144790764";
google_ad_slot = "1983414114";
google_ad_width = 468;
google_ad_height = 60;
//--></script>
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>
</p>
]]></content:encoded>
			<wfw:commentRss>http://tacacs.org/2008/11/04/cisco-wireless-control-system/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Managing Cisco ACE (Application Control Engine) modules with TACACS+</title>
		<link>http://tacacs.org/2008/10/16/managing-cisco-ace-application-control-engine-modules-with-tacacs/</link>
		<comments>http://tacacs.org/2008/10/16/managing-cisco-ace-application-control-engine-modules-with-tacacs/#comments</comments>
		<pubDate>Thu, 16 Oct 2008 16:07:05 +0000</pubDate>
		<dc:creator>jpayne</dc:creator>
				<category><![CDATA[ACE]]></category>
		<category><![CDATA[Cisco]]></category>
		<category><![CDATA[Application Control Engine]]></category>

		<guid isPermaLink="false">http://blogs.sackheads.org/jpayne/?p=33</guid>
		<description><![CDATA[This snippet is tested against &#8220;recent&#8221; Shrubbery tac_plus daemons as of the date of the post.
Searching for ACE and TACACS or similar gets confusing because of the RSA ACE server.  Good job Cisco<br />
Cisco Application Control Engine modules are really separate devices from the &#8220;mother&#8221; switch, only suckling power and connectivity.  These devices need [...]]]></description>
			<content:encoded><![CDATA[<div>

This snippet is tested against “recent” Shrubbery tac_plus daemons as of the date of the post.

Searching for ACE and TACACS or similar gets confusing because of the RSA ACE server.  Good job Cisco <img class="wp-smiley" src="http://blogs.sackheads.org/jpayne/wp-includes/images/smilies/icon_smile.gif" alt=")" />

Cisco Application Control Engine modules are really separate devices from the “mother” switch, only suckling power and connectivity.  These devices need their own authentication schemes.  It’s pretty easy to turn on TACACS+ authentication and accounting (no authorization again.  Why do vendors insist on only doing 1 or 2 As and not 3?).

ACE modules needs a specific <strong>optional </strong>av-pair in the “exec” service in TACACS+ to authenticate. You can put this in a group or user stanza:
<pre>service = exec {
optional shell:Admin = "Admin default-domain"
}</pre>
The format is: shell:&lt;Context&gt; = “&lt;Role&gt; &lt;domain&gt;”

I’m not all that into ACE modules yet, so I’ll assume that the reader knows what each of those should be set to in their environment.  For us, we simply want the equivalent of priv-lvl = 15, and that’s what we get above.

Note that without that av-pair, the defaults come through as Admin context, default-domain and “Network-Monitoring” role.

Also note that excluding the “optional” keyword will render you unable to log in to any IOS devices that use your TACACS+ server for authorization.

[ad#footer]</div>]]></content:encoded>
			<wfw:commentRss>http://tacacs.org/2008/10/16/managing-cisco-ace-application-control-engine-modules-with-tacacs/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

