TACACS+ is now in the v4.0.x branch

Michael Ströder michael at stroeder.com
Fri Feb 3 16:47:57 CET 2017


Alan DeKok wrote:
> On Feb 3, 2017, at 10:26 AM, Michael Ströder <michael at stroeder.com> wrote:
>>
>> A good addition for people stuck with legacy network hardware.
> 
>   The IETF is in the process of standardizing TACACS+
> 
> https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-05
> 
> Any feedback on the draft would be appreciated.  I've done multiple reviews (it's
> *horrible*), and the authors are sort of vaguely fixing it.

Haven't looked at it for a while but I vaguely remember the I-D above was just meant to
document current TACACS+ usage and not to fix the protocol's deficiencies. This scope
might have changed but I don't know.

>> What hit me in a former project integrating an LDAP user management with another
>> TACACS+ server implementation was that IIRC TACACS+ cannot handle users with
>> multiple group membership. It was one of the reasons to I wanted to be able to limit
>> user group visibility in Æ-DIR for server groups.
> 
> Yeah.  Most TACACS / RADIUS software is designed to implement TACACS+ / RADIUS.  It's
> not designed to implement custom policies.
> 
> In contrast, the bulk of the FreeRADIUS code is dealing with policies, and with gluing
> different systems together.

Similar most LDAP deployments use LDAP servers as dumb backend database while I put
policies into Æ-DIR's schema / data structures.

>> How does your implementation deal with that?
>
>   We let the administrator do whatever they want with the data. :)

I sort of expected "man unlang". ;-)

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20170203/b1950e69/attachment-0001.bin>


More information about the Freeradius-Users mailing list