[tac_plus] Re: PAP authentication in tac_plus F4.0.4.15 overrides ACL restictions

Jon Nathan jnathan at salesforce.com
Tue Mar 2 14:52:59 UTC 2010


Thanks Jathan.  Is there any way then to do ACLs or something similar for
authorization?  Or something more clever I could do in my group definition
that would prevent them from doing anything after they logged in to a denied
host?

-Jon


On 3/2/10 9:17 AM, "jathan." <jathan at gmail.com> wrote:

> Hey Jon-
> 
> From what I know of using the ACL feature is that it is an
> authorization action (i.e. when exec is launched on the device), not
> authentication.  So if you look a little closer it is performing
> properly by disallowing authorization to occur on the deny match.
> 
> If I am wrong, please send all threats to /dev/null.
> 
> On Mon, Mar 1, 2010 at 1:21 PM, Jon Nathan <jnathan at salesforce.com> wrote:
>> Hello,
>> 
>> We use tac_plus F4.0.4.15 to manage authentication for our network switches.
>> Our Cisco MDS (San-OS/NX-OS) switches can only use PAP or MSCHAP to
>> authenticate, so we were able to accommodate this by adding pap lines to
>> each user who required access to these switches as follows:
>> 
>> user = jon {
>>        login = PAM
>>        pap = des xxx/jE
>>        member = saneng
>> }
>> 
>> We wanted to restrict some users to certain Cisco MDS switches, so we built
>> an acl as follows:
>> 
>> acl = backups_acl {
>>        permit = ^10.22(6|8).13.(20|21)$
>>        permit = ^10.225.10.(98|99)$
>>        permit = ^10.231.(10|11).18$
>>        deny = .*
>> }
>> 
>> Where the IPs above correspond to the allowed switches.  However, when we
>> set a user to a group that used this acl as follows:
>> 
>> user = jon {
>>        login = PAM
>>        pap = des xxx/jE
>>        member = saneng_backups
>> }
>> 
>> group = saneng_backups {
>>        default service = permit
>>        acl = backups_acl
>>        service = exec {
>>                priv-lvl = 15
>>                cisco-av-pair = "shell:roles=network-admin vsan-admin"
>>        }
>> }
>> 
>> We were able to log into the explicitly permitted switches, and all other
>> Cisco MDS switches that were not permitted.  It looks like tac_plus accepts
>> the pap authentication before trying to confirm against the ACL.  Here are
>> log snippets from -d 24:
>> 
>> Logging into a host not permitted by the acl:
>> 
>> 
>> Mon Mar  1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17
>> Mon Mar  1 21:04:38 2010 [12259]: connect from 10.228.13.17 [10.228.13.17]
>> Mon Mar  1 21:04:38 2010 [12259]: pap-login query for 'jon' 0 from
>> 10.228.13.17 accepted
>> Mon Mar  1 21:04:38 2010 [11255]: session.peerip is 10.228.13.17
>> Mon Mar  1 21:04:38 2010 [12263]: connect from 10.228.13.17 [10.228.13.17]
>> Mon Mar  1 21:04:38 2010 [12263]: Start authorization request
>> Mon Mar  1 21:04:38 2010 [12263]: cfg_acl_check(backups_acl, 10.228.13.17)
>> Mon Mar  1 21:04:38 2010 [12263]: ip 10.228.13.17 matched deny regex .* of
>> acl filter backups_acl
>> Mon Mar  1 21:04:38 2010 [12263]: authorization query for 'jon' 0 from
>> 10.228.13.17 rejected
>> 
>> Logging into a a host permitted by the acl:
>> 
>> Mon Mar  1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17
>> Mon Mar  1 21:06:03 2010 [14202]: connect from 10.228.13.17 [10.228.13.17]
>> Mon Mar  1 21:06:03 2010 [14202]: pap-login query for 'jon' 0 from
>> 10.228.13.17 accepted
>> Mon Mar  1 21:06:03 2010 [14200]: session.peerip is 10.228.13.17
>> Mon Mar  1 21:06:03 2010 [14203]: connect from 10.228.13.17 [10.228.13.17]
>> Mon Mar  1 21:06:03 2010 [14203]: Start authorization request
>> Mon Mar  1 21:06:03 2010 [14203]: do_author: user='jon'
>> Mon Mar  1 21:06:03 2010 [14203]: user 'jon' found
>> Mon Mar  1 21:06:03 2010 [14203]: exec authorization request for jon
>> Mon Mar  1 21:06:03 2010 [14203]: exec is explicitly permitted by line 290
>> Mon Mar  1 21:06:03 2010 [14203]: nas:service=shell (passed thru)
>> Mon Mar  1 21:06:03 2010 [14203]: nas:cmd= (passed thru)
>> Mon Mar  1 21:06:03 2010 [14203]: nas:cisco-av-pair*
>> svr:cisco-av-pair=shell:roles=network-admin vsan-admin -> replace with
>> cisco-av-pair=shell:roles=network-admin vsan-admin (f)
>> Mon Mar  1 21:06:03 2010 [14203]: nas:shell:roles* svr:absent/deny -> delete
>> shell:roles* (i)
>> Mon Mar  1 21:06:03 2010 [14203]: nas:absent, server:priv-lvl=15 -> add
>> priv-lvl=15 (k)
>> Mon Mar  1 21:06:03 2010 [14203]: replaced 2 args
>> Mon Mar  1 21:06:03 2010 [14203]: authorization query for 'jon' 0 from
>> 10.228.13.17 accepted
>> 
>> 
>> It looks like a bug in tac_plus.  Tac_plus is accepting the user's login
>> before confirming with the ACL that he is logging into a permitted host.
>> What do you think?
>> 
>> Thanks,
>> Jon Nathan
>> Salesforce.com
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> tac_plus mailing list
>> tac_plus at shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>> 
> 
> 
> 
> --
> Jathan.
> -



More information about the tac_plus mailing list