I would be cool if TACACS/TACACS+ would be supported in next ROS version. Is it planned in ROSv6/ROSv7 or not?

Isn't that a protocol that RADIUS was/is based on?

I would be cool if TACACS/TACACS+ would be supported in next ROS version. Is it planned in ROSv6/ROSv7 or not?

Why don't you just use RADIUS? I wrote a TACACS server for dial-up connections early in 1996 ... switched to RADIUS around year 2000.

Isn't that a protocol that RADIUS was/is based on?

Wow.... Bit surprised to see a MikroTik employee asking this sort of question

Snip from http://www.tacacs.net/docs/TACACS_Advantages.pdf


The primary functional difference between RADIUS and
TACACS+ is that TACACS+ separates out the Authorization
functionality, where RADIUS combines both Authentication and
Authorization. Though this may seem like a small detail, it makes
a world of difference when implementing administrator AAA in a
network environment.

RADIUS doesn’t log the
commands used by the
administrator. It will only log
the start, stop, and interim
records of that session. This
means that if there are two or
more administrators logged at
any one time, there is no way
of telling which administrator
entered which commands.
RADIUS can include privilege information in the authentication reply; however, it can only provide the
privilege level, which means different things to different vendors. Because there is no standard between
vendor implementations of RADIUS authorization, each vendor’s attributes often conflict, resulting in
inconsistent results. Even if this information were consistent, the administrator would still need to manage the
privilege level for commands on each device. This will quickly become unmanageable.
RADIUS doesn’t log the commands used by the administrator. It will only log the start, stop, and interim
records of that session. This means that if there are two or more administrators logged at any one time, there
is no way to tell from the RADIUS logs which administrator entered which commands.


TACACS+ is far better than RADIUS if you need more than a simple 'Oh yep, that user account is allowed'

Tacacs is the proper solution for network device user management.

I would very much like to have that, too.

Isn't that a protocol that RADIUS was/is based on?

Wow.... Bit surprised to see a MikroTik employee asking this sort of question

Snip from http://www.tacacs.net/docs/TACACS_Advantages.pdf


The primary functional difference between RADIUS and
TACACS+ is that TACACS+ separates out the Authorization
functionality, where RADIUS combines both Authentication and
Authorization. Though this may seem like a small detail, it makes
a world of difference when implementing administrator AAA in a
network environment.

RADIUS doesn’t log the
commands used by the
administrator. It will only log
the start, stop, and interim
records of that session. This
means that if there are two or
more administrators logged at
any one time, there is no way
of telling which administrator
entered which commands.
RADIUS can include privilege information in the authentication reply; however, it can only provide the
privilege level, which means different things to different vendors. Because there is no standard between
vendor implementations of RADIUS authorization, each vendor’s attributes often conflict, resulting in
inconsistent results. Even if this information were consistent, the administrator would still need to manage the
privilege level for commands on each device. This will quickly become unmanageable.
RADIUS doesn’t log the commands used by the administrator. It will only log the start, stop, and interim
records of that session. This means that if there are two or more administrators logged at any one time, there
is no way to tell from the RADIUS logs which administrator entered which commands.


TACACS+ is far better than RADIUS if you need more than a simple 'Oh yep, that user account is allowed'

while your whole answer is based on TACACS+ that is later creation than RADIUS. However, DIAMETER is even newer and addresses many drawbacks of RADIUS and is compatible with the RADIUS.

and on the off-note, I am sure you know what sarcasm is.

RADIUS has it's place, however, I think we can agree from a network administration perspective TACACS+ does have some nice features. One such feature is extremely granular centralized command authorization based on user permissions assigned by the server. Also, Tacacs was ported to linux, all though a bit roughly, via tac_plus. RADIUS user authentication for management purposes is nice if you want a read only or read/write access only, but is lacking when more granular control is required. Let's please keep a constructive dialog going on this issue as RADIUS and TACACS were intended for different purposes fundamentally. Sarcasm from a Mikrotik employee to mock a contributor on a valid point is childish.


+1 for TACACS support

+1 for TACACS/TACACS+ support

+1 for TACACS/TACACS+ support

+1 for tacacs+ support, I think this would make a lot of people happy.

+1 for this. Will defnitely be a big plus point for big networks.

+1 for TACACS+ support, many companies don't consider your product, if you will, "Enterprise Grade", without TACACS+ support and frankly with security being the #1 issue in the enterprise TACACS+ is needed to not only secure a multitude of devices in complex networks, but also to provide auditing trails of admin usage when those pesky auditors come around yearly/quarterly

+1 for this this request. TACACS+ also encrypts the communications channel between client and server; RADIUS does not.

I wonder if IPSec could be used to secure the RADIUS traffic between endpoints and an auth server. This would only cover the encryption side of the discussion not the feature differences.

+1 for TACACS/TACACS+ support

+1 for TACACS+ support

+ 1

+1 for TACACS+ support

I would like to see TACACS+ support as well. Being able to restrict the commands that a user can execute is incredibly important.

Especially with all of the attacks against MikroTik devices - it provides another layer of protection in addition to the firewall if a lower level user account is compromised.

+1 Tacacs

At least disable the local users if AAA is configured and reachable. TACACS would be nice, but the current radius is functional, just doesnt disable local accounts.

At least disable the local users if AAA is configured and reachable. TACACS would be nice, but the current radius is functional, just doesnt disable local accounts.

Why not just set your one local admin account to have an impossible IP address restriction, and then you've still got console-level access should your connectivity to TACACS go fubar...?

+1 for TACACS+ support.

+1 for TACACS+

+1 on tacacs+ support.

+1 for TACACS+

+1 for TACACS+ support

+1 for TACACS+ support

+1 for TACACS+ support

+1 TACACS

+1 TACACS

+1 for TACACS+ support

As long as Router OS does not log all commands run by who, I would also ask for TACACS support.

As long as Router OS does not log all commands run by who I would also ask for TACACS support.

that's why +1 for TACACS+

+1.

@normis
how about to add this feature?

+1 for TACACS+ support!
Really like being able to limit what commands a user can run (great for creating a backup user that can only run a backup command).

+1 for TACACS+ support

I have TACASCS+ configured on Linux to authenticate / restrict sessions/cmd's on various switches. It really helps the admin when managing large enterprise. Plus we are now able to satisfy the external Audit team. Would love if its support adds in the TIK

+1 for tacacs+ auth

+1 for TACACS+ on RouterOS

+1 for TACACS+ support

+1 for TACACS+ support

+1 for TACACS+ support!