A hospital's Threat Defense appliances run release 7.6 and must apply access-control rules based on Active Directory group membership. The Windows team allows one lightweight agent on an approved member server, forbids installing software on domain controllers, and forbids the appliance from polling domain controllers directly. The hospital runs no Cisco ISE. Which identity source should populate the user-to-IP mapping table?
Select an answer to reveal the explanation.
Short Explanation
You can meet the Windows team's limits with passive identity: install the Passive Identity Agent on the approved member server, not on a domain controller. It monitors Active Directory logon activity and sends user-to-IP mappings to the Management Center, without requiring ISE.
Full Explanation
On Threat Defense 7.6 and later, the Passive Identity Agent is installed on a Windows member server, monitors Active Directory logon activity, and sends user-to-IP mappings to the Management Center without ISE or software on domain controllers. The mappings let access-control rules use AD users and groups through the realm. This agent replaces the retired Firepower User Agent for this use case. RADIUS accounting from the access network would require an accounting source the scenario does not describe, and accounting alone does not provide AD group context. VPN authentication records cover only remote-access users, leaving on-site users out of the mapping table. Windows Event Forwarding can move domain-controller logon events to the approved server, but it is not itself an identity source consumed by the Management Center; a component must still read the events and publish mappings. Exam caveat: passive identity needs a realm for group lookups, and mappings are only as fresh as the logon events. Practical check: after deployment, open the user activity view in the Management Center and confirm current mappings for test users before relying on identity-based rules.