Issues with Identity Awareness - some users are not seen and some traffic is incorrectly marked

[columb]

Hello,

I need to deploy IA across few firewalls in order to replace statically assigned IPs with IA-based rules.

For the record I'm running 80.30 Take 50 across all of our firewalls.

I have 4 collectors and they seems to be talking fine to my Gateways.

I have done some investigation on the PDP/PEP and connectivity to the AD - or, actually, Collectors. Long story short I think we can summarise our issue in 2 separate points:

1. Some users are not being recognised as a AD users by PDP. Or they are "lost"
2. Some traffic is marked as initiated by the users but that’s not the case at all as user just logged on to the server. Traffic is not generated by them. I will explain below exactly what I mean by that.

In terms of problem number 1:

1. My user (one of many!) is not to be seen by PDP/PEP daemons.
1. I have 2 devices (laptop/PC) and I have logged on to both of them today. I have also done full reboot of my PC and I had confirmation that my trust with the AD was established, all of the log on scripts were run correctly.
2. My user was recognised before – I have logs to prove this
3. Some other users were recognised before but they are not now (for example my colleague who sits right next to me – I could see his username yesterday but not today. He has definitely logged on to this PC multiple times today)
4. Sometimes I can see user but NOT IP associated with that user
5. Looking at the "Logs & Monitor" tab in SMS Console I can see events related to the "Log in/log out" however looking at "pdp monitor user" I can see user within PDP/PEP

Problem 2 manifests itself by marking traffic between servers as USER TRAFFIC.

Here is a specific scenario of what happens:

• Server is sending syslog messages to another server (and this traffic is seen correctly)
• User A logs in to the server and performs some operations NOT RELATED to the syslog (for example looking at the DHCP configuration)
• From that point on server marks traffic as sent by the user and goes against user’s ACLs.
• Only Syslog traffic (514) seems to be marked as the user's traffic.

Needless to say that both issues would be a showstoppers to implement this into PROD environment.

Please see some details about our setup – I have created a quick script to give us one-page summary about most important features of PDP:

Now, users and machines numbers are taken from this grep:

pdp monitor summary all | grep -c "[u]"

 Thank you in advance for your help. I'm not sure what I could be looking into. I do have case open with our 1st line support (before we hit TAC) but that's slow to progress so I'm hoping I can get some help from "the experts in the field"

Cheers

Chris

[PhoneBoy]

The first issue most likely requires investigation with the TAC.

The second issue, I’m afraid, is normal, as once the user logs into the server with an AD user, their username will be associated with the IP of the server.
It may be possible to filter that somehow.

[Kaspars_Zibarts]

Ok

for issue #1 I suspect that there is another user that logs onto your machine after you had logged onto it. Could be some AD service account for example. The best you can do is check for all IA associated logs with that specific IP, for example use filter

x.x.x.x and blade:"Identity Awareness"

Go through logs and see what's going on. Can be quite tricky to see the issue but usually you can see it there. For us it was "two" user problem per IP, i.e if you log in with a regular account "user1" and get your IP association  and later run something on your machine with admin account "admin1" then IA will swiftly move IP association from user1 to admin1

for the issue #2, you may exclude your server networks from IA completely in IDC. Give it a go!

[Chris_Atkinson]

As above excluding networks or service accounts may help, some scenarios can only be overcome using the Identity Awareness Agent/s however.

[Timothy_Hall]

Just another note about #1, when using the Identity Agents in conjunction with Identity Sharing I've seen some issues where user mappings get "lost" or don't get propagated correctly between different gateways.  What seemed to help was disabling Identity Sharing completely, then having the Identity Agents directly send the identities to all the involved gateways instead of having them share with each other.

As for #2 I'd agree with the other posters, you are probably going to have to deploy the Identity Agent to the involved systems to make that work the way you want.

[columb]

Hello,

First of all many thanks to you all for your input. Much appreciated! Since posting this question I had my call with TAC and we are one step closer to get this working.

In regards to issue #1 it looks like we are missing events 4624, 4768, 4769. SK99006 says how the policy should be configured (and it is!) but we are still not getting them 😞 Obviously we need to look closer what else could be an issue here. Any help with this would be more than appreciated.

Thank you all for tips around issue #2 - I will set up some filters and see how it goes.

Thanks all!

Cheers

Chris

[Juraj_Skalny]

Hello Chris,

Unfortunately there is no better way for Identity Based Access Rules than to go with Identity Agents.

Even when you sort your two issues you will hit another one in case you have wire/wireless users in your organization.

Imagine wired user correctly mapped already on PEP level with IP address.

Identity Based Access Rule is correctly reinforced and life is good.

Then what happens when our wired user goes to the meeting room with laptop and connects to Wi-Fi.

User gets different IP address from local DHCP server.

This information is however not propagated over to Domain Controller instantly as no communication with DC takes place.

Consequently this info doesn't get through to your Identity Collector

And finally this info  doesn't get through to your PDP and ultimately PEP firewall will drop the traffic as new IP address is not mapped with allowed user yet.

New IP to user mapping happens at the end of the day but user needs to sit in the meeting room waiting for his laptop to talk to DC. Or lock the screen. Or reboot the laptop. Then all propagates down the stream over to PEP very quickly. Imagine asking every user to do this.

I wish Identity Collector way for IA blade would be enough but is not in my experience. Unless Im missing something here.

Please correct me anyone if I m wrong here.

Thanks,

Juraj

[Timothy_Hall]

As @Juraj_Skalny said, roaming users can be a problem and the Identity Agent can help solve it.  Roamers can also sometimes get remapped automatically with Transparent Kerberos Authentication via the captive portal, but this can be tricky to get working consistently in most customer environments. 

[Kaspars_Zibarts]

It works for us actually as normally you lock/unlock laptop and that triggers AD event that's passed onto IDC and new wifi address gets reflected. For sure it's not the fastest and more reliable ways but it seems to cover some non-critical services quite OK