James Roman wrote:
>>>  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.

I generally agree with John and James. Just want to add a bit about the
roadmap and plans. With the open source whatever makes sense and is
needed gets implemented. The TACACS support is not on the roadmap  now
but it can be if there is a real need in the community. There is no need
to make it fully integrated day one. It can be a gradual process.

The first step would be to set up TACACS server and use IPA for
authentication via PAM proxy on the TACACS server or via PAM auth on the
device itself.
The full integration would be for the TACACS server to read all its
identity and  configuration information from LDAP . It will take time
and a lot of effort for this to happen.
There are gradual interim solutions in between. If someone wants to
drive it with the TACACS community we are all open to assist and guide
on the IPA/SSSD side.

Regarding the groups mentioned above. I am not familiar with the TACACS
code but I would assume that it uses the libc functions to get user and
group entries. If this is the case than nsswitch can be configured to
use identities provided by IPA via nss_ldap or better via SSSD. So the
identities and authentication would come from the same identity server.
The TACACS server will still hold the policies but those can be moved to
LDAP back end gradually with collaboration with the TACACS community if
there is more need than the basic integration described here can provide.


> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-users mailing list

Reply via email to