topic Re: Service arguments value when ISE 3rd party equipment tacacs are se in Network Access Control

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

CCC3 — Mon, 15 Jan 2024 06:34:48 GMT

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?

Re: Service arguments value when ISE 3rd party equipment tacacs are se

Arne Bier — Tue, 16 Jan 2024 20:37:16 GMT

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.

Re: Service arguments value when ISE 3rd party equipment tacacs are se

CCC3 — Wed, 17 Jan 2024 02:50:15 GMT

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.

Re: Service arguments value when ISE 3rd party equipment tacacs are se

Arne Bier — Wed, 17 Jan 2024 03:33:16 GMT

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+

Re: Service arguments value when ISE 3rd party equipment tacacs are se

CCC3 — Wed, 17 Jan 2024 04:31:54 GMT

It's a really cool site.

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

Re: Service arguments value when ISE 3rd party equipment tacacs are se

Arne Bier — Wed, 17 Jan 2024 06:00:13 GMT

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 ...

Re: Service arguments value when ISE 3rd party equipment tacacs are se

CCC3 — Wed, 17 Jan 2024 06:16:18 GMT

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.

Re: Service arguments value when ISE 3rd party equipment tacacs are se

thomas — Wed, 17 Jan 2024 14:45:51 GMT

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 in 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	?

Re: Service arguments value when ISE 3rd party equipment tacacs are se

Arne Bier — Wed, 17 Jan 2024 23:58:35 GMT

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

Re: Service arguments value when ISE 3rd party equipment tacacs are se

CCC3 — Thu, 18 Jan 2024 00:10:46 GMT

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.

Re: Service arguments value when ISE 3rd party equipment tacacs are se

Arne Bier — Thu, 18 Jan 2024 02:55:38 GMT

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.

Re: Service arguments value when ISE 3rd party equipment tacacs are se

CCC3 — Thu, 18 Jan 2024 04:04:44 GMT

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?

Re: Service arguments value when ISE 3rd party equipment tacacs are se

Arne Bier — Thu, 18 Jan 2024 04:08:33 GMT

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.

Re: Service arguments value when ISE 3rd party equipment tacacs are se

CCC3 — Thu, 18 Jan 2024 04:28:14 GMT

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.

Re: Service arguments value when ISE 3rd party equipment tacacs are se

Arne Bier — Thu, 18 Jan 2024 05:07:47 GMT

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.

Re: Service arguments value when ISE 3rd party equipment tacacs are se

CCC3 — Thu, 18 Jan 2024 05:13:31 GMT

I know it's effective to use the device type
but It is difficult to determine the device list currently in use.

Therefore, we will probably proceed with default device.
That's why I didn't mention the device type.

Re: Service arguments value when ISE 3rd party equipment tacacs are se

thomas — Fri, 19 Jan 2024 16:16:48 GMT

@Arne Bier , I'm confused now.

Is each line you show a unique Service-Argument value depending on the vendor + product + role ?

I can put each of these in my table for Service-Arguments directly?

Re: Service arguments value when ISE 3rd party equipment tacacs are se

Arne Bier — Sat, 20 Jan 2024 02:42:07 GMT

Those are examples from working solutions after much digging around the internet - unlike TACACS+ on IOS/IOS-XE, other vendor products have their own nuances. Most vendors only publish how to configure their systems to talk to a TACACS+ server - but 95% of the time they don't tell you what attributes the TACACS+ server should return. If you're lucky, you'll see some references to how Vendor X implemented TACACS+ on some ancient Cisco ACS system, or FreeRADIUS and then translate that into ISE.

I find that even a few keywords such as the ones I published, might be a good start for others to search for more details. I remember searching high and low for the F5 stuff.

Re: Service arguments value when ISE 3rd party equipment tacacs are se

CCC3 — Wed, 24 Jan 2024 05:49:31 GMT

Hello.

The fortinet, f5, and Riverbed in the ISE Device Administration attributes seem to be the tacacs profile custom attribute value for the tacacs setting of the third party equipment on the rise, not the service argument.