Alright experts, I need some assistance because this isn't making a lick of sense. I have a customer running FMC 6.2.2 and AD User Agent 2.3 that is having an issue where a lot of their connection events are showing Unkown under Initiator User. Some users show their AD accounts but most do not. The site is not using a proxy server and from my understanding this was working previously before the AD admin changed the rights of the user that was configured for the AD User Agent. He configured the user according to this document:
As it sits, I'm going to see if we can test with an AD domain admin account just to see if it produces the same result. I'm wondering if any of you have seen this behavior?
Check out this trouble shooting guide.
So I did some more testing and can see one of the users I'm having the issue with log in. Yet, when we do a test that hits a policy that should allow him through based on his ID it fails. When I go to look at the event it still shows "unknown user" even though it shows his ID under Analysis>User>User Activity. It's almost like it's not correlating that Initiator User and the Initiator IP.
Correct me if I'm wrong, but it looks like you're just doing passive authentication. If that's the case, then you will see A LOT of unknown user activity. This is because the system will only identify users when it is able to passively ID them through the identity policy you've setup. Passive authentication through AD user agent has always been iffy for us, so we've never set internal policies based on user groups. I've been told and have seen demos of it working MUCH better with Cisco ISE and AnyConnect as 802.1x agent. It's also worth noting that you can have that User Agent on up to 5 domain servers, which could also help. I personally have only gotten the user-based control to work with the remote VPN users, since they're actively authenticated.
So I was finally able to get a TAC engineer to work on the issue and after about 4 - 5 hours he was able to get the issue resolved I believe. I know there was a bunch of hocus pocus he was doing in the CLI, but we believe the gist of the issue is that we had a second authentication realm that was causing issues even though it was inactive. Once we removed that and gave it some time (about 24 hours) we were seeing the correct users versus either stale entries or Unknown.
I would suggest if experiencing this issue, check if there's an inactive realm and remove it and/or open a TAC case.
I have the same problem on one of our clients and was solved by TAC.
I'm going to post how we can identify this problem, but the solution sould be aplied by TAC. They used scripts to directly modify records on snort DB.
If you can identify the problem, TAC can apply the scripts in a few minutes webex session.
"User activity" show all users
Only a few was matched by policy, as seen on events.
What he do, was to check user-ip map.
First, he created an script on manager and sensor, to see user-ip and user-group mappings.
============================== | Database | ============================== ##) IP Address [Realm ID] 1) ::ffff:10.x.x.x  2) ::ffff:10.y.y.y  3) ::ffff:10.z.z.z  ##) Group Name (ID) [realm: Realm Name (ID)] 1) Domain Users (6) [realm: xxx.local (2)] 2) Restringidos (25) [realm: xxx.local (2)]
============================== | Database | ============================== No IP Addresses ##) Group Name (ID) 1) Restringidos (25) 2) Domain Users (6)
Then, and this can be done before calling TAC, he checked the file with ip-user mappings.
The file was 40k on FSight and only a few bytes on sensor.
I figured out how it works. Sensor donwnload full file each 5min and make incremental updates on a separate file. So it has two, full, which should be same size as the file on manager, and a smallone.
Expert mode command: ls -halt /var/sf/user_enforcement/
SFR, not working:
root@SFR2:/var/sf/user_enforcement# ls -halt
-rw-r--r-- 1 root root 497 Mar 22 16:28 user_ip_map.1521735637
drwxr-xr-x 2 www www 4.0K Mar 22 16:21 .
-rw-r--r-- 1 root root 23K Mar 22 16:20 user_ip_map.snapshot.1521735637
-rw-r--r-- 1 root root 509 Mar 22 16:15 user_ip_map.1521734735
-rw-r--r-- 1 root root 20K Mar 22 16:02 user_ip_map.snapshot.1521734538
drwxr-xr-x 67 root root 4.0K Nov 29 2016 ..
Then, he created and run a second script, which clear the DB.
(I can't post the full script here)
After that, the file user_ip_map show almost the same size on SFR than FS (same command). And users become detected correctly.
Please rate if this info was helpfull