FMC passive identity - user not found in the connection event log

[Chess Norris]

Hello,

I'm trying to get passive identity to work with FMC, but I'm a bit stuck.

So far I have a working PXGrid connection between FMC and ISE and I have also configured the Realm and an identity policy in FMC.

All those things seems to work and I can download AD users and groups from the Realm and I can also see the users in FMC under Analysis->Users. Under Analysis->User Activity, I can also see that the user name to IP address mapping is working

The thing that doesn't seem to work is to display the initiator user in FMC under the  Analysis->Connection Events->Table View of Connection Events. All I see there is "user not found" in the Initiator User field (see below)

Does anyone know whats missing to get this to work? 

Thanks

/Chess

[Mohammed al Baqari]

Hello,

Have you assigned the identity policy to your access control policy under
advanced settings?

If yes, then you need to check if FTD is getting the mapping from FMC. This
is done from the CLI using expert mode and applying the command
user_map_query.pl -i #ip_address#

**** please remember to rate useful posts

[Chess Norris]

Yes, the identity policy is assigened to the ACP.

The query from FTD CLI gives me the following output, so something must be missing.

root@ftd01:/home/admin# user_map_query.pl -i 10.46.0.66

WARNING: This script was not tested on this major version (7.3.0)! The results may be unexpected.
Current Time: 05/03/2023 12:11:11 UTC

Getting information on IP Address(es)...

ERROR: Unable to find IP address '10.46.0.66' in the database!

Then, if I run the same query from FMC I get a different result were it actually looks like it find the user

root@fmc01:/Volume/home/admin# user_map_query.pl -i 10.46.0.66

WARNING: This script was not tested on this major version (7.3.0)! The results may be unexpected.
Current Time: 05/03/2023 12:21:17 UTC

Getting information on IP Address(es)...

NOTICE: Unable to get the user info for user_id '10000003'!

___
IP #1: 10.46.0.66
---

==============================
| Database |
==============================

##) Username (ID)
1) (10000003)
for_policy:
Last Seen: Unknown
2) jofr (9)
for_policy: 0
Last Seen: Unknown

/Chess

[Mohammed al Baqari]

See that is the problem. It should be downloaded to FTD as well. Not only
on FMC. So its not syncing to FTD.

>From FTD, running the following

cat /var/sf/detection_engines/#just tab here#/user_identity.dump

see the output if you have any users synched. Also, from FTD CLI, use this
command and initiate some traffic to see if identity lookup is happening.

system support identity-debug



Please specify an IP protocol:

Please specify a client IP address: 10.46.0.66

Please specify a client port:

Please specify a server IP address:

Please specify a server port:

**** please remember to rate useful posts

[Chess Norris]

I dont have a user_identity.dump file under /var/sf/detection_engines/2e8f465a-4ad7-11ec-8aef-c4473a3b5ede/ 

Here is the files avaiblabe under that directory 

The output from system support identity-debug looks like this:

> system support identity-debug

Enable firewall-engine-debug too? [n]:
Please specify an IP protocol:
Please specify a client IP address: 10.46.0.66
Please specify a client port:
Please specify a server IP address:
Please specify a server port:

Monitoring identity debug messages

