[tac_plus] PAP authentication in tac_plus F4.0.4.15 overrides ACL restictions
Jon Nathan
jnathan at salesforce.com
Mon Mar 1 21:21:32 UTC 2010
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
More information about the tac_plus
mailing list