From both a network and a security point of view, TACACS+ is
considered preferable to RADIUS; among other benefits, it enciphers
the entire conversation, rather than just portions of it, and can
provide more fine-grain authorization than RADIUS. Most Cisco shops
I've encountered consider RADIUS to be an unacceptable solution for
AAA. Cisco considers use of TACACS+ a best practice for AAA.
What I am looking for is a device on the network which provides AAA
facilities to network infrastructure devices, and which allows
provisioning of network infrastructure credentials through the same
interface and at the same time as systems credentials, and which keeps
those credentials synchronized.
O.K. fair enough. However TACACS is not on our roadmap. If you can
demonstrate strong need by enterprise customers for TACACS it would be
taken into consideration for a future version of the product.
The more practical solution which may be available to you would be to
avail yourself of the PAM integration in the tac_plus project (but to
be honest I don't see how that would give you any of the sophisticated
features you cite as being a prime motivator for utilization of
TACACS). FreeIPA is an open source project and from what you say so is
tac_plus. I would imagine patches would be welcomed by both projects
which would allow the tac_plus daemon to utilize IPA as it's back end.
We would be happy to answer any questions for the person(s) who wanted
to undertake this and contribute their work.
From what I can see it looks like the missing piece would be the
ability to look up tac_plus user->group assignments from the FreeIPA/389
LDAP server. It looks like tac_plus has ""integrated"" the
authentication with LDAP via PAM, but not the authorization. When
building an authentication solution for network devices with FreeIPA,
providing authentication via TACACS+ would be secondary, since you could
have your Cisco device directly authenticate the user against FreeIPA
using Kerberos. TACACS+ primary benefit is in the granular control of
Authorization to network device services. If you can get tac_plus to
reference an LDAP server for group membership, then you might have a
reasonable solution. You would still need to assign the group's network
permissions in the tac_plus configuration file, but that would be done
once. Once the group access was defined, you could assign LDAP users to
groups that match what's in the tac_plus config file.
This really requires the tac_plus team to code direct LDAP integration
into their application similar to the way Freeradius can rely on an LDAP
server as a back-end. The local PAM stack was not really intended to be
a service that can be farmed out for other systems to use. It was meant
as a way to provide access to local services running on that system. To
use PAM for group membership (I.E. through the pam_listfile ACL) would
require a separate tac_plus daemon and PAM configuration for each
network device.
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
