Domain Controllers not detected by Identity Collector

[CaseyB]

Reference document(s): Identity Awareness Clients Administration Guide , Identity Collector - Technical Overview 

I created an Access Role on the firewall as follows:

I am noticing in the logs that our Domain Controllers are NOT hitting this rule which is defined by the above Access Role. Logging into the firewall I run these commands:

• pdp monitor machine_exact <my computer>
  • Works as expected
• pdp monitor machine_exact <domain controller>
  • Blank response

Checking the Logs:

• blade:"Identity Awareness" AND origin:<firewall> AND <my computer>
  • Results are returned
• blade:"Identity Awareness" AND origin:<firewall> AND <domain controller>
  • No results

Is this a limitation of the Identity Collector that it cannot report on Domain Controllers? Or is this something else like a misconfiguration? Could not find any verbiage in my searching mentioning this is a limitation.

R82-JHF 44 / Identity Collector 82.129.0000

[Vincent_Bacher]

As info about Idc config is missing here I just can speculate what’s going on.

Most likely you’re using AD polling as identity source, not sylog or ISE (pxGrid)
So basically, the reason you’re not seeing the Domain Controller show up is because the Identity Collector relies on security events that are generated when clients authenticate to the domain. When a normal client logs in, a security event is created that ties the user identity to the machine and its IP address. The Identity Collector uses these events to build the user-to-IP and machine mappings.

Domain Controllers themselves do not generate these kinds of user login events for their own identity. They operate as infrastructure components and typically run under system accounts, so there are no relevant security events that Identity Awareness can use to identify the DC as an endpoint. Therefore, this behavior is expected and not a misconfiguration.

As an alternative approach, we are currently in a testing phase using 802.1X together with Cisco ISE. In this setup, session information is shared via pxGrid (Security Group Tags / SGT) which can then be consumed by the Identity Engine / Identity Collector. This approach does work and provides visibility even for servers or infrastructure devices that do not have interactive user logins.

[CaseyB]

Yes, we are using AD polling as the identity source.

An RDP event to the Domain Controller wouldn't generate a login event that could be used either?

[Vincent_Bacher · Accepted solution]

Yes, that’s correct.

Even if you RDP to a Domain Controller, the resulting logon event is still associated with the user and the client IP, not with the Domain Controller itself as an endpoint identity.

From an Identity Awareness / AD polling perspective, the event only tells the collector:

• which user logged in
• from which source IP (the client/workstation)

It does not create a machine identity for the Domain Controller. Therefore, this type of event cannot be used to identify the DC itself in Identity Awareness or to match an Access Role.

Also, while the logon is recorded in the Security Event Log (not the Application log), it still does not change the behavior — Domain Controllers are not treated as identity-aware endpoints.

As we don’t use ad polling maybe my statement is not absolutely correct in all details but in general it should apply.