Wired Intelligent Edge

Hello,

 

Did anyone get tacacs authentication and authorization working in Clearpass for the ArubaOS-CX switches?

 

I setup clearpass and configured the switch as follows:

tacacs-server host 10.13.111.19 vrf default
aaa group server tacacs clearpass
server 10.13.111.19 vrf default

tacacs-server key plaintext mypasskey123
tacacs-server auth-type chap

aaa authentication login default group clearpass local

aaa authentication allow-fail-through

When I don't add the switch ip to the devices I get a message in the event viewer about a unknown NAD. Which is to be expected.

 

But when I do add the switch ip to the devices list with the key as defined in the switch I sometimes (almost never) see any messages anymore in the event viewer as well as the Access tracker.

 

I'm currently testing with ArubaOS-CX Version : TL.10.02.0001 and Clearpass 6.7.2

 

With kind regards,

 

Rens

 

Hi Rensk,

 

it work for me...

 

Your ArubaCX is L3 Router ? (with multiple interface ?)

Do you have configure the ip souce interface for TACACS ?

Hello alagoutte,

 

I'm currently testing with an empty switch. Only one L3 interface has been setup.

 

Anyhow I tested with setting up the source interface. No change in behaviour.

 

When I don't define the NAD in Clearpass or enter the wrong pre shared key I get a notification in the Event viewer every time I try to login. As soon as I define the correct NAD settings all notification dry up.

Nothing I the Event viewer; nothing in the access tracker.

 

Can you share your config? Wich ArubaOS-CX version are you using?

 

Regards,

 

Rens

it is the same configuration (i try with 10.1 but i can look for try with 10.2)

 

You don't have forget to add TACACS Service ?

Do you have a TACACS service configured in Clearpass? If you add the NAD, and it properly sends a request, you should see something in a access tracker

Can you run a show tacacs-server detail?
also run a show aaa authentication?

Also, why do you have failthrough enabled? You only have one server in the server group, so it shouldn't be neccessary (unless my understanding of failthrough is wrong, and different then the WLCs)

Hello cwickline14,

 

---

@cwickline14 wrote:

Do you have a TACACS service configured in Clearpass? If you add the NAD, and it properly sends a request, you should see something in a access tracker

---

I've just tested but only when I use PAP in stead of CHAP you see someting in the access tracker. With CHAP I almost never get someting in the access tracker.

 

Can you run a show tacacs-server detail?
also run a show aaa authentication?

---

8320# show aaa authentication
AAA Authentication:
Fail-through : Enabled
Limit Login Attempts : Not set
Lockout Time : 300
Minimum Password Length : Not set

Default Authentication for All Channels:
----------------------------------------------------------------------------------------------------------------------------------
GROUP NAME | GROUP PRIORITY
----------------------------------------------------------------------------------------------------------------------------------
clearpass | 0
----------------------------------------------------------------------------------------------------------------------------------
8320# show tacacs-server detail
******* Global TACACS+ Configuration *******

Shared-Secret: AQBapeZNldLuxrMvpYdzUXZrR4sZ95R9PjZRHNpSp8QcCG/oDAAAAPdrx0iq4S50CpjxWw==
Timeout: 5
Auth-Type: chap
Number of Servers: 1

****** TACACS+ Server Information ******
Server-Name : 10.13.111.19
Auth-Port : 49
VRF : default
Shared-Secret (default) : AQBapeZNldLuxrMvpYdzUXZrR4sZ95R9PjZRHNpSp8QcCG/oDAAAAPdrx0iq4S50CpjxWw==
Timeout (default) : 5
Auth-Type : pap
Server-Group : clearpass
Group-Priority : 1

 

Also, why do you have failthrough enabled? You only have one server in the server group, so it shouldn't be neccessary (unless my understanding of failthrough is wrong, and different then the WLCs)

---

If the clearpass servers aren't reachable I would like to have the ability to login to the switch with the local admin account. That's why I enabled failthrough.

 

Now I've enabled PAP it's sort of working

But I get two access requests. The first one fails with 

Tacacs server	Invalid Sequence number

Second one works.

I just deployed the 10.02 OVA, and having the same issue. If i do PAP, it sends two requests, but I can access the switch.

However, when I do CHAP, I do still see the request in Clearpass, it just can't catergorize it.(I'm looking into that) In Access tracker, do a filter for the NAD ip address, and see if it shows up.

Edit**

A quick google search and I came across this https://community.arubanetworks.com/t5/Security/Clearpass-and-Fortigate-TACACS-auth-fail/td-p/315220

It seems like CHAP might not be supported in Clearpass...

---

@cwickline14 wrote:

I just deployed the 10.02 OVA, and having the same issue. If i do PAP, it sends two requests, but I can access the switch.

