Service arguments value when ISE 3rd party equipment tacacs are set

[CCC3]

When setting up third-party equipment tacacs in ise
If you look at the live log details, different service arguments are imported from vendor to vendor, such as cisco is shell and juniper is junos-exec.

Does anyone have any knowledge of Cisco-provided documents or personal knowledge of other third-party equipment (Alcatel) service devices?

[Arne Bier]

Hi @CCC3 

This is a common issue I also face from time to time. I recently had to implement TACACS+ on a bunch of Riverbed equipment and I have never logged into one or knew what the various device types were used for.

Solution: I used various search engines queries to drill into vendor documentation (mostly insufficient information there) and then picked up little bits of info in community chat forums (not only Cisco's). To find a needle in a haystack, I often used the terms TACACS and avpair in the same query. 

Alcatel documentation should be pretty decent though (at least from my experience of their Omnivista and OXE PBX RADIUS stuff). Try asking the vendor for some documentation. 

[CCC3]

Thank you for your answer.

My client company uses equipment from various vendors.

So, when writing the tacacs policy, we will divide it by the service arguments value by vendor.

As a result, cisco is shell
Juniper confirmed that it comes out as junos-exec

It's hard to see how other vendors' equipment comes out.
(Altheon, F5, etc.)

I needed to check if anyone had a cisco document or knew about it.

[Arne Bier]

One great place to start is https://cs.co/ise-guides

@thomas  maintains this list and in this case there isn't a nice hash-tag short cut for what you're looking for. But. If you open that link and then search the page (cmd/ctrl-F) and search for keyword tacacs, you will find a few page hits on how to do TACACS+ on certain 3rd party devices. Your mileage may vary - e.g.

Juniper - Configure and Troubleshoot External TACACS Servers on ISE - Cisco

However, Thomas, I noticed that this link under the #Juniper section takes you to a generic TACACS article - it's probably a mistake?

It would be cool though to keep adding 3rd party vendor links in here on how their little nuances regarding RADIUS and TACACS+ 

[CCC3]

It's a really cool site.

However, I can't find any information about service instruments.

[Arne Bier]

What is "service instruments" ?

When asking a question on this community forum you must give us useful details to help us to help you. 

Each vendor can have multiple products that all behave slightly differently with TACACS+ - e.g. Alcatel is a classic case of a massive vendor with many different products. You need to tell us what the product is called, and what version of code etc.  The next thing is then to do a bunch of google searches - I can give it a stab if you give me some useful breadcrumbs to work off ...

[CCC3]

Service instruments are incorrect in translation
It is officially service-argument. If you successfully authenticate tacacs and look at the details of the live log, the service-argument will appear as in the attached picture.
It has not been confirmed whether this has a unique value for each vendor
When we tested the cisco and juniper equipment
cisco는 shell
The juniper has a value of junos-exec.

You need to verify that this value has a unique value for each vendor.

[thomas]

This is a great suggestion! I am happy to create a list of TACACS+ Service-Arguments for various vendors! I will add it to our existing ISE Device Administration Attributes document since it lists the many variables and now I can add these as values. I will also mention Service-Argument inCisco ISE Device Administration Prescriptive Deployment Guide since that is the most comprehensive guide we have for TACACS+ and reference the list in ISE Device Administration Attributes.

But since I do not have any other vendors gear for testing, we will need to community source this list starting with what has already been provided in this thread. If I need to add a column for product-specific Service-Arguments, please let me know. Please respond with other vendors and their respective Service Arguments in this thread!

Vendor	Service-Argument
Avaya	?
Brocade	?
Checkpoint	?
Cisco	shell
Juniper	junos-exec
Alcatel	?
Altheon	?
F5	?
Extreme	?
Fortinet	?
HP	?
Huawei	?
MicroTik	?
Omnivista	?
Palo Alto	?

[Arne Bier]

I think it's useful to not only provide the Service-Arguments, but also some example values. It's tricky though, due to the RBAC nature of this - each role needs to have its own specific value.

I'll list here what I know from my customers (the list is not exhaustive but it's a good starting point) - the values shown in the courier font box is the Raw Shell data that I put into an ISE TACACS Profile. Note that the "=" sign denotes that an attribute is MANDATORY. If an attribute were OPTIONAL, then the '*' character is used instead.:

F5

Big-IP LTM Admin Role

F5-LTM-User-Info-1=ADMIN_ROLE
F5-LTM-User-Console=1
F5-LTM-User-Role=0
F5-LTM-User-Partition=all

Big-IQ Admin Role

F5-BIGIQ-User-Info-01=bigiq-admin

Fortigate

admin_prof=super_admin
memberof=Fortinet_Admins

Riverbed

SteelHead/SteelFusion/SteelCentral

riverbed-roles-list=System Administrator
service=system

[CCC3]

Do you happen to know the difference between mandatory and option?

I know it's simply the difference between necessity and choice

When tested with the juniper equipment, different results came out for the two cases.

In the case of mandatory, the tacacs account connects normally
If you set it to optional, it seems to be authenticated on the live log
Actual connection failed.

[Arne Bier]

I have to admit I am also still learning the finer nuances of TACACS+, but I can tell you that in the production environment, I have seen the Fortigate stuff work well with optional.

When I login to the Fortigate, I can see the TACACS+ Authorization Log Details in ISE returning the AVPair=memberof*Fortinet_admins; AVPair=admin_prof*super_admin

And the same in the Fortigate. I didn't set this up and I don't want to set it to MANDATORY in ISE for fear of breaking something. But it would be good to know the impact and differences of doing either.

[CCC3]

When authenticating tacacs, the portigate equipment is used
Can you check how the service-argument value comes out in the live log detail?

And do you mean that you set the fortigate equipment as optional?

[Arne Bier]

Yes so in my reply to Thomas I show the example where the "=" is used - which means MANADTORY. I always assumed that in my production ISE, the Fortigate service-argument was misconfigured as "optional" because in my mind that makes no sense - there is nothing optional about it. But it works. Perhaps the Fortis are not that concerned - they just expect some hint about the role for that user.  I don't have a lab to test this with.

[CCC3]

What I was trying to make up is
Assume that each vendor has its own service-argument

When configuring the policy sets, we intended to give vendor-specific policies under those conditions.

However, if the fortigate does not have its own service-argument
I'll need to think again.

[Arne Bier]

I don't understand what you mean by "However, if the fortigate does not have its own service-argument. I'll need to think again."

The way I do it, is to create ISE Network Device Device-Types for each vendor, and sub-types for various vendor products. Then in TACACS Policy Set overall condition, I check the Device-Type == Fortigate     or another Policy Set to check Device-Type == Cisco IOS   ... etc.  When you add Network Devices (NADs) into ISE, you assign a Device-Type to them. This is how it's commonly done.