Identity Awareness issue

[Ryan_Ryan]

Hi all,

Having a lot of trouble getting IA working on terminal servers.

I have the agent installed, it shows connected, it shows the username as authenticated. I go to smartlog, I can see a login event with the correct username and server name in the IA blade. I can also see my traffic is coming through with the correct source port range, however no username is shown in the logs and traffic is not matched against my IA rules.

I don't think this is the issue, but we have two gateways, one is configured with terminal servers and is set to share with the other, I can see the user through "pdp monitor" on the gateway and I can see its published to the other gateway, (I cannot see the pdp monitor on the other gateway - but i don't think I should be able to ) However traffic hitting both gateways comes without any source username in the log fields.

AD query is working perfectly (username shows in the logs) and terminal server agent *was* working at some stage but its been extremely flakey and now its not working at all. 

Any ideas where I should start looking?

[PhoneBoy]

The FAQ for the Identity Agent for Terminal Servers: Identity Awareness Support for Terminal Servers - FAQ 

I would first check to see if there is a connection between the agent on the terminal server and the gateway using the command pdp connections ts

[Ryan_Ryan]

Hi Dameon, yes if I run pdp connections ts i can see my two terminal servers listed in the output.

If I run pdp monitor user I see myself authenticated against one of the IPs and a member of the roles.

[Kaspars_Zibarts]

Just curious what does pep CLI output shows for your user and IP? Do you see role associated with IP and username? Since pep actually will do policy enforcement..

pep s u q cid (IP)

pep s u q usr (username)

I'm 99% sure syntax is correct, not working so can't check  and we never played with TS agent I must admit so I'm not entirely sure about pep behaviour when many users must be associated with a single IP. 

[Roman_Niewiado1]

Did you already install the IA Hotfix fw1_wrapper_HOTFIX_giraffe_v3_GA_FULL.tgz ?

Identity Awareness enhancements for R77.30 - Giraffe Hotfix 

[Ryan_Ryan]

Hi guys, thanks for all the responses.

In an unrelated issue, i had to reboot the firewall, after rebooting everything worked perfectly. 1 day later, its stopped working again. 

I have not installed that IA patch, but I guess I will if it will help

pep s u q cid (IP)

- shows the client username and access roles listed

pep s u q usr (username)

- shows the test machine IP and access roles 

smartview tracker shows a drop with no username listed in the field, smartview tracker also does show the logon event for that username. I can confirm the source port is also showing int he correct range. 

Any ideas here Im starting to lose my mind now

[Kaspars_Zibarts]

Out of curiosity - when it stopped working and you checked pep s u q cid command - how many users did you see associated with that IP? Was it only one or more?

Also - do you happen to run multiple user IDs on your machine? As in you use one general user ID  to log in but then run some apps as another user?

In any case - have you opened service request?

[Ryan_Ryan]

Hi there,

When its not working, I can see 9 users connect with that command, when it has been working, I still see multiple users connected aswell. 

And no we don't keep multiple user ID's, we log in and don't run as with any other accounts.

There is one oddity, after installation of the MUH agent, if I go into "C:\Program Files (x86)\CheckPoint\Identity Agent" and double click "IdentityAgent.exe" nothing happens, I do not get the window popup, nor do I see a taskbar icon (show taskbar icon is enabled in global properties). In order to see the MUH agent window, I double click the installer file again which shows it running/connected with the user list etc. Reason why I wasn't too concerned about this was I did the install on 2 on domain PC's and one completely separate sandbox machine and all 3 showed the same behaviour. (without opening the file, MAD service is running) - so I don't think that that is an issue. 

I have yet to log a ticket, was hoping it was something that happens to everyone  

[Kaspars_Zibarts]

If it's only "under construction" service, as in you can play with it, try purging all pep/pdp tables and restart pepd/pdpd daemons. Then log in with your test machine / user and see if it works. If it does, log in with more user IDs from the same IP / TS and see if it stops eventually. Then it would be MUH related problem somehow

To generate table purge commands you can use this oneliner

fw tab -s | egrep ' pep| pdp' | awk '{print "fw tab -t "$2" -x -y"}'

At the end restart both processes

fw kill pepd

fw kill pdpd

I have run this fairly often on large live deployment when IA gets "stuck" so there is no real danger to affect anything else apart form IA

[Ryan_Ryan]

thanks for that, tried it out, ran the command,s logged out, logged back in, the username showed back up in the pep database, saw the login event in tracker, yet still did not match any rules and the log message in tracker still doesn't show a username.

I guess at this stage I will log a ticket, I'm out of ideas!

I got the MUH client off the firewall, is there a "latest" version I can download somewhere from the Internet?

[Kaspars_Zibarts]

I would open an SR. Royi Priov‌ - any ideas?  sorry to drop you in...

[Royi_Priov]

Thanks for tagging me Kaspars Zibarts‌

Hi Ryan Ryan‌,

The fact that the logs are not written with the correct username and the enforcement is not correct, should point us to the PEP process.

I understand from reading in the above thread that you do see the user listed in "pep show user query cid".

Please verify the following and let us know where it fails:

1. Check that the relevant traffic does arrives to the PEP with the correct port (which is part of this user port pool).

2. Check that no other identity source (e.g. AD Query) is reporting the same IP to the PEP. If it does, it should be excluded.

3. Check that pep_client_db and pep_src_mapping_db kernel tables are equal:

# fw tab -t pep_client_db -t pep_src_mapping_db -s

Thanks,

Royi Priov, Identity Awareness R&D.

[Ryan_Ryan]

Hi Royi,

appreciate your time and repsonse

*Login with user account to the machine*

pdp monitor user
- shows my user and tcp port allocations

pep show user query cid
-shows my username and Ia roles

pep show user query usr
- shows my user, the IP and Access roles


initiate web traffic, logs show my source port as: 63650
- pdp monitor user shows:
Tcp Ports: <trimmed>63625-63656;

[Expert@FW]# fw tab -t pep_client_db -t pep_src_mapping_db -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost pep_client_db 275 2817 3050 0
localhost pep_src_mapping_db 278 1592 1739 0

You may have eluded to something very important however, yes we also run AD query, and no I have not excluded this machine from it, I will give that a try, is there anyway to tell if that is causing the issue?

EDIT** have excluded this sever by IP address from AD query on all devices doing AD Query, restarted the pdp and pep process after flushing the tables but has not seemed to make any difference

Also I don't see a way to show my allocate tcp ports with a pep command (only pdp) should I be able to see this?

Regards

[Royi_Priov]

Having the same identity reported by 2 identity sources (in this case, TS agent and ADQ) is always not a good idea.

Q: "Also I don't see a way to show my allocate tcp ports with a pep command (only pdp) should I be able to see this?"

A: No, you should not see this. this information is not presented on pep outputs.

I suggest you to open ticket with TAC, as probably there is a need to run kernel debugs to understand what is the response to the identity query on the kernel.

Thanks,

Royi Priov, Identity Awareness R&D.

[Ryan_Ryan]

Just an update to this case, I installed take 317 as it includes the Giraffe hotfix now, since that was installed, the MUH agent has been working flawlessly for 4 days! Seems like its all resolved now.

[Royi_Priov]

That's great, thanks for the update.

Thanks,

Royi Priov, Identity Awareness R&D.