However, when I do CHAP, I do still see the request in Clearpass, it just can't catergorize it.(I'm looking into that) In Access tracker, do a filter for the NAD ip address, and see if it shows up.

---

Missing CHAP on authentification method ? (you use TACACS ?)

 

I get same issue with RADIUS (about double request...) but coming from SSH Server of ArubaCX... (for discovery supported cipher...)

There isn't a option to choose authentication methods for TACACS services, unless i'm missing something

Found this post from one and a half year ago https://community.arubanetworks.com/t5/Security/Clearpass-and-Fortigate-TACACS-auth-fail/td-p/315220

According to this articile Tacacs+ with CHAP isn't supported on Clearpass

 

Can't confirm if it's true but this seems to match what we see

Yes, no possible for the moment...

Hello,

 

Did you try defining the source interface for the TACACS? Try adding:

 

ip source-interface tacacs <<MGMT IP HERE>>

 My switch was using some random VLAN in my default VRF as the source for TACACS. You can check to see if that's the case in the Event Viewer for ClearPass. You might see something like this:

 

 

Let me know if that helps!

No, it is not the same issue...

Do you have try last release ? (10.02.0020)

 

SSH

CR_37061

Symptom: The switch incorrectly sends a default blank password attempt.

Scenario: When logging into the switch through SSH, the switch incorrectly has an automatic attempt

to log in with a blank password before the user receives the password prompt.

Workaround: There is no functional impact. Console login does not have the additional login attempt.

I realize this thread hasn't been updated in quite some time but I'm running into the same issue on an 8325 (firmware 10.04.3000) with ClearPass 6.8.7.

 

Similar to the original post I've setup TACACS auth on the switch pointing it to a ClearPass cluster, I never see any authentication attempts in Activity Monitor on ClearPass.

 

I've setup a number of other switches (CX 6400 and 6300 series) on the same firmware version that point to this same ClearPass server in exactly the same fashion using the exact same CLI commands on the switches for configuration.

 

Just wondering if this is still an outstanding issue in the 8300 series by chance?

 

Hello Stevepo,

 

I believe it's working as it should. Can't confirm your exact software version. But I'm currently building a new network on 10.5.0011.

 

Tacacs is working fine,

 

Regards,

 

Rens

Thanks for checking back in and replying Rensk, I notice when I run a "show tacacs-server statistics" on the problematic switches I have a high count of "Packet Dropped" and "Auth reply malformed".  

 

Firmwares range from 10.04.0010 to 10.05.0011 across about 10 different CX switches, I don't see this on any other switch model / firmware version except my 8300 series.  The two 8300 series in question are in a VSX pair, authentication via TACACS using credentials defined in NetEdit seems to work as well as TACACS login via HTTPS, but logging into the switch via SSH with those same credentials fails, all TACACS attempts on the VSX peer switch fail (NetEdit, HTTPS and direct SSH login).  

 

I'll either upgrade to see if it resolves or drop Aruba TAC a case at this point and post back.

I am also a bit stuck here. I was having accepts on 6.9.4 but the switch SSH would not connect consistantly and get the multiple server attempts in the TACACS group. 

Now after applying the 6.9.5 patch on CP which included that TACACS+ Fragmentation patch the SSH seems to work but I can't seem to get any authentications in the CP log for the HTTPS sessions to the switch on authentication. 

I am using aaa authentication login default group xxxXXX-T-TACACS local which should send the HTTPS session auths to CP but I am not seeing anything and get an invalid credentials message. 



------------------------------
Christopher Calhoun
------------------------------

Original Message:
Sent: Oct 08, 2020 09:43 AM
From: Steve Pollock
Subject: ArubaOS-CX Tacacs authentication

Thanks for checking back in and replying Rensk, I notice when I run a "show tacacs-server statistics" on the problematic switches I have a high count of "Packet Dropped" and "Auth reply malformed".  

 

Firmwares range from 10.04.0010 to 10.05.0011 across about 10 different CX switches, I don't see this on any other switch model / firmware version except my 8300 series.  The two 8300 series in question are in a VSX pair, authentication via TACACS using credentials defined in NetEdit seems to work as well as TACACS login via HTTPS, but logging into the switch via SSH with those same credentials fails, all TACACS attempts on the VSX peer switch fail (NetEdit, HTTPS and direct SSH login).  

 

I'll either upgrade to see if it resolves or drop Aruba TAC a case at this point and post back.

Rens,

I realize this thread is dated, but you were correct the firmware version(s) was not the issue and TACACS was working as expected.  Mistake on my end, there were multiple IP interfaces defined on the particular switch(es) I was having the issues with.  I needed to add the following to specify which interface the TACACS requests should come from:

ip source-interface tacacs interface <interface name>

This resolved the issue for me as ClearPass then saw the request coming from the desired IP.  Just thought I'd post the follow up in case it helps anyone else out there searching.

Thanks,
Steve