Complex User-ID Scenario... Ideas? Solutions?

[MRosloniec]

Hey all -

I work for a very large global organization.  Our design for User-ID is such that some locations can use the UID Agent, others can't - and so they use the Agentless, on-box UID.  One issue we have is that we have thousands of what we call "common" and "job" (or, process) accounts that some people use to access remote machines from their machine, map drives to remote machines with, and run local background processes with.

The problem is that when those accounts authenticate, to AD it's a successful login from the user's computer.  That being said, it overwrites their User-to-IP mapping in the firewall and things that they should have access to, they no longer have access to because the account that the Firewall thinks they're logged in as is blocked.  Since the UID Agent / Agentless does not accept / process wildcards, that put us into a management nightmare scenario...From everything I can find, just about our only option is to create a seriously large list of these accounts and maintain it.  It won't be so difficult from the UID Agent perspective because it's just a txt file with one entry per line, however, with many of our locations being Agentless, it presents one heck of a nightmare.

My question is - has anyone else come upon a similar scenario?  And, if so, how are you handling it?

Does anyone else have any other suggestions?  I thought that the Agent / Agentless could ignore users based on a group that I tell it to ignore but that also does not appear to be the case.. (One thought was to put all these accounts in a common group to use for this purpose).

Thanks a bunch!!

Matt

[pulukas]

Looking over the agent documentation again, I don't see any way you can prevent this behavior in the current tools.  The agent is directly reading the AD login information and using this to update the ip address associations.

There are some LDAP filtering ability on the firewall configuration for the purpose of browsing group names and contents.  But there does not seem to be any similar browse on the Agent to restrict updates.

Essentially, what you need is a way to exclude a portion of the AD tree from logging ip address updates at login.

I think you need to contact your Sales team and put in a feature request for this function.

[cstancill · Accepted solution]

From the description, this sounds like it may be an issue with monitoring server session reads. Just so I understand the flow, is the following correct?

1. User is logged into their workstation, and is correctly mapped to the IP of that workstation.
2. User maps a drive to a share on a server using different credentials and the mapping is updated based on that information causing an issue with the rule set.

In the above case, you can disable server session reads to resolve the issue. Please let me know if there is more to this.

[MRosloniec]

You are correct - we have server session read enabled.  Really I was enabling this to help provide more coverage (in case someone slipped past the AD logon) but, seeing as how it can cause this problem as I have outlined it may be best to disable it.  Thanks for the suggestion!  I will disable it and test it out some more.

[torm]

Hi Matt,

I've got a similar scenario at one of my customers. Did disabling the server session read help you, or did you come up with a different solution?

In my case, I also want to ignore events from admin and service accounts that actually creates entries in the security logs on the DC, so disabling server session read won't be a good enough solution for me.

Any input would be appreciated!

- Tor

[gwesley]

The 7.0.3 agent now supports wildcards in the ignore_user_list.