topic Re: ISE 3.2 patch-4 to patch-5 in Network Access Control

ISE 3.2 patch-4 to patch-5

adamscottmaster2013 — Mon, 01 Apr 2024 19:14:00 GMT

I have the following SNS-3655 running ISE 3.2 patch-4:

ise1: Primary Admin/Primary MNT;
ise2: Secondary Amdin/Secondary MNT
ise3: PSN
ise4: PSN

I would like to do the followings:

- patch ise1 to patch-5; reboot
- patch ise3 to patch-5; reboot

After one week:
- patch ise4 to patch-5; reboot
- patch ise2 to patch-5; reboot

Can I have different nodes running different patches for one week? Is this something that Cisco supports?

Re: ISE 3.2 patch-4 to patch-5

Arne Bier — Mon, 01 Apr 2024 20:42:54 GMT

I can't answer on behalf of Cisco (or Cisco TAC) but I can't see why they would not allow this.

Why one week? Surely you'd know after a couple of days?

I had an unfortunate incident the other day after upgrading a customer from 2.7 to 3.2p5 - upgrade went well, but some wireless Windows users were unable to connect on 3.2p5. I didn't realise that this customer used AnyConnect NAM on Windows 10 hosts. To my horror, I saw in the ISE 3.2 release notes that AnyConnect 4.10.x was "supported" (what does that mean for older versions?) - but around half the PCs were running AnyConnect 4.9 (failing). What on earth could make ISE 3.2 not work with a sub-version release of AnyConnect NAM? ISE 3.2 had TLS1.0/1.1/SHA1 and all the legacy stuff enabled. But clients were failing to establish the TLS tunnel (clients gave up talking to ISE).

Upgrading AnyConnect to the latest 4.10 release resolved the Windows connectivity issues.

Re: ISE 3.2 patch-4 to patch-5

ahollifield — Tue, 02 Apr 2024 12:17:55 GMT

Agree with @Arne Bier why a full week? You can have nodes on different patch levels but you want this time to be as minimal as possible. A week is way too long IMHO.

Re: ISE 3.2 patch-4 to patch-5

adamscottmaster2013 — Tue, 02 Apr 2024 12:43:31 GMT

Because for a full week, I can confidently identify all issues with patch-5. If there are issues and in the worst case scenario, I can shutdown node ise1 and ise3, promote ise2 to be primary to rollback the change. After that, I just need to rebuild ise1 and ise3.

I do NOT trust rolling back from patch-5 to patch-4. I've had issues in the past about rolling back patches. You're NOT going to get 100% rollback, am I right?

Re: ISE 3.2 patch-4 to patch-5

ahollifield — Tue, 02 Apr 2024 13:19:57 GMT

What you would you find over a full week vs a couple of days? Your plan for shutdown/rebuild sounds good though?

What do you mean 100% rollback? Each ISE patch includes rollback. I’ve personally never had issues rolling back a patch but I typically avoid it anyway I can.

Re: ISE 3.2 patch-4 to patch-5

adamscottmaster2013 — Tue, 02 Apr 2024 16:13:53 GMT

"What do you mean 100% rollback? Each ISE patch includes rollback."

LOL... Have you ever tried to roll back on on the Cisco FTD devices? I've been burned about rollback so many times that it is not even funny anymore. The rollback from Cisco, or any vendors for that matter, is pretty much useless.

Re: ISE 3.2 patch-4 to patch-5

ahollifield — Tue, 02 Apr 2024 17:32:52 GMT

I don't disagree and like I said I avoid rollbacks at all costs. But FTD != ISE....

Re: ISE 3.2 patch-4 to patch-5

PSM — Tue, 02 Apr 2024 17:40:00 GMT

Just beware of this bug if you have Win 10 and TPM module in environment. Cisco is forgetting to take care of the work around they provided every time they are releasing new version or patch. If you have disabled RSA PSS, after patch it will be reenabled automatically and you need to disable it again.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwb19635

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwb77915

Re: ISE 3.2 patch-4 to patch-5

Arne Bier — Tue, 02 Apr 2024 20:33:26 GMT

Hi @PSM

Thanks for that reminder - before I could confirm that the issue was due to AnyConnect, I thought for a minute that this could be my bug too. But I didn't see any RSA_PSS on the clients.

If the workaround is to disable RSA_PSS on the clients (Windows config), do you know why there is also the option in ISE to disable RSA_PSS ? Is that only used/useful if the client has RSA_PSS enabled (and cannot disable it), so that ISE sends an EAP NAK, to force the client to use something else?

I have never run into this with any of my customers that use the native Windows 10 supplicant, and very new laptops with the latest TPM modules. How does anyone land in this unfortunate situation in the first place?

Re: ISE 3.2 patch-4 to patch-5

PSM — Wed, 03 Apr 2024 10:47:51 GMT

Hi @Arne Bier yes, this workaround is when clients has RSA_PSS enabled and TPM has issue in signing during TLS handshake. This was to make the things easier for customers although this is actually a Microsoft issue. We discovered this issue 1st time when we were moving to 3.1 (patch 3 or 4 don't remember exactly). That time TAC engineer disabled RSA_PSS using root access of PSNs. In the next patches of 3.1, a new option using toggle switch was introduced by Cisco where customer can disable RSA_PSS using 'application configure ise' command. But the problem is that RSA_PSS setting is not retained every time you patch ISE and it has to set again.

Re: ISE 3.2 patch-4 to patch-5

CiscoU9834 — Wed, 03 Apr 2024 20:49:17 GMT

For the RSA/PSS not preserved upon patch installation, looking at the Bug CSCwf80386, it seems to be fixed on 003.003(000.430).

Looking into ISE 3.3 release notes I see:

CSCwb77915 : Use the toggle button to enable or disable RSA PSS ciphers based on policy under Allowed Protocols in the Cisco ISE GUI.

So maybe starting from ISE 3.3 they enabled the RSA/PSS toggle on the Web Gui and it's preserved on future patch. I don't have a 3.3 version where to check, but maybe can someone check and confirm this?

Thank you

Re: ISE 3.2 patch-4 to patch-5

PSM — Thu, 04 Apr 2024 06:11:40 GMT

Hi @CiscoU9834 looks new documentation bug. If you open detail in bug search tool it just explain same CLI work around.

And I checked 3.3, and cannot see option in allowed protocols.