Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

KB-39695: Does vulnerability CVE-2020-1472 affect Centrify?

Authentication Service ,   Privileged Access Service ,  

2 October,20 at 10:53 PM

Question:

1. Does vulnerability CVE-2020-1472 affect Centrify Infrastructure Service?
2. Does vulnerability CVE-2020-1472 affect Centrify Privileged Access Service?
3. Has Centrify Cloud service patched against CVE-2020-1472?

Answer:

1. The CVE-2020-1472 (ZeroLogon) vulnerability affects Windows Domain Controllers. To help correct this CVE, Microsoft has provided a patch that should be applied to all Domain Controllers. That patch will now log an Event Viewer event with an ID of 5829 and message text stating "
The Netlogon service allowed a vulnerable Netlogon secure channel connection."

Events with an ID of 5829 may be logged from systems that adclient is installed on. Below are two explanations of why the 5829 events are received from adclient.

adclient will not failback and use NTLM if Kerberos Authentication does not succeed, however, adclient can be forced to use secure the NetLogon Channel for certain tasks if explicitly set in the centrifydc.conf. adclient with then use NTLM Authentication instead of Kerberos Authentication.  If explicit NTLM Authentication for adclient is being used, please review Explanation #2

If explicit NTLM Authentication is not set, adclient will by default use Kerberos Authentication. For an explanation of why the 5829 events are triggered when Kerberos Authentication is used, please review Explanation #1.

Explanation #1

While the normal communication of adclient is done through Kerberos, adjoin and adleave are causing the 5829 events to be triggered. adjoin and adleave use NetLogon secured by GSSKerberos RpcSec, however, the problem is that this form of secure communication is not perceived by the Domain Controller as a "Secure Channel" (SCHANNEL) communication. This triggers the 5829 event to be logged, even though it is encrypted and signed with GSSKerberos in the RPC layer.

If the Domain Controller patch is set to enforce "deny", the NetLogon request used by adjoin and adleave will fail, however, the denied NetLogon does not affect adjoin/adleave functionality as this NetLogon request is used for editing the AD computer object as being managed by adclient. This operation is not critical to functionality, and in the event of failing to use NetLogon, adjoin/adleave will fall back to LDAP and will not affect the outcome of the join or leave.

To alleviate the 5829 events triggered by adjoin the following parameter may be set in centrifydc.conf:


adclient.netlogon.packet.security.type: 2

This parameter will tell adclient to use SCHANNEL instead of GSSKerberos in NetLogon negotiations and adjoin will no longer trigger event 5829.

adleave, however, will still trigger the 5829 event due to an issue that will be fixed in a future release, but for now, it does not affect adleave operation even when the Domain Controller is set to enforce "deny" and the event ID of 5827 (denied NetLogon) will be found in the Event Viewer. The following entry will also be found in the logs for adclient: 


Oct  1 15:10:29 cent1234 adleave[19922]: INFO  smb.rpc.join Clear tattoo via NetLogon channel failed: Access Denied.Will retry using LDAP binding

Explanation #2

For customers that use NTLM authentication by explicitly specifying it's use in centrifydc.conf, using the following parameter: 
 

pam.ntlm.auth.domains: <domain> <domain> ...

This parameter should NOT be set and will break NTLM authentication for adclient:

adclient.netlogon.packet.security.type: 2

This is caused by an issue in adclient, where during normal communication adclient can use GSSKerberos but fails when trying to use SCHANNEL. This will be fixed in a future release but in the meantime, please do not use the above SCHANNEL setting, and do not "deny insecure NetLogon", i.e., please tolerate event 5829 for now if explicitly using NTLM communication with adclient. Please note: that by not using the above setting all communication is still secured by GSSKerberos.

As a final note: all the above issues from both explanations will be fixed in a future release.


2. No, this CVE does not affect Centrify Privileged Access Service.

3. Yes, Centrify has patched and addressed the CISA Emergency Directive 20-04 by Mon 9/21. Centrify cloud services are patched against this vulnerability.

References:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472
https://cyber.dhs.gov/ed/20-04/
Centrify Corporation does not take any responsibility for the content or availability of this link and it was provided as a courtesy.  Customers should contact the vendor if there are any further questions.

 

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.