10.46.0.66 62280 -> 172.27.50.131 53 17 AS=0 ID=0 GR=1-1 Starting Auth SrcZone first with zone 1 -> 2, geo 0 -> 0, vlan 0
10.46.0.66 62280 -> 172.27.50.131 53 17 AS=0 ID=0 GR=1-1 match rule order 1, id 1 action Auth Agent, passive realm sequence 4, active auth realm id 0
10.46.0.66 62280 -> 172.27.50.131 53 17 AS=0 ID=0 GR=1-1 Looking up source attrs in subnet cache
10.46.0.66 62280 -> 172.27.50.131 53 17 AS=0 ID=0 GR=1-1 Found sgt 0, sgt_type 0
10.46.0.66 62280 -> 172.27.50.131 53 17 AS=0 ID=0 GR=1-1 Looking up destination attrs in subnet cache
10.46.0.66 62280 -> 172.27.50.131 53 17 AS=0 ID=0 GR=1-1 Found sgt 0, sgt_type 0
10.46.0.66 62280 -> 172.27.50.131 53 17 AS=0 ID=0 GR=1-1 user_id 9999999 src_sgt 0 src_sgt_type unknown dst_sgt 0 dst_sgt_type unknown device_type 0
10.46.0.66 62280 -> 172.27.50.131 53 17 AS=0 ID=0 GR=1-1 IdentityFlowSetupEventHandler Retrieved identity info: user_id 9999999, authRealmId 0, src sgt 0, src sgt type unknown, dst sgt 0, dst sgt type unknown, deviceType 0, locationIP ::
10.46.0.66 51933 -> 93.184.221.240 80 6 AS=0 ID=0 GR=1-1 Starting Auth SrcZone first with zone 1 -> 2, geo 0 -> 0, vlan 0
10.46.0.66 51933 -> 93.184.221.240 80 6 AS=0 ID=0 GR=1-1 match rule order 1, id 1 action Auth Agent, passive realm sequence 4, active auth realm id 0
10.46.0.66 51933 -> 93.184.221.240 80 6 AS=0 ID=0 GR=1-1 Looking up source attrs in subnet cache
10.46.0.66 51933 -> 93.184.221.240 80 6 AS=0 ID=0 GR=1-1 Found sgt 0, sgt_type 0
10.46.0.66 51933 -> 93.184.221.240 80 6 AS=0 ID=0 GR=1-1 Looking up destination attrs in subnet cache
10.46.0.66 51933 -> 93.184.221.240 80 6 AS=0 ID=0 GR=1-1 Found sgt 0, sgt_type 0
10.46.0.66 51933 -> 93.184.221.240 80 6 AS=0 ID=0 GR=1-1 user_id 9999999 src_sgt 0 src_sgt_type unknown dst_sgt 0 dst_sgt_type unknown device_type 0
10.46.0.66 51933 -> 93.184.221.240 80 6 AS=0 ID=0 GR=1-1 IdentityFlowSetupEventHandler Retrieved identity info: user_id 9999999, authRealmId 0, src sgt 0, src sgt type unknown, dst sgt 0, dst sgt type unknown, deviceType 0, locationIP ::
10.46.0.249 8 -> 10.46.0.66 0 1 AS=0 ID=0 GR=1-1 Starting Auth SrcZone first with intf 2 -> 1, geo 0 -> 0, vlan 0, icmpType 0, icmpCode 0
10.46.0.249 8 -> 10.46.0.66 0 1 AS=0 ID=0 GR=1-1 match rule order 1, id 1 action Auth Agent, passive realm sequence 4, active auth realm id 0
10.46.0.249 8 -> 10.46.0.66 0 1 AS=0 ID=0 GR=1-1 looked for user_id with realm_id 4 auth_type 1, no binding found
10.46.0.249 8 -> 10.46.0.66 0 1 AS=0 ID=0 GR=1-1 Looking up source attrs in subnet cache
10.46.0.249 8 -> 10.46.0.66 0 1 AS=0 ID=0 GR=1-1 Found sgt 0, sgt_type 0
10.46.0.249 8 -> 10.46.0.66 0 1 AS=0 ID=0 GR=1-1 Looking up destination attrs in subnet cache
10.46.0.249 8 -> 10.46.0.66 0 1 AS=0 ID=0 GR=1-1 Found sgt 0, sgt_type 0
10.46.0.249 8 -> 10.46.0.66 0 1 AS=0 ID=0 GR=1-1 user_id 9999999 src_sgt 0 src_sgt_type unknown dst_sgt 0 dst_sgt_type unknown device_type 0
10.46.0.249 8 -> 10.46.0.66 0 1 AS=0 ID=0 GR=1-1 IdentityFlowSetupEventHandler Retrieved identity info: user_id 9999999, authRealmId 0, src sgt 0, src sgt type unknown, dst sgt 0, dst sgt type unknown, deviceType 0, locationIP ::200:0:4410:92f5:2e15:0
^C

/Chess

[Chess Norris]

Any tips on how to troubleshoot why the mapping of IP's not beeing delivered from FMC to FTD?

I can add that I have configured ISE with an PassiveIDAgent using the MS-RPC protocol (I was testing with WMI as well, but newer got that to work). The agent was then pushed to the AD server from ISE

Thanks

/Chess

[Mohammed al Baqari · Accepted solution]

Hi,

The problem in your case that users are not downloaded from FMC to FTD hence it returned user 9999999 in the identity lookup. FTD isn't able to send the events to FMC with user identity. So we need to troubleshoot that part. 

Cross check again that the correct identity policy is assigned to the matched ACP. Also, make sure that the correct ACP is matched (not another ACP or prefilter rule). 

On the FTD, there are other commands you can do but I strongly recommend you contact TAC to avoid damaging your FTD. For reference, in FTD with expert mode, run OmniQuery.pl. Next, run select * from user_identities; and select * from user_group; to see if anything received from FMC.

**** please remember to rate useful posts

[Chess Norris]

Thank you!!! Your suggestion lead me to finally pinpoint the issue.

I tested the OmniQuery querys on my lab FTD and could see that the FTD actually had both users and groups. However this specific user that I used for testing this, was not found. I then created another AD user and now I could see the IP/user mapping with the user_map_query.pl -i 10.46.0.66 command on the FTD. I also checked the FMC event log and YES!!!, I can now see the user ID  

Not sure why it didn't work with the other user, but it's probably related to the group the user was in.

Anyway, thank you again. I can now go on and implement this for my customer who requested this feature.

Thanks

/Chess