PDF(132.8 KB) View with Adobe Reader on a variety of devices
ePub(113.3 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Updated:April 13, 2017
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to overcome the issue of March 2017 Microsoft security update, which breaks CDA functionality i.e. User mappings no longer appear in SWT Context Directory Agent (CDA).
Cisco CDA relies on Event ID 4768 being populated on all versions of Windows 2008 and 2012 domain controllers. These events indicate successful user logon events. If success logon events are not being audited in the local security policy or if these event IDs are not populated for any other reason then the WMI queries from CDA for these events will return no data. As a result, user mappings will not be created in CDA and therefore user mapping information will not be sent from CDA to the Adaptive Security Appliance (ASA). In cases where customers are leveraging user or group-based policies from AD in Cloud Web Security (CWS), the user information does not appear in the whoami.scansafe.net output.
Note:This does not affect Firepower User Agent (UA) since it leverages event ID 4624 to create user mappings and that type of event is not impacted by this security update.
Problem: User-to-IP Mappings No Longer Appear in Cisco CDA after March 2017 Microsoft Update
A recent Microsoft security update has caused issues in several customer environments wherein their domain controllers stop logging these 4768 event IDs. The offending KBs are listed below:
To confirm that this issue is not with the logging configuration on the Domain Controller, make sure that the proper audit logging is enabled in the Local Security Policy. The bold items in this output below mustbe enabled for proper logging of 4768 event IDs. This should be run from the command prompt of each DC that is not logging events:
C:\Users\Administrator>auditpol /get /category:*
System audit policy
Security System Extension No Auditing
System Integrity Success and Failure
IPsec Driver No Auditing
Other System Events Success and Failure
Security State Change Success
Logon Success and Failure
Account Lockout Success
IPsec Main Mode No Auditing
IPsec Quick Mode No Auditing
IPsec Extended Mode No Auditing
Special Logon Success
Other Logon/Logoff Events No Auditing
Network Policy Server Success and Failure
Kerberos Service Ticket Operations Success and Failure
Other Account Logon Events Success and Failure
Kerberos Authentication Service Success and Failure
Credential Validation Success and Failure
If you see that the proper audit logging is not configured, navigate to Local Security Policy > Security Settings > Local Policies > Audit Policy and ensure that Audit account logon events is set to Success, as shown in the image:
As a current workaround, some users have been able to uninstall the above mentioned KBs and the 4768 event IDs resumed logging. This has proven effective for all Cisco customers thus far.
Microsoft has also provided the following workaround to some customers hitting this issue as seen in support forums. Note that this has not yet been fully tested or verified in Cisco labs:
The four audit policies you need to enable as a workaround to the bug are under Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Account Logon. All four policies under that heading should be enabled for Success and Failure:
Audit Credential Validation Audit Kerberos Authentication Service Audit Kerberos Service Ticket Operations Audit Other Account Logon Events
When you enable those four policies, you should start to see the 4768/4769 Success events again.
Refer to the image above that shows Advanced Audit Policy Configuration at the bottom of the left pane.
As of the date of this initial publication (3/28/2017), we do not yet know of a permanent fix from Microsoft. However, they are aware of this issue and working on a fix.