Turning RC4 in Microsoft Active Directory - CVE-2022-38023

[adamscottmaster2013]

I have two Production Cisco ISE environment.  Environment #1 is Cisco ISE version 3.1 patch 5 and Environment #2 is Cisco ISE version 3.0 patch 4.  Both Cisco ISE environments are integrated with Microsoft Active Directory.

Today, I was informed by the Active Directory (AD) Administrators that they will implement CVE-2022-38023 and they will turn OFF RC4 on the AD servers.

Does it mean that communications between Cisco ISE and Microsoft ADs will be broken if they turn off RC4?  

https://community.cisco.com/t5/network-access-control/cisco-ise-with-ad-cve-2022-38023-patch/m-p/4726688#M578449

https://bst.cisco.com/bugsearch/bug/CSCvo60450

https://bst.cisco.com/bugsearch/bug/CSCvo60450

It looks like Cisco ISE 3.0 and 3.1 are also impacted by this?

Any thoughts?

P.S.:  I also opened a TAC case with cisco but the TAC engineer is pretty much clueless and he said that he would get back to me.

[Rodrigo Diaz]

hi @adamscottmaster2013 the bug that you mention https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvo60450 is affecting the versions 3.X of ISE , as the bug states the ISE supports encryption AES128 and AES256 as well of RC4 when communicating with the AD , so when you turn off the RC4 from your AD, the other fallback methods will be used by ISE to communicate with your AD , what you can do is to take capture from the ISE towards the AD to review if RCA is being used , you have to make sure that your AD handles the AES versions from where ISE will encrypt the traffic .  In the situation where there is no communication between ISE and your AD , what I would advise is to try to deregister /register back your nodes with your AD. 

Let me know if that helped you. 

[adamscottmaster2013]

@Rodrigo Diaz:  I don't agree with this statement:  "in the situation where there is no communication between ISE and your AD , what I would advise is to try to deregister /register back your nodes with your AD"

I can't do this in a production environment.  This is what TAC engineer typically suggests.

If ISE claims that it supports AES128 and AES256, then turning OFF RC4 on the AD servers should NOT impact the communication between ISE and AD servers, correct?  

When you mentioned deregister/register, you meant leave/join with AD servers, right?  deregister/register is a term to remove/add nodes into the ISE cluster.  Do I have to do that for all nodes?  For example, I have:

node#1:  Primary admin, Primary MNT

node#2: Secondary admin, secondary MNT

node#3: PSN

node #4: PSN

Do I have to do that for ALL nodes?

[Rodrigo Diaz]

Answering your questions , yes ISE does support that protocols so as long as you have them in your AD , you should be fine. 

The reason I asked you to take a capture is to verify if you are using RC4 or any AES protocol, in case you are using AES as protocol to encrypt packets between ISE and your AD you can turn off RC4 without any issue, in case you run into any communication issues you can remove/add the AD servers from ISE ( a maintenance window would be recommended ) as the ISE and AD will have to re negotiate the encryption, and yes, you will have to do this procedure if your communication fails with all the nodes within your production. 

[Ricky S]

Hi, were you able to find an answer to this?  We are facing the same dilemma with ISE.

Thanks

Ricky

[Greg Gibbs]

See a more recent discussion here:

https://community.cisco.com/t5/network-access-control/cscvo60450-encryption-rc4-aes256-amp-ms-ad-cve-2022-38023-patch/td-p/4783005

[zac ragoonath]

that thread doesn't have a conclusion though. any update you know of?

[ahollifield]

See Page 2:

from @Surendra 

1. The update on April 11th will have no impact on ISE communication to Active Directory. That was the first urgent concern.
2. We are still communicating with Active Directory on less secure protocols, that is a longer term open item that will be addressed with a security advisory and fix to ISE. Once we have a timeline for a fix we'll work internally to get a Security Advisory out that can be tracked. In the mean time it is also tracked by CSCvo60450.

It is important to note that MS is enforcing only "RequireSeal" for RPC communication and irrespective of the setting for this registry, there is no tested impact with ISE - AD Communication. If customers decide to enforce not using RC4 by setting the "RejectMd5Clients" to 1 EXPLICITLY on their own discretion, then it is bound to fail as we do not use any other encryption method apart from this as it stands today. The change that is being brought by MS on April 11 or July 11 does not have any impact on ISE-AD communication with the tests that were done so far. Please keep a track of this bug to get any further notifications/updates on the timelines of having a better encryption method than we have today. It is our priority as well.

[ahollifield]

1. The update on April 11th will have no impact on ISE communication to Active Directory. That was the first urgent concern.
2. We are still communicating with Active Directory on less secure protocols, that is a longer term open item that will be addressed with a security advisory and fix to ISE. Once we have a timeline for a fix we'll work internally to get a Security Advisory out that can be tracked. In the mean time it is also tracked by CSCvo60450.

It is important to note that MS is enforcing only "RequireSeal" for RPC communication and irrespective of the setting for this registry, there is no tested impact with ISE - AD Communication. If customers decide to enforce not using RC4 by setting the "RejectMd5Clients" to 1 EXPLICITLY on their own discretion, then it is bound to fail as we do not use any other encryption method apart from this as it stands today. The change that is being brought by MS on April 11 or July 11 does not have any impact on ISE-AD communication with the tests that were done so far. Please keep a track of this bug to get any further notifications/updates on the timelines of having a better encryption method than we have today. It is our priority as well.

[zac ragoonath]

yup. i asked there and the Cisco employee replied.

thxx