TACACS+ is now in the v4.0.x branch
I've just committed a patch to add TACACS+ to the v4.0.x branch: https://github.com/FreeRADIUS/freeradius-server/commit/6a59647304955d984f2ed... It's experimental, and works in basic tests. Minor things in the configuration are likely to change as we update v4, but the basic TACACS+ functionality should remain the same. Thanks to Alexander Clouter for doing the work. He had to read the TACACS+ proposed standard document, and figure out what it said: not much... The implementation is inter-operable with the switches we have access to, but you never now. People interested in trying the bleeding edge can now use TACACS+ in the v4 branch. Alan DeKok.
Alan DeKok wrote:
I've just committed a patch to add TACACS+ to the v4.0.x branch:
Thanks to Alexander Clouter for doing the work. He had to read the TACACS+ proposed standard document, and figure out what it said: not much...
A good addition for people stuck with legacy network hardware. 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. How does your implementation deal with that? Ciao, Michael.
On Feb 3, 2017, at 10:26 AM, Michael Ströder <michael@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.
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.
How does your implementation deal with that?
https://github.com/FreeRADIUS/freeradius-server/blob/v4.0.x/raddb/sites-avai... We let the administrator do whatever they want with the data. :) You have to write your own "unlang" policies to deal with TACACS+ attributes. There is no module which reads "standard" TACACS+ files and enforces the policies. That should be written (hint hint). The point is that the *hard* part is getting the protocol implemented. Once the attributes are in the server, it becomes a lot simpler. Alan DeKok.
Alan DeKok wrote:
On Feb 3, 2017, at 10:26 AM, Michael Ströder <michael@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.
On Feb 3, 2017, at 10:47 AM, Michael Ströder <michael@stroeder.com> wrote:
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.
This was discussed a lot on the IETF OPSAWG mailing list. The draft (all revisions) can best be described as vaguely hinting at the protocol. It in no way gives sufficient information for someone to create an inter-operable version. After many reviews, the authors don't seem to be clear on this point. The text is philosophical instead of prescriptive.
I sort of expected "man unlang". ;-)
Having a module which reads and enforces the standard TACACS+ file format would be greatly beneficial. Alan DeKok.
Hi,
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.
we use parent/child group membership - ie users are members of groups, but groups can be members of other groups. thats with shrubbery tacacs+ daemon will be interesting to try this 4.x FR as a TACACS+ server (and using unlang with AD policies) - but it would certainly be ++++ if it could read TACACS+ config files - or convert... alan
On 6 Feb 2017, at 13:58, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
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.
we use parent/child group membership - ie users are members of groups, but groups can be members of other groups. thats with shrubbery tacacs+ daemon
will be interesting to try this 4.x FR as a TACACS+ server (and using unlang with AD policies) - but it would certainly be ++++ if it could read TACACS+ config files - or convert...
What do they look like? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Michael Ströder