ISE 3.2 patch-4 to patch-5

[adamscottmaster2013]

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?

[Arne Bier]

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.

[ahollifield]

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.  

[adamscottmaster2013]

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?

[ahollifield]

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.

[adamscottmaster2013]

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

[ahollifield]

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

[PSM]

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

[Arne Bier]

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?

[PSM]

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.

[CiscoU9834]

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

[PSM]

